get ... config... -> Timeout

[toms01]

Heißt das, dass die Geräte und Dongle nicht assoziert sind?
Wenn es dort ausführliche Logs gibt, nehme ich die gerne. 

Nein, das heisst es nicht. Alle Geräte sind zumindest mit dem Dongle assoziiert - darauf hab ich geachtet. 
Ich kenne OpenHAB gar nicht - mache mich mal langsam dran. Falls es da was zu loggen gibt, gebe ich das gern weiter.

[A.Harrenberg]

Hi,
das hier passiert bei meinem nieghborUpdate:

Code Auswählen Erweitern

2015.11.24 18:16:27.002 2: ZWave set ZWave_SWITCH_BINARY_159 neighborUpdate
2015.11.24 18:16:27.003 5: ZWDongle_Write 00 489f
2015.11.24 18:16:27.003 5: SW: 010400489f2c
2015.11.24 18:16:27.127 5: ACK received, removing 010400489f2c from dongle sendstack
2015.11.24 18:16:27.238 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480221
2015.11.24 18:16:27.239 5: SW: 06
2015.11.24 18:16:27.240 5: ZWDongle_0 dispatch 00480221
2015.11.24 18:16:27.240 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.24 18:16:27.240 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.24 18:16:27.421 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480221
2015.11.24 18:16:27.421 5: SW: 06
2015.11.24 18:16:27.422 5: ZWDongle_0 dispatch 00480221
2015.11.24 18:16:27.422 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:21 ARG:
2015.11.24 18:16:27.422 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE started
2015.11.24 18:16:27.761 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00480222
2015.11.24 18:16:27.761 5: SW: 06
2015.11.24 18:16:27.762 5: ZWDongle_0 dispatch 00480222
2015.11.24 18:16:27.762 4: ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
2015.11.24 18:16:27.762 4: ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done
2015.11.24 18:16:37.005 2: ZWave: No ACK from ZWave_SWITCH_BINARY_159 after 10s for sent:489f

wobei ich der Meinung bin das
2015.11.24 18:16:27.003 5: ZWDongle_Write 00 489f
2015.11.24 18:16:27.003 5: SW: 010400489f2c
einen Controllerbefehl darstellt
'48'  => 'ZW_REQUEST_NODE_NEIGHBOR_UPDATE' (ZWDongle.pm)
mit 9f = node_id 159
2c Checksumme ?

Als "Antwort" kommt dann eine 00480221, was ich mangels Info nicht entschlüsseln kann, es scheint aber als neighbor update startet gedeutet zu werden. Dann kommt noch eine 00480222 hinterher was dann als "done" interpretiert wird.

Dann kommt das NO_ACK, das aber mMn hier eine Fehlmeldung ist, das nie ein Befehl direkt an 159 geschickt wurde sondern das zwischendurch irgendwo in einen Controllerbefehl umgesetzt wird.

EIn Get-NeighborList bringt nur den Nachbarn, nicht den Controller:
2015.11.24 18:23:37.428 4: ZWDongle_ReadAnswer for neighborList: 01800000000000000000000000000000000000000020000000000000000000

Zu mehr Diagnose / mehr Versuchen habe ich jetzt leider keine Zeit mehr.

Gruß,
Andreas.

[krikan]

Der Aufruf von neigborUpdate endet bei mit immer mit:

Code Auswählen Erweitern

ZWave: No ACK from ZWave_xy after 10s for sent:48xy

Wenn das Endgerät erreichbar ist (wach oder eingesteckt), dann liefert neigborUpdate:

Code Auswählen Erweitern

ZWDongle_Read ZWDongle_0: sending ACK, processing 00480222
SW: 06
ZWDongle_0 dispatch 00480222
ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:22 ARG:
ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE done

Wenn das Endgerät nicht erreichbar ist (schlafend oder ausgesteckt), dann liefert neigborUpdate:

Code Auswählen Erweitern

ZWDongle_Read ZWDongle_0: sending ACK, processing 00480123
SW: 06
ZWDongle_0 dispatch 00480123
ZWDongle_0 CMD:ZW_REQUEST_NODE_NEIGHBOR_UPDATE ID:23 ARG:
ZWDongle_0 ZW_REQUEST_NODE_NEIGHBOR_UPDATE failed

Meine derzeitige Schlussfolgerung:
Bei neigborUpdate bekommt man kein ACK (0013xy00), sondern die Erreichbarkeit des Endgerätes wird über done/failed (22/23) mitgeteilt.
neigborUpdate in  FHEM läuft korrekt durch; nur

Code Auswählen Erweitern

ZWave: No ACK from ZWave_xy after 10s for sent:4806
könnte raus. Aber das ist mMn unerheblich.

Gruß, Christian

[krikan]

Als "Antwort" kommt dann eine 00480221, was ich mangels Info nicht entschlüsseln kann, es scheint aber als neighbor update startet gedeutet zu werden. Dann kommt noch eine 00480222 hinterher was dann als "done" interpretiert wird.

00 -> Request
48 -> ZW_REQUEST_NODE_NEIGHBOR_UPDATE
02 -> funcId=callbackId, da von FHEM im Befehlsaufruf nicht gesetzt, ist das "irgendetwas" -> Nebenwirkungen ?
21 -> bStatus= 21 started, 22 done, 23 failed

[A.Harrenberg]

Hi Christian,

deckt sich mit meiner Einschätzung.
Ein ACK (0013xy00) kann da auch nicht kommen, da ja ein 0048, also ZW_REQUEST_NODE_NEIGHBOR_UPDATE verschickt wurde und kein 0013 ZW_SEND_DATA.

Ich frage mich nur was da auf der Protokollebene passiert wenn das neighborUpdate ja anscheinend einwandfrei beendet wird und auch danach ID 1 nicht gemeldet wird.

Könnte das irgendetwas mit Explorerframes zu tun haben? Ich weiß ist 'ne gewagte Assoziation, aber ansonsten fällt mir nur die etwas geänderte Initialisierung (anlässlich SECURITY) des Dongles als größere Änderung im ZWave-Code ein.

Gruß,
Andreas.

[krikan]

Ich frage mich nur was da auf der Protokollebene passiert wenn das neighborUpdate ja anscheinend einwandfrei beendet wird und auch danach ID 1 nicht gemeldet wird.

Finde Rudis Einwurf überdenkenswert und will das auch noch mal testen

Könnte das irgendetwas mit Explorerframes zu tun haben?

Wüsste nicht, warum. Mir fehlt da jeder Ansatzpunkt.
Dann müsste unter ozw auch das Gleiche passieren.

Gruß, Christian

[A.Harrenberg]

Hi,

ich habe gerade was rausgefunden 

Die API Funktion GetRoutingInfo welche sich hinter dem "get ... neighborList" verbigt ("'80'  => 'GET_ROUTING_TABLE_LINE'"), hat folgende Parameter:

Code Auswählen Erweitern

HOST->ZW: REQ | 0x80 | bNodeID | bRemoveBad | bRemoveNonReps | funcID
wobei

Code Auswählen Erweitern

bRemoveNonReps  = GET_ROUTING_INFO_REMOVE_NON_REPS
Remove non-repeaters from the routing info
ist

In 10_ZWave.pm ist das Abrufen der neighborlist hart mit 0101 als Parameter codiert.

Code Auswählen Erweitern

