HM-MOD-Em-8 - wie funktioniert eventFilterTime ?

[pwlr]

Moin,
ich steh gerade auf dem Schlauch, vielleicht kann jemand helfen ?

Ich möchte bei einem Kanal eines HM-MOD-Em-8 die eventFilterTime nutzen und habe das Register dazu testweise auf 600 Sekunden gesetzt. Sinn der Sache ist, dass der Kanal nach einem gesendeten Eingangssignal anschließend für 600 Sekunden nicht mehr sendet, auch wenn weitere Signale an TA1 kommen. Also eine Kanalsperre für 600 Sekunden.

Ist das Funktionsprinzip so richtig ?

In der Praxis (bei mir) sind keine Einflüssen des Registers eventFilterTime auf die Funktion erkennbar. Jeder Eingangsimpuls an TA1 wird gesendet.

List vom Device

Code Auswählen Erweitern

  DEF        31313F
   HMLAN1_MSGCNT 126
   HMLAN1_RAWMSG E31313F,0000,19FFE443,FF,FFD4,26A24131313F123ABC0119C8
   HMLAN1_RSSI -44
   HMLAN1_TIME 2018-01-21 02:07:25
   HMLAN2_MSGCNT 68
   HMLAN2_RAWMSG E31313F,0000,1A43BC2C,FF,FFA0,26A24131313F123ABC0119C8
   HMLAN2_RSSI -96
   HMLAN2_TIME 2018-01-21 02:07:26
   IODev      HMLAN1
   LASTInputDev HMLAN2
   MSGCNT     194
   NAME       HM_31313F
   NOTIFYDEV  global
   NR         855
   NTFY_ORDER 50-HM_31313F
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HM_31313F_Btn_01
   channel_02 HM_31313F_Btn_02
   channel_03 HM_31313F_Btn_03
   channel_04 HM_31313F_Btn_04
   channel_05 HM_31313F_Btn_05
   channel_06 HM_31313F_Btn_06
   channel_07 HM_31313F_Btn_07
   channel_08 HM_31313F_Btn_08
   lastMsg    No:26 - t:41 s:31313F d:123ABC 0119C8
   protCmdDel 5
   protLastRcv 2018-01-21 02:07:26
   protNack   1 last_at:2018-01-21 02:01:58
   protSnd    121 last_at:2018-01-21 02:07:25
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:126 max:-39 min:-57 avg:-42.11 lst:-44
   rssi_at_HMLAN2 lst:-96 avg:-96.97 min:-104 max:-92 cnt:68

READINGS:
     2018-01-21 02:03:53   CommandAccepted yes
     2018-01-21 02:03:52   D-firmware      1.0
     2018-01-21 02:03:52   D-serialNr      LEQ1114385
     2018-01-21 02:03:56   PairedTo        0x123ABC
     2018-01-21 01:54:20   R-ledMode       on
     2018-01-21 01:54:20   R-localResDis   off
     2018-01-21 01:54:20   R-lowBatLimitBA2 0 V
     2018-01-21 01:54:20   R-pairCentral   0x123ABC
     2018-01-21 01:54:20   R-transmDevTryMax 3
     2018-01-21 02:03:56   RegL_00.          02:01 05:40 0A:12 0B:3A 0C:BC 12:00 14:03 18:00  00:00
     2018-01-21 01:54:04   alive           yes
     2018-01-21 02:07:25   battery         ok
     2018-01-21 01:54:04   powerOn         2018-01-21 01:54:04
     2018-01-21 01:54:04   recentStateType info
     2018-01-21 02:07:25   state           CMDs_done


List vom Kanal

Code Auswählen Erweitern

DEF        31313F01
   NAME       HM_31313F_Btn_01
   NOTIFYDEV  global
   NR         858
   NTFY_ORDER 50-HM_31313F_Btn_01
   STATE      0
   TYPE       CUL_HM
   chanNo     01
   device     HM_31313F
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1516496845.98898
           VALUE      open
   READINGS:
     2018-01-21 02:03:53   R-eventFilterTime 600 s
     2018-01-21 01:54:21   R-longPress     0.4 s
     2018-01-21 01:54:21   R-msgScPosA     closed
     2018-01-21 01:54:21   R-sign          off
     2018-01-21 01:54:21   R-transmitTryMax 3
     2018-01-21 01:54:21   R-triggerMode   sensor
     2018-01-21 02:03:56   RegL_01.          04:10 08:00 20:60 23:8A 30:03 92:21 00:00
     2018-01-21 02:07:25   contact         open (to vccu)
     2018-01-21 02:07:25   state           open
     2018-01-21 02:07:25   trigger_cnt     25
   helper:
     peerIDsRaw ,00000000
     regLst     ,1,4p
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     role:
       chn        1
     shadowReg:
     tmpl:
Attributes:
   DbLogInclude state
   comment    Testdevice
   devStateIcon 100:weather_rain_heavy@blue 0:weather_sun@red .*:message_attention@red
   event-on-update-reading state
   eventMap   closed:100 open:0
   expert     251_anything
   group      HM-MOD-Em-8
   model      HM-MOD-Em-8
   peerIDs    00000000,
   room       Test
   subType    threeStateSensor

Entweder stmmt meine Theorie nicht oder ich mach nen Fehler ...

Moin und schon mal Danke für Eure Hilfe !
Bernd

[Pfriemler]

es fällt mir gerade hochnotpeinlich auf, dass ich hier falsch lag. eventFilterTime ignoriert eigentlich alle kurzfristigen Änderungen am Eingang außer sie sind dann letztlich für diese Zeit stabil?

Weitere Meinungen?

[pwlr]

Schade...
ich hatte gehofft, mit den Infos aus dem "PIR-Thread" ein altes, offenes Problem elegant lösen zu können.

Allesdings, bei einer eingestellten Filterzeit von 600 Sekunden kommen meine kurzen Trigger (< 1 Sekunde) durch ? Die müssten dann doch als "Störimpuls" ignoriert werden - oder geht es bei der Filterei um die Flankensteilheit am Input (dann wäre die  zulässige Range allerdings viel zu groß). Sorry für die blöden Fragen, aber ich nix Ahnung - leider.

Ist der HM-MOD-Em-8 einigermaßen erforscht oder gibt es noch viele weiße Flecken ? Vielleicht muss man den Filter noch zusätzlich einschalten oder er funktioniert nur in einem anderen Mode ?

Bernd

[Pfriemler]

Du beziehst Dich auf diesen Thread?
Oder welchen?`

Ich habe jetzt mein übriges EM-8 rausgekramt und mit eventFilterTime herumprobiert. Es hat - egal ob es die Aussendung verzögern oder weitere Aussendugen unterbinden soll - schlicht null Effekt. Ich habe die Firmware 1.0, wie Du.

Kann das nochmal jemand anderes bestätigen oder dementieren? oldman aus dem o.g. Thread liefert mir hoffentlich Infos betreffs Firmware 1.1

Übrigens besitzt das Register "stabFltTime" beim Modul HM-MOD-EM-8bit im Datenkanal so oder so die gewünschte Eigenschaft, dort kann man sie auch konfigurieren, siehe Wiki-Artikel. Die Infos dort sind aber theoretisch und nicht wirklich verifiziert, aber zumindest so laut Doc von eQ3. Im Artikel unter Modus 5 und 7 beschrieben.

Nachtrag:
Das meine Kellerfenster überwachende EM-8 steht auf eventFilterTime 5s. Da kann ich im 2-Sekunden-Takt das Fenster auf- und zumachen und jedes Änderung wird umgehend gemeldet. Und dort ist Firmware 1.1 aktiv.

Da ist was faul.

Übrigens: Bei meinem Neigungssensor HM-SEC-TIS funktioniert das einwandfrei. Seit ich dort 4 Sekunden eingestellt habe, bekomme ich keine Statusänderungen mehr wenn der Ball gegen das Garagentor donnert und alles vibriert.

[pwlr]

Du beziehst Dich auf diesen Thread?
Oder welchen?`

Ja, dadurch bin ich erst wieder darauf gekommen. Ich hatte das Problem für mich schon vor einiger Zeit beerdigt und nun noch einmal probiert.

Test mit FW 1.1 (wie Du schon geschrieben hast) bei mir auch negativ. D.h. keine erkennbaren Auswirkungen von eventFilterTime.

Siehst Du irgendwie ne Chance ?

[Pfriemler]

Ich denke ich werde mal bei den Nachbarn nach deren Erfahrungen fragen und eine Anfrage an ELV schicken.
Martin könnte vielleicht auch nochmal drübersehen. Setzen und Auslesen lässt sich das Register ja klaglos, aber das wäre nicht das erste Mal, wenn das nicht sauber in der Firmware umgesetzt ist. Die scheinen die Module eh outgesourct zu haben, so lausig wie die laufen. Der Bug mit der Laufzeit beim Re-8 ist bis heute nicht gefixt. Wenn sie dann noch den Batteriesparmodus ausschaltbar machen könnten (Device benötigt keinen Burst), wäre das Modul ja ein Renner.
Aber das ist eine andere Baustelle.

[pwlr]

Danke, dass Du Dich darum kümmern willst !

Wenn ich helfen kann, sag Bescheid. Ich habe bloss überhaupt keine Ahnung vom Kommunikationsprotokoll und den anderen Internas. Bin mehr auf der Anwendungsebene aktiv, aber lerne gern dazu.

Moin
Bernd