Hallo,
Ich habe einen Eltako FRW Rauchmelder schon länger in fhem. Heute habe ich einen fhem update gemacht, seither werden die Status Telegramme, die der FRW alle 20 Minuten sendet, wohl nicht mehr empfangen. Bei Auslösen eines Testalarms kommen Telegramme an.
Im svn habe ich mir das Diff zwischen rev13422 und rev12565 angesehen (ohne das inhaltlich zu verstehen), aber es hat sich wohl irgendwas im Umfeld der EEP F6-05-02 geändert:
"F6.04.01" => {attr => {subType => "keycard"}, GPLOT => "EnO_keycard:Keycard,"},
359 351 #"F6.04.02" => {attr => {subType => "keycard.02"}, GPLOT => "EnO_keycard:Keycard,"},
360 "F6.05.00" => {attr => {subType => "windSpeed.00"}},
361 352 "F6.05.01" => {attr => {subType => "liquidLeakage"}, GPLOT => "EnO_liquidLeakage:LiquidLeakage,"},
362 "F6.05.02" => {attr => {subType => "smokeDetector.02"}},
363 353 "F6.10.00" => {attr => {subType => "windowHandle"}, GPLOT => "EnO_windowHandle:WindowHandle,"},
364 354 #"F6.10.01" => {attr => {subType => "windowHandle.01"}, GPLOT => "EnO_windowHandle:WindowHandle,"},
... ...
374 364 "N5.38.08" => {attr => {subType => "gateway", comMode => "confirm", eep => "A5-38-08", gwCmd => "switching", manufID => "00D", model => "TF", teachMethod => "confirm", webCmd => "on:off"}},
375 365 "G5.ZZ.ZZ" => {attr => {subType => "PM101", manufID => "005"}, GPLOT => "EnO_motion:Motion,EnO_brightness4:Brightness,"},
376 "L6.02.01" => {attr => {subType => "smokeDetector.02", eep => "F6-05-02", manufID => "00D"}},
366 "L6.02.01" => {attr => {subType => "FRW", eep => "F6-02-01", manufID => "00D"}},
Muss ich an meiner Device Definition was anpassen ? Ich habe prinzipiell auf allen Funk-Devices einen Watchdog, damit ich einen Device-Ausfall mitbekomme. Der funktioniert jetzt natürlich nicht mehr ....
Meine Definition ist (schon seit Monaten):
defmod FRW_DG EnOcean 01A36A63
attr FRW_DG IODev TCM_ESP3_0
attr FRW_DG alias RauchmelderDG
attr FRW_DG devStateIcon off:secur_smoke_detector@green smoke-alarm:secur_smoke_detector@red
attr FRW_DG eep F6-02-01
attr FRW_DG group contact
attr FRW_DG manufID 00D
attr FRW_DG stateFormat alarm
attr FRW_DG subType FRW
attr FRW_DG teachMethod RPS
Grüße, gadget
Die periodischen Telegramme des Rauchmelder werden jetzt vom fhem Profil selbst überwacht. Es werden deshalb nur noch Events ausgegeben, falls diese periodischen Telegramme ausbleiben oder sich der Status des Rauchmelders ändert. Die fhem Watchdog wird nicht mehr benötigt und funktioniert in der bisherigen Form nicht mehr. Bitte bei Bedarf das Reading "alarm" überwachen.
Hallo,
ok - danke für die schnelle Info.
In der commandref habe ich gerade noch gesehen:
"Set attr subType to smokeDetector.02 manually." und habe das jetzt auch noch angepasst. Sollte evtl. noch im Wiki geändert werden, da steht noch FRW und eine andere EEP (F6-02-01 statt F6-02-02)
https://wiki.fhem.de/wiki/EnOcean-FRW-Rauchmelder (https://wiki.fhem.de/wiki/EnOcean-FRW-Rauchmelder)
Grüße, gadget
Hallo,
ist das mit dem internen Monitoring wirklich sauber implementiert und getestet ? Mein FRM steht jetzt seit heut früh auf "dead_sensor", obwohl der offenbar laufend sendet:
list FRW_DG
Internals:
CHANGED
DEF 01A36A63
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 100
NAME FRW_DG
NR 562
NTFY_ORDER 50-FRW_DG
STATE dead_sensor
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 100
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -54
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 1
TCM_ESP3_0_SubTelNum 12
TCM_ESP3_0_TIME 2017-03-20 18:04:19
TYPE EnOcean
Readings:
2017-03-20 07:40:29 alarm dead_sensor
2017-03-19 20:13:46 battery ok
2016-11-13 17:39:10 buttons released
2016-11-13 17:39:08 channelA AI
2017-03-19 20:13:46 state off
2016-11-13 17:39:08 teach RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID
Helper:
lastEvent 0
alarmTimer:
HASH(0x38ebdd0)
alarm
dead_sensor
1
5
Attributes:
IODev TCM_ESP3_0
alias RauchmelderDG
devStateIcon off:secur_smoke_detector@green smoke-alarm:secur_smoke_detector@red
eep F6-02-02
group contact
manufID 00D
room Alarmanlage
stateFormat alarm
subType smokeDetector.02
teachMethod RPS
verbose 5
Sprich: Der hat doch lt. TCM_ESP3_0_TIME zuletzt um 18:04 Uhr ein Lebenszeichen von sich gegeben, trotzdem steht der seit 07:40 Uhr auf "dead sensor" ...
Grüße, gadget
Ist fhem wirklich per "update" auf dem aktuellen Stand? Ein ähnliches wie das beschriebene Problem wurde letztlich gemeldet und korrigiert.
Hallo,
Hatte Samstag update gemacht. Jetzt grad noch mal, waren nur noch einige wenige Changes in Modulen die ich nicht einsetze. Nach dem fhem Neustart ist der FRW jetzt erst mal wieder auf "ok" - Ich beobachte ...
Danke schon mal,
gadget
Edit nach 12 Stunden: Bislang keine dead sensor Falschmeldungen mehr
Hallo,
Fazit nach einigen Tagen: Sporadische Fehlalarme ca. alle 2 Tage bezügich "dead sensor":
list FRW_DG
Internals:
CHANGED
DEF 01A36A63
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 266
NAME FRW_DG
NR 562
NTFY_ORDER 50-FRW_DG
STATE dead_sensor
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 266
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -54
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 1
TCM_ESP3_0_SubTelNum 11
TCM_ESP3_0_TIME 2017-03-24 12:39:20
TYPE EnOcean
Readings:
2017-03-24 12:02:40 alarm dead_sensor
2017-03-20 21:39:44 battery ok
2016-11-13 17:39:10 buttons released
2016-11-13 17:39:08 channelA AI
2017-03-20 21:39:44 state off
2016-11-13 17:39:08 teach RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID
Helper:
lastEvent 0
alarmTimer:
HASH(0x2e52de8)
alarm
dead_sensor
1
5
Attributes:
IODev TCM_ESP3_0
alias RauchmelderDG
devStateIcon off:secur_smoke_detector@green smoke-alarm:secur_smoke_detector@red
eep F6-02-02
group contact
manufID 00D
room Alarmanlage
stateFormat alarm
subType smokeDetector.02
teachMethod RPS
-> Status "dead sensor" seit 12:02 Uhr obwohl um 12:39 ein Telegram empfangen wurde.
Kann ich was sinnvolles tun um zum Debugging beizutragen ?
Bitte das "dead sensor" Feature erst mal nicht auf andere Sensoren (Fensterkontakte, Wassersensor, Bewegungsmelder) ausdehnen bis das sauber funktioniert.
Grüße, gadget
Es wäre wichtig zu wissen, ob tatsächlich alle 20 min ein Telegramm empfangen wird und welche Abweichungen von der Sollperiode auftreten. Derzeit wird erwartet, dass die Periode kleiner als 22 min ist. Man könnte natürlich auch weniger scharf überwachen und ein fehlendes Telegramm akzeptieren, also z. B. den Timer auf 44 min setzen.
Der watchdog, den ich vorher im Einsatz hatte, war auf 50 min. eingestellt. Mit dem hatte ich nie einen Fehlalarm.
Ich finde es aber merkwürdig, das der "dead sensor" Status nicht mehr zurück gesetzt wird. Ist das plausibel ?
Aktuell sieht das bei mir so aus:
list FRW_DG
Internals:
CHANGED
DEF 01A36A63
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 359
NAME FRW_DG
NR 562
NTFY_ORDER 50-FRW_DG
STATE dead_sensor
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 359
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -54
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 1
TCM_ESP3_0_SubTelNum 12
TCM_ESP3_0_TIME 2017-03-25 18:59:00
TYPE EnOcean
Readings:
2017-03-24 12:02:40 alarm dead_sensor
2017-03-20 21:39:44 battery ok
2016-11-13 17:39:10 buttons released
2016-11-13 17:39:08 channelA AI
2017-03-20 21:39:44 state off
2016-11-13 17:39:08 teach RPS teach-in accepted EEP F6-02-01 Manufacturer: no ID
Helper:
lastEvent 0
alarmTimer:
HASH(0x2e52de8)
alarm
dead_sensor
1
5
Attributes:
IODev TCM_ESP3_0
alias RauchmelderDG
devStateIcon off:secur_smoke_detector@green smoke-alarm:secur_smoke_detector@red
eep F6-02-02
group contact
manufID 00D
room Alarmanlage
stateFormat alarm
subType smokeDetector.02
teachMethod RPS
Grüße, gadget
Der Spuk sollte jetzt vorbei sein. Natürlich sollte die Fehlermeldung beim Empfang eines neuen Telegramms zurückgesetzt werden. Leider war noch ein Fehler in der Logik. Ich baue ungern Profile um, falls ich kein eigenes Testmuster habe, aber... Die Zeiten habe ich beibehalten. Bitte mit Entwicklerversion testen.
Hallo,
Ist installiert. Ich werde berichten. Wenn es mal wieder regnet mache ich noch eine statistische Auswertung des alten Logfiles des FRW und kann dann hoffentlich auch was zu den 22 Minuten sagen.
Grüße, gadget
Hallo,
hat zwar nicht geregnet, aber hier mal meine Statistik über knapp 3 Monate Logfiles eines FRW:
Heartbeat Paket im Schnitt alle 19,7 Minuten
40 mal wurde die Zeitschranke 22 Minuten überschritten
2 mal wurde die Zeitschranke von 50 Minuten überschritten (Das waren aber sehr wahrscheinlich Wartungsarbeiten an fhem oder raspian)
Ergo würde ich dafür plädieren den Timeout hoch zu setzen oder konfiguierbar zu machen.
Grüße, gadget
Was war den der Maximalwert zweier unterbrechungsfreier Zeitinterwalle? Meine 10 % Schwankungsbreite scheint ja nicht auszureichen. Einstellbar würde ich das ungern machen... wieder ein Attribut mehr, es sind schon so viele.
Hallo,
Ich hab es noch mal vor und zurück ausgewertet: Um Fehlbenachrichtungen sicher auszuschließen muß man ein einzelnes verlorenes Paket einkalkulieren. Das passiert durchaus alle paar Tage - trotz idealer Funkbedingungen (FRW und EnOceanPi sind in meinem Fall im gleichen Raum). Mit 42 Minuten wäre man dann auf der sicheren Seite.
Die Testversion läuft soweit ansonsten problemlos, nach "dead sensor" kommt jetzt auch wieder ein "ok" wenn der FRW sich wieder meldet.
Grüße, gadget
Hallo,
ich hol diesen alten Thread noch mal hoch, weil ich immer noch nach jedem Update die 10_Enocean.pm patchen muss, um keine dead_sensor Fehlalarme zu bekommen.
Patch, mir dem das bei mir seit über einem Jahr nicht mehr vorgekommen ist:
--- /tmp/10_EnOcean.pm2017-09-30 13:44:52.347003776 +0200
+++ 10_EnOcean.pm2017-10-09 20:29:53.744018871 +0200
@@ -7050,7 +7050,7 @@
}
@{$hash->{helper}{alarmTimer}} = ($hash, 'alarm', 'dead_sensor', 1, 5);
RemoveInternalTimer($hash->{helper}{alarmTimer});
- InternalTimer(gettimeofday() + 1320, 'EnOcean_readingsSingleUpdate', $hash->{helper}{alarmTimer}, 0);
+ InternalTimer(gettimeofday() + 14400, 'EnOcean_readingsSingleUpdate', $hash->{helper}{alarmTimer}, 0);
} elsif ($st eq "windSpeed.00") {
# wind speed threshold detector
Vielleicht schafft es diese Änderung doch noch in den Mainstream.
Grüße,
gadget.
Hallo,
Aktuell steht in der 10_EnOcean.pm als dead_sensor Timeout für den FRW:
InternalTimer(gettimeofday() + 1440, 'EnOcean_readingsSingleUpdate', $hash->{helper}{timer}{alarm}, 0);
Ich würde mir zu Weihnachten noch eine Null wünschen:
InternalTimer(gettimeofday() + 14400, 'EnOcean_readingsSingleUpdate', $hash->{helper}{timer}{alarm}, 0);
Grüße, gadget
Änderungen zum Überwachungsinterval siehe https://forum.fhem.de/index.php/topic,92774.msg853290.html#msg853290