Kein Batteriealarm bei POPP Rauchmelder (POPE004001)?

Begonnen von bs, 03 September 2018, 15:37:14

Vorheriges Thema - Nächstes Thema

bs

Hallo,

ich habe 2 Rauchmelder (POPE004001), die ich vor knapp 2 Jahren in mein FHEM gesteuertes ZWave Netz eingebunden habe. Die Spannungsversorgung erfolgt hier ja mittels 9V Block Batterie. Einer dieser beiden scheint seit ein paar Tagen zu merken, dass die Batteriespannung nachlässt, gibt dies seither jedoch leider nur akkustisch durch sporadisches, sehr kurzes aber ebenso lautstarkes Signal von sich. Seltsam dabei sind jetzt 2 Aspekte:

  • Es erfolgte keine Notification bzw. Alarm per ZWave
  • Das Reading steht nach wie vor bei 100% (was ja nach fast 2 Jahren eher ungewöhnlich sein sollte)

Komplett sieht das Device so aus:

Internals:
   DEF        d4a43eb6 11
   IMAGE      /fhem/deviceimages/zwave/ZC10-16125371
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     35
   NAME       WZ.Rauchmelder
   NR         43
   STATE      off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 35
   ZWDongle_0_RAWMSG 0004000b03800364
   ZWDongle_0_TIME 2018-09-03 14:12:08
   ZWaveSubDevice no
   cmdsPending 0
   homeId     d4a43eb6
   isWakeUp
   lastMsgSent 1535976726.71115
   nodeIdHex  0b
   READINGS:
     2017-01-07 21:37:39   CMD             ZW_APPLICATION_UPDATE
     2018-08-31 09:50:46   alarm           Smoke: unknown event 254, arg 0000
     2018-08-31 09:53:21   alarmEventSupported_Smoke (2) detected - Unknown Location
     2018-09-03 10:54:15   alarmTypeSupported Smoke
     2018-08-31 09:54:06   alarm_type_00   level 00
     2018-08-31 09:59:07   assocGroupCmdList_1 BATTERY:03 DEVICE_RESET_LOCALLY:01 SENSOR_BINARY:03 ALARM:05 SWITCH_BINARY:03
     2018-08-31 10:05:51   assocGroupName_1 Lifeline
     2018-08-31 10:04:38   assocGroupName_2 Smoke alarm action
     2018-08-31 10:04:57   assocGroupName_3 Smoke basic action
     2018-08-31 09:58:15   assocGroup_1    Max 4 Nodes ZWDongle_0
     2018-08-31 10:04:27   assocGroup_2    Max 4 Nodes
     2018-08-31 09:54:42   assocGroup_3    Max 4 Nodes
     2018-08-31 10:06:13   assocGroups     3
     2018-08-31 10:00:48   basicReport     0
     2018-09-03 14:12:08   battery         100 %
     2018-08-31 10:06:40   configSirenAlarmSequenceInterval 10
     2018-08-31 10:06:40   configSirenAlarmToneLength 8
     2018-08-31 10:06:40   configStatusOfAutomatedMeshingOf6 ActiveDefault
     2018-08-31 10:06:40   configStatusOfAutomatedMeshingOfSmoke5 ActiveDefault
     2018-08-31 10:06:40   configValueOfOffCommand 0
     2018-08-31 10:06:40   configValueOfOnCommand 255
     2018-08-31 10:07:11   model           Popp Smoke Detector and Siren
     2018-08-31 10:07:11   modelConfig     popp/smoke-detector.xml
     2018-08-31 10:07:11   modelId         0154-0100-0201
     2018-08-31 07:40:58   neighborList    ZWDongle_0 WZ.Steckdose.beide WZ.Schalter.Stehlampe SZ.Drucker WZ.Fenster SZ.Fenster UNKNOWN_20 SZ.Heizung WZ.Heizung.Wand
     2018-08-31 10:10:49   reportedState   off
     2018-08-31 10:10:44   smoke           off
     2018-08-31 10:10:49   state           off
     2018-09-03 14:12:08   timeToAck       1.300
     2018-09-03 14:12:08   transmit        OK
     2018-08-31 07:31:01   zwavePlusInfo    version:01 role:SleepingListeningSlave node:Z-Wave+Node installerIcon:0c01 userIcon:0c01
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BASIC SWITCH_BINARY SENSOR_BINARY ALARM CONFIGURATION ASSOCIATION BATTERY DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC MARK BASIC
   devStateIcon off:audio_volume_mute on:audio_volume_high@red
   extendedAlarmReadings 2
   group      Rauchmelder
   room       Wohnzimmer
   vclasses   1


Was mich u.a. auch stutzig macht, ist dass bei alarmTypeSupported lediglich Smoke auftaucht. Sollte dort nicht auch etwas wie "Battery" o.ä. stehen? Insgesamt wirft das bei mir folgende Fragen auf:

  • Wird Batteriealarm per ZWave vom Gerät überhaupt unterstützt? Im Handbuch (http://manuals-backend.z-wave.info/make.php?lang=de&type=&sku=POPE004001) wird dies jedenfalls behauptet:
    ZitatDas Z-Wave Funkmodul ermöglicht es, den Rauch- und Batteriealarm an eine zentrale Z-Wave- Steuerung zu übermitteln.
  • Sollten der akkustische Batteriealarm und die zugehörige ZWave Notification eigentlich miteinander gekoppelt sein?
      - Müsste also bei jedem Pieption eine ZWave Nachricht an den Controller gesendet werden?
      - Oder kann es sein, dass das battery Reading völlig unabhängig von der Erkennung, die zum akkustischen Signal führt, arbeitet?
Bei einigen Recherchen bin ich u.a. auf folgenden Link gestoßen: https://community.openhab.org/t/popp-smoke-detector-and-siren/8316/25. Hier beschreibt jemand ein vergleichbares Phänomen mit dem Gerät. Wenn ich das dort beschriebene Verhalten mit meiner Beobachtung kombiniere, komme ich zu folgendem Verdacht:

  • Das Reading "battery" hat nur 2 Zustände (voll = 100% / leer = 0%), wobei ab Spannung < x Volt leer angezeigt wird
  • Das Gerät meint aber schon, ab einem Schwellwert von y > x Volt eine akkustische Warnung von sich geben zu müssen.
Kann das irgendjemand bestätigen oder wiederlegen? Sollte das wirklich zutreffen, wäre der Batterielaram per ZWave ja komplett obsolet. Es würde ja niemand ernsthaft in einer bewohnten Umgebung sich das Gepiepse antun und mit dem Batteriewechsel warten, bis das Ereignis dann endlich auch mal per Funk gemeldet wird ;-) Ich habe den Popp Support bereits mit der gleichen Fragestellung konfrontiert, bezweifle aber, dass hier eine aus technischer Sicht verwertbare Antwort kommt. Die ersten Reaktionen gehen in die Richtung, dass man annimmt, in FHEM läge bestimmt ein "Anzeige- oder Softwareproblem" vor. Diese Behauptung aufzustellen, ist für die natürlich zunächst mal viel einfacher, als für mich zu widerlegen. Jetzt wäre die Frage, wie man mit einer gewissen Sicherheit herausbekommen kann, dass FHEM die Readings korrekt dekodiert. Ich würde ja nun gerne das Reading "alarm" mittels

get <device> alarm battery

o.ä. updaten und die Logs sichern. Jedoch bekomme ich dies natürlich mit einer Fehlermeldung von fhem quittiert (ich denke, weil bei alarmTypeSupported  ausschließlich Smoke verfügbar ist). Könnt Ihr mir weiterhelfen?

Vielen Dank und Gruß
bs

krikan

Habe das Gerät nicht, daher nur ein paar allgemeine Anmerkungen:

Der batteryLevel wird typischerweise über die Class BATTERY gemeldet; die Batteriemeldung ist auch in der Assogroup 1 des Gerätes (assocGroupCmdList_1 BATTERY:03) gelistet. Damit gibt es eine low-Meldung und %-Werte, die man zusätzlich manuell mit "get <device> battery" abrufen kann. Wann das Gerät automatisch battery-Werte liefert, ist afaik in den Specs nicht festgelegt.

Die Meldung des batteryLevels über Class ALARM (neuer Name: NOTIFICATION) muss nicht existieren. Wenn "get <device> alarmTypeSupported" nur smoke liefert, dann wird über die Class ALARM auch kein Batteriestand gemeldet.

Prüfen, ob FHEM richtig arbeitet, kann man durch Vergleich der Rohnachrichten (verbose 5 beim ZWDongle-Device) mit den Specs auf http://zwavepublic.com/downloads.

Von einem Fehler in FHEM gehe ich erst einmal frech nicht aus.  :) Das wäre vermutlich längst aufgefallen. Zudem sind die Batteriemeldungen der Geräte in der Genauigkeit unterschiedlich.

Gruß, Christian

bs

Hallo Christian,

vielen Dank schon mal für Deine Antwort. Ich denke aus dem gleichen Grund auch, dass hier kein Fehler in FHEM vorliegt. Andererseits würde ich aber auch vermuten, dass es auch zu einer gewissen Resonanz in Form von Unmut gekommen sein müsste, wenn das Gerät tatsächlich so konzipiert ist, wobei ich die Verbreitung natürlich nicht beurteilen kann.

Ich kann sehr gut damit leben, dass der Batterielevel nicht auf das Prozent genau angezeigt wird, meinetwegen auch nur 2 Zustände hat und ich das Reading vlt. sogar noch aktiv auslesen muss. Von mir aus, alles kein Problem. Was aber meiner Meinung nach ein absolutes "No-Go" ist: Wenn das Gerät schon lautstark nach einer neuen Batterie schreit und ich das Reading aktualisiere, dass dann immer noch der Zustand "voll" signalisiert wird. Sollte das Gerät vom Hersteller tatsächlich so designed sein, müsste man ihm das grad vor die Füße werfen - oder sehe ich das falsch?

Ich habe schon überlegt, ob ich - wenn das nicht über die ALARM / NOTIFICATION Klasse abgewickelt wird - noch irgendwas aktivieren muss, damit eine Benachrichtigung erfolgt. Andererseits würde das ja auch nur etwas nützen, wenn es zusätzlich zu dem Reading "battery" noch ein weiteres geben würde, was ich noch gar nicht gesehen habe. Ansonsten würde ja nach wie vor 100% übermittelt. Dass ich in der assocGroup_2 oder 3 das ZWDongle-Device explizit hinzufügen muss, kann eigentlich nicht sein, oder vielleicht doch? Wenn ich das richtig verstehe, dient das ja nur dazu, ein bestimmtes Kommando in einem anderen ZWave Gerät zu triggern...


Prüfen, ob FHEM richtig arbeitet, kann man durch Vergleich der Rohnachrichten (verbose 5 beim ZWDongle-Device) mit den Specs auf http://zwavepublic.com/downloads.


So in etwa habe ich mir das fast gedacht (oder befürchtet)  ;) ...vielen Dank für den Link, bei Gelegenheit wühle ich mich da mal durch, eventuell ergeben sich ja noch weitere Erkenntnisse.

Insgesamt erhärtet sich bei mir der Verdacht, dass das Gerät zwar wahrscheinlich irgendwann mal eine Meldung auf Basis des battery Readings absetzen würde, man jedoch - bis es dazu kommt - einen Gehörschaden erleidet. Interessant wäre, ob jemand ähnliche Erfahrungen mit dem Gerät hat (oder bessere)  :D

Baerli34

Habe 5 Stück davon - leider noch nicht ganz die 2 Jahre - aber habe mich die letzten Monate auch schon gewundert warum immer noch 100% BatteryPercent^^
Wenn dem so ist wie du beschreibst ist es natürlich doof, weil man sich nicht auf einen Wechsel vorbereiten kann und es dann ähnlich wie bei den Billigheimern nervt, da es
nach Murphys Gesetz immer nachts anfängt zu piepsen ;( Aber - nach wie vor halte ich den Rauchmelder mit FLIRS sowie der steuerbaren Sirene (die bei mir auch als Alarm genutzt wird)
für eine tolle Sache - und 2 Jahre für so ein Z-Wave Gerät, welches immer ansprechbar ist finde ich ok. Na dann warte ich mal ab und bin gespannt was die nächsten Monate bei mir so zeigen werden  :o

vg, Jörg
ZWave Fibaro Relay/Motion, Duwi ZW3500 Switche, Aeon MultiSensors, Vision ZS6301 CO, Wasser/Rauchmelder, Everspring AN158, ZD2102 Door, Popp Smoke, Milight, Plex, Vu+, Fritz, Sonos, CUL, Selve & Wolf Heiz,Lüftung,Solar, FireTV, Alexa, Ubiquiti, Hue... | Smarthome-Kanal: https://bit.ly/2MY9gGi

mba

Also ich habe auch 2 stück davon und kann nur bestätigen das der Batteriestand nicht korreckt ist. Die haben 2 Jahre 100% angezeigt. Irgendwann fingen die (natürlich Nachts) an sporadisch zu piepen.
Da ich auch normale Rauchmelder habe suchte ich natürlich dort den Übeltäter da die Popps ja 100% gemeldet haben.
Aber nach Batteriewechsel in den Popps war wieder alles gut.
Für mich ist das ein no go, also nie wieder Popp.

Grüße
MB
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

bs

Nach einigem Hin und Her mit dem POPP Support habe ich mittlerweile offiziell die Bestätigung erhalten, dass die Funktionsweise der Geräte tatsächlich von Vornherein so gedacht war und auch keinerlei Änderung geplant sei. Es ist also tatsächlich so, dass der Z-Wave Batteriestatus nur 100% und 0% kennt (wobei die 0% vermutlich noch niemand zu Gesicht bekommen hat). Diese Bestätigung habe ich allerdings erst erhalten, nachdem man mehrfach versucht hat, mich mit Ablenkungsmanövern abzuwimmeln. Ich habe mich daraufhin beschwert, weil das aus der Produktbeschreibung definitiv anders hervorgeht (s.u.). Leider zeigt sich der Hersteller hier extrem ignorant und sieht sich überhaupt nicht in der Verantwortung. Eine Rücknahme der Rauchmelder wurde ohne Begründung abgelehnt. Erst nachdem ich den Hersteller mit einer offiziellen Mängelanzeige wegen fehlender Eigenschaften verbunden mit angedrohten Konsequenzen konfrontiert habe, hat man mein Anliegen ernst genommen und einer Rücknahme über den Händler zugestimmt. Überraschenderweise aber auch nur nach dem Motto "die Garantie ist zwar schon lange abgelaufen, aber damit wir jetzt diese unsachliche Diskussion beenden können und wir so lieb und nett sind, du böser Kunde uns aber so unverholen drohst, zeigen wir uns ausnahmsweise kulant". Man gibt sich also obendrein noch beleidigt und stellt sich als Opfer meiner Drohgebärden dar. Das ist wirklich ein starkes Stück, wie ich finde.

Die aus meiner Sicht einzig logische Schlussfolgerung daraus ist, dass der Hersteller hier ganz bewusst folgende Strategie verfolgt: Man wirbt mit einem Feature (s.u.), das nicht existiert und nie vorgesehen war. Bis das jemand überhaupt bemerkt, ist die Gewährleistung längst abgelaufen, so dass von den Wenigen, die das überhaupt stört oder bemerken, sich nur noch ein Bruchteil meldet. Diese versucht man dann abzuwimmeln. Nur vernachlässigbar viele Ausnahmen dürften dann noch übrig bleiben, die sich die Mühe machen, der Sache dann noch weiter nachzugehen, wenn die alternative ist, dass man durch eine frische Batterie wieder 2 Jahre seine Ruhe hat. Ich würde das "arglistige (Verbraucher)täuschung" nennen.

Über den Händler, über den ich die Rauchmelder damals bezogen habe, kann ich jedoch nur Positives berichten. Dieser wollte mir sogar zunächst, ohne dass ich die Geräte zurücksenden muss, den Kaufpreis erstatten. Zu dem Zeitpunkt wusste dieser noch gar nicht, dass der Hersteller der Rücknahme dann doch zugestimmt hatte und ging wohl davon aus, ohnehin auf den Kosten sitzen zu bleiben. Ich war dann so fair, diesen darüber zu informieren, woraufhin er mich dann bat, ob ich die Teile nicht doch zurückschicken könne. Das mache ich in dem Fall wirklich gerne.

Für alle Betroffenen, die trotz abgelaufener Garantie / Gewährleistung ganz gerne die Rauchmelder zurück geben möchten, eine kleine Argumentationshilfe:

  • Mängelanzeige wegen fehlender Eigenschaft
  • Kaufgegenstand hätte nach der Produktbeschreibung/üblichen Eigenschaften/Erwartungen folgende Wirkung erzeugen müssen: Meldung des Batteriealarms per Z-Wave Funkmodul an eine zentrale Z-Wave-Steuerung
  • In Wirklichkeit macht der Kaufgegenstand aufgrund des Mangels Folgendes: Meldung des Batteriealarms nur akkustisch, jeodch nicht per Z-Wave Funkmodul
  • Abgelaufene Gewährleistungsfrist? Nein, weil der Mangel arglistig verschwiegen wurde (s.o.).

Quellen:

  • Bedienungsanleitung (https://www.popp.eu/004001de):
    ZitatDas Z-Wave Funkmodul ermöglicht es, den Rauch- und Batteriealarm an eine zentrale Z-Wave- Steuerung zu übermitteln
  • Produktbeschreibung (https://www.popp.eu/de/produkte/sensoren/rauchmelder-sirene/) (wichtig: Dieser Stichpunkt befindet sich im Absatz Z-Wave Funktionen!):
    ZitatBatteriestatus-Warnung, wenn das Batterielevel unter 20% fällt (lokale kurze Signalisierung durch Licht- und Tonsignale)



Baerli34

Ja - ich kann jetzt auch bestätigen - vor einer Woche hatte ich auch den ersten der rumpiepte  :o Dafür
habe ich diese eigentlich nicht gekauft - beim nächsten Melder mache ich den Test vorher - und wohlgemerkt
nicht mehr von Popp - so kann man sich auch einen Namen machen  :-X

vg, Jörg
ZWave Fibaro Relay/Motion, Duwi ZW3500 Switche, Aeon MultiSensors, Vision ZS6301 CO, Wasser/Rauchmelder, Everspring AN158, ZD2102 Door, Popp Smoke, Milight, Plex, Vu+, Fritz, Sonos, CUL, Selve & Wolf Heiz,Lüftung,Solar, FireTV, Alexa, Ubiquiti, Hue... | Smarthome-Kanal: https://bit.ly/2MY9gGi

Gernot69

Ich habe auch das selbe Problem.  Werde versuchen diese auch zurückzusenden.
Gibt es dafür eine bessere alternative?

Ich habe aber noch ein anderes Problem. Bei Brandalarm passiert es, das alle meine BM auslösen, und sich dann  obwohl der Brandalarm nicht mehr ansteht nicht wieder beruhigt. --> Erst als ich noch Mein FHEM Server konnte nicht mehr erreicht werden. Erst durch Neustart vom FHEM Server hat wieder alles funktioniert.

Bei mir steht folgendes in der
vclasses:
ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:2 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2


Hilft das, wenn ich "1" reinschreibe?


danke
Gernot