FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: krikan am 05 Mai 2016, 21:14:55

Titel: [patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 05 Mai 2016, 21:14:55
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 06 Mai 2016, 08:33:02
Habs eingecheckt.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 06 Mai 2016, 21:51:03
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)
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 06 Mai 2016, 22:03:02
; ist in Perl Befehlstrenner. Da in diesem Block {} nur ein Befehl vorkommt, muss man es auch nicht trennen.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 08 Mai 2016, 21:47:38
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 08 Mai 2016, 22:32:47
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: ??
            
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 09 Mai 2016, 09:45:57
Hab das Patch eingecheckt.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 17 Mai 2016, 23:57:15
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 18 Mai 2016, 09:12:22
Eingecheckt.
Vorher habe ich noch weitere 3+64 Leerzeichen am Ende der Zeile vernichtet :)
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 18 Mai 2016, 18:37:40
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 18 Mai 2016, 19:17:05
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 :)
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 18 Mai 2016, 20:51:08
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 19 Mai 2016, 14:17:28
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...
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 19 Mai 2016, 15:28:32
Danke fuer den Hinweis.
Ich muss mal ein groesseres Netz fuer mein ZME-Stick aufbauen, und dann die Nachrichten mit dem CUL ueberwachen.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 20 Mai 2016, 00:01:13
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...
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 20 Mai 2016, 09:24:37
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?
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 20 Mai 2016, 10:35:40
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 21 Mai 2016, 16:05:08
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 21 Mai 2016, 21:18:05
Habs eingecheckt
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 31 Mai 2016, 17:03:00
Sollen wir die ZWave-Device-Befehle "sucRouteAdd" und "sucRouteDel" -analog gestrigem versionClass:0-Patch- ausblenden, falls kein SUC/SIS vorhanden ist?
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 31 Mai 2016, 17:17:56
Ja. Wie?
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 31 Mai 2016, 17:27:24
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...
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 31 Mai 2016, 17:42:01
Hab was gebaut, bitte testen.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 31 Mai 2016, 18:05:00
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 31 Mai 2016, 19:19:20
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 31 Mai 2016, 20:07:29
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.
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: krikan am 09 Juni 2016, 17:16:35
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)
Titel: Antw:[patch] SUC/SIS einrichten/abfragen
Beitrag von: rudolfkoenig am 09 Juni 2016, 17:31:27
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.