Kommunikationsablauf ZWave

Begonnen von A.Harrenberg, 02 November 2015, 17:09:25

Vorheriges Thema - Nächstes Thema

A.Harrenberg

Hallo,

irgendwie kriege ich das mit den 0013xx und 0113xx Nachrichten immer noch nicht richtig "sortiert"...
Stimmt meine Annahmen über den Kommunikationsablauf hier?

01         IO-Write ->
02                         <- ACK [Empfangsbestätigung vom Dongle]
03                         <- 0113xx (xx:01=ok, 00=not ok) [Sende-Rückmeldung vom Dongle]
04               ACK ->           [Empfangsbestätigung von FHEM an den Dongle]
05                         <- 0013<id>xx (id:Geräte-id, xx:'00'=>'OK', '01'=>'NO_ACK', '02'=>'FAIL', '03'=>'NOT_IDLE', '04'=>'NOROUTE')
06               ACK ->           [Empfangsbestätigung von FHEM an den Dongle]

Im Fall eines Get-Befehls kommt dann noch die Antwort vom Gerät hintendran:
07                        <- IO-Read
08               ACK ->           [Empfangsbestätigung von FHEM an den Dongle]

Meine Fragen/Annahmen:

  • ACK Messages sind mMn nur Bestätigungen der Übertragung zwischen FHEM und Dongle und werden nicht "wirklich" an das Gerät gesendet
  • Senden alle Dongles 0113xx Nachrichten oder gibt es da (bekannte) Ausnahmen?
  • Gibt es für 0113 Nachrichten noch mehr "Optionen" als 01=ok und 00=nicht ok?
  • Senden alle Geräte eine 0013<id>xx Nachricht als Bestätigung oder gibt es hier auch Ausnahmen?
  • Gibt es nach dem Schritt 8.) auch noch eine Rückantwort an das Gerät, also etwas analog zu 0013? Das würde dann wahrscheinlich vom Dongle gemacht werden und nicht in FHEM sichtbar sein, aber rein aus Protokollsicht müsste es das geben... (Gibt es eigentlich ZWave-"Sniffer" mit denen man soetwas auslesen könnte?)
  • Gibt es irgendeinen Anhaltspunkt was die Daten hinter 0013<id>xx bedeuten? Bei mir kommt z.B. mal 0013a9010299 also mit 0299 als Argument für ein NO_ACK oder 0013a9000004 mit Argument 0004 bei einem OK

In dem Thread hier hat gerade jemand ein Problem mit CAN-Messages die anscheinend dadurch hervorgerufen werden das zwischen Schritt 5 und 6 bereits ein neuer Befehl (an eine ANDERE Node) versendet wird. (ProcessSendStack wird nach erfolgreichem Empfang einer 0013xx00 Nachricht aufgerufen.)

Bisher bin ich davon ausgegangen das immer nur eine Kommunikation pro NODE aktiv sein kann, der Dongle aber durchaus in der Lage ist mehrere Kommunikationen mit verschiedenen Nodes führen kann. Bei etwas mehr Nachdenken ist aber das ACK nicht an eine Node gebunden sondern bezieht sich immer auf die letzte übertragene Nachricht. Ein Senden von neuen Nachrichten bevor ACK gesendet (oder empfangen) wurde, ist daher anscheinend zu vermeiden...

Für Kommentare, Korrekturen und weiterführende Informationen bin ich dankbar,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatACK Messages sind mMn nur Bestätigungen der Übertragung zwischen FHEM und Dongle und werden nicht "wirklich" an das Gerät gesendet.
Korrekt, bzw. das laeuft in beide Richtungen. In diese Klasse Fallen die NAK und die CAN

ZitatSenden alle Dongles 0113xx Nachrichten oder gibt es da (bekannte) Ausnahmen?
Alle Dongles, und bedeutet, dass die Nachricht gesendet werden konnte (oder nicht)

ZitatSenden alle Geräte eine 0013<id>xx Nachricht als Bestätigung oder gibt es hier auch Ausnahmen?
Keine Ausnahmen

