[gelöst] Z-Wave Node neu verbinden - replaceFailedNode

[micha80]

Hallo zusammen,

ich habe einen Fibaro FGWPE Wall Plug, der jedes mal beim Ausstecken aus der Steckdose, bzw sobald er stromlos wird, keine Befehle mehr annimmt und sich scheinbar zurücksetzt. Beim Einstecken leuchtet der LED-Ring dann rot, wie im Handbuch beschrieben zur Ersteinrichtung.

1) Insert the Plug into a socket,
2) Auto-inclusion will be activated, i.e. Plug automatically starts looking for Z-Wave network controller.
Auto-inclusion activation is signaled by a single, red, LED ring blink.

Jetzt habe ich heraus gefunden, dass ich den mit seiner "alten" ID wieder verbinden kann.

Leider funktioniert das nicht über FHEM und "set ZWDongle_0 replaceFailedNode 22".
Dafür aber über die razberry software

Mag sich jemand das angehängte z-way-server Log-File anschauen und evtl raus finden, was für Kommandos notwendig sind?

mfg
micha


NACHTRAG
Das Problem wurde behoben und es können jetzt Geräte neu verbunden werden.
Dazu ist aber folgendes zu beachten: Die Node muß im "failed"-Status sein! Geprüft werden kann der Status über "get ZWDongle_0 isFailedNode <nodeID>". jetzt muß als Rückmeldung 016201 kommen. Wenn nicht, kann mit "set ZWDongle_0 sendNIF <nodeID>" nachgeholfen werden.

[krikan]

Hallo Micha,
ändere bitte mal in der aktuell 00_ZWDongle.pm in der Zeile 34:

Code Auswählen Erweitern

"replaceFailedNode"=> { cmd => "64%02x" },   # ZW_REPLACE_FAILED_NOD
den Wert 64 in 63 ab, führe ein reload von 00_ZWDongle.pm aus und teste mal, ob das schon reicht.
Ein Fhem-Log mit verbose 5 wäre anschließend gut.
Gruß, Christian

[rudolfkoenig]

Danke fuer den Hinweis, habs eingecheckt.

[krikan]

@Rudi: Danke

Micha könntest Du bitte auch mal nachschauen, ob bei den "caps" (get <zwdongle> caps) auch ZW_REPLACE_FAILED_NODE angezeigt wird? Danke.

[micha80]

Guten Morgen zusammen,

also hier die caps, wobei mit der z-way-software das replace ja auch funktioniert...

Code Auswählen Erweitern


ZWDongle_0 caps => Vers:5 Rev:0 ManufID:0147 ProductType:0400 ProductID:0001 UNKNOWN_01 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0f ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET UNKNOWN_1b UNKNOWN_1f MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER UNKNOWN_26 UNKNOWN_27 UNKNOWN_28 UNKNOWN_29 UNKNOWN_2a UNKNOWN_2b UNKNOWN_2c UNKNOWN_40 ZW_GET_NODE_PROTOCOL_INFO UNKNOWN_43 ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY UNKNOWN_4f ZW_SET_LEARN_MODE ZW_ENABLE_SUC ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID UNKNOWN_5d UNKNOWN_5f ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE UNKNOWN_65 UNKNOWN_66 UNKNOWN_77 UNKNOWN_7f UNKNOWN_8f ZW_SEND_DATA_ROUTE_DEMO UNKNOWN_92 UNKNOWN_97 UNKNOWN_b3 UNKNOWN_b5 UNKNOWN_b6 UNKNOWN_b7 UNKNOWN_b8 UNKNOWN_b9 ZW_ARE_NODES_NEIGHBOURS ZW_TYPE_LIBRARY UNKNOWN_be UNKNOWN_d1 UNKNOWN_d2 UNKNOWN_d3 UNKNOWN_ee UNKNOWN_f1 UNKNOWN_f3


Das logfile habe ich angehängt.
Der Wall Plug hat die ID:16 und NodeID:22
Seltsamerweise steht im log zwar "unhandled command" (Zeile 82), funktioniert aber trotzdem! 

Das Ding ist irgendwie kaputt: die Einstellungen zur Assoziation und config-Parameter "LED-immer-aus" hat er gespeichert,
ich kann dem Ding aber trotzdem keine Kommandos schicken ("TRANSMIT_NO_ACK") solange ich ihn nicht neu eingebunden habe...

mfg
micha

[krikan]

caps

Also der Razberry reportet ZW_REPLACE_FAILED_NODE nicht und kann es trotzdem. Genauso ist das bei meinem VISION-Stick.
Ich dachte schon mein Stick hätte eine Macke, aber anscheind kann man den Controller-caps nicht trauen bzw. ich verstehe nicht, warum das nicht im Report auftaucht.
Kann das jemand erklären?

Seltsamerweise steht im log zwar "unhandled command" (Zeile 82), funktioniert aber trotzdem! 

Sieht gut aus. "unhandeld command" ist normal, solange keiner eine Auswertung dieser Nachrichten in Fhem einbaut. Hat nichts mit der grds. Funktion zu tuen. Man muss so halt die Rohnachrichten selbst analysieren. Wenn mir keiner zuvorkommt, setze ich das bei mir auf Todo. Im übrigen scheinen die Logs von Zway ganz hilfreich zu sein.

[micha80]

Wenn du das log gut findest, schau dir mal die Developer Doku an
http://razberry.z-wave.me/index.php?id=5

In den caps sind ja zum Glück noch ne Menge unknown drin

Aber cool, mein 2. "Patch"
Irgendwie sah das in dem zway log umständlicher aus, als es war?!

Mfg
Micha

[krikan]

Wenn du das log gut findest, schau dir mal die Developer Doku an

Kenn ich; hilft mir aber leider nicht wirklich, da dort die notwendigen Low-Level-Infos nicht drinstehen.

In den caps sind ja zum Glück noch ne Menge unknown drin

Die unknown können es aber eigentlich nicht sein, da die ID für ZW_REPLACE_FAILED_NODE bekannt ist.

Irgendwie sah das in dem zway log umständlicher aus, als es war?!

In den zway-logs sieht man die notwendigen Low-Level-Codes und Befehls-Abläufe. Hier war es aber sehr einfach, da in 00_ZWDongle.pm bloß ein Tippfehler drin war.

Was mich noch interessieren würde: Hast Du einen alten Razberry (300er Chip?) oder den neuen ZWave Plus-Razberry (500er Chip)?

[micha80]

wenn du mir sagst, wie ich das rausfinden kann?
(geheime low-level developer codes eingeben? )

okay, warte. ich poste mal noch das komplette z-way logfile. da stehen dann auch die function classes des Controllers drin(Zeile 218ff)

[krikan]

Nö, nix geheimnisvolles:

verbose 5 beim Dongle einschalten
"get ZWDongle_0 nodeList" abrufen
Im Log die Rohnachricht raussuchen; die letzten Stellen geben den Chipsatz an
Bei mir zum Bsp beim 401er Chipsatz:

ZWDongle_Read ZWDongle_0: 010205001d39000000000000000000000000000000000000000000000000000000000401

Edit: OK, laut Deinem ZWay-Log 500er Chipsatz, also neuester Razberry mit ZWave plus-Zertifizierung.

[micha80]

der Dongle ist 2 Monate alt, da wusste ich noch nicht, auf was ich mich einlass...

Code Auswählen Erweitern


==> log/fhem-2015-05-14.log <==
2015.05.14 22:02:48 5: SW: 01030002fe
2015.05.14 22:02:48 5: ZWDongle/RAW: /06
2015.05.14 22:02:48 5: ZWDongle/RAW: /0125010205081d71
2015.05.14 22:02:48 5: ZWDongle/RAW: 0125010205081d71/0079000000000000
2015.05.14 22:02:48 5: ZWDongle/RAW: 0125010205081d710079000000000000/0000000000000000
2015.05.14 22:02:48 5: ZWDongle/RAW: 0125010205081d7100790000000000000000000000000000/0000000000000000
2015.05.14 22:02:48 5: ZWDongle/RAW: 0125010205081d71007900000000000000000000000000000000000000000000/000000000500c4
2015.05.14 22:02:48 5: SW: 06
2015.05.14 22:02:48 5: ZWDongle_Read ZWDongle_0: 010205081d71007900000000000000000000000000000000000000000000000000000500


Glück gehabt

EDIT: war ich zu langsam. dabei hab ich mir schon shortcuts für debugging angelegt 

[krikan]

Danke dir. Erkenntnis habe ich leider immer noch nicht wirklich  .
Außer, dass in Zway anscheinend ZW_REPLACE_FAILED_NODE als vorhanden erkannt wird und bei Fhem nicht  .

[micha80]

noch ein Zitat aus der z-way Doku:

Routing Table (Seite 26)
A red indicator shows that there are no good short connections between the two nodes. This does not mean that they are unable to communicate with each other but any route with more than 2 routers between Z-Way is considering as not reliable, even taking into account that Z- Wave supports routes with up to four devices between.

war dir das klar? reliable?

und direkt darunter (Seite 27):

Battery powered devices will report their neighbors when woken up and report their mains powered neighbor correctly. However mains powered devices will report battery-powered devices as neighbors only when routes are updated twice. This is less critical because battery powered devices cant be used as routers and are therefore not relevant for calculating route between two nodes anyway.
The context menu command 'Network Reorganization' allows re-detecting all neighborhood information (battery powered devices will report after their next wakeup!)

d.h. das NeighborUpdate müsste warten, bis die (battery-powerd) node erwacht ist...im Moment wird das Kommando einfach rausgeschickt, kommt also nie an...


get ZWDongle_0 caps:

Code Auswählen Erweitern


==> log/fhem-2015-05-14.log <==
2015.05.14 22:23:59 5: SW: 01030007fb
2015.05.14 22:23:59 5: ZWDongle/RAW: /06012b0107050001
2015.05.14 22:23:59 5: ZWDongle/RAW: 012b0107050001/4704000001fe83ff
2015.05.14 22:23:59 5: ZWDongle/RAW: 012b01070500014704000001fe83ff/88cf1f0000fb9f7d
2015.05.14 22:23:59 5: ZWDongle/RAW: 012b01070500014704000001fe83ff88cf1f0000fb9f7d/a067008080008086
2015.05.14 22:23:59 5: ZWDongle/RAW: 012b01070500014704000001fe83ff88cf1f0000fb9f7da067008080008086/000000e87300000e
2015.05.14 22:23:59 5: ZWDongle/RAW: 012b01070500014704000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e/0000400a0049
2015.05.14 22:23:59 5: SW: 06
2015.05.14 22:23:59 5: ZWDongle_Read ZWDongle_0: 01070500014704000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000400a00


z-way log:

Code Auswählen Erweitern


[2015-05-14 01:53:14.564] [I] [zway] Adding job: Get controller info and supported function classes
[2015-05-14 01:53:14.570] [D] [zway] SENDING: ( 01 03 00 07 FB )
[2015-05-14 01:53:14.571] [D] [zway] RECEIVED ACK
[2015-05-14 01:53:14.580] [D] [zway] RECEIVED: ( 01 2B 01 07 05 00 01 47 04 00 00 01 FE 83 FF 88 CF 1F 00 00 FB 9F 7D A0 67 00 80 80 00 80 86 00 00 00 E8 73 00 00 0E 00 00 40 0A 00 49 )
[2015-05-14 01:53:14.581] [D] [zway] SENT ACK


wo versteckt sich die ZW_REPLACE_FAILED_NODE => 0x63 oder 99b ?

[krikan]

Das erste ist mir eigentlich verständlich. Je mehr Zwischenstationen, desto schlechter (Reaktionsgeschwindikeit, Kollisionsgefahr,..)

[micha80]

macht das Protokoll das automatisch? wenn ja, fallen mir gleich zig kontraproduktive Situationen ein
(Und genau aus dem Grund habe ich mich für z-wave entschieden... mesh network...)

EDIT: die beiden "Zeichenketten" von z-way und fhem sind gleich, also wo versteckt er sich?
01070500014704000001fe83ff88cf1f0000fb9f7da067008080008086000000e87300000e0000400a00