if($type eq "get") {
      # GET_ROUTING_TABLE_LINE, include dead links, non-routing neigbors
      $cmdList{neighborList}{fmt} = "80${id}0101";
Wenn man hier das Bit für bRemoveNonReps weglässt, also 0100 einträgt wird sowohl der Controller als auch mein WakeUp-Gerät gemeldet.

Der Controller wird also anscheinend als non-repeater betrachtet, wobei mir nicht klar ist ob der Controller wirklich als repeater agieren würde wenn zwei Geräte die sich nicht direkt empfangen können assoziiert werden, obwohl ich das schon so erwarten würde...

Warum einige Geräte das jetzt unterschiedlich melden ist mir aber weiterhin unklar.

Vielleicht hilft das ja schon mal etwas weiter.

Gruß,
Andreas.

[krikan]

Wenn man hier das Bit für bRemoveNonReps weglässt, also 0100 einträgt wird sowohl der Controller als auch mein WakeUp-Gerät gemeldet.

Bei meinem 400er-Stick ändert das nichts an der Meldung des Controllers. Wo in der Standardabfrage der Controller enthalten ist, bleibt er auch bei 0100 drin; wo er fehlt, fehlt er auch bei 0100 weiterhin.

[A.Harrenberg]

Guten Morgen Christian,

Bei meinem 400er-Stick ändert das nichts an der Meldung des Controllers. Wo in der Standardabfrage der Controller enthalten ist, bleibt er auch bei 0100 drin; wo er fehlt, fehlt er auch bei 0100 weiterhin.

hmm, das verstehe ich dann jetzt so gar nicht mehr...

Dachte das konnte zur Lösung des Problems beitragen, jetzt wirft es zumindest für mich mehr Fragen auf als es Antworten ermöglicht....

Keine weiteren Ideen,
Andreas.

[krikan]

das verstehe ich dann jetzt so gar nicht mehr...

Geht mir nicht anders. Wir bräuchten vermutlich mal ein Doku für den 500er Chipsatz. Ich glaube aber, dass die Meldung/Nicht-Meldung des Controllers in neigborList nicht problematisch ist. Aber.....

[toms01]

Hallo allerseits,

viel habe ich bisher nicht beizutragen. OpenHAB (mit HABmin) habe ich vorerst aufgegeben,
ich hätte anscheinend alles wieder reinkludieren müssen. Da ist mir der Aufwand noch
deutlich zu hoch.

Fortschritte gab es aber mit Domoticz, das benutzt ja OZW als Unterbau.
Folgende Topologie konnte ausgelesen werden:
topo: node=1 3,8,11,13,16,17,18,19,20,24,25,26,28
topo: node=2 4,5,8,9,11,13,15,16,17,18,20,24,26,27,28,29
topo: node=3 1,5,7,8,9,11,13,14,15,16,17,18,19,20,22,24,25,26,28,29
topo: node=4 2,5,8,9,11,16,24,25
topo: node=5 2,3,4,7,8,9,11,13,14,16,17,22,24,25,26,27,28,29
topo: node=7 3,5,8,9,13,14,15,16,17,18,20,22,24,25,26,28,29
topo: node=8 1,2,3,4,5,7,9,11,13,14,15,16,17,18,20,22,24,25,26,28,29
topo: node=9 2,3,4,5,7,8,11,13,14,15,16,17,18,20,22,24,25,26,27,28,29
topo: node=15 2,3,7,8,9,13,16,17,18,19,20,22,24,25,26,28,29
topo: node=16 1,2,3,4,5,7,8,9,13,15,17,18,19,20,22,24,25,26,27,28,29
topo: node=18 1,2,3,7,8,9,13,15,16,17,19,20,21,22,24,26,27,28,29
topo: node=21 13,17,18,20,22,24,25,26,27
topo: node=22 3,5,7,8,9,11,13,15,16,17,18,20,21,24,25,26,28,29
topo: node=24 1,2,3,4,5,7,8,9,11,13,15,16,17,18,20,21,22,25,26,27,28,29
topo: node=25 1,3,4,5,7,8,9,11,13,15,16,17,20,21,22,24,26,27,28,29
topo: node=26 1,2,3,5,7,8,9,13,15,16,17,18,19,20,21,22,24,25,27,28
topo: node=28 1,2,3,5,7,8,9,13,15,16,17,18,19,20,22,24,25,26,27,29
topo: node=29 2,3,5,7,8,9,11,13,15,16,17,18,20,22,24,25,28

Den Stick habe ich dann wieder mit FHEM betrieben und siehe da:
Bis auf die ID1 identisch. Also irgendwas liest man da nur noch nichts aus.
Warum kann man eigentlich auf dem Controller (ID1) keine Neighborlist lesen?

Oben ausgelesene Topologie macht übrigens nach den Geräteabständen Sinn.

Den gesamten Init-Log von Domoticz/OZW/Aeotec-Stick würde ich auch gern
weitergeben falls erwünscht, allerdings nicht hier öffentlich wegen der HomeID usw.

Gruß,
Thomas

[krikan]

Hallo Thomas,

Interesse hätte ich schon an den Logs, wenn es die ozw-logs aus Domoticz mit höchstem Loglevel sind (im Log vieeele hex-codes).
Jedoch bräuchte ich auch ein FHEM Log mit verbose 5 bei ZWDongle für die Abfrage der neigbourList zumindest für einen Node den FHEM ohne, aber ozw mit ID1 meldet. Ansonsten ist das nicht so aussagekräftig.

Es würde evtl. auch schon der Log-Auszug aus ozw im Vergleich zu FHEM für einen betroffenen Node jeweils mit Abfrage/Antwort reichen, wenn Du die kompletten Daten nicht so gerne herausgeben möchtest.

Und Du solltest nicht die Topologie nach Wechsel ozw zu FHEM umgestellt haben.

Gruß, Christian

[toms01]

Hallo Christian,

nach o.g. Topologie hab ich mal ID3 abgefragt:

Code Auswählen Erweitern

2015.11.25 18:09:18 2: ZWave get ID003 neighborList
2015.11.25 18:09:18 5: ZWDongle_Write 00 80030101
2015.11.25 18:09:18 5: SW: 010600800301017a
2015.11.25 18:09:18 4: ZWDongle_ReadAnswer arg:neighborList regexp:^0180
2015.11.25 18:09:18 5: ACK received, removing 010600800301017a from dongle sendstack
2015.11.25 18:09:18 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0180d0c1a21b00000000000000000000000000000000000000000000000000
2015.11.25 18:09:18 5: SW: 06
2015.11.25 18:09:18 4: ZWDongle_ReadAnswer for neighborList: 0180d0c1a21b00000000000000000000000000000000000000000000000000


Wie kann ich dir das Log zukommen lassen? Ich hoffe es ist ausreichend. Mehr LogLevel habe ich in Domoticz
nicht gefunden und Änderungen an der options.xml von ozw wurden bisweilen ignoriert.

Gruß,
Thomas

[krikan]

Die Logs von Thomas korrespondieren mit Andreas Erkenntnissen aus #51:
ozw setzt bei Abfrage von GetRoutingInfo andere Parameter. ozq fragt mit 80xy0000 ab, während FHEM 80xy0101 absetzt. Dass die Ergebnisse abweichen, erklärt sich daraus automatisch.

Warum die Abfrageergebnisse bei verschiedenen Chipsätzen der Controller abweichen, ist mir weiterhin unklar.

Was mir bei ozw (erneut) auffällt, aber den Sinn nicht erkenne:
Es werden die Routen bei Systemstart manuell gelöscht und neu gesetzt (ZW_DeleteReturnRoute und ZW_AssignReturnRoute).
Für jede Abfrage/Antwort-Kombination werden die Laufzeiten ermittelt. zway macht das auch.

[toms01]

Bei HABmin wird erklärt, was bei einem "Healing" passiert:

The heal performs the following steps:

    - Ping the node to see if it's awake
    - Update all the neighbours so that all nodes know who is around them
    - Update the associations so that we know which nodes need to talk to others
    - Update the routes between devices that have associations set
    - Retrieve the neighbour list so that the binding knows who's out there
    - Ping the node to see if it's awake
    - Save the device files

Vielleicht macht ozw einen Teil davon jedesmal vorab um auf eine "geänderte" Umgebung zu reagieren.
Sicherheitshalber? Andere machen das "Healing" ja einmal pro Tag default.

https://github.com/cdjackson/HABmin/wiki/Z-Wave-Network-Healing