[patch] Controllerfunktion replaceFailedNode (ZW_REPLACE_FAILED_NODE)

krikan · 02 Oktober 2015, 22:12:30

Anliegender Patch implementiert die Controllerfunktion replaceFailedNode. Mit dem Befehl können NodeIds, die auf der failedNodeList stehen, durch neue Geräte genutzt werden. Habe es mit einem Sensor getestet:
Sensor inkludiert, auf failedNodeList gesetzt, replaceFailedNode aufgerufen, Sensor (nach Reset) in Inklusionmodus gesetzt -> ZW_REPLACE_FAILED_NODE failedNodeReplaceDone und Sensor zeigt normale Funktion. Nebenwirkungen habe ich keine festgestellt.

Ob das nur -wie getestet- beim Austausch von gleichen Geräten funktioniert oder sogar beim Austausch von verschiedenen Geräten (Sensor gegen Aktor) funktioniert, habe ich nicht geprüft.

Empfehlung: Ohne genaue Tests nur beim Austausch/Ersatz von gleichen Geräten nutzen.

@Rudi: kleinere Optimierungen an removeFailedNode sind auch enthalten.

rudolfkoenig · 03 Oktober 2015, 12:19:54

Habs eingecheckt, nach etwas umformatieren, damit es (mAn) leichter lesbar ist.
Dabei fiel mir auf, dass die Werte im Antwort nach einem Bitfeld ausschauen (2,4,8,10,20).
D.h. wenn wir unknown_XX bekommen sollten, dann wissen wir warum.

krikan · 03 Oktober 2015, 15:03:18

Danke.

Versuche bei den Controllerfunktionen die NodeIds über CallbackId in die Events zu bekommen. Es stört mich, dass man anhand der Events nicht nachvollziehen kann, welcher Node betroffen ist. Habe dazu mit der Ausnahme "neigborUpdate" angefangen, da ich dachte, das wäre am Einfachsten. Das funktionierte aber nicht. Nach längerer Ursachensuche habe ich festgestellt, dass die in 10_ZWave.pm (Zeile 689) eingebaute "neigborUpdate"-Funktion anscheinend gar nicht aufgerufen wird. Das neigborUpdate wird direkt versandt. Feststellbar bei mir an den WakeUp-Devices, bei denen das Telegramm direkt verschickt wird, statt im WakeUp-Sendstack zu landen. Folge ist das neigborUpdate bei wakeup-Geräten fehlschlägt.

Kurz: Könntest Du mal bitte gegentesten, ob "neigborUpdate" noch den WakeUp-Sendstack beachtet und überhaupt noch über 10_ZWave.pm läuft !? Danke.

rudolfkoenig · 03 Oktober 2015, 16:08:37

Neighborupdate landet bei WAKE_UP Geraeten auf dem Sendstack, wenn man es am Geraet absetzt (set remote neighborUpdate). Man kann es auch am Dongle absetzen (set ZWDongle neighborUpdate 9), dann wird WAKE_UP nicht beruecksichtigt.

Vorschlag: neighborUpdate fuer ZWDongle entfernen, und neighborList genauso vom ZWDongle nach ZWave verschieben.

krikan · 03 Oktober 2015, 18:06:20

ZitatNeighborupdate landet bei WAKE_UP Geraeten auf dem Sendstack, wenn man es am Geraet absetzt (set remote neighborUpdate). Man kann es auch am Dongle absetzen (set ZWDongle neighborUpdate 9), dann wird WAKE_UP nicht beruecksichtigt.

Genau das ist mein Fehler gewesen. Die Aufrufmöglichkeit über das Gerät ist an mir vorbeigegangen. Hätte ich mal sofort gefragt..

Bei Abruf neigborUpdate über das Gerät bekomme ich abschließend immer die10s NO_ACK-Meldung:

Code Auswählen

2015.10.03 17:45:58 2: ZWave set ZWave_SWITCH_BINARY_6 neighborUpdate 
2015.10.03 17:45:58 5: ZWDongle_Write 00 480606
2015.10.03 17:45:58 5: SW: 010500480606b2
2015.10.03 17:45:59 5: ACK received, removing 010500480606b2 from dongle sendstack
2015.10.03 17:45:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480621
2015.10.03 17:45:59 5: SW: 06
2015.10.03 17:45:59 5: ZWDongle_0 dispatch 00480621
2015.10.03 17:45:59 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.10.03 17:45:59 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.10.03 17:45:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480621
2015.10.03 17:45:59 5: SW: 06
2015.10.03 17:45:59 5: ZWDongle_0 dispatch 00480621
2015.10.03 17:45:59 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.10.03 17:45:59 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.10.03 17:45:59 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480622
2015.10.03 17:45:59 5: SW: 06
2015.10.03 17:45:59 5: ZWDongle_0 dispatch 00480622
2015.10.03 17:45:59 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.10.03 17:46:00 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done
2015.10.03 17:46:08 2: ZWave: No ACK from ZWave_SWITCH_BINARY_6 after 10s for sent:480606

Beim Aufruf über ZWDongle habe ich das nicht:

Code Auswählen

2015.10.03 17:48:32 4: ZWDongle set ZWDongle_0 neighborUpdate 6
2015.10.03 17:48:32 5: ZWDongle_Write 00 4806
2015.10.03 17:48:32 5: SW: 0104004806b5
2015.10.03 17:48:33 5: ACK received, removing 0104004806b5 from dongle sendstack
2015.10.03 17:48:33 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480621
2015.10.03 17:48:33 5: SW: 06
2015.10.03 17:48:33 5: ZWDongle_0 dispatch 00480621
2015.10.03 17:48:33 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.10.03 17:48:33 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.10.03 17:48:33 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480621
2015.10.03 17:48:33 5: SW: 06
2015.10.03 17:48:33 5: ZWDongle_0 dispatch 00480621
2015.10.03 17:48:33 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.10.03 17:48:33 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.10.03 17:48:34 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480622
2015.10.03 17:48:34 5: SW: 06
2015.10.03 17:48:34 5: ZWDongle_0 dispatch 00480622
2015.10.03 17:48:34 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.10.03 17:48:34 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done
2015.10.03 17:50:56 2: SONOS1: Discover Sonosplayer 'Jan' (S1) Software Revision 5.4 with ID 'RINCON_B8E937E'

Kommt von meinem Produktivsystem. Testsystem kann ich momentan nicht gegenchecken.

ZitatVorschlag: neighborUpdate fuer ZWDongle entfernen, und neighborList genauso vom ZWDongle nach ZWave verschieben.

Guter Vorschlag, dann fällt man auch nicht darauf rein. Das betrifft dann aber letztlich alle Node-bezogenen Controller-Befehle.
Spricht denn etwas dagegen, dass die Ergebnisse der Befehle auch in den Readings der Devices landen, statt nur als Events generiert zu werden?

rudolfkoenig · 04 Oktober 2015, 17:33:57

Ich habe vmtl. ein Bug im Geraete-neighborUpdate ausgebaut, bitte nochmal testen, bei mir tut es.

Weiterhin sind beide Kommandos nur noch ueber das eigentliche Geraet aufrufbar (ZWDongle -> ZWave), neighborList erzeugt ein Reading/Event und loest die nodeIds soweit moeglich auf.

krikan · 04 Oktober 2015, 20:30:14

Habe getestet und keine direkten Probleme festgestellt, außer dass ich die No ACK-Meldung immer bekomme:

Code Auswählen

2015.10.04 19:48:36 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 neighborList 
2015.10.04 19:48:36 5: ZWDongle_Write 00 80040101
2015.10.04 19:48:36 5: SW: 010600800401017d
2015.10.04 19:48:36 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.10.04 19:48:36 5: ACK received, removing 010600800401017d from dongle sendstack
2015.10.04 19:48:36 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 01802000000600000000000000000000000000000000000000000000000000
2015.10.04 19:48:36 5: SW: 06
2015.10.04 19:48:36 4: ZWDongle_ReadAnswer for neighborList: 01802000000600000000000000000000000000000000000000000000000000
2015.10.04 19:48:46 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 10s for sent:80040101

Könnte aber auch an meinem überlasteten Raspi/Dongle liegen.