[Info:] Popp 009402 Rauchwarnmelder - warum man FLiRS Geräte nicht pollen sollte

[Klaus.A]

Hallo zusammen,

dieser Beitrag ist eine Informationssammlung und Erfahrungsbericht mit den Popp 009402 10-Jahres-Rauchwarnmelder mit Sirene, mit ZWave Modul.
Das Gerät ist ein FLiRS (Frequent Listening Routing Slave) Typ. Daraus ergeben sich einige Besonderheiten, die nicht unbedingt allgemein bekannt sind.

In der Dokumentation zum Rauchwarnmelder heißt es einfach man darf ihn nicht "pollen" - ohne zu erklären warum und was die Konsequenzen wären.
Vorweg: Bei falscher Behandlung (häufige Requests) kann die Lebensdauer der Batterie im ZWave-Modul für alle FLiRS Geräte in einer Installation sehr kurz werden.

Die folgende Darstellung ist mein aktueller Kenntnisstand nach umfangreicher Recherche und Experimenten. Sollten sich Fakten verändert haben oder wesentliche Informationen fehlen bin ich für Ergänzungen dankbar. Ich bin privater Anwender im Ruhestand, arbeite nicht für irgendwelche Hersteller oder Publikationen. Es ist also in keiner Weise Werbung für oder gegen Produkte oder Hersteller.

Ein (batteriebetriebenen) "wakeup" Gerät wacht in einem definierbaren Intervall auf und verarbeitet die zwischenzeitlich für das Gerät angeforderten Befehle. Die Initiative geht damit vom Gerät aus, und zwar von dem einzelnen Gerät. Andere batteriebetriebene Geräte sind nicht involviert. Ein Wakeup-Gerät kann also nie unmittelbar auf Befehle von außen reagieren. (Es sei denn man setzt das WakeUp Intervall auf einen extrem kurzen Wert - dann ist aber die Batterie innerhalb kürzester Zeit leer!) Das ist der Grund weshalb beispielsweise die Fibaro Rauchwarnmelder nicht vernetzbar sind - sie könnten nicht innerhalb einer akzeptablen Zeitspanne auf Nachrichten von anderen Meldern reagieren. Beim WakeUp kann man mit geeigneter Funktion auch den Batteriestatus senden lassen (was ich in meiner Installation realisiert habe).

Ein FLiRS Gerät dagegen ist ständig in einer Art Halbschlaf. Wenn ein Befehl eintrifft dann kann es extrem kurzzeitig reagieren. Der Popp Rauchwarnmelder ist ein FLiRS und kann daher sehr kurzzeitig reagieren. Er hat kein "WakeUp", keine periodische Funktionalität die vom Gerät ausginge.

Man könnte meinen, eine Abfrage (Polling) wie "get <Gerätename> battery" sollte kein Problem sein. Das funktioniert auch (FHEM at oder DOIF), aber man sei gewarnt:

Bei FLiRS Geräten warten alle Geräte darauf angesprochen zu werden. Da man zu einer Zeit immer nur ein Gerät ansprechen kann, müssen alle einzeln abgefragt werden und alle (!) prüfen jedes mal wer denn nun gemeint ist. Alle die nicht relevant sind gehen wieder in den Halbschlaf, das adressierte Gerät verarbeitet die Anfrage. Es erfolgt also immer zuerst bei allen FLiRS Geräten eine kurzzeitige Aktion. Das beansprucht auf Dauer die Batterie.

Angenommen ich würde alle 12 Rauchwarnmelder in meinem Haus durch FLiRS Varianten ersetzen. Dann bedeutet das bei der Abfrage des Batteriestatus für alle Geräte insgesamt 12 x 12 =144 Aktionen (jeden der 12 einzeln abfragen, und jedes mal müssen alle 12 prüfen wer gemeint ist ...).

Beim Popp 10-Jahres-Rauchwarnmelder ist eine 10-Jahres Batterie für den Melder und die Sirene fest verbaut, und eine austauschbare Batterie im ZWave-Modul. Sollte man - warum auch immer - einen periodisch ermittelten Batteriestatus benötigen dann entschärft diese Lösung das Problem in gewisser Weise: Man kann zumindest die stark beanspruchte Batterie tauschen.

Lt. Dokumentation soll der Rauchwarnmelder "rechtzeitig vor Lebensende der Batterie" ein Signal per ZWave senden. Der Zeitraum soll so dimensioniert sein das ausreichend Zeit bleibt die Batterie zu wechseln. Bei welchem Prozentsatz diese Meldung erfolgt ist mir nicht bekannt.

Ein Polling per FHEM "at" oder "DOIF" erscheint daher nicht unbedingt erforderlich. Es ist machbar und funktioniert auch (erfolgreich getestet). Jeder muss selbst entscheiden ob er den daraus resultierenden Batterieverbrauch - für alle installierten FLiRS Geräte akzeptieren kann. (Auch wenn man nur ein einziges FLiRS Gerät abfragen würde müssen zunächst alle intern reagieren).

