Events beim Fensterkontakt HM-SEC-SCO

[Grml]

Hallo zusammen,
ich stehe gerade völlig auf dem Schlauch...

Mein Fensterkontakt scheint nur Events zu generieren, wenn wirklich was passiert (open/close). Trotz gesetztem "event-min-interval state:60".
Das ist für mich deshalb blöd, weil ich den aktuellen Status per MQTT an Node-Red weiterreiche um den Status eines Fenster darzustellen. Wenn aber Node-Red mal neu startet, kann es dann sein, dass es eben den aktuellen Status nicht mitbekommt.
Deshalb war mein Verständnis von event-min-interval das *auf jeden Fall* nach 60 Sekunden ein Event erzeugt wird, der den state schickt.

Aber schon im FHEM Event-Monitor passiert nichts.

Habe ich event-min-interval nicht verstanden? Habe ich einen groben Denkfehler? Oder schickt das Teil wirklich nur ein Update wenn sich der Status tatsächlich ändert?

Code Auswählen Erweitern

Internals:
   DEF        4FDD74
   FUUID      5c4adb72-f33f-b8cb-49ff-1f4214d37f532617
   HMLAN1_MSGCNT 64
   HMLAN1_RAWMSG E4FDD74,0000,821C5458,FF,FFBE,05A6414FDD7437A0F00194C8
   HMLAN1_RSSI -66
   HMLAN1_TIME 2019-05-25 23:33:48
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     64
   NAME       WinSensOptStudio01
   NOTIFYDEV  global
   NR         84
   NTFY_ORDER 50-WinSensOptStudio01
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:05 - t:41 s:4FDD74 d:37A0F0 0194C8
   protLastRcv 2019-05-25 23:33:48
   protRcv    64 last_at:2019-05-25 23:33:48
   protSnd    64 last_at:2019-05-25 23:33:48
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:64 min:-66 max:-58 avg:-61.18 lst:-66
   Helper:
     DBLOG:
       state:
         LogDB:
           TIME       1558818251.25289
           VALUE      open
   READINGS:
     2019-05-26 00:00:01   Activity        alive
     2016-11-09 11:49:50   CommandAccepted no
     2016-11-09 11:48:59   D-firmware      1.0
     2016-11-09 11:48:59   D-serialNr      NEQ1159416
     2018-03-12 12:34:20   PairedTo        0x37A0F0
     2016-11-19 19:21:59   R-cyclicInfoMsg on
     2016-11-19 19:21:59   R-eventDlyTime  0 s
     2016-11-19 19:21:59   R-pairCentral   0x37A0F0
     2016-11-19 19:21:59   R-sabotageMsg   on
     2016-11-19 19:21:59   R-sign          on
     2018-03-12 12:34:20   RegL_00.        02:01 09:01 0A:37 0B:A0 0C:F0 10:01 14:06 00:00
     2018-03-12 12:34:21   RegL_01.        08:01 20:9C 21:00 30:06 00:00
     2016-11-09 11:49:01   aesCommToDev    ok
     2016-11-09 11:49:01   aesKeyNbr       00
     2019-05-25 23:18:02   alive           yes
     2019-05-25 23:33:48   battery         ok
     2019-05-25 23:33:48   contact         open (to Area51.VCCU)
     2018-03-12 10:40:14   powerOn         2018-03-12 10:40:14
     2019-05-25 23:18:02   recentStateType info
     2019-05-25 23:18:02   sabotageError   off
     2019-05-25 23:33:48   state           open
     2018-10-11 08:03:43   trigDst_37A0F0  noConfig
     2019-05-25 23:33:48   trigger_cnt     148
   helper:
     HM_CMDNR   5
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +4FDD74,00,00,00
       nextSend   1558820028.20744
       prefIO     
       rxt        2
       vccu       
       p:
         4FDD74
         00
         00
         00
     mRssi:
       mNo        05
       io:
         HMLAN1:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLAN1
       flg        A
       ts         1558820028.11752
       ack:
         HASH(0x5642c6a22b90)
         05800237A0F04FDD740101C800
     rssi:
       at_HMLAN1:
         avg        -61.1875
         cnt        64
         lst        -66
         max        -58
         min        -66
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      HMLAN1
   actCycle   002:50
   actStatus  alive
   alarmDevice Sensor
   alarmSettings |WinSensOptStudio01:open|Fenster Studio|on
   alias      Fenster Studio
   autoReadReg 4_reqStatus
   devStateIcon closed:fts_window_1w open:fts_window_1w_tilt
   event-min-interval state:60
   expert     2_raw
   firmware   1.0
   icon       hm-sec-win
   model      HM-SEC-SCO
   mqttPublish state:topic={"$base/$device/$name"} state:retain=0
   peerIDs    00000000,
   room       Studio
   serialNr   NEQ1159416
   subType    threeStateSensor

