[patch] SUC/SIS einrichten/abfragen

Begonnen von krikan, 05 Mai 2016, 21:14:55

Vorheriges Thema - Nächstes Thema

rudolfkoenig

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?

krikan

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

krikan

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.

rudolfkoenig


krikan

Sollen wir die ZWave-Device-Befehle "sucRouteAdd" und "sucRouteDel" -analog gestrigem versionClass:0-Patch- ausblenden, falls kein SUC/SIS vorhanden ist?

rudolfkoenig


krikan

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

rudolfkoenig


krikan

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.

rudolfkoenig

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.

krikan

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.

krikan

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)

rudolfkoenig

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.