ZitatGibt es nach dem Schritt 8.) auch noch eine Rückantwort an das Gerät, also etwas analog zu 0013?
Nein, sonst wuerde das ewig so weitergehen.

ZitatGibt es eigentlich ZWave-"Sniffer" mit denen man soetwas auslesen könnte?
Mir nicht bekannt, bzw. liegt auf meinem TODO: Zwave fuer CUL. Laut diesen PDF geht das, mein erster Versuch war nicht erfolgreich, ich habe aber damit auch nur 2-3 Stunden verbracht.

ZitatEin Senden von neuen Nachrichten bevor ACK gesendet (oder empfangen) wurde, ist daher anscheinend zu vermeiden...
Der ZWDongle Stack sendet erst nach einem ACK die naechste Nachricht.
Der ZWave Stack erst nach einem 0013. Jedenfalls theoretisch, sonst ist es ein Bug.


Auf die nicht beantworteten Fragen haette ich auch gerne eine Antwort, und der Rest ist meine Annahme bzw. Wissensstand.


A.Harrenberg

Hi Rudi,

danke für die Antworten, dann liege ich ja nicht soo falsch.

ZitatGibt es nach dem Schritt 8.) auch noch eine Rückantwort an das Gerät, also etwas analog zu 0013?
Nein, sonst wuerde das ewig so weitergehen
Hmm, stimmt, aber das bedeutet das ein Gerät nicht sicher ist ob seine Antwort angekommen ist. Bei einem GET könnte der Controller ja noch mal fragen wenn nichts ankommt, aber bei zeitgesteuerten Reports würden die Geräte demnach ohne jede Rückbestätigung senden oder übersehe ich jetzt auch wieder was?

ZitatEin Senden von neuen Nachrichten bevor ACK gesendet (oder empfangen) wurde, ist daher anscheinend zu vermeiden...
Der ZWDongle Stack sendet erst nach einem ACK die naechste Nachricht.
Der ZWave Stack erst nach einem 0013. Jedenfalls theoretisch, sonst ist es ein Bug.

Ich muss mich etwas korrigieren, das Probem tritt zwischen Schritt 4 und Schritt 5 (und nicht 5->6 wie ich geschrieben hatte). Es scheint da aber dennoch einen Bug zu geben. Ich hab mal alles "unwichtige" aus dem Log rausgeworfen:

2015.11.01 21:17:30.208 5: ZWDongle_Write 00 130f07600d01022501FF250f
2015.11.01 21:17:30.209 5: SW: 010e00130f07600d01022501FF250f75
2015.11.01 21:17:30.219 5: ZWDongle_Write 00 131407600d01022501FF2514
2015.11.01 21:17:30.257 5: ACK received, removing 010e00130f07600d01022501FF250f75 from dongle sendstack
2015.11.01 21:17:30.257 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.01 21:17:30.257 5: SW: 06
2015.11.01 21:17:30.258 5: ZWDongle_0 dispatch 011301
2015.11.01 21:17:30.259 5: SW: 010e00131407600d01022501FF251475

Hier wird der nächste Befehl gesendet bevor 0013 empfangen und verarbeitet wurde. Vielleicht liegt das Problem darin das es sich hier um eine andere Node handelt? Die Stacks sind doch für jede Node einzeln, oder?

2015.11.01 21:17:30.261 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130f00
2015.11.01 21:17:30.261 5: SW: 06
2015.11.01 21:17:30.262 5: ZWDongle_0 dispatch 00130f00
2015.11.01 21:17:30.262 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.11.01 21:17:30.262 4: ZWDongle_0 transmit OK for 0f
2015.11.01 21:17:30.263 4: ZWDongle_Read ZWDongle_0: CAN received

Resultat ist jedenfalls eine CAN Nachricht.

PDF schaue ich mir mal an, da ich aber gar keinen CUL habe und auch noch nie was in der Richtung gemacht habe wird das wohl nichts...

Danke,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatDie Stacks sind doch für jede Node einzeln, oder?
Ja.
Wenn deine Theorie stimmt, dass der Dongle nur eine ausstehende Nachricht abkann (und nicht eins pro Node), dann muesste das umgebaut werden.

