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.
Habs eingecheckt.
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 8)
; ist in Perl Befehlstrenner. Da in diesem Block {} nur ein Befehl vorkommt, muss man es auch nicht trennen.
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:
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:
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.
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: ??
Hab das Patch eingecheckt.
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.
Eingecheckt.
Vorher habe ich noch weitere 3+64 Leerzeichen am Ende der Zeile vernichtet :)
Zitat von: rudolfkoenig am 18 Mai 2016, 09:12:22
Vorher habe ich noch weitere 3+64 Leerzeichen am Ende der Zeile vernichtet :)
Diese Win-User. 8) 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. :-X
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.
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.
Zitatweil Explorer Frames keine Routeninfos beinhalten.
Kennst du da Details? Bisher sind mir die EF-Daten ein Blackbox.
ZitatWie 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 :)
ZitatKennst 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.
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...
Danke fuer den Hinweis.
Ich muss mal ein groesseres Netz fuer mein ZME-Stick aufbauen, und dann die Nachrichten mit dem CUL ueberwachen.
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...
Die wirkliche Tragweite deines Vorgehens ist mir auch nicht ganz klar, habs aber trotzdem eingecheckt. :)
Kannst du mir erklaeren, wozu ein SUC/SIS gut ist? Ich habe diverse Dokus gelesen, ohne den Sinn verstanden zu haben.
Wie kriegt FHEM mit, wenn ein SUC/SIS ein neues Geraet in das Netzwerk inkludiert hat?
Zitat von: rudolfkoenig am 20 Mai 2016, 09:24:37
Die wirkliche Tragweite deines Vorgehens ist mir auch nicht ganz klar, habs aber trotzdem eingecheckt. :)
OK, zu schwammig formuliert. Bei der Zuweisung der CallbackId bin ich unsicher, ob ich das im Programmablauf korrekt eingebunden habe. Der Aufruf zur Zuweisung der CallbackId funktioniert und die abgesetzten Befehle sind iO.
ZitatKannst du mir erklaeren, wozu ein SUC/SIS gut ist? Ich habe diverse Dokus gelesen, ohne den Sinn verstanden zu haben.
Wie kriegt FHEM mit, wenn ein SUC/SIS ein neues Geraet in das Netzwerk inkludiert hat?
Momentan sehe ich Sinn nur bei mehreren Controllern im Netz zur Erhöhung der Netzwerkstabilität, obwohl zwapi SUC auch bei einem alleinigen Controller empfiehlt. Ob SUC/SIS bei aktuellen ZWave-Geräten wirklich notwendig ist oder nur Komplexität unnötig erhöht, ist eine Frage, die mich selbst noch beschäftigt. (ozw/Zway nutzen mWn SUC)
Information kommt -abhängig vom Setup- iW automatisch über ApplicationControllerUpdate.
Momentan fehlen jedoch auch noch Patches :).
Lass mich noch ein wenig probieren und Gedanken/Quellen sortieren, dann kommen mehr Infos und weitere Patches. Die Funktionen aller SUC/SIS-Patches müsste ich abschließend eigentlich noch im Modul verknüpfen. Bisher experimentiere ich noch über "notify"-Konstrukte. Das ist zwar auch machbar; erfordert aber von den Anwendern viel Einarbeitung.
Anliegend der Patch zur Einbindung von ZW_SEND_SUC_ID und ZW_REQUEST_NETWORK_UPDATE sowie Doku zu den ZW_APPLICATION_UPDATE-Events, worüber Inklusion , Exklusion und SUC/SIS-Infos verbreitet werden.
Mit ZW_REQUEST_NETWORK_UPDATE (sucNetworkUpdate) müssen Sekundär- und Inklusionscontroller aktiv beim SUC/SIS die Routenänderungen anfordern. Die Übermittlung der Änderungen erfolgt automatisch ist für FHEM unsichtbar (Sniff-Fall für ZWCUL)
Mit ZW_SEND_SUC_ID (sucSendNodeId) müssen nach Einrichtung eines SUC/SIS alle Controller (außer Primary) im Netz über die Existenz des SUC/SUS informiert werden. Erst dann funktioniert ZW_REQUEST_NETWORK_UPDATE.
Damit sollten alle grundlegenden Funktionen zur Nutzung eines SUCs, der zur Syncroniserung und zentralen Verwaltung von Routen im Netzwerk dient, implementiert sein.
Bisher umfassenste, aber auch wenig technische Beschreibung des Themas/Konzeptes SUC/SIS habe ich im Paetz unter "Automatische Aktualisierung des Netzes" gefunden. Daraus und zwapi schließe ich mittlerweile, dass ein SUC auch bei nur einem Controller sinnvoll sein kann: Mit einem SUC können Routing Slaves nach "sucRouteAdd" selbstständig eine Aktualisierung der Routen vom SUC anfordern. Ohne SUC (und EF) sollten Routen nach meinem derzeitigen Verständnis manuell über ZW_ASSIGN_RETURN_ROUTE zugewiesen werden (Interpretation aus Paetz Tabelle 3.6). Ob EF den SUC ersetzt ist mir immer noch unklar. Paetz schreibt: Nein.
Details folgen nach weiteren Tests. Insbesondere muss ich noch die ctrlCaps verstehen lernen und evtl. anpassen. Die Ausgaben von ctrlCaps stehen nicht immer im Einklang mit dem Zensys Tool. Ich erkenne das System nur nicht.
Habs eingecheckt
Sollen wir die ZWave-Device-Befehle "sucRouteAdd" und "sucRouteDel" -analog gestrigem versionClass:0-Patch- ausblenden, falls kein SUC/SIS vorhanden ist?
Ja. Wie?
Zitat von: rudolfkoenig am 31 Mai 2016, 17:17:56
Ja. Wie?
Wollte erst mal nur Dein Ok. Einen Code müsste ich erst noch produzieren und insb. probieren. 8)
Vom Grundsatz her: Wenn Reading sucNodeId des zugehörigen ZWDongle eq "no", dann die Befehle nicht anzeigen, sonst wohl.
Wenn Du es selbst machen willst, bin ich auch nicht böse...
Hab was gebaut, bitte testen.
Zitat von: rudolfkoenig am 31 Mai 2016, 17:42:01
Hab was gebaut, bitte testen.
Danke. Mache ich. Bin mit dem Thema vermutlich sowieso noch länger beschäftigt.
Hast Du auf die Schnelle eine einfache Idee, wie ich verhindern kann, dass bei Empfang des NIF für ein ZWave-Device, das noch nicht in FHEM angelegt ist, die Inits automatisch abgearbeitet werden? Also automatische Device-Anlage aber kein Init (insbesondere keine automatische Assoziation).
Hintergrund:
Existenz von 2 FHEM-Instanzen mit je einem USB-Controller mit der gleichen HomeId (=1. ZWave-Netz). In der 1. Instanz sind Controller, FHEM-Device und Gerät vollständig eingerichtet. Wenn jetzt in der 2. Instanz über den SUC der NIF empfangen wird, wird u.a. durch das automatische Setzen der Assoziation im Init die Konfiguration in der 1. Instanz kaputt gemacht.
Achtung, ist noch Forschung.
Am Anfang von ZWave_execInits die gleiche Abfrage wie fuer sucRouteAdd einbauen.
Mit security koenntest du trotzdem noch Probleme kriegen.
Habe ein ungutes Gefuehl, wenn die beiden Dongles an zwei FHEM-Instanzen haengen. Ein FHEM mit den beiden Dongles muesste auch funktionieren, da Dispatch() doppelte Nachrichten (== gleiche Daten von unterschiedlichen IODevs) rausfiltert.
Zitat von: rudolfkoenig am 31 Mai 2016, 19:19:20
Habe ein ungutes Gefuehl, wenn die beiden Dongles an zwei FHEM-Instanzen haengen. Ein FHEM mit den beiden Dongles muesste auch funktionieren, da Dispatch() doppelte Nachrichten (== gleiche Daten von unterschiedlichen IODevs) rausfiltert.
Mach Dir keine Gedanken; das dient nur der Forschung bzw. meinem Verständnis und ist nichts was ich im Endeffekt im Modul als Code sehe. Dispatch() filtert korrekt. Genau das erleichtert mir das Verstehen bisher nicht.
SUC/SIS für den Normalfall -ein USB-Controller und evtl. weitere Fernbedienungen als Controller- sollte übrigens jetzt schon komplett funktionsfähig im Modul sein. Für Deinen Goodway mit SDK 5 dürfte der SUC übrigens die einzige Möglichkeit für automatische Routenkorrekturen/-aktualisierungen sein.
Nach fast 2 Wochen loggen/Tests mit ZWCul und verbose 5 hat jetzt meine SD-Karte im Raspi aufgegeben und ich konnte bis jetzt immer noch kein "Lost"-Frame und RediscoveryNeeded für den SUC finden.
Da ich nur ExplorerFrame-unterstützende Geräte/Controller besitze, könnte es natürlich sein, dass SUC als Routenreparaturmechanismus dann keine Rolle mehr spielt. EFs konnte ich nämlich laut Log häufiger einfangen.
Oder ich habe falsch getestet, der SUC nutzt 9600k oder .. oder ..
Mit dem Thema werde ich erst einmal pausieren und mit neuer SD irgendwann noch einmal anfangen; außer jemand überzeugt mich von Dringlichkeit oder liefert mir neue Ideen. 8)
ZitatDa ich nur ExplorerFrame-unterstützende Geräte/Controller besitze, könnte es natürlich sein, dass SUC als Routenreparaturmechanismus dann keine Rolle mehr spielt.
Das ist auch meine Vermutung.