[patch] SUC/SIS einrichten/abfragen

[krikan]

Anliegender Patch implemtiert ZW_SET_SUC_NODE_ID und ZW_GET_SUC_NODE_ID.

Habe das mit meinem PrimaryController getestet. Empfehlung von zwapi ist Einrichtung SUC, wenn nur der Primary existiert.

Nicht testen kann ich die Einrichtung von SUC/SIS auf einem per Funk angebundenen Sekundärcontroller. ZW_SET_SUC_NODE_ID wird mit transmitFlag für ExplorerFrames aufgerufen, so das es auch funktionieren sollte. Es werden vermutlich nur unhandeld Answer auftreten, da ich in Trockenübung die Rückgabewerte nicht herausfinden kann.

Die Abfrageergebnisse von ctrlCaps sind hinsichtlich SUC/SIS mMn noch unscharf. Kommt auf Todo.

[rudolfkoenig]

Habs eingecheckt.

[krikan]

Bei der Nachkontrolle meines eigenen Patches wundere ich mich über fehlendes, abschließendes Semikolon:

Zeile 397:   $msg = ($r[2]==0)?"no":hex($r[2])

Warnung erhalte ich dafür nicht und Funktionsfehler kann ich auch nicht feststellen. Nach meinem Perl-Buch und diversen Internetbeispielen müsste es aber wohl so lauten:

Zeile 397:   $msg = ($r[2]==0)?"no":hex($r[2]);

Fazit: Habe keine Ahnung und wollte es nur anmerken 

[rudolfkoenig]

; ist in Perl Befehlstrenner. Da in diesem Block {} nur ein Befehl vorkommt, muss man es auch nicht trennen.

[krikan]

Anliegender Patch bindet ZW_SET_SUC_NODE_ID-Events für funkangebunde (Sekundär-)controller ein. Eventnummern habe ich experimentiell ermittelt.
SUC-Anlage/Löschung ist bei funkangebundenen Controllern nur erfolgreich, wenn der Event "setSucNodeCallbackSucceeded" kommt. Dummerweise kommt zunächst "setSucNodeOk" egal ob der Befehl im Endeffekt erfolgreich ist.

Beim Befehlsaufruf habe ich noch jeweils ein nicht-interpretiertes Telegramm. Ist vermutlich "ApplicationControllerUpdate". Genaue Bedeutung habe ich noch nicht gefunden. Vermutlich aber unerheblich, da es nur eine Info ist.

SUC-Anlage:

Code Auswählen Erweitern

2016.05.08 21:22:25.894 5: ZWDongle_0 dispatch 0049103500
2016.05.08 21:22:25.895 4: CMD:ZW_APPLICATION_UPDATE ID:35 ARG:00 CB:10
2016.05.08 21:22:25.895 2: ZW_REQUEST_NODE_INFO unknown 10

SUC-Löschung:

Code Auswählen Erweitern

2016.05.08 21:24:43.535 5: ZWDongle_0 dispatch 0049100000
2016.05.08 21:24:43.536 4: CMD:ZW_APPLICATION_UPDATE ID:00 ARG:00 CB:10
2016.05.08 21:24:43.536 2: ZW_REQUEST_NODE_INFO unknown 10

Dann habe ich noch ein hex() aus dem ersten Patch entfernt. Sonst stimmt die NodeId aus dem get-Befehl nicht.

[krikan]

Code Auswählen Erweitern

ZWDongle_0 dispatch 0049103500
0x00: REQ
0x49: ApplicationControllerUpdate
0x10: UPDATE_STATE_SUC_ID (laut https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/Defs.h)
0xZZ: NodeId SUC : 0x00=kein SUC
0x00: ??
            

[rudolfkoenig]

Hab das Patch eingecheckt.

[krikan]

Anliegend Korrekturpatch für SUC/SIS-Einrichtung auf funkangebundenen Controller. Hatte die transmitOption falsch gesetzt. Es gibt keine ExplorerFrames, sondern nur die Wahl für normal/low power und  ist aufgrund meines Fehlers bisher auf low power. Der Patch setzt das fix auf normal power.

Da das ein kurzfristiger, fehlerbehebender "Hotfix"   ist, enthält der Patch auch noch andere unkritische Änderungen aus meinem Testsystem:
Events für ZW_APPLICATION_UPDATE (Controller) sind eingebaut, aber noch nicht dokumentiert.
Doku hinsichtlich <> angepasst; ZWDongle-Events den Befehlen zugeordnet und andere Kleinigkeiten.

[rudolfkoenig]

Eingecheckt.
Vorher habe ich noch weitere 3+64 Leerzeichen am Ende der Zeile vernichtet

[krikan]

Vorher habe ich noch weitere 3+64 Leerzeichen am Ende der Zeile vernichtet

Diese Win-User.   Dabei hatte ich für 00_ZWDongle.pm die automatische Leerzeichenlöschung am Zeilenende eingeschaltet. Der Patch hatte aber trotzdem Leerzeichen bei 00_ZWDongle.pm am Zeilenende. 


Btw.: Hast Du eine Ahnung/Theorie ob die Routen manuell mit ZW_AssignReturnRoute (hier: ZW_AssignSUCReturnRoute) gesetzt werden müssen. Bisher war meine Annahme, dass Explorer Frames Routen setzen können, aber langsam bekomme ich Zweifel, weil Explorer Frames keine Routeninfos beinhalten. Wie sollen sich dann die Routen aktualisieren. Leider habe ich noch keine verlässliche Quelle zum Thema gefunden.

[rudolfkoenig]

Ich habe keine Ahnung, wie man ZW_AssignReturnRoute parametrisieren muss, wuesste es aber sehr gerne. Ich meine ich habe damit kurz experimentiert, ohne sichtbaren Erfolg. Ich habe aber bei ZWCUL gesehen, dass wenn ich einem Node eine Frage auf einem bestimmten Weg schicke (siehe das zwaveRoute Attribut), dann kommt die Antwort ueber den umgekehrten Weg zurueck.

weil Explorer Frames keine Routeninfos beinhalten.

Kennst du da Details? Bisher sind mir die EF-Daten ein Blackbox.

Wie sollen sich dann die Routen aktualisieren

Da ist ja einiges denkbar, z.Bsp. speichert jeder Knoten, ob er die Daten das letze Mal erfolgreich weiterschicken konnte, und wenn ja, ueber welchen Weg. Ein bisschen Route-Information im EF waere dazu schon nuetzlich, gebe ich zu

[krikan]

Kennst du da Details?

Leider nicht. Steht nur wörtlich im Paetz bei der Definition von Explorer Frames im Abschnitt "Automatische Aktualisierung des Netzes". Dort wird  auch SUC erläutert,  obwohl das ein manuelles ZW_AssignSUCReturnRoute auf Progammebene voraussetzt. Darum wurde ich hinsichtlich Explorer Frames mißtrauisch. Hiernach http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames (auch Paetz?) "The explorer frame will eventually reach its destination and update the routing table automatically this way." muss es automatisch gehen. Weiteres Indiz: Mir ist kein Weg bekannt, programmgesteuert festzustellen,dass der Controller einen Explorer Frame erhalten hat, um dann per Programm ZW_AssignReturnRoute o.ä. aufzurufen.

[krikan]

Nach https://de.scribd.com/doc/140919912/Getting-Started-With-Z-Wave-INS11469-2 auf Seite 21 werden in EF NodeIds weitergereicht. Detaillierte Erläuterung wäre aber anders...

[rudolfkoenig]

Danke fuer den Hinweis.
Ich muss mal ein groesseres Netz fuer mein ZME-Stick aufbauen, und dann die Nachrichten mit dem CUL ueberwachen.

[krikan]

Bin mal auf die Ergebnisse gespannt. Zumindest gehe ich nun wieder davon aus, dass Explorer Frames Routingprobleme auf Protokollebene eigenständig lösen können.

Zurück zum SUC/SIS:
Den Slaves muss zwingend der SUC mit ZW_ASSIGN_SUC_RETURN_ROUTE durch das Programm (FHEM) bekannt gemacht werden, damit SUC/SIS-Konzept zur Lösung von Routingproblemen beitragen kann. Gelöscht wird mit ZW_DELETE_SUC_RETURN_ROUTE. Beide Funktionen habe ich als  sucRouteAdd und sucRouteDel im anliegenden Patch eingearbeitet. Die Befehle müssen über das ZWave-Device aufgerufen werden, damit Wakeup-Sendstack greift. Lieber, weil unaufdringlicher, wäre mir der Aufruf über ZWDongle gewesen. Zudem brauchte ich eine CallbackId beim Aufruf der Funktion. Ohne CallbackId streikt mein Controller beim massenhaften Absetzen des ASSIGN_SUC_RETURN_ROUTE - Befehls nach einiger Zeit, während mit CallbackId alles durchlief. Habe es jetzt so gelöst, dass auch bei neigbhorUpdate die Callbackid angehängt wird. Habe beim Test keine Probleme festgestellt, bin mir aber der wirklichen Tragweite meines Vorgehens nicht sicher...