Routenzuweisung über ZW_ASSIGN_RETURN_ROUTE

[krikan]

Im SUC/SIS-Thread https://forum.fhem.de/index.php/topic,53066.0.html hatten wir das Thema zwar schon einmal kurz, eröffne aber einen neuen Thread.

In zwapi steht bei CC Assocation und CC Multi Channel Association jeweils, dass für ein stabiles Netz bei Assoziationsanlage auch über ZW_ASSIGN_RETURN_ROUTE die Routen im RoutingSlave gespeichert werden sollen. Insbesondere bei direkten Assoziationen zwischen 2 Routing Slaves leuchtet mir das ein, da Routing Slaves die Netzinformationen grds. nur vom Controller bekommen können.

Bei ozw ist mir die intensive Nutzung von ZW_ASSIGN_RETURN_ROUTE bekannt. Dort befürchte ich aber immer Altlasten, die letztlich unnötig sind. Habe mich im Netz noch mal auf die Suche nach zway-Logs gemacht. Selbst dort scheint ZW_ASSIGN_RETURN_ROUTE noch eingesetzt zu werden. zway setzt per ZW_ASSIGN_RETURN_ROUTE selbst die Routen zwischen Controller und Routing Slave. Zusätzlich wird auch per Explorer Frames beim Start eine gewisse Zeit verschickt.

Habe dann einmal in meinem Netz ZW_ASSIGN_RETURN_ROUTE entsprechend abgesetzt (Node 6 zu Controller 1) und mit ZWCul geloggt:

Code Auswählen Erweitern

2016.06.04 21:36:21.745 5: SW: 010500460601bb
2016.06.04 21:36:21.748 5: ACK received, removing 010500460601bb from dongle sendstack
2016.06.04 21:36:21.752 4: ZWDongle_Read ZWDongle_0: rcvd 014601 (answer ZW_ASSIGN_RETURN_ROUTE), sending ACK
2016.06.04 21:36:21.752 5: SW: 06
2016.06.04 21:36:21.753 5: ZWDongle_0 dispatch 014601
2016.06.04 21:36:21.754 4: ZWDongle_0 unhandled ANSWER: ZW_ASSIGN_RETURN_ROUTE 01
2016.06.04 21:36:21.758 5: e345c452 S:01 F:41 f:0 SN:f L:10 T:06 P:010c010020 C:9901
2016.06.04 21:36:21.758 5:    F: singleCast ackReq
2016.06.04 21:36:21.766 5: e345c452 S:06 F:03 f:0 SN:f L:0b T:01 P: C:fa06
2016.06.04 21:36:21.767 5:    F: ack
2016.06.04 21:36:21.844 5: e345c452 S:01 F:41 f:0 SN:1 L:11 T:06 P:010c01111320 C:27c3
2016.06.04 21:36:21.844 5:    F: singleCast ackReq
2016.06.04 21:36:21.852 5: e345c452 S:06 F:03 f:0 SN:1 L:0b T:01 P: C:e107
2016.06.04 21:36:21.852 5:    F: ack
2016.06.04 21:36:21.931 5: e345c452 S:01 F:41 f:0 SN:2 L:11 T:06 P:010c01213e20 C:bf98
2016.06.04 21:36:21.931 5:    F: singleCast ackReq
2016.06.04 21:36:21.956 5: e345c452 S:06 F:03 f:0 SN:2 L:0b T:01 P: C:b857
2016.06.04 21:36:21.956 5:    F: ack
2016.06.04 21:36:22.133 5: e345c452 S:01 F:41 f:0 SN:3 L:12 T:06 P:010c0132041a10 C:f645
2016.06.04 21:36:22.133 5:    F: singleCast ackReq
2016.06.04 21:36:22.140 5: e345c452 S:06 F:03 f:0 SN:3 L:0b T:01 P: C:8f67
2016.06.04 21:36:22.141 5:    F: ack
2016.06.04 21:36:22.142 4: ZWDongle_Read ZWDongle_0: rcvd 00468500 (request ZW_ASSIGN_RETURN_ROUTE), sending ACK
2016.06.04 21:36:22.142 5: SW: 06
2016.06.04 21:36:22.144 5: ZWDongle_0 dispatch 00468500
2016.06.04 21:36:22.144 4: CMD:ZW_ASSIGN_RETURN_ROUTE ID:00 ARG: CB:85
2016.06.04 21:36:22.145 4: ZWDongle_0 unhandled command ZW_ASSIGN_RETURN_ROUTE


Mit der Anlayse der ZWCul Daten hakt es aber ein wenig.
Es werden 4 Assign-Route-Nachrichten an den Node 6 vom Controller verschickt. Im Payload ist 0x0c wohl die Angabe für assign_return_route, aber den Rest bekomme ich nicht interpretiert. Die Hexwerte direkt als NodeIds zu interpretieren halte ich für unwahrscheinlich, weil die erste Nachricht "010020" dann einen Node 00 enthalten würde.
Rudi, hast Du dafür schon eine Interpretation?

Ob und wie ZW_ASSIGN_RETURN_ROUTE in FHEM eingebaut werden soll, ist dann das nächste Thema.

Gruß, Christian

[krikan]

Die verfügbaren Nodes:

Code Auswählen Erweitern

2016.06.05 08:44:28.044 4: ZWDongle_ReadAnswer for nodeList: 010205001d29000406004e01307f00000000000000000000000000000000000000000401

[rudolfkoenig]

Rudi, hast Du dafür schon eine Interpretation?

Nicht wirklich.
Die Nutzdaten sind:

Code Auswählen Erweitern

01 00       20
01 11 12    20
01 21 3e    20
01 32 04 1a 10
Ich tippe darauf, dass hier 4 alternative Wege gespeichert werden (Nibble 3 ist dabei Route-Slot-Nummer), und Nibble 4 ist Anzahl der Hops. Das unschoene an dieser Theorie ist, dass ich keine Ahnung habe, wie die Nodes kodiert werden, da du laut nodeList keine Nodes 12,3e und 1a hast. Was genau hast du als return route gesetzt? Oder hat man hier keine freie Wahl, und der Controller "macht es schon richtig"? Was sagt neighborList 06?

[krikan]

hier 4 alternative Wege gespeichert werden

Passt, da 4 Maximalanzahl an zuweisbaren Wegen ist. Rest gibt auch Sinn.

Was genau hast du als return route gesetzt? Oder hat man hier keine freie Wahl, und der Controller "macht es schon richtig"?

Letzteres. Kann nur Ziel- und Startnode angeben, der Rest läuft automatisch. Alleine "010500460601bb" im Log löst die gezeigten Nachrichten aus.

Was sagt neighborList 06?

Habe wohl ein blödes Beispiel gewählt, da neighborList sehr gut gefüllt ist:

Code Auswählen Erweitern

2016.06.05 19:44:02.926 4: ZWDongle *** get ZWDongle_0 neighborList onlyRep 6
2016.06.05 19:44:02.927 5: ZWDongle_Write 0080060101 ()
2016.06.05 19:44:02.927 5: SW: 010600800601017f
2016.06.05 19:44:02.929 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2016.06.05 19:44:02.929 5: ACK received, removing 010600800601017f from dongle sendstack
2016.06.05 19:44:02.930 4: ZWDongle_Read ZWDongle_0: rcvd 01800900040400000020200000000000000000000000000000000000000000 (answer GET_ROUTING_TABLE_LINE), sending ACK
2016.06.05 19:44:02.930 5: SW: 06
2016.06.05 19:44:02.932 4: ZWDongle_ReadAnswer for neighborList: 01800900040400000020200000000000000000000000000000000000000000

[rudolfkoenig]

Habe wohl ein blödes Beispiel gewählt, da neighborList sehr gut gefüllt ist:

Hex: 4, 13, 1b, 3e und 46.
Immerhin ist 3e aufgetaucht

[krikan]

Die 1a gibt es als nicht unmittelbaren Nachbarn auch.
In neighborList sind ja nur direkte Nachbarn enthalten.
In nodeList ist 1a und 3e drin. Nur die 12 bleibt mir ein Rätsel; existiert nicht.
Danke, habe jetzt (hoffe ich) ein wenig mehr Einblick.

[krikan]

Habe es noch einmal mitgeloggt. Jetzt sind nur noch bekannte Nodes im Payload. Aber interessanterweise teilweise andere.
Kann die NodeId 12 von vorher ein gekipptes Bit sein? Sind die Telegramme stark gegen Fehler gesichert?

Code Auswählen Erweitern

2016.06.05 20:59:05.181 5: e345c452 S:01 F:41 f:0 SN:a L:10 T:06 P:010c010020 C:d1bf
2016.06.05 20:59:05.181 5:    F: singleCast ackReq
2016.06.05 20:59:05.188 5: e345c452 S:06 F:03 f:0 SN:a L:0b T:01 P: C:11f6
2016.06.05 20:59:05.188 5:    F: ack
2016.06.05 20:59:05.263 5: e345c452 S:01 F:41 f:0 SN:b L:11 T:06 P:010c01111320 C:c85b
2016.06.05 20:59:05.263 5:    F: singleCast ackReq
2016.06.05 20:59:05.271 5: e345c452 S:06 F:03 f:0 SN:b L:0b T:01 P: C:26c6
2016.06.05 20:59:05.271 5:    F: ack
2016.06.05 20:59:05.350 5: e345c452 S:01 F:41 f:0 SN:c L:11 T:06 P:010c01213e20 C:ccef
2016.06.05 20:59:05.350 5:    F: singleCast ackReq
2016.06.05 20:59:05.357 5: e345c452 S:06 F:03 f:0 SN:c L:0b T:01 P: C:a356
2016.06.05 20:59:05.358 5:    F: ack
2016.06.05 20:59:05.575 5: e345c452 S:01 F:41 f:0 SN:d L:12 T:06 P:010c0132044610 C:8463
2016.06.05 20:59:05.575 5:    F: singleCast ackReq
2016.06.05 20:59:05.583 5: e345c452 S:06 F:03 f:0 SN:d L:0b T:01 P: C:9466
2016.06.05 20:59:05.583 5:    F: ack

[rudolfkoenig]

Kann die NodeId 12 von vorher ein gekipptes Bit sein?

Theoretisch ja.

Sind die Telegramme stark gegen Fehler gesichert?

Stark ist relativ , es ist das CRC (C:) am Ende, bei 100k 2 Byte (CRC-16), bei 9.6/40k ein Byte.
Damit es durchgeht, muessen selbst bei dem ein Byte-CRC mehrere Bits "passend" umkippen.
Ich hatte bisher wegen Bitkipper bei meinen ZWCUL Experimenten (40k/1Byte Checksum) nie Probleme, halte es in deinem Fall (2-Byte/CRC16) fuer ausgeschlossen.

[krikan]

Ich hatte bisher wegen Bitkipper bei meinen ZWCUL Experimenten (40k/1Byte Checksum) nie Probleme, halte es in deinem Fall (2-Byte/CRC16) fuer ausgeschlossen.

Ist auch nicht so. Nach dieser Anmerkung habe ich mir das obige, erste Log noch einmal angeschaut. Erkenntnis: Uns kontrolliert keiner und die NodeId 12 ist doch ein Tippfehler. Richtig ist laut Log die 11 und die gibt es. Also hast Du das Rätsel der Telegramme korrekt gelöst  .

