(gelöst)Rauchmelder FRW Alive Telegramme werden nach Update nicht mehr empfangen

[gadget]

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:

Code Auswählen Erweitern

"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):

Code Auswählen Erweitern

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

[klaus.schauer]

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. 

[gadget]

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

Grüße, gadget

[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:

Code Auswählen Erweitern



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

[klaus.schauer]

Ist fhem wirklich per "update" auf dem aktuellen Stand? Ein ähnliches wie das beschriebene Problem wurde letztlich gemeldet und korrigiert.

[gadget]

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

[gadget]

Hallo,

Fazit nach einigen Tagen: Sporadische Fehlalarme ca. alle 2 Tage bezügich "dead sensor":

Code Auswählen Erweitern



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

[klaus.schauer]

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.

[gadget]

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:

Code Auswählen Erweitern


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

[klaus.schauer]

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.

[gadget]

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

[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

[klaus.schauer]

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.

[gadget]

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

[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:

Code Auswählen Erweitern


--- /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.