krikan

ZitatWenn deine Theorie stimmt, dass der Dongle nur eine ausstehende Nachricht abkann (und nicht eins pro Node), dann muesste das umgebaut werden.
Könntet Ihr Euch mal die NOTE (bzgl callbacks) bei ZW_SEND_DATA  in INS* durchlesen? Interpretiere das leider in die Richtung, obwohl mir das gar nicht gefällt.... Oder werfe ich etwas durcheinander?

A.Harrenberg

Hi,

ich bin ja bisher auch davon ausgegangen das der Controller für jede Node eine Kommunikation gleichzeitig führen kann.
Wenn ich mir das Log anschaue fällt mir dazu erst mal keine andere Erklärung ein.

Irgendwie ist diese ganze "Bestätigungs"-Kommunikation nicht wirklich intuitiv.
ACK/CAN/NACK/SOF sind ohne jeden Bezug zur NodeID einfach immer für den letzten Befehl.
0113 Nachrichten sind auch ohne jeden Bezug zur NodeID, was schon mal dafür sprechen würde das der Dongle zumindest bis hierhin nur eine Nachricht bearbeiten kann, unabhängig davon ob es verschiedene Nodes sind.

Ich stelle mir gerade die Frage ob in der 0013 Antwort eigentlich die CallBack-ID oder die Node-ID gemeldet wird. Da FHEM ja beides gleich setzt ist das momentan nicht zu unterscheiden... (Müsste man mal in Logs von OZW nachschauen...)

Ich bin ja für meine voreiligen Erkenntnisse bekannt, aber es deutet einiges darauf hin das man nur eine ausstehende Nachricht im Dongle abarbeiten kann.
Da ich hier nur eine begrenzte Anzahl an ZWave-Geräten habe bin ich nicht sicher ob ich etwas derartiges nachstellen kann um da vielleicht etwas genauer zu verstehen was da passiert.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi,
Zitat von: krikan am 02 November 2015, 18:45:53
Könntet Ihr Euch mal die NOTE (bzgl callbacks) bei ZW_SEND_DATA  in INS* durchlesen? Interpretiere das leider in die Richtung, obwohl mir das gar nicht gefällt.... Oder werfe ich etwas durcheinander?
könntest Du bitte genauer sagen welches Dokument? (und vielleicht auch Seitennummer?)

Danke,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

Zitat von: A.Harrenberg am 02 November 2015, 19:11:05
Hi,könntest Du bitte genauer sagen welches Dokument? (und vielleicht auch Seitennummer?)
INS11095-2 S. 120

rudolfkoenig

Ich habe folgendes gelesen: "The data buffer is queued to the end of the transmit queue (first in; first out)". Ich habe eigentlich auf einem queue im Firmware getippt.

Andererseits kriege ich sofort "no ACK, resending message", wenn ich parallel zwei Geraete anspreche (set x1 config1; set x2 config2; set x1 config1; set x2 config2). Wenn ich die Daten nur an dem einen oder dam anderen schicke, dann gibt es kein Problem. Ich behaupt, dass die Theorie von Andreas korrekt ist, und ich muss den Stack umbauen. Seufz.

A.Harrenberg

Hi,

soweit ich das Dokument verstehe ist das ja die Implementierung der Nodes, für den Dongle sollte etwas ähnlich gelten. Ich würde also schon davon ausgehen das da eine queue drin sein müsste...

Ich lese weiter hinten: "The completedFunc is called when the frame transmission completes, that is when transmitted if ACK is not requested; when acknowledge received from the destination node,..." und die Note: "NOTE: Allways use the completeFunc callback to determine when the next frame can be send. Calling the ZW_SendData or ZW_SendDataMulti in a loop without checking the completeFunc callback will overflow the transmit queue and eventually fail."