Bin jetzt nur unsicher, ob wir ZW_ASSIGN_RETURN_ROUTE in FHEM einbauen sollten. Die Notwendigkeit/den Vorteil kann ich experimentell nicht ermitteln, sondern nur anhand der alten Doks wiedergeben. Weiteres Indiz für Verbesserung der Netzwerkstabilität ist Nutzung durch z-way (zumindest in den gefundenen wenigen Logs). Aber ZW_ASSIGN_RETURN_ROUTE nur einfach als Befehl mit Anwendereigenverantwortung einzubauen ohne automatische Abläufe anzubieten (bspw. automatische Ausfürung bei associationAdd) finde ich nicht optimal. Andererseits befürchte ich unnötige Verkomplizierung. Wir bräuchten dann auch eine Funktion "networkHeal" o.ä. Meinungen?

Btw.:
Mich würde interessieren, was im z-way Server-Log bei Ausführung der Netzwerkheilung steht. Leider finde ich dazu nichts in den Weiten des Internets. Und dass sich hier jemand befindet, der so etwas zur Verfügung stellen könnte, ist wohl auch unwahrscheinlich  .

[rudolfkoenig]

Bin jetzt nur unsicher, ob wir ZW_ASSIGN_RETURN_ROUTE in FHEM einbauen sollten.

Wir koennen es einbauen, mit der Doku-Hinweis, dass es was fuer "Experten" oder interne Funktionen sei, da es nicht unbedingt das macht, was man so naiv denkt. Waere sinnvoll als Teil des networkHeals, jeweils nach einem durchgefuehrten neighborUpdate. Leider kann man nur sehr schlecht beurteilen ob es was bringt, da man ohne ZWCUL keine Infos hat, was passiert.

Gibt es einen "offiziellen" Weg diese 4 Routen aus dem Dongle rauszufischen? Oder steht es im Backup? Wir koennten damit grafisch darstellen, wie das Mash funktioniert, das waere lustig, und womoeglich sogar nuetzlich. networkHeal wuerde ich erst danach angeben, damit man die Aenderungen messen kann, wir sind ja laut Amt Wissenschaftler

Fuer den "normalen" Benutzer ist es mAn sinnvoller auf ZWave+ und Explorer-Frames zu setzen.
Apropos: die muessen auch noch entschluesselt werden.

[krikan]

Leider kann man nur sehr schlecht beurteilen ob es was bringt, da man ohne ZWCUL keine Infos hat, was passiert.

Auch mit ZWCul habe ich bei dem Thema Schwierigkeiten. Zuweisung und Löschung kann ich nachvollziehen. Routenauswahl bei Dongle und letztlich bei Versand Endgerät nicht.

Gibt es einen "offiziellen" Weg diese 4 Routen aus dem Dongle rauszufischen?

Habe keinen gefunden. Scheint eine BlackBox zu sein. Interessant ist, dass die zugewiesenen Routen über mehrere Hops bei 3 Tests unterschiedlich waren, obwohl ich am Netz nichts geändert hatte. Zufallsprinzip?

Oder steht es im Backup?

Kann ich nicht feststellen. Ist ein Netz mit 400er Chipsatz-Dongle ohne Backup-Möglichkeit. 100k und Explorer Frames kann das aber. Sind oben auch 100k-Logs.

Wir koennten damit grafisch darstellen, wie das Mash funktioniert,

Könnten wir nicht schon jetzt Rückschlüsse aus neigbhorList ziehen? Man könnte doch daraus die notwendige Anzahl an Hobs ermitteln, grafisch aufbereiten und Auffäligkeiten "erahnen". Nur welche Route genommen wird wissen wir dann immer noch nicht!?

mAn sinnvoller auf ZWave+ und Explorer-Frames zu setzen.

Das ist sicherlich so.
Bin mir (immer noch) unsicher, ob ASSIGN_RETURN_ROUTE und auch SUC nicht alter "Kram" sind, die man nur zur Rückwärtskompatibilität braucht. So interpretiere ich
http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames#How_to_deal_with_failed_routes hinsichtlich SUC. Widerspricht aber allen anderen (Paetz-)Veröffentlichungen. Mir fehlt momentan der experimentelle Ansatz für beide Themen und evtl. ein zusätzlicher CUL für die Abdeckung des ganzen Spektrums (9.6, 40 und 100k).

[krikan]

Anhängend der Patch zur Einbindung von ZW_ASSIGN_RETURN_ROUTE und ZW_DELETE_RETURN_ROUTE, um den RoutingSlaves statische Routen zu übergeben.
"experts only" habe ich nur in commandref erwähnt.

[rudolfkoenig]

Danke, habs eingecheckt. Konntest du die Telegramme bei ZW_DELETE_RETURN_ROUTE auch mit ZWCUL beobachten?

[krikan]

Konntest du die Telegramme bei ZW_DELETE_RETURN_ROUTE auch mit ZWCUL beobachten?

Ja  :

Code Auswählen Erweitern

2016.06.06 18:35:39.242 4: ZWDongle *** get ZWDongle_0 raw 470615
2016.06.06 18:35:39.242 5: ZWDongle_Write 00470615 ()
2016.06.06 18:35:39.242 5: SW: 010500470615ae
2016.06.06 18:35:39.244 4: ZWDongle_ReadAnswer arg:raw regexp:^0147
2016.06.06 18:35:39.244 5: ACK received, removing 010500470615ae from dongle sendstack
2016.06.06 18:35:39.245 4: ZWDongle_Read ZWDongle_0: rcvd 014701 (answer ZW_DELETE_RETURN_ROUTE), sending ACK
2016.06.06 18:35:39.245 5: SW: 06
2016.06.06 18:35:39.246 4: ZWDongle_ReadAnswer for raw: 014701
2016.06.06 18:35:39.650 5: e345c452 S:01 F:81 f:0 SN:e L:13 T:06 R:001013 P:010c000008 C:2bdc
2016.06.06 18:35:39.650 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:13 
2016.06.06 18:35:39.671 5: e345c452 S:01 F:81 f:0 SN:e L:13 T:06 R:001013 P:010c000008 C:2bdc
2016.06.06 18:35:39.672 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:13 
2016.06.06 18:35:39.694 5: e345c452 S:01 F:81 f:0 SN:e L:13 T:06 R:001013 P:010c000008 C:2bdc
2016.06.06 18:35:39.694 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:13 
2016.06.06 18:35:39.866 5: e345c452 S:01 F:81 f:0 SN:f L:13 T:06 R:00103e P:010c000008 C:88de
2016.06.06 18:35:39.867 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:3e 
2016.06.06 18:35:39.933 5: e345c452 S:01 F:81 f:0 SN:f L:13 T:06 R:00103e P:010c000008 C:88de
2016.06.06 18:35:39.933 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:3e 
2016.06.06 18:35:39.999 5: e345c452 S:01 F:81 f:0 SN:f L:13 T:06 R:00103e P:010c000008 C:88de
2016.06.06 18:35:39.999 5:    F: singleCast routed, rf:00 hopCnt:1 hopPos:0 hops:3e 
2016.06.06 18:35:40.688 4: ZWDongle_Read ZWDongle_0: rcvd 00471500 (request ZW_DELETE_RETURN_ROUTE), sending ACK
2016.06.06 18:35:40.688 5: SW: 06
2016.06.06 18:35:40.689 5: ZWDongle_0 dispatch 00471500
2016.06.06 18:35:40.690 4: CMD:ZW_DELETE_RETURN_ROUTE ID:00 ARG: CB:15
2016.06.06 18:35:40.690 4: ZWDongle_0 unhandled command ZW_DELETE_RETURN_ROUTE

[krikan]

Entschuldige, habe einen Copy/Paste-Fehler im vorherigen Patch in der commandref eingebaut. Anhängend Korrektur.