In welchem Umfang die Beaming-Funktion bei diesem Gerät implementiert ist bzw. wie hier eine Verbesserung der Situation erreichbar wäre ist mir nicht bekannt. Da die Dokumentation ausdrücklich darauf hinweist kein Polling vorzunehmen erwarte ich in diesem Punkt allerdings keinen Einfluss.

Randbemerkung: Ich habe zwei dieser Rauchwarnmelder im Einsatz. Der erste hatte die Firmware mit "falscher ID", hat sich als Sirene angemeldet. Kurios war dabei, das der Rauchwarnmelder - angeblich ein FLiRS - eine periodisches WakeUp durchgeführt hat und damit auch im Intervall den Batteriestatus melden konnte. Nach OTA Firmware Update (FHEM - danke nochmals an Christian (krikan) für die große Unterstützung den Update erfolgreich durchzuführen) hat sich nicht nur die ID geändert, natürlich auch die Readings, und das periodische WakeUp ist weg. Da müssen also weitere Änderungen in der Firmware vorgenommen sein, was einen Firmware Update für das Gerät sehr empfehlenswert macht. Der zweite Rauchwarnmelder hatte gleich die richtige Firmware. Das Verhalten beider ist jetzt identisch.

(Ich kann mir denken, dass diese ursprünglich vorhandene WakeUp-Funktion auch alle anderen FLiRS Geräte erreicht hätte und damit die Belastung der Batterien in den ZWave Moduln der FLiRS Geräte ein Thema war.)

Gruß, Klaus

[rudolfkoenig]

Eigentlich schade, dass man die beiden Verfahren (FLiRS und WAKE_UP) nicht kombiniert.
Das FHEM Modul muesste aber dafuer auch angepasst werden, z.Zt. geht entweder/oder.

Nachtrag:

Ich kann mir denken, dass diese ursprünglich vorhandene WakeUp-Funktion auch alle anderen FLiRS Geräte erreicht hätte und damit die Belastung der Batterien in den ZWave Moduln der FLiRS Geräte ein Thema war.

Ich kann das nicht vorstellen, eher ein Problem mit dem HA-Software.
Bei FLiRS wird das "beam-tone" 0.25s bis 1s lang gesendet vom Controller, ein spezialisierter Teil des Empfaengers wacht alle 0.25-1s kurz auf, und prueft auf beam. Wenn vorhanden, dann wird der Rest der Hardware geweckt, was wohl Batterie-Intensiv ist. Beim WAKE_UP muss ja kein Beam gesendet werden, da der Empfaenger (in diesem Fall der Controller) kein Beam benoetigt, und damit werden die anderen Geraete auch nicht geweckt.

[Deckoffizier]

Hallo Klaus,

Danke für Deine ausführliche Schilderung!

Gibt für mich Stoff zum nachdenken.
Habe auch schon ewig Versucht den ab und zu massenhaften Warnmeldungen nur
die Fibaro Thermostate betreffend auf die Spur zu kommen.

Irgendwie habe ich das Gefühl mein Problem ähnelt Deinem?

Auffällig ist momentan hauptsächlich die Warnmeldungen nach FHEM update und Neustart.
Vielleicht passt diese Ausführung von Dir hierzu?

Bei FLiRS Geräten warten alle Geräte darauf angesprochen zu werden. Da man zu einer Zeit immer nur ein Gerät ansprechen kann, müssen alle einzeln abgefragt werden und alle (!) prüfen jedes mal wer denn nun gemeint ist. Alle die nicht relevant sind gehen wieder in den Halbschlaf, das adressierte Gerät verarbeitet die Anfrage. Es erfolgt also immer zuerst bei allen FLiRS Geräten eine kurzzeitige Aktion. Das beansprucht auf Dauer die Batterie.

Angenommen ich würde alle 12 Rauchwarnmelder in meinem Haus durch FLiRS Varianten ersetzen. Dann bedeutet das bei der Abfrage des Batteriestatus für alle Geräte insgesamt 12 x 12 =144 Aktionen (jeden der 12 einzeln abfragen, und jedes mal müssen alle 12 prüfen wer gemeint ist ...).

Momentan scheint es sich im laufenden Betrieb gebessert zu haben , weil ich in den zugehörigen PID20 Modulen der einzelnen
Thermostate das attr. pidActorKeepAlive den Standartzeitwert von allen immer etwas versetzt gewählt habe.
Somit erreiche ich nach Neustart weniger Gleichzeitigkeit?

In Punkto Batterieabfrage muss ich Deinen Beitrag versuchen noch besser zu verstehen um nicht
wieder neue Probleme zu schaffen.

Bin nur Anwender deshalb meine Vermutungen bitte nicht allzu Ernst nehmen.

Gruß
Hans-Jürgen