Das kann/muss man wohl wirklich so deuten das man auf die 0013 warten muss. Ich frage mich allerdings was passiert wenn man bei einem Get-Befehl dann zwischen dem 0013 und dem Eintreffen der Antwort was sendet... Meine bisherige Theorie war ja das dann auch eine CAN-Msg erzeugt wird, zumindest wenn es sich um die gleiche Node handelt. Ich "befürchte" allerdings das auch das Senden an eine andere Node eine CAN-Msg auslöst.

@Rudi: Kannst Du mal Dein Log von Deinem Versuch posten? Mich würde mal interessieren was da genau abgeht.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi,

ich habe in dem Dokument noch etwas weiter gelesen, ziemlich weit hinten (S.284) kommt dann noch eine Passage:
ZitatThe Serial API embedded sample code can only perform one host-initiated task at a time. A data frame
will be dropped without any notification (no ACK/NAK frame transmitted) by the ZW if it is not ready to
execute a new host-initiated task. As of Serial API version 4 a CAN frame is transmitted by the ZW when
a received data frame is dropped.
Scheint also wirklich so zu sein das der Dongle bzw. das Serial API hier "single task only" ist und keine zwei Kommunikationen gleichzeitig mag.

Das Dokument hatte ich mir bisher nicht wirklich angeschaut, es scheinen aber durchaus sehr wertvolle Informationen enthalten zu sein.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

dennis_n

Hallo Rudi,

ich stehe gerne für Tests bereit. Wie http://forum.fhem.de/index.php?topic=42843.msg354134#msg354134 berichtet habe ich ähnliche Probleme und Beobachtungen gemacht. Aktuell logge ich mit Verbose 5 und mseclog alles mit.

Wenn ich euch also unterstützen kann, gebt Bescheid.

Gruss
Dennis

A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 02 November 2015, 20:16:49
Ich behaupt, dass die Theorie von Andreas korrekt ist, und ich muss den Stack umbauen. Seufz.
hast Du schon eine Idee wie Du das realisieren willst?
Ich habe mir mal grob eine Art State-Machine für eine einzelne Node skizziert, darin kommt aber immer wieder ein "warten auf ..." bzw. "Timeouts" vor, was ja in FHEM (zumindest für mich) nicht so einfach zu realisieren ist ohne alles zu blockieren. Eine vage Idee hätte ich schon, die würde aber EINDEUTIGE Callback-IDs benötigen, d.h. die müssen pro Dongle eindeutig sind und nicht nur per Node.

Hierzu würde man z.B. einen Time-Out Timer starten der die aktuelle CB-ID und den Status der Statemachine kennt und in x Sekunden aufgerufen wird und prüft ob die Statemachine immer noch da "hängt" oder inzwischen weitergelaufen ist. Da evtl. bereits der nächste Befehl dran ist muss man die Befehle aber auseinanderhalten können -> Callback-IDs...

Ich möchte daher doch noch mal eine Lanze für Callback-IDs brechen. Sie stören sicherlich NICHT, können aber helfen solch eine Statemachine zu realisieren.

So eine Statemachine dann zu programmieren ist aber auch noch mal eine Herausforderung für sich... "Störungen" durch eingehende Meldungen von Sensoren oder Tastern habe ich da z.B. noch gar nicht betrachtet.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Zitathast Du schon eine Idee wie Du das realisieren willst?

Ja, sehr einfach: den Hash nicht in der ZWave- sondern in den ZWDongle-Instanz halten.
Allerdings brauche ich etwas Ruhe zum testen.

CallBack-Ids stoeren sicher nicht, mann muss nur fleissig alles umbauen. Nur die Vorteile werden zunehmend geringer (z.Z. gleich 0), da wir ja gerade festgestellt haben, dass insg. nur ein Befehl fuer alle Nodes ausstehend sein kann. Callbackids sind sinnvoll, wenn wir pro Node mehrere Befehle ausstehend haben koennen, die wiederum in beliebiger Reihenfolge beantwortet werden koennen.

A.Harrenberg

Hi,

und hast Du auch eine Idee wie man auf die Antwort bei einem Get wartet ohne mit ReadAnswerFn zu blockieren bzw. wie man das aus dem WakeUpStack heraus löst?

Wenn ich was testen soll sag Bescheid.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY