Popp 10-Jahres Rauchmelder (9402) - Batteriestand lässt sich nicht abfragen

Hallo zusammen,

Ich habe mehrere der im Titel genannten Popp Rauchmelder im Einsatz, so dass ich nicht von einem einzelnen defekten Gerät ausgehe. Leider lässt sich bei keinem Rauchmelder der aktuelle Stand der Batterie auslesen. Alle Geräte wurden mit der Option „sicheres inkludieren“ angelernt und werden über ein Razberry-Modul angesprochen das sich direkt auf dem RaspberryPi mit Symcon (IP-Symcon 4.30, 22.08.2017, 87c3413724e6) befindet. Alarm-Meldungen werden korrekt übermittelt und können erfolgreich ausgewertet werden, d.h. die Kommunikation an sich scheint zu funktionieren, Variable für den Batteriestand wird angelegt, bleibt allerdings dauerhaft auf 0%.

Beim ersten Laden der Gerätekonfiguration kam der Hinweis, dass die WAKE_UP Klasse nicht unterstützt wird. Versuche ich die Variablen zu aktualisieren erscheint die Fehlermeldung „(RequestSwitchBinary) (SEC) Waiting for nonce timed out.“, siehe auch den Screenshot im Anhang.

Die folgenden Klassen werden als unterstützt angezeigt (sind nur 7 obwohl 8 in der Übersicht steht):

[ul]
[li]BATTERY
[/li][li]VERSION
[/li][li]MANUFACTURER_SPECIFIC
[/li][li]SECURITY
[/li][li]ZWAVEPLUS_INFO
[/li][li]FIRMWARE_UPDATE_MD
[/li][li]DEVICE_RESET_LOCALLY
[/li][/ul]

Die folgenden secure Klassen werden als unterstützt angezeigt:

[ul]
[li]SWITCH_BINARY
[/li][li]SENSOR_BINARY
[/li][li]ALARM
[/li][li]ASSOCIATION
[/li][li]CONFIGURATION
[/li][li]VERSION
[/li][li]MANUFACTURER_SPECIFIC
[/li][li]ZWAVEPLUS_INFO
[/li][li]ASSOCIATION_GRP_INFO
[/li][/ul]

Als Anhang zusätzlich noch zwei Dumps, einmal das erstmalige „Gerätekonfiguration laden“ und einmal die fehlgeschlagene Aktualisierungsanfrage.

Gruß Bernd

dump-Popp-Aktualisierungsanfrage.txt (128 Bytes)

dump-Popp-Gerätekonfiguration.txt (3.99 KB)

Das klingt natürlich so nicht richtig. Wir schauen uns das an.

Ich habe noch einen Nachzügler hier liegen den ich die nächsten Tage einbinden wollte, soll ich dabei noch einen Dump vom inkludieren erstellen?

Gruß Bernd

Gesendet von meinem SM-T580 mit Tapatalk

Ja bitte einen Dump erstellen und uns dann schicken bzw. hier mit anhängen.

Ansonsten wäre ein Ab-/Anlernen ebenfalls eine Möglichkeit.

Wir schauen dann weiter.

Grüße
Pio

Im Anhang die Dumps vom Z-Wave Configurator und dem zugehörigen Serial-Port.

gruß Bernd

dump-Popp-SerialPort.txt (50.7 KB)

dump-Popp-ZWaveConfigurator.txt (2.43 KB)

Ich uns mal so ein Gerät bestellt und werde berichten, sobald es da ist.

paresy

Ich habe die Ursache identifiziert und arbeite an einer Lösung.

paresy

Fix ist jetzt im Beta-Bereich online. Ihr müsste nach dem Update in der Instanz das Gerät einmal neu „Laden“. Danach sollte alles wie gewohnt wieder laufen.

paresy

Beta ist eingespielt, aber leider klappt das neu laden nicht… Es erscheint die Meldung „(RequestInfo) Waiting for Feedback timed out“, wobei das Gerät selbst angesprochen wird, d.h. die gelbe LED leuchtet direkt bei der Abfrage auf.

Folgendes kommt im Debug auf dem Rauchmelder an:


TXT: 10.10.2017 22:48:16.00 | (S) RequestProtocolInfo | 
HEX: 10.10.2017 22:48:16.00 | (S) RequestProtocolInfo | 
TXT: 10.10.2017 22:48:16.00 |  (S) RequestNodeInfo | 
HEX: 10.10.2017 22:48:16.00 |  (S) RequestNodeInfo | 
TXT: 10.10.2017 22:48:17.00 |               Update | <EOT><BEL><SOH>^zs?Z??rï 
HEX: 10.10.2017 22:48:17.00 |               Update | 04 07 01 5E 7A 73 80 5A 98 86 72 EF 20 
TXT: 10.10.2017 22:48:17.00 |          NodeClasses | ^zs?Z??r
HEX: 10.10.2017 22:48:17.00 |          NodeClasses | 5E 7A 73 80 5A 98 86 72 
TXT: 10.10.2017 22:48:17.00 |   NodeControlClasses |  
HEX: 10.10.2017 22:48:17.00 |   NodeControlClasses | 20 
TXT: 10.10.2017 22:48:17.00 | (S) RequestNodeSecureInfo | 
HEX: 10.10.2017 22:48:17.00 | (S) RequestNodeSecureInfo | 

Ist das Gerät korrekt als SECURE Geräte angelernt? Bleibt er immer an der selben Stelle stehen?

paresy

Du kennst auch keinen Feierabend [emoji3]

Gerät ist secure angelernt, Klassen werden sauber erkannt. Auch ein mehrfaches „neu laden“ bleibt immer mit der gleichen Fehlermeldung bzw. den gleichen Debug-Meldungen stehen.

Ich würde morgen Abend testweise einen Rauchmelder ablernen und frisch anlernen wenn du keine andere Idee hast. Ein einfaches anlernen ohne vorherigen exclude zeigte gerade keine Veränderung, das hatte ja in einem anderen Thread geholfen um die Kommunikation wiederherzustellen.

Gesendet von meinem SM-T580 mit Tapatalk

So, habe nun einen Rauchmelder komplett exkludiert und frisch inkludiert, allerdings erscheint beim ersten Klick auf „Laden“ wieder die Meldung dass die WAKE_UP Klasse nicht unterstützt würde. Zudem meldet das Gerät keine unterstützten Security-Klassen (vorher 9), die unterstützten (nicht-security) Klassen sind weiterhin bei 8 (inkl. Security-Klasse).

Symcon-Version ist auch definitiv die Beta von gestern: IP-Symcon 4.30, 10.10.2017, 5b8ce6012100

Das Auslesen der Batterie klappt nach dem neu-inkludieren zwar, aber dafür werden keine Notifications mehr empfangen bei einem Probe-Alarm. Der Debug zeigt das Auslesen, eine Aktualisierungsanfrage und sollte eigentlich auch noch einen Test-Alarm anzeigen (jedoch keine Aktivität im Debug-Log):


TXT: 11.10.2017 20:50:28.00 | (S) RequestProtocolInfo | 
HEX: 11.10.2017 20:50:28.00 | (S) RequestProtocolInfo | 
TXT: 11.10.2017 20:50:28.00 |  (S) RequestNodeInfo | 
HEX: 11.10.2017 20:50:28.00 |  (S) RequestNodeInfo | 
TXT: 11.10.2017 20:50:29.00 |               Update | <EOT><BEL><SOH>^zs?Z??rï 
HEX: 11.10.2017 20:50:29.00 |               Update | 04 07 01 5E 7A 73 80 5A 98 86 72 EF 20 
TXT: 11.10.2017 20:50:29.00 |          NodeClasses | ^zs?Z??r
HEX: 11.10.2017 20:50:29.00 |          NodeClasses | 5E 7A 73 80 5A 98 86 72 
TXT: 11.10.2017 20:50:29.00 |   NodeControlClasses |  
HEX: 11.10.2017 20:50:29.00 |   NodeControlClasses | 20 
TXT: 11.10.2017 20:50:29.00 | (S) RequestInfoManufacturerSpecific | r<EOT>
HEX: 11.10.2017 20:50:29.00 | (S) RequestInfoManufacturerSpecific | 72 04 
TXT: 11.10.2017 20:50:30.00 | (R) Class (72): MANUFACTURER_SPECIFIC | <ENQ><SOH>T<NUL><EOT><NUL><EOT>¼<NUL>
HEX: 11.10.2017 20:50:30.00 | (R) Class (72): MANUFACTURER_SPECIFIC | 05 01 54 00 04 00 04 BC 00 
TXT: 11.10.2017 20:50:30.00 |       ManufacturerID | 0154
HEX: 11.10.2017 20:50:30.00 |       ManufacturerID | 30 31 35 34 
TXT: 11.10.2017 20:50:30.00 |          ProductType | 0004
HEX: 11.10.2017 20:50:30.00 |          ProductType | 30 30 30 34 
TXT: 11.10.2017 20:50:30.00 |            ProductID | 0004
HEX: 11.10.2017 20:50:30.00 |            ProductID | 30 30 30 34 
TXT: 11.10.2017 20:50:30.00 | (S) DeleteReturnRoute | G;e
HEX: 11.10.2017 20:50:30.00 | (S) DeleteReturnRoute | 47 3B 65 
TXT: 11.10.2017 20:50:30.00 | (S) AssignReturnRoute | F;<SOH>e
HEX: 11.10.2017 20:50:30.00 | (S) AssignReturnRoute | 46 3B 01 65 
TXT: 11.10.2017 20:51:36.00 |   (S) RequestBattery | ?<STX>
HEX: 11.10.2017 20:51:36.00 |   (S) RequestBattery | 80 02 
TXT: 11.10.2017 20:51:38.00 | (R) Class (80): BATTERY | <ETX>d»<NUL>
HEX: 11.10.2017 20:51:38.00 | (R) Class (80): BATTERY | 03 64 BB 00 

Das klingt aber eher so, als wenn das SECURE Inkludieren fehlgeschlagen ist. Magst du es noch mal probieren. Es müssen nach dem Laden definitiv SECURE Klassen angezeigt werden.

paresy

Leider immer wieder das gleiche Ergebnis… :frowning: