Gleichzeitiges Absetzen von "neighborUpdate" für mehrere Geräte

krikan · 13 Juni 2016, 16:45:12

Habe heute einmal versucht ein "neighborUpdate" mit einer RegEx-devspec aufzurufen ("set ZWave_SWITCH_MULTILEVEL.* neighborUpdate", usw).
neighborUpdate scheitert in diesen Fällen bei mehr als 2 matchenden Geräten reproduzierbar jeweils mit dem Event "ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed". Wenn nur 2 Devices angesprochen werden, wird teilweise ein neigborUpdate ordnungsgemäß mit "ZW_REQUEST_NODE_NEIGHBOR_UPDATE done" abgeschlossen; das andere scheitert wieder.

Dann habe ich ein neigbhorUpdate gestartet und weitere per notify auf "ZW_REQUEST_NODE_NEIGHBOR_UPDATE started" gestartet. Auch hier scheitern die neighborUpdates zumeist mit "failed". Wobei das Vorgehen häufiger zum Erfolg "done" führt als per RegEx-devspec.

Zuletzt bin ich hingegangen und habe ein weiteres neighborUpdate für ein weiteres Gerät erst bei "ZW_REQUEST_NODE_NEIGHBOR_UPDATE done" oder "ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed" starten lassen. Dieser Ablauf lässt die neighborUpdate problemlos auch über mehrere Geräte hinweg durchführen.

Meine Schlußfolgerungen/Vermutung für meine Umgebung: Ein neighborUpdate-Befehl an den Controller/Gerät muss mit "done" oder "failed" abgeschlossen sein, bevor der nächste neigborUpdate-Befehl an den Controller weitergegeben werden darf. Wenn jemand anderes feststellt, bitte melden.

rudolfkoenig · 13 Juni 2016, 17:08:59

Ich tippe darauf, dass bei einem ausstehenden ZW_REQUEST_NODE_NEIGHBOR_UPDATE auch andere Befehle (set/get) schiefgehen: der ZWDongle Firmware ist nicht in der Lage, mehrere nicht abgeschlossene Aufgaben parallel zu bearbeiten. Das wird in FHEM fuer get bereits beachtet, neighborUpdate muesste also zu einem "get" werden.

Eigentlich brauchen wir ein "neighborUpdateAll", was der Reihe nach die Geraete abklappert.

krikan · 13 Juni 2016, 19:00:02

Zitat von: rudolfkoenig am 13 Juni 2016, 17:08:59
Ich tippe darauf, dass bei einem ausstehenden ZW_REQUEST_NODE_NEIGHBOR_UPDATE auch andere Befehle (set/get) schiefgehen

Habe ich nicht probiert. Aber sicherlich hast Du recht. Unangeforderte Nachrichten wurden teilweise korrekt verarbeitet.

ZitatDas wird in FHEM fuer get bereits beachtet, neighborUpdate muesste also zu einem "get" werden.

Einziger Controllerbefehl bei den ZWave-Devices ist derzeit neighborList und das funktioniert so als Vorlage nicht.

ZitatEigentlich brauchen wir ein "neighborUpdateAll", was der Reihe nach die Geraete abklappert.

Das wäre dann im ZWDongle-Device? Ich wollte über die devspec-Nutzung das über den vorhandenen ZWave-Device-Befehl probieren.

Bei ZW_ASSIGN_RETURN_ROUTE und den anderen von mir eingebundenen Controller-Befehlen gibt es mit Regex-devspecs auch noch Probleme; denke das dürfte ein ähnliches Problem sein.

rudolfkoenig · 13 Juni 2016, 21:30:36

ZitatEinziger Controllerbefehl bei den ZWave-Devices ist derzeit neighborList und das funktioniert so als Vorlage nicht.

Hab mich versucht beim Umbau, und bin dran gescheitert.
Was mir aufgefallen ist: wir warten nur bei den get des gleichen Geraetes auf die Antwort, bevor wir weitermachen, bei mehreren Geraeten laeuft es parallel ab. Scheinbar funktioniert es auch parallel, habe es aber nur mit 2 probiert.
Fuer "get neighborList" muesste ich eine Sonderbehandlung machen oder alle gets in einem Topf werfen, beides ist mir jetzt zu viel.

krikan · 13 Juni 2016, 21:46:20

Keine Eile.

Zitatwir warten nur bei den get des gleichen Geraetes auf die Antwort, bevor wir weitermachen, bei mehreren Geraeten laeuft es parallel ab. Scheinbar funktioniert es auch parallel, habe es aber nur mit 2 probiert.

Ist mir bisher nicht aufgefallen. Habe aber mit dem Sendstack sowieso meine (Verständnis-)Probleme.

A.Harrenberg · 13 Juni 2016, 22:30:02

Hi Christian,

Zitat von: krikan am 13 Juni 2016, 21:46:20
Habe aber mit dem Sendstack sowieso meine (Verständnis-)Probleme.

willkommen im Club

Hoffentlich kommt übermorgen mein neues (gebrauchtes) Laptop, das muss ich dann "nur" noch auf Windows 10 updaten und mir 'ne virtuelle Linux-Maschine da drauf knallen, dann kann ich das Ding dann übernächste Woche mit in Urlaub nehmen und schauen ob ich eure ganzen Änderungen nachvollzogen bekomme.

Gruß,
Andreas.

krikan · 14 Juni 2016, 09:50:38

Zitat von: A.Harrenberg am 13 Juni 2016, 22:30:02
Hi Christian,willkommen im Club

Na ja, immerhin verstehst Du sicherlich den SECURITY-Code um den ich einen großen Bogen mache...

Zitat
Was mir aufgefallen ist: wir warten nur bei den get des gleichen Geraetes auf die Antwort, bevor wir weitermachen, bei mehreren Geraeten laeuft es parallel ab. Scheinbar funktioniert es auch parallel, habe es aber nur mit 2 probiert.

Bei meinem Controller mit 4er Chipsatz funktioniert ein gleichzeitiges get bei einem laufenden neighborUpdate (verschiedene Geräte) nicht zuverlässig. Die Nachrichten gehen teilweise durch CANs verloren. Was mich wundert: Werden nicht 3 Sendeversuche von ZWave-Geräten bei CAN an den Controller durchgeführt? Ich sehe bei allen bisherigen Versuchen nur eine.

A.Harrenberg · 14 Juni 2016, 21:24:25

Hi Christian,

Zitat von: krikan am 14 Juni 2016, 09:50:38
Na ja, immerhin verstehst Du sicherlich den SECURITY-Code um den ich einen großen Bogen mache...

na ja, das ist jetzt auch schon 'ne Weile her das ich mich damit beschäftigt habe. Aber die "high-level" Funktionen sind ja für das System mehr oder weniger transparent. Die Nachrichten werden "normal" erzeugt, dann "abgefangen und verschlüsselt versendet", davon bekommt man im Normalfall ja nichts mit. Beim Empfang ist es ähnlich, die verschlüsselte Nachricht wird abgefangen, entschlüsselt und dann wieder "normal" per Dispatch verarbeitet.

Die "low-level" Funktionen, also die Verschlüsselung an sich habe ich damals eng an OZW angelehnt, wobei dort sogar ein Fehler drin war... Die Funktionsweise der Verschlüsselung habe ich auch nicht wirklich verstanden, dazu muss man glaube ich Mathematiker oder Cryptologe sein ,-)

Dafür bist Du mir bei den Protokollsachen was Routing oder die Controllerbefehle angeht um einiges voraus.

Wenn ich dran denke das ich eigentlich noch vorhabe einen ZWave-Aktor zu bauen habe ich da noch einiges aufzuholen.

Gruß,
Andreas

rudolfkoenig · 07 Juli 2016, 17:13:30

Habe neighborUpdate serialisiert, mehrere auf einmal zu planen funktioniert damit bei mir.

Bei neighborUpdateAll sehe ich das Problem, dass das nur bei nicht WAKE_UP Geraeten sinnvoll ist, und damit nicht wirklich "All" ist.
Falls ihr eine andere/bessere Idee habt, bitte melden.

Weiterhin ist timeToAck jetzt ein Reading (ohne Event), damit man nach einem Neustart diese Werte noch hat und beim Malen verwenden kann.

krikan · 07 Juli 2016, 17:36:52

ZitatHabe neighborUpdate serialisiert, mehrere auf einmal zu planen funktioniert damit bei mir.

Danke.

ZitatBei neighborUpdateAll sehe ich das Problem, dass das nur bei nicht WAKE_UP Geraeten sinnvoll ist, und damit nicht wirklich "All" ist.

Mir ist nicht klar, warum das nicht sinnvoll ist?
Bei den WAKE_UP-Geräten müsste neighborUpdate doch in den Sendstack gelegt werden, sonst muss man für die WAKE_UP-Geräte weiterhin einzeln ein Update anstoßen?
(Und eigentlich wäre eine Info schön, welche neighborUpdate mit welchem Ergebnis schon durch sind und welche nicht.. - Aber ich probiere erst mal Deine Änderung aus, bevor ich weiter philosophiere und es eventuell schon drin ist und ich es nur im Code nicht erkenne

)

krikan · 07 Juli 2016, 21:16:24

Habe es mit 15 netzbetriebenen Geräten getestet:
Grundsätzlich alles OK.

Auffälligkeiten bei Extrembelastungen (also nicht überbewerten):
Auf ein failed, kommt bei 5 Tests immer noch ein failed beim nächsten Node. Zufall?
Mehrfaches Absetzen von "set TYPE=ZWave neighborUpdate" hintereinander mag mein Controller nicht. neighborUpdate endet dann irgendwann nur noch in failed und Erholung erst nach Controller ein- und abstecken.
Abarbeitung der offenen neighborUpdate unterbleibt teilweise. Dann kann ich weitere Absetzen ohne dass diese verarbeitet werden (set XY neighborUpdate im Log, aber keine weitere Aktion). Wie kann ich feststellen was/wo es hängen bleibt? Im Log kann ich die Ursache nicht erkennen. Gibt es kein timeout?

Ergebnis von neigborUpdate fände ich nützlich in den Readings der Nodes.

krikan · 07 Juli 2016, 21:35:43

Zitat von: krikan am 07 Juli 2016, 21:16:24
Abarbeitung der offenen neighborUpdate unterbleibt teilweise. Dann kann ich weitere Absetzen ohne dass diese verarbeitet werden (set XY neighborUpdate im Log, aber keine weitere Aktion). Wie kann ich feststellen was/wo es hängen bleibt? Im Log kann ich die Ursache nicht erkennen. Gibt es kein timeout?

Ursache ist vermutlich 2x, dass kein done bzw. failed kommt. Demnach vermute ich: es gibt keinen timeout.

docfred · 08 Juli 2016, 09:01:37

Möchte diesen Grundlagen-Thread nutzen, um ein paar Fragen zu stellen, die ich nicht 100% beantwortet gefunden habe.

1. Falls ich nur ZW+ Devices einsetzte: Mit Explorerframes ist ein SUC überflüssig oder ist die Kombination das beste.
2. Bei einem Stick ist SUC nicht aktiviert. Wie mache ich das. Der Befehl SUCNodeId steht auf no und erwartet drei Parameter.
3. Sollte sich ein ZW+ Netz nicht selbst heilen? Also selbständig ein NeigborhoodUpdate durchführen? Bzw. sollte der Controller dies auf Anordnung nicht selbst erledigen?
4. Wenn ich SUC aktiviere würde dann der Controller auch die SIS Funktion übernehmen?
5 Wenn ich in einem ZW+ Netz ein SDK 5 Gerät habe hat dies keine Auswirkung auf die Funktion in 3. solange alle ZW+ Geräte eine Route über ZW+ Geräte haben?

6. Wenn ich ein SDK5 Slave habe, kann ich dieses nur in direkter Reichweite zum Controller inkludieren. Wenn ich dieses Device dann an eine andere Position verbringe, reicht dann ein NeigborhoodUpdate? Oder wie gehe ich mit dem Befehl AddReturnRoute um? Kann ich ja nur Definieren, wenn ich das Device erreiche?

Viele Fragen,
Vielen Dank im vorraus Friedemann

rudolfkoenig · 08 Juli 2016, 13:13:30

Habe Timeouts fuer neighborUpdate eingebaut, weiterhin wird neighborUpdate ab sofort als Device Reading/Event gemeldet, und nicht mehr als ZWDongle event.

krikan · 08 Juli 2016, 13:18:45

Hallo Friedemann!

Einige Anmerkungen zu Deinen Fragen nach meinem aktuellen Kenntnis- und Vermutungsstand. Mangels offizieller Doku müssen wir vieles erforschen und sind noch lange nicht am Ende.

Zitat1. Falls ich nur ZW+ Devices einsetzte: Mit Explorerframes ist ein SUC überflüssig oder ist die Kombination das beste.

SUC ist mMn überflüssig, wenn alle Geräte (wozu auch der Controller gehört!) ExplorerFrames unterstützen. ZW+ ist dabei nicht zwingend, sondern nur EF-Unterstützung. Schlußfolgerung aus http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames und ich konnte bei einem 2wöchigen Test in meinem Netz mit ausschließlich EF-unterstützenden Geräten keine SUC-Nachrichten loggen.

Zitat
2. Bei einem Stick ist SUC nicht aktiviert. Wie mache ich das. Der Befehl SUCNodeId steht auf no und erwartet drei Parameter.

Wenn ControllerNodeId =1 und nur SUC aktiviert werden soll:

Code Auswählen

set <ZWDongle> sucNodeId 1 1 0
Es müssen anschließend die Routen zum basic SUC den Geräten zugewiesen werden. Andere Controller müssen über "sucSendNodeId" über die Existens des SUC informiert werden.

Zitat3. Sollte sich ein ZW+ Netz nicht selbst heilen? Also selbständig ein NeigborhoodUpdate durchführen? Bzw. sollte der Controller dies auf Anordnung nicht selbst erledigen?

Gehe davon aus, dass alles automatisch läuft. Der Controller sollte alles von alleine machen. neighborUpdate ist in diesem Fall mMn nicht zwingend. Genaue Wechselwirkung ist aber unklar. Spekulation: Evtl. werden durch das neighborUpdate unnötige EF bei Netzänderungen vermieden und darum evtl. schnelleres Netz.

Zitat4. Wenn ich SUC aktiviere würde dann der Controller auch die SIS Funktion übernehmen?

Wenn Du den nicht nur den "basic SUC" aktivierst, sondern auch den SIS (statt der letzten 0 im obigen Befehl 1) wird der Controller zum SIS. Unterscheidung im Netz zwischen Primär- und Sekundärcontroller entfällt. Alle Controller sind dann Inklusionscontroller. Der SIS und der (regelmäßige) Abgleich aller Controller mit dem SIS muss aber anschließend manuell in FHEM angestoßen werden. In einem Netz aus nur EF-fähigen Geräten ist das meiner Meinung nach aber nicht notwendig. NetworkWide Inklusion sollte immer funktionieren.

Zitat5 Wenn ich in einem ZW+ Netz ein SDK 5 Gerät habe hat dies keine Auswirkung auf die Funktion in 3. solange alle ZW+ Geräte eine Route über ZW+ Geräte haben?

Vermutlich. Nur das SDK 5 -Gerät bekommt nicht automatisch die Verbindung zum Controller.

Zitat6. Wenn ich ein SDK5 Slave habe, kann ich dieses nur in direkter Reichweite zum Controller inkludieren. Wenn ich dieses Device dann an eine andere Position verbringe, reicht dann ein NeigborhoodUpdate? Oder wie gehe ich mit dem Befehl AddReturnRoute um? Kann ich ja nur Definieren, wenn ich das Device erreiche?

Auch ohne SUC könnte neighborUpdate reichen. Mit einem SUC und nach sucRouteAdd könnte nach Ortsveränderung evtl. kein neighborUpdate notwendig sein, da die SUC-Automatik hilft. Da ich keine SDK 5-Geräte habe, kann ich so etwas nicht testen.

Genug vermutet, vielleicht hat jemand ja auch noch weitere/andere/bessere Infos..

Gruß, Christian

@Rudi: Danke!