Network wide inklusion und Explorer frames

[krikan]

Das ist Fortsetzung und Vertiefung von http://forum.fhem.de/index.php/topic,37121.msg294914.html#msg294914 zurInklusion mit "network wide" (Bit = 0x40)

Habe nochmals zwapi, Aussagen im zwave.me Forum und insbesondere Logs von diversen Programmen zu den Treadthemen durchsucht. Danach vermutete ich, dass network wide inklusion (nwi) und Explorer Frames, die mit SDK 4.5 eingeführt wurden, in direktem Zusammenhang stehen.

Testhalber habe ich in 00_ZWDongle.pm bei der Inklusion das Bit 0x40 für die nwi (ADD_NODE_OPTION_NETWORK_WIDE) und zudem in 10_ZWave.pm bei SENDDATA die TRANSMIT_OPTION_EXPLORE für alle Übertragungen aktiviert (statt 05 den Wert 25). Diese Fassungen habe ich mit den folgenden Testgeräten (alle unterstützen Explore Frames)
- Dongle SDK 6
- batteriegspeistes Gerät SDK 6.5
- 2 netzbetriebene Einbau-Gerät SDK 4.5
- netzbetriebenes Stecker-Gerät SDK 6.5
und diversen Tests versucht mit dem Verhalten bei den originalen Dateien aus dem SVN zu vergleichen. Geräte/Dongle habe ich jeweils vorher zurückgesetzt.

Schlußfolgerungen:
- Inklusion ist mit der geänderten Variante auch in großen Entfernung problemlos möglich, bei der die SVN-Fassungen scheitern
- Die Explore Frames scheinen mit der geänderten Variante zu funktionieren: während mit den SVN-Fassungen beim Herausnehmen des Stecker-Gerätes das batteriegespeiste Gerät nicht erreicht wurde, funktioniert das bei der geänderten Variante problemlos.

Ein neigbourUpdate habe ich bei meinen Tests (bewußt) nicht durchgeführt, da ich auf die "Selbstheilung" der Explore Frames gesetzt habe.

Probleme habe ich bei der geänderten Fassung keine festgestellt. Jedoch kann ich nicht abschätzen, ob bei und mit alten SDK5-Geräten und Dongles Probleme auftreten. Wenn ich zwapi richtig verstehe, sollten die zusätzlichen/geänderten Bits bei den alten SDK 5 Devices ignoriert werden, also zu keinen Problemen führen. Aber das bleibt ein Risiko wegen fehlender Tests.

Am Schluß noch ein Link, auf die Aussage eines Offiziellen im Zwave.me Forum zum Problem von batteriebetrieben Devices ohne Explorer Frame Support http://forum.z-wave.me/viewtopic.php?f=3422&t=20440&p=51265&hilit=explorer+frames#p51289

[rudolfkoenig]

Verstehe ich richtig: du hast keine Probleme mit 0xc1 entdeckt, weisst aber nicht, ob es in manchen Faellen nicht doch problematisch ist. Ich schlage vor, wir aendern 0x81 in 0xc1, und warten ab, ob jemand was meldet. Gegenvorschlaege?

[krikan]

Ja, meine Geräte sind alle aktuell (SDK4.5 und SDK 6.x).
Ich  habe keine Ahnung, was bei den Geräten mit dem alten SDK 5.x  (Aeon Labs S2-Stick, DÜWI,..) passiert, da ich das nicht testen kann.

Kannst Du gerne auf 0xc1 ändern, ist aber nach meiner Meinung nur mit Hinzufügen der TRANSMIT_OPTION_EXPLORE bei SENDDATA überhaupt nutzbar (-> Zeile 587 10_ZWave.pm: 25 statt 05 und bei wakeUpNoMoreInformation)

Also wenn schon, dann bin ich für doppeltes Risiko.

Gut wäre aber dennoch, wenn einer es kurz gegencheckt.

[krikan]

Gut wäre aber dennoch, wenn einer es kurz gegencheckt.

Das heißt natürlich nicht meine Tests, sondern nur ob bei SDK5.x oder älter noch Inklusion und Kommunikation funktioniert.

[krikan]

Code Auswählen Erweitern

Ich schlage vor, wir aendern 0x81 in 0xc1,
Das kannst Du vielleicht zunächst machen.

Bei den Explore frames habe ich im Log mit meiner genannten Änderung noch ein Problem gefunden (callback bei get fehlt). Funktion ist aber mit meinen genannten minimalen Änderungen gegeben; zumindest habe ich keine Fehler hier im Produktivbetrieb entdecken können.
Für die Explore Frames würde ich Dir einen Patch machen, wenn ich meine auch callback im Griff zu haben. Es sei denn, Du willst an Explore Frames nicht ran.

[krikan]

Kennt jemand eine Möglichkeit, wie ich die Telegrammlaufzeit (Sending bis ACK) messen kann? Am liebsten wäre mir eine entsprechende Funktion des Controller. Gibt es so etwas?

[rudolfkoenig]

Mit mseclog kommst du vmtl. dem eigentlichen Wert nahe, ein Call dafuer kenne ich aber nicht, und wuerde es auch nicht vom API erwarten.

[krikan]

Explorer Frames:

Mein ursprünglicher Gedankengang war, einfach bei allen versandten Telegrammen mit 0x25 die Optionen ACK, AUTO_ROUTE und EXPLORE zu aktivieren. Dadurch sollten nach meiner Auffassung die Explorer Frames nur als letzte Variante genutzt werden, wenn die Empfänger eines Telegramms nicht direkt oder über bekannte Routen erreicht werden. Nachdem ich gestern Einsicht in ein ausführliches Log von zway genommen hatte, musste ich feststellen, dass dort die Explorer Frames anscheinend nur bei Inklusion und bei Problemen in der Funkkommunikation (failed Nodes) eingeschaltet wurden. Nach einigen Telegrammen wurde wieder auf 0x05 zurückgeschaltet (Warum?, Wann?). Dass das bei diesem Programm kein Einzelfall ist, habe ich im Forum entsprechend auch bei einem User festgestellt. Ausführliche Logs von anderen Programmen konnte ich leider nicht per Suchmaschine finden.

Die Nutzung der Explorer Frames soll eine hohe Funklast auslösen. Daher bin ich über das Zurückschalten auf 0x05 verunsichert. War mein erster Gedankengang falsch und wird sobald auf 0x25 umgeschaltet wird per Exporer Frames verschickt und eine unnötig hohe Funklast erzeugt? Testhalber habe ich (mit msceclog) jeweils ein paar Stunden die Telegramme jeweils einmal mit 0x05 und einmal 0x25 verschickt. Funktionseinschränkungen habe ich bei 0x25 wie auch zuvor nicht finden können. In den Logs habe ich keine Auffäligkeiten festgestellt: Die Telegrammlaufzeiten waren in beiden Fällen schwankend zwischen 8 und 16. Eine höhere Funklast, die sich nach meiner laienhaften Meinung in längeren Laufzeiten ausdrücken könnte, kann ich nicht erkennen. Per Zufall bin ich mit google auf das mir vorher unbekannte Dokument INS10682-9 (nur Flash) gestoßen. Dort werden die SENDDATA-Optionen  auf S. 10f. erläutert. Nur leider bin ich danach auch nicht wirklich schlauer: Ist 0x25 als Standardoption in irgendeiner Form ungünstig?

Hat dazu vielleicht jemand ein besseres Verständnis oder Ideen?

Danke.

[rudolfkoenig]

In dem erwaehnten Dokument steht: "Transmit frame as an explore frame if everything else fails.". Klingt nach ungefaehrlich

[krikan]

Network wide inklusion (Patch):

Anhängend der Patch für nwi. Habe nwi über ein zusätzlichen Modus "nwOn" für addNode gelöst. Für ein Ersetzen von 0x81 durch 0xc1 bei "on" habe ich erst einmal mangels Testcontroller mit SDK vor 4.5 bzw. SDK 5 nicht genug Mut gehabt. Im Fazit fände ich das aber besser, da "nwOn" mehr Inklusionserfolg als "on" verspricht. Entsprechend bin ich bei removeNode vorgegangen.


Explorer  Frames:

Danke für Deine Einschätzung. Der von Dir zitierte Satz  war mein Ausgangspunkt; die Seite 10 im genannten Dokument zur Kombination der Options und z-way haben mich irritiert. Bin nun wieder bei meiner ursprünglichen Meinung. Gestützt wird das auch durch Openzwave. Habe mir den Code von Openzwave angeschaut und nach meinem Nicht-Programmierer-Verständnis, schickt Openzwave standardmäßig mit 0x25. Ausnahmen scheint es nur sehr wenige zu geben (bspw. Class SECURITY), die aber nach meiner Ansicht derzeit in Fhem keine Rolle spielen. Einen Patch habe ich noch nicht, da ich immer noch Probleme bei den Callbacks im Log festelle. Halte die Explorer Frames-Unterstützung aber weiterhin für eine sehr wichtige Funktion zur Netzwerkstabilität. Bleibe also dran. Einen kurzen Überblick erhält man durch Suche von "Tabelle 3.6: Vergleich verschiedener Methoden zum Korrigieren von Routen" in eine Internetsuchmaschine.

[rudolfkoenig]

Hab dein Patch eingecheckt, der ist in dieser Form sicher unproblematisch.
Wo hast du die WATCHDOG-Definitionen her? Ich will Hunde nur ungern treten...

[krikan]

Wo hast du die WATCHDOG-Definitionen her? Ich will Hunde nur ungern treten...

Aus INS11095-2 kopiert. Mich störte UNKNOWN beim Durchforsten der Commands.

[krikan]

Nur zur Info zu NWI:
openzwave nutzt seit gestern standardmäßig "Network Wide Inclusion", wenn highpower-Option eingeschaltet ist: https://github.com/OpenZWave/open-zwave/commit/dc67ae71a13a167c535b85c190e2b380d4e5a279.

[krikan]

Nur zur Info zu NWI:
openzwave nutzt seit gestern standardmäßig "Network Wide Inclusion", wenn highpower-Option eingeschaltet ist: https://github.com/OpenZWave/open-zwave/commit/dc67ae71a13a167c535b85c190e2b380d4e5a279.

Aktualisierung:
Mittlerweile prüft ozw, ob der Controller FUNC_ID_ZW_EXPLORE_REQUEST_INCLUSION unterstützt. Falls ja, wird Network-Wide-Inklusion genutzt, andernfalls Standard-Inklusion
(https://github.com/OpenZWave/open-zwave/commit/ad7068e91d7ede31200ee33a96b2b6c65fbb6232)

----

@Rudi
(andere dürfen sich aber auch gerne beteiligen)

Bei der Einbindung der Explorer Frames würde ich pro ZWave-Device ein Attribut "useExplorerFrames" einbauen, das standardmäßig auf 1 (yes) steht.

Hintergrund:
Explorer Frames würde ich zunächst immer bei allen Devices aktivieren. Jedoch erzeugen Explorer Frames, wenn sie genutzt werden müssen, wohl recht hohe Funklast. Ist ein Device länger nicht erreichbar (transmit NO_ACK), möchte ich die automatische Möglichkeit haben, Explorer Frames auszuschalten (bspw. nach 3 erfolglosen Versuchen). Zudem hätte man dann flexibel die Möglichkeit Device-spezifisch ohne Explorer Frames zu arbeiten, was angesichts der diversen Unsicherheiten beim Thema, vielleicht hilfreich sein könnte. Im Test bei meinem Kleinsystem ist diese Attributlösung ohne erkennbare Probleme möglich.

Jedoch kann ich nicht überblicken:
- ist das Attribut ein gangbarer und sinnvoller Weg?
- erzeugt die Abfrage des Attributs vor jedem Telegramm zu viel Rechenlast?

[rudolfkoenig]

Ich sehe gar keine Probleme mit der vorgeschlagenen Loesung, ich wuerde es auch so machen.