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?
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
Zitat von: Grml am 26 Mai 2019, 00:03:55
Habe ich event-min-interval nicht verstanden? Habe ich einen groben Denkfehler?
Tatsächlich:
Zitat von: CommandRefEin 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.
auch wenn FHEM oder mosquitto neu startet hast du das gleiche problem
Gesendet von meinem SM-J510FN mit Tapatalk
Naja... dieses Problem hat aber einfache Lösungen. Es reicht ein simpel "at"
Ä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?
@Grml
Zitat
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).
Zitat
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.
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
Zitat von: OdfFhem am 26 Mai 2019, 00:52:17
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.
Zitat von: OdfFhem am 26 Mai 2019, 00:52:17Bedeutet 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.
Zitat von: Grml am 26 Mai 2019, 00:42:48
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"
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
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
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:
Zitat
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
Zitatalso 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]
Zitat2019-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? ;)
Zitat von: MadMax-FHEM am 26 Mai 2019, 11:57:53
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.
Zitat von: amenomade am 26 Mai 2019, 12:06:05
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 ;-)
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...
Zitat von: OdfFhem am 26 Mai 2019, 00:52:17
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