[amenomade]

Habe ich event-min-interval nicht verstanden? Habe ich einen groben Denkfehler?

Tatsächlich:

Ein Event wird nur dann generiert, falls seit dem letzten Auftreten des gleichen Events mindestens minInterval Sekunden vergangen sind.

Ziel von event-min-interval ist, die Anzahl von Events zu reduzieren.

[knopf_piano]

auch wenn FHEM oder mosquitto neu startet hast du das gleiche problem

Gesendet von meinem SM-J510FN mit Tapatalk

[amenomade]

Naja... dieses Problem hat aber einfache Lösungen. Es reicht ein simpel  "at"

[Grml]

Äh, ok. Aber das ist ja was ich möchte (glaube ich ).
Wenn mein Fenster um 22:00 "open" war, soll (bei state:60) um 22:01 wieder ein Event ausgelöst werden (nämlich mit dem state "open"). Für den (erstmal theoretischen Fall das in der Zwischenzeit Node-Red neu gestartet wurde und erstmal "denkt" das Fenster sei "closed").

Was wäre denn der korrekte Wert, dass ohne tatsächliche Statusänderung (open/close) alle xx Sekunden/Minuten/Stunden ein Event generiert wird?

[OdfFhem]

@Grml

Deshalb war mein Verständnis von event-min-interval das *auf jeden Fall* nach 60 Sekunden ein Event erzeugt wird, der den state schickt.

Wenn ein Reading aktualisiert wird, wird nach 60 Sekunden ein Event generiert - egal, ob sich der Wert des Readings durch die Aktualisierung geändert hat oder nicht. Bedeutet umgekehrt: schickt das Gerät keinen Wert, wird auch kein Event erzeugt; FHEM erzeugt nicht von alleine ein Event.

Das maximale Akrualisierungsintervall für den Fensterkontakt beträgt übrigens 2 Stunden und 50 Minuten (actCycle).

Wenn aber Node-Red mal neu startet, kann es dann sein, dass es eben den aktuellen Status nicht mitbekommt.

Hier würde ich eher auf die MQTT-Features zurückgreifen und nicht unnötig viele Nachrichten generieren - s. retain-Flag.

[knopf_piano]

warum wird nodered neu gestartet?
das problem ist schwer lösbar. wie willst du was anzeige, wovon du nicht mitbekommen hast, dass es passiert ist? dein trigger ist ansonstenn ein zyklisches at mit getStatus bzw ReadingVal o.ä.
bzw. trigger dieses getStatus, nachdem nodered wieder alive ist. setzt aber voraus, das FHEM den Wechsel gesehen hat.

Gesendet von meinem SM-J510FN mit Tapatalk

[amenomade]

Wenn ein Reading aktualisiert wird, wird nach 60 Sekunden ein Event generiert - egal, ob sich der Wert des Readings durch die Aktualisierung geändert hat oder nicht.

Falsch! Durch event-min-interval wird kein weiteres Event nach 60 Sekunden erzeugt, nur inzwischen die mögliche nachfolgende Events unterdruckt.

Bedeutet umgekehrt: schickt das Gerät keinen Wert, wird auch kein Event erzeugt; FHEM erzeugt nicht von alleine ein Event.

Stimmt. Fhem erzeugt nicht von alleine ein Event. Mit event-min-intervall aber auch nicht, siehe oben.

Wenn mein Fenster um 22:00 "open" war, soll (bei state:60) um 22:01 wieder ein Event ausgelöst werden (nämlich mit dem state "open"). Für den (erstmal theoretischen Fall das in der Zwischenzeit Node-Red neu gestartet wurde und erstmal "denkt" das Fenster sei "closed").

Ich würde einfach ein DOIF statt den Fensterkontakt in MQTT "publishen"

Code Auswählen Erweitern

defmod difenster DOIF ([Fenster] eq "opened")() DOELSE
attr difenster cmdState opened|closed
attr difenster event-on-update-reading state
attr difenster repeatcmd 10:5
attr difenster repeatsame 3:6

Wenn "Fenster" auf "opened" geht, wird im Abstand von 10 Sek. 3 mal ein Event "open" beim DOIF generiert
Wenn "Fenster" auf "closed" geht, wird im Abstand von 5 Sek. 6 mal ein Event "closed" beim DOIF generiert

Code Auswählen Erweitern


2019-05-26 11:36:22 DOIF difenster opened
2019-05-26 11:36:32 DOIF difenster opened
2019-05-26 11:36:42 DOIF difenster opened

2019-05-26 11:37:02 DOIF difenster closed
2019-05-26 11:37:07 DOIF difenster closed
2019-05-26 11:37:12 DOIF difenster closed
2019-05-26 11:37:17 DOIF difenster closed
2019-05-26 11:37:22 DOIF difenster closed
2019-05-26 11:37:27 DOIF difenster closed

[MadMax-FHEM]

Hallo,

also ich habe ja auch die Fensterkontakte und die liefern bei cyclicInfoMsg on (wie hier gesetzt) immer wieder den Zustand (auch ohne Änderung).

Mich stört das, ich will nur Events, wenn sich der Zustand auch geändert hat, daher habe ich event-on-change-reading gesetzt...

Es kommen auch Zustandsnachrichten vom Gerät:

     2019-05-25 23:33:48   battery         ok
     2019-05-25 23:33:48   contact         open (to Area51.VCCU)
     2019-05-25 23:33:48   state           open

Die sollten in regelmäßigen Abständen kommen und wenn keine "event-irgendwas" gesetzt ist auch "durchschlagen" und Events generieren (ist zumindest bei mir so).

Anmerkung: actCycle hat NICHTS damit zu tun wann das Gerät etwas schickt! Das ist der Zyklus wann/wieoft der ActionDetector prüft, ob das Gerät "noch lebt"... Und dann den Status/Zustand alive/dead/... setzt...

Also entferne doch mal das event-min-interval und schaue im EventMonitor (Filter auf das Gerät setzten), da sollten Events mit open/close kommen, auch wenn du nicht auf/zu machst...

Gruß, Joachim

[amenomade]

also ich habe ja auch die Fensterkontakte und die liefern bei cylicMessageInfo on (wie hie gesetzt) immer wieder den Zustand (auch ohne Änderung).

Bei mir auch. Aber ich bin davon ausgegangen, dass der Abstand ihm nicht gefällt. Wenn es doch passt, dann ist deine "Lösung" natürlich... besser (standard).[/quote]

2019-05-25 23:33:48   contact         open (to Area51.VCCU)

Oha! Hast Du auch in Area1, Area2,... Area 50 jeweils eine VCCU? Oder hat es wirklich mit den Aliens zu tun?

[Grml]

Hallo,

also ich habe ja auch die Fensterkontakte und die liefern bei cyclicInfoMsg on (wie hier gesetzt) immer wieder den Zustand (auch ohne Änderung).

Mich stört das, ich will nur Events, wenn sich der Zustand auch geändert hat, daher habe ich event-on-change-reading gesetzt...

Es kommen auch Zustandsnachrichten vom Gerät:

Die sollten in regelmäßigen Abständen kommen und wenn keine "event-irgendwas" gesetzt ist auch "durchschlagen" und Events generieren (ist zumindest bei mir so).

Anmerkung: actCycle hat NICHTS damit zu tun wann das Gerät etwas schickt! Das ist der Zyklus wann/wieoft der ActionDetector prüft, ob das Gerät "noch lebt"... Und dann den Status/Zustand alive/dead/... setzt...

Also entferne doch mal das event-min-interval und schaue im EventMonitor (Filter auf das Gerät setzten), da sollten Events mit open/close kommen, auch wenn du nicht auf/zu machst...

Gruß, Joachim

Ohne event-min-interval kommen die schon. Aber halt nur sehr selten. Zu selten für mich bzw um eine verlässliche und einigermaßen aktuelle Darstellung in Node-Red zu erreichen.

[Grml]

Bei mir auch. Aber ich bin davon ausgegangen, dass der Abstand ihm nicht gefällt. Wenn es doch passt, dann ist deine "Lösung" natürlich... besser (standard).
Oha! Hast Du auch in Area1, Area2,... Area 50 jeweils eine VCCU? Oder hat es wirklich mit den Aliens zu tun?

Hausnummer 51

[Grml]

Danke erstmal für eure Beiträge. Bin gerade noch unterwegs und werde mir das später genauer anschauen. Die Lösung mit dem DoIf scheint mir ein Weg zu sein...

[MadMax-FHEM]

Hier würde ich eher auf die MQTT-Features zurückgreifen und nicht unnötig viele Nachrichten generieren - s. retain-Flag.

Dazu würde ich auch raten, sollte ja genau für diesen Zweck da sein!?

Wenn fhem neu gestartet wird und du das Fenster öffnest/schließt (während fhem noch startet) hast du auch das Problem und dahilft eigentlich nur ein erneutes Senden des Gerätes selbst...
...hierfür muss dir dann wohl das Sendeinterval des Gerätes genügen.

Gruß, Joachim