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

[krikan]

@Rudi:
Könntest Du Dir bitte mal die Auswertung der caps anschauen. Irgendetwas ist "komisch". Wenn ich Zeile 333 der ZWDongle.pm abändere auf

Code Auswählen Erweitern

        my $id = sprintf("%02x", $byte*8+$bit+1);
habe ich zumindest die Angabe zu ZW_REPLACE_FAILED_NODE wieder in den caps. Auch die anderen Angaben sind plausibel. Bin aber sehr unsicher.

@Micha:
Wenn Du Zeit hast, könntest Du das vielleicht testen und mit Zway vergleichen. Aber ohne Erfolgsversprechen.

[krikan]

Habe jetzt mal die abweichenden Razberry-Controller-caps laut Angaben von Zway und Fhem hoffentlich tippfehlerfrei in der anliegenden CSV mit den IDs gegenübergestellt. Ich verstehe es nicht, vielleicht hilft es jemand anderem.

[micha80]

Also ich kann dir die geänderten caps geben

Code Auswählen Erweitern


ZWDongle_0 caps => Vers:5 Rev:0 ManufID:0147 ProductType:0400 ProductID:0001 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_0a 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 ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER UNKNOWN_27 UNKNOWN_28 UNKNOWN_29 UNKNOWN_2a UNKNOWN_2b UNKNOWN_2c UNKNOWN_2d ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT 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 ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID UNKNOWN_5e ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 UNKNOWN_b6 UNKNOWN_b7 UNKNOWN_b8 UNKNOWN_b9 UNKNOWN_ba ZW_TYPE_LIBRARY UNKNOWN_be UNKNOWN_bf UNKNOWN_d2 UNKNOWN_d3 UNKNOWN_d4 UNKNOWN_ef UNKNOWN_f2 UNKNOWN_f4


Aber auswerten bzw etwas damit anfangen nicht wirklich...

[krikan]

Danke! 

Mit der obigen Änderung der Zeile 333 auf

Code Auswählen Erweitern

   my $id = sprintf("%02x", $byte*8+$bit+1);

sind die Ausgaben zwischen Zway und Fhem tatsächlich gleich! Dann muss ich mich bei den Trockenübungen mit Deiner Rohmessage vertan haben, da hatte ich ein anderes Ergebnis.
Die Ergebnisse von meinem Controller sind mit der Änderung auch sinnvoller (alle unterstützen Code sind gelistet).

[rudolfkoenig]

Mit der obigen Änderung der Zeile 333 auf...sind die Ausgaben zwischen Zway und Fhem tatsächlich gleich!

Habe die Aenderung eingecheckt.

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

Bin verwirrt: neighborUpdate ist doch ein ZWDongle Befehl, und keins fuer die einzelnen Geraete. D.h. das Befehl soll warten, bis alle batteriegetriebenen Geraete gleichzeitig wach sind? Oder nur irgendeins?

[micha80]

Hi rk,

das neighborUpdate wird doch an die einzelnen Nodes geschickt und verlangt deshalb ja auch eine NodeID.
Müsste das Kommando dann nicht warten, bis genau diese Node wach ist?
was ich immer noch nicht verstehe: ich inkludiere eine battery powerd node (direkt neben dem Controller) und will die dann irgendwo weit weit weg im Haus installieren. Wie kann die wieder nach Hause funken? Dazu bräuchte sie ein neighborUpdate, das kommt aber nie an?! Also wie geht?

in der z-way software und dev Doku wird genau dieses verhalten beschrieben:

Code Auswählen Erweitern


The context menu command 'Network Reorganization' allows re-detecting all neighborhood information (battery powered devices will report after their next wakeup!)

(logfile gefällig? )

Wenn ich das richtig verstanden habe, speichert sich jedes einzelne Gerät seine Routing Tabelle. Also muß Node x wissen, dass sie nur über node y an den Controller kommt, oder wie ist das zu verstehen? Und: wie bringe ich ihr das bei?

mfg
micha

p.s. habt ihr schon die neueste c't gelesen? 

[krikan]

(logfile gefällig? )

Zeig mal, schadet ja nicht, obwohl ich das nicht als vordingliches Problem erachte. Oder hast Du derzeit Routing Probleme?

habt ihr schon die neueste c't gelesen?

Ja und ich befürchtedas Schlimmste...

[rudolfkoenig]

Ich habe jetzt neighborUpdate als set Befehl fuer jedes ZWave Geraet auch hinzugefuegt, damit es fuer batteriebetriebene erst beim Aufwachen gesendet wird. Allerdings mag mein KFOB es nicht, und sagt mir was von CANCEL. Falls jemand ein Problem mit der Implementierung findet, der moege sich melden.

[krikan]

Allerdings mag mein KFOB es nicht, und sagt mir was von CANCEL.

Gleiches Problem hier mit meinem Philio PST02-1A. Bin mir auch nicht sicher, ob das der richtige Weg ist.

Die batteriebetriebenen Geräte sind keine normalen Router, sondern speichern als batteriebetriebene Slaves with routing capabilities nur Nachbarinfos(Routen). Ob zu einer Anpassung dieser Routen ein neigbourUpdate notwendig ist, habe ich erst einmal Zweifel. Mir ist nur verständlich, dass zunächst die batteriebetriebenen aufgeweckt werden müssen und dann erst die neuen Routen/neigbourUpdates für alle Geräte gemacht werdn kann . Am Besten wäre das angedrohte Log...

[krikan]

Ziehe meine Zweifel zurück. neighbourUpdate (0x48) ist nach openX auch bei batteriebetriebenen Geräten zu nutzen. CAN ist wohl wegen langlaufender Prozedur halbwegs normal.

[micha80]

Hallo zusammen,

anbei mal das versprochene Log-File zur Netzwerk-Reorganisation in z-way

Um 12:00 Uhr habe ich auf den "Start"-Knopf im z-way-UI geklickt.
Dürfte dann im Log ab dieser Zeile losgehen:

Code Auswählen Erweitern


[2015-05-19 12:00:25.118] [I] [zway] Adding job: Get routing table line


Geräte: 5,17,23 sind WAKE_UP Geräte. (Wobei ich für 5 zu ungeduldig war  )
12:02 dürfte es Gerät 23 und
12:07 dürfte es Gerät 17 geschafft haben

[krikan]

Danke! Noch eine Bitte :
Könntest Du mir für ein batteriebetriebenes Device bei einer Abfrage mit bspw. "get <device> smStatus" das Telegramm (hinter SENDING im Log) angeben. Mich interessiert dabei vor allem die Drittletzte Zahlenkombination wg. Explorer Frames. Ist das 05 oder 25?

[micha80]

hab ich das richtige erwischt?

Code Auswählen Erweitern


[2015-05-19 16:48:53.219] [I] [zway] Adding job: MultiCmd, SensorMultilevel V5 Get, SensorMultilevel V5 Get
[2015-05-19 16:48:53.219] [D] [zway] SETDATA devices.23.instances.0.commandClasses.132.data.lastSleep = 1432046933 (0x555b4d55)
[2015-05-19 16:48:53.219] [I] [zway] Node 23:0 CC Wakeup: Send node to sleep
[2015-05-19 16:48:53.219] [I] [zway] Adding job: Wakeup Sleep
[2015-05-19 16:48:53.219] [D] [zway] SENDING (cb 0x06): ( 01 18 00 13 17 11 56 01 8F 01 02 04 31 04 01 00 04 31 04 03 08 07 89 05 06 AE )
[2015-05-19 16:48:53.222] [D] [zway] RECEIVED ACK
[2015-05-19 16:48:53.226] [D] [zway] RECEIVED: ( 01 04 01 13 01 E8 )
[2015-05-19 16:48:53.227] [D] [zway] SENT ACK


[krikan]

Ja, danke. Leider bekommt meine Vorstellung zu den Explorer Frames dadurch Risse.... Aber da kannst Du nicht für. Also muss ich weiterforschen.

[micha80]

ich hätte noch ein get battery anzubieten, steht aber auch 05 drin.

Code Auswählen Erweitern


[2015-05-19 16:54:55.109] [I] [zway] Node 23:0 CC MultiCmd: Only one packet fits in MultiCmd - should rather be sent as plain
[2015-05-19 16:54:55.109] [D] [zway] SENDING (cb 0x16): ( 01 0D 00 13 17 06 56 01 80 02 50 58 05 16 3E )
[2015-05-19 16:54:55.111] [D] [zway] RECEIVED ACK
[2015-05-19 16:54:55.115] [D] [zway] RECEIVED: ( 01 04 01 13 01 E8 )
[2015-05-19 16:54:55.115] [D] [zway] SENT ACK
[2015-05-19 16:54:55.115] [D] [zway] Delivered to Z-Wave stack
[2015-05-19 16:54:55.181] [D] [zway] RECEIVED: ( 01 07 00 13 16 00 00 07 FA )
[2015-05-19 16:54:55.181] [D] [zway] SENT ACK
[2015-05-19 16:54:55.181] [I] [zway] Job 0x13 (Battery Get): Delivered
[2015-05-19 16:54:55.181] [D] [zway] SETDATA devices.23.data.lastPacketInfo.delivered = True
[2015-05-19 16:54:55.181] [D] [zway] SETDATA devices.23.data.lastPacketInfo.packetLength = 9 (0x00000009)
[2015-05-19 16:54:55.181] [D] [zway] SETDATA devices.23.data.lastPacketInfo.deliveryTime = 65 (0x00000041)
[2015-05-19 16:54:55.181] [D] [zway] SETDATA devices.23.data.lastPacketInfo = **********
[2015-05-19 16:54:55.182] [D] [zway] SendData Response with callback 0x16 received: received by recipient
[2015-05-19 16:54:55.182] [D] [zway] SETDATA devices.23.data.lastSend = 65264 (0x0000fef0)
[2015-05-19 16:54:55.182] [D] [zway] Job 0x13 (Battery Get): success
[2015-05-19 16:54:55.182] [I] [zway] Removing job: Battery Get
[2015-05-19 16:54:55.232] [D] [zway] RECEIVED: ( 01 0D 00 04 00 17 07 56 01 80 03 51 7B 10 08 )
[2015-05-19 16:54:55.232] [D] [zway] SENT ACK
[2015-05-19 16:54:55.232] [D] [zway] SETDATA devices.23.data.lastReceived = 0 (0x00000000)
[2015-05-19 16:54:55.232] [D] [zway] SETDATA devices.23.instances.0.commandClasses.128.data.history.81 = Empty
[2015-05-19 16:54:55.232] [D] [zway] SETDATA devices.23.instances.0.commandClasses.128.data.history.81 = 1432047295 (0x555b4ebf)
[2015-05-19 16:54:55.232] [D] [zway] SETDATA devices.23.instances.0.commandClasses.128.data.last = 81 (0x00000051)