FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: A.Harrenberg am 02 November 2015, 17:09:25

Titel: Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 17:09:25
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:

In dem Thread hier (http://forum.fhem.de/index.php/topic,43366.msg353416.html#msg353416) 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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 02 November 2015, 18:01:13
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 (https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf) 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.

Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 18:30:14
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 02 November 2015, 18:37:10
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 02 November 2015, 18:45:53
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?
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 19:09:37
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 19:11:05
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 02 November 2015, 19:23:48
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
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 02 November 2015, 20:16:49
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 20:28:07
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 02 November 2015, 21:52:30
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: dennis_n am 03 November 2015, 15:25:59
Hallo Rudi,

ich stehe gerne für Tests bereit. Wie http://forum.fhem.de/index.php?topic=42843.msg354134#msg354134 (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
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 03 November 2015, 21:50:23
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 04 November 2015, 07:20:28
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 04 November 2015, 07:31:03
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.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 08 November 2015, 14:40:53
Der Umbau musste in ZWDongle stattfinden, da der ZWave Stack auch fuer WakeUp devices relevant ist. Ich habe versucht auf 0113 zu reagieren, das hat aber nicht gereicht, jetzt geht erst dann weiter, wenn 0013 gemeldet wurde. Im Zuge dieser Umbau habe ich auch das delayNeeded IODev Attribut entfernt. Ich habe es bei mir mit zwei Geraeten getestet, mal eingesteckt, mal ausgesteckt: in beiden Faellen hat es funktioniert. Komisch: das AN158 meldet innerhalb von 0.02 Sekunden Vollzug, das FGS221 braucht 0.2 Sekunden.

Ab sofort meldet "get dongle nodeList" die GeraeteNamen, bzw UNKNOWN_decimalId, das Format sollte dem "get device neighborList" entsprechen.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 08 November 2015, 15:12:33
Danke für den Umbau.

Zitat von: rudolfkoenig am 08 November 2015, 14:40:53
Ab sofort meldet "get dongle nodeList" die GeraeteNamen, bzw UNKNOWN_decimalId, das Format sollte dem "get device neighborList" entsprechen.
Finde ich zur Feststellung "toter" nodeIds eine gute Idee.
Sorry, aber:
Value des Readings "nodeList" ist bei größeren Netzen recht umfangreich und wird nicht umgebrochen wie bspw. caps, so dass man nach Abfrage in der Detailansicht von ZWDongle ewig nach rechts scrollen muss. Kann man das ändern? Oder ist das bei mir firefox-spezifisch?
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 08 November 2015, 15:24:56
Habe Komma durch Leerzeichen ersetzt.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 08 November 2015, 18:11:38
Hallo Rudi,

werde mir die Änderungen bzgl. des Ablaufs mal anschauen, aber das kann dauern, ich bin gerade dabei meinen Hauptrechner neu aufzusetzen... ,-(
Kann also dauern bis ich Rückmeldung geben kann.

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 08 November 2015, 21:05:19
Hi Rudi,

irgendwie ist das sehr merkwürdig...

Wenn ich (ohne Security, aber mit WakeUp) ein ConfigRequestAll mit dem AETOC Multisensor6 mache bekomme ich von den 23 configs nur 11 zurück... Die Befehle gehen aber nicht durch CAN oder NO_ACK verloren, sondern die Antworten kommen einfach nicht...

Ich habe das unten im Log mal versucht etwas zu kommentieren, was passiert ist folgendes:
Es werden 13 get Request gesendet ohne das eine Antwort ankommt, dann kommt die Antwort auf die 1.te Anfrage, dann wird der 14.te get Request gesendet, danach kommt die Antwort auf den 13.ten Request, dann wird der 15.te Request gesendet, dann kommt die Antwort auf den 14.ten Request.

Hier sind dann also 11 Antworten dazwischen "verschwunden".

Dann ändert sich das Muster, es gibt ein CAN für den 15.ten Request mit resend, der 16.te Request wird gesendet, die Antwort auf den 15.ten Request kommt, es gibt ein CAN für den 16.ten Request, der 17.te Request wird gesendet... und so weiter. Das wiederholt sich dann mit den CAN bis alle 23 Request abgearbeitet sind.

Interessant ist für mich jetzt mal das 13 Get-Befehle ohne Fehlermeldung verschickt werden können ohne das eine Antwort eintrifft. Dann kommt sogar die Antwort auf die erste Anfrage, danach bleiben dann aber einfach 11 Befehle unbeantwortet.

Kommentiertes Log:
2015.11.08 18:28:23.141 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9028407
2015.11.08 18:28:23.141 5: SW: 06
2015.11.08 18:28:23.142 5: ZWDongle_0 dispatch 000400a9028407
2015.11.08 18:28:23.142 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:028407
2015.11.08 18:28:23.143 5: ZWDongle_Write 00 13a90370052c25a9
70052c gesendet -> 01

2015.11.08 18:28:23.143 5: SW: 010a0013a90370052c25a999
2015.11.08 18:28:23.145 5: ACK received, WaitForAck=>2 for 010a0013a90370052c25a999
2015.11.08 18:28:23.159 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.159 5: SW: 06
2015.11.08 18:28:23.160 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.268 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a900000b
2015.11.08 18:28:23.268 5: SW: 06
2015.11.08 18:28:23.269 5: device ack reveived, removing 010a0013a90370052c25a999 from dongle sendstack
2015.11.08 18:28:23.269 5: ZWDongle_0 dispatch 0013a900000b
2015.11.08 18:28:23.269 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:000b
2015.11.08 18:28:23.270 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.270 5: ZWDongle_Write 00 13a90370050525a9
700505 gesendet -> 02

2015.11.08 18:28:23.270 5: SW: 010a0013a90370050525a9b0
2015.11.08 18:28:23.273 5: ACK received, WaitForAck=>2 for 010a0013a90370050525a9b0
2015.11.08 18:28:23.287 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.287 5: SW: 06
2015.11.08 18:28:23.288 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.341 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.341 5: SW: 06
2015.11.08 18:28:23.342 5: device ack reveived, removing 010a0013a90370050525a9b0 from dongle sendstack
2015.11.08 18:28:23.342 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.342 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.342 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.342 5: ZWDongle_Write 00 13a9037005fc25a9
7005fc gesendet -> 03

2015.11.08 18:28:23.342 5: SW: 010a0013a9037005fc25a949
2015.11.08 18:28:23.344 5: ACK received, WaitForAck=>2 for 010a0013a9037005fc25a949
2015.11.08 18:28:23.357 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.357 5: SW: 06
2015.11.08 18:28:23.358 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.405 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.405 5: SW: 06
2015.11.08 18:28:23.406 5: device ack reveived, removing 010a0013a9037005fc25a949 from dongle sendstack
2015.11.08 18:28:23.406 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.406 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.406 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.407 5: ZWDongle_Write 00 13a90370050425a9
700504 gesendet -> 04

2015.11.08 18:28:23.407 5: SW: 010a0013a90370050425a9b1
2015.11.08 18:28:23.408 5: ACK received, WaitForAck=>2 for 010a0013a90370050425a9b1
2015.11.08 18:28:23.419 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.419 5: SW: 06
2015.11.08 18:28:23.420 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.479 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.479 5: SW: 06
2015.11.08 18:28:23.480 5: device ack reveived, removing 010a0013a90370050425a9b1 from dongle sendstack
2015.11.08 18:28:23.480 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.480 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.480 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.480 5: ZWDongle_Write 00 13a90370056f25a9
70056f gesendet -> 05

2015.11.08 18:28:23.480 5: SW: 010a0013a90370056f25a9da
2015.11.08 18:28:23.483 5: ACK received, WaitForAck=>2 for 010a0013a90370056f25a9da
2015.11.08 18:28:23.496 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.496 5: SW: 06
2015.11.08 18:28:23.497 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.545 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.545 5: SW: 06
2015.11.08 18:28:23.547 5: device ack reveived, removing 010a0013a90370056f25a9da from dongle sendstack
2015.11.08 18:28:23.547 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.547 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.547 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.547 5: ZWDongle_Write 00 13a90370056525a9
700565 gesendet -> 06

2015.11.08 18:28:23.547 5: SW: 010a0013a90370056525a9d0
2015.11.08 18:28:23.551 5: ACK received, WaitForAck=>2 for 010a0013a90370056525a9d0
2015.11.08 18:28:23.567 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.567 5: SW: 06
2015.11.08 18:28:23.569 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.618 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.618 5: SW: 06
2015.11.08 18:28:23.619 5: device ack reveived, removing 010a0013a90370056525a9d0 from dongle sendstack
2015.11.08 18:28:23.619 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.619 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.620 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.620 5: ZWDongle_Write 00 13a90370057025a9
700670 gesendet -> 07

2015.11.08 18:28:23.620 5: SW: 010a0013a90370057025a9c5
2015.11.08 18:28:23.621 5: ACK received, WaitForAck=>2 for 010a0013a90370057025a9c5
2015.11.08 18:28:23.644 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.645 5: SW: 06
2015.11.08 18:28:23.646 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.693 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.693 5: SW: 06
2015.11.08 18:28:23.694 5: device ack reveived, removing 010a0013a90370057025a9c5 from dongle sendstack
2015.11.08 18:28:23.694 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.694 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.694 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.695 5: ZWDongle_Write 00 13a90370056625a9
700566 gesendet -> 08

2015.11.08 18:28:23.695 5: SW: 010a0013a90370056625a9d3
2015.11.08 18:28:23.697 5: ACK received, WaitForAck=>2 for 010a0013a90370056625a9d3
2015.11.08 18:28:23.713 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.713 5: SW: 06
2015.11.08 18:28:23.714 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.762 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.762 5: SW: 06
2015.11.08 18:28:23.763 5: device ack reveived, removing 010a0013a90370056625a9d3 from dongle sendstack
2015.11.08 18:28:23.763 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.763 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.763 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.763 5: ZWDongle_Write 00 13a90370057125a9
700571 gesendet -> 09

2015.11.08 18:28:23.763 5: SW: 010a0013a90370057125a9c4
2015.11.08 18:28:23.766 5: ACK received, WaitForAck=>2 for 010a0013a90370057125a9c4
2015.11.08 18:28:23.783 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.783 5: SW: 06
2015.11.08 18:28:23.784 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.827 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.827 5: SW: 06
2015.11.08 18:28:23.828 5: device ack reveived, removing 010a0013a90370057125a9c4 from dongle sendstack
2015.11.08 18:28:23.828 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.828 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.828 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.828 5: ZWDongle_Write 00 13a90370056725a9
700567 gesendet -> 10

2015.11.08 18:28:23.828 5: SW: 010a0013a90370056725a9d2
2015.11.08 18:28:23.832 5: ACK received, WaitForAck=>2 for 010a0013a90370056725a9d2
2015.11.08 18:28:23.842 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.842 5: SW: 06
2015.11.08 18:28:23.844 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.902 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.902 5: SW: 06
2015.11.08 18:28:23.903 5: device ack reveived, removing 010a0013a90370056725a9d2 from dongle sendstack
2015.11.08 18:28:23.903 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.903 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.903 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.903 5: ZWDongle_Write 00 13a9037005ca25a9
7005ca gesendet -> 11

2015.11.08 18:28:23.903 5: SW: 010a0013a9037005ca25a97f
2015.11.08 18:28:23.906 5: ACK received, WaitForAck=>2 for 010a0013a9037005ca25a97f
2015.11.08 18:28:23.927 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.927 5: SW: 06
2015.11.08 18:28:23.928 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:23.966 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:23.966 5: SW: 06
2015.11.08 18:28:23.967 5: device ack reveived, removing 010a0013a9037005ca25a97f from dongle sendstack
2015.11.08 18:28:23.967 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:23.967 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:23.967 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:23.968 5: ZWDongle_Write 00 13a90370052a25a9
70052a gesendet -> 12

2015.11.08 18:28:23.968 5: SW: 010a0013a90370052a25a99f
2015.11.08 18:28:23.972 5: ACK received, WaitForAck=>2 for 010a0013a90370052a25a99f
2015.11.08 18:28:23.984 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:23.984 5: SW: 06
2015.11.08 18:28:23.985 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:24.043 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000005
2015.11.08 18:28:24.043 5: SW: 06
2015.11.08 18:28:24.044 5: device ack reveived, removing 010a0013a90370052a25a99f from dongle sendstack
2015.11.08 18:28:24.044 5: ZWDongle_0 dispatch 0013a9000005
2015.11.08 18:28:24.044 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0005
2015.11.08 18:28:24.044 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:24.044 5: ZWDongle_Write 00 13a90370052725a9
700527 gesendet -> 13

2015.11.08 18:28:24.044 5: SW: 010a0013a90370052725a992
2015.11.08 18:28:24.047 5: ACK received, WaitForAck=>2 for 010a0013a90370052725a992
2015.11.08 18:28:24.061 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:24.061 5: SW: 06
2015.11.08 18:28:24.062 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:24.123 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a90570062c010a
70062c received -> Antwort auf 01

2015.11.08 18:28:24.123 5: SW: 06
2015.11.08 18:28:24.124 5: ZWDongle_0 dispatch 000400a90570062c010a
2015.11.08 18:28:24.124 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:0570062c010a
2015.11.08 18:28:24.259 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000014
2015.11.08 18:28:24.259 5: SW: 06
2015.11.08 18:28:24.260 5: device ack reveived, removing 010a0013a90370052725a992 from dongle sendstack
2015.11.08 18:28:24.260 5: ZWDongle_0 dispatch 0013a9000014
2015.11.08 18:28:24.260 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0014
2015.11.08 18:28:24.260 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:24.260 5: ZWDongle_Write 00 13a90370052e25a9
70052e gesendet -> 14

2015.11.08 18:28:24.260 5: SW: 010a0013a90370052e25a99b
2015.11.08 18:28:24.262 5: ACK received, WaitForAck=>2 for 010a0013a90370052e25a99b
2015.11.08 18:28:24.280 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:24.280 5: SW: 06
2015.11.08 18:28:24.282 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:24.292 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9057006270114
700627 received -> Antwort auf 13

2015.11.08 18:28:24.292 5: SW: 06
2015.11.08 18:28:24.294 5: ZWDongle_0 dispatch 000400a9057006270114
2015.11.08 18:28:24.294 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:057006270114
2015.11.08 18:28:24.352 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000008
2015.11.08 18:28:24.352 5: SW: 06
2015.11.08 18:28:24.353 5: device ack reveived, removing 010a0013a90370052e25a99b from dongle sendstack
2015.11.08 18:28:24.354 5: ZWDongle_0 dispatch 0013a9000008
2015.11.08 18:28:24.354 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0008
2015.11.08 18:28:24.354 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:24.354 5: ZWDongle_Write 00 13a9037005cb25a9
7005cb gesendet -> 15

2015.11.08 18:28:24.354 5: SW: 010a0013a9037005cb25a97e
2015.11.08 18:28:24.375 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a90570062e0100
70062e received -> Antwort auf 14

2015.11.08 18:28:24.375 5: SW: 06
2015.11.08 18:28:24.376 5: ZWDongle_0 dispatch 000400a90570062e0100
2015.11.08 18:28:24.376 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:0570062e0100
2015.11.08 18:28:24.377 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:25.378 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a9037005cb25a97e
2015.11.08 18:28:25.378 5: SW: 010a0013a9037005cb25a97e
CAN für 7005cb -> resend

2015.11.08 18:28:25.380 5: ACK received, WaitForAck=>2 for 010a0013a9037005cb25a97e
2015.11.08 18:28:25.394 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:25.394 5: SW: 06
2015.11.08 18:28:25.395 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:25.413 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:25.413 5: SW: 06
2015.11.08 18:28:25.414 5: device ack reveived, removing 010a0013a9037005cb25a97e from dongle sendstack
2015.11.08 18:28:25.414 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:25.415 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:25.415 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:25.415 5: ZWDongle_Write 00 13a90370052b25a9
70052b gesendet -> 16

2015.11.08 18:28:25.415 5: SW: 010a0013a90370052b25a99e
2015.11.08 18:28:25.431 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9067006cb020000
7006cb received -> Antowrt auf 15

2015.11.08 18:28:25.431 5: SW: 06
2015.11.08 18:28:25.432 5: ZWDongle_0 dispatch 000400a9067006cb020000
2015.11.08 18:28:25.432 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:067006cb020000
2015.11.08 18:28:25.435 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:26.435 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370052b25a99e
2015.11.08 18:28:26.435 5: SW: 010a0013a90370052b25a99e
CAN für 70052b -> resend

2015.11.08 18:28:26.436 5: ACK received, WaitForAck=>2 for 010a0013a90370052b25a99e
2015.11.08 18:28:26.449 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:26.449 5: SW: 06
2015.11.08 18:28:26.450 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:26.475 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:26.475 5: SW: 06
2015.11.08 18:28:26.476 5: device ack reveived, removing 010a0013a90370052b25a99e from dongle sendstack
2015.11.08 18:28:26.476 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:26.476 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:26.476 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:26.476 5: ZWDongle_Write 00 13a90370050325a9
700503 gesendet -> 17

2015.11.08 18:28:26.476 5: SW: 010a0013a90370050325a9b6
2015.11.08 18:28:26.519 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a90670062b020064
70062b received -> Antwort auf 16

2015.11.08 18:28:26.519 5: SW: 06
2015.11.08 18:28:26.520 5: ZWDongle_0 dispatch 000400a90670062b020064
2015.11.08 18:28:26.520 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:0670062b020064
2015.11.08 18:28:26.521 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:27.521 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370050325a9b6
2015.11.08 18:28:27.521 5: SW: 010a0013a90370050325a9b6
CAN für 700503 -> resend

2015.11.08 18:28:27.523 5: ACK received, WaitForAck=>2 for 010a0013a90370050325a9b6
2015.11.08 18:28:27.535 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:27.535 5: SW: 06
2015.11.08 18:28:27.536 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:27.563 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:27.563 5: SW: 06
2015.11.08 18:28:27.564 5: device ack reveived, removing 010a0013a90370050325a9b6 from dongle sendstack
2015.11.08 18:28:27.564 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:27.564 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:27.564 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:27.564 5: ZWDongle_Write 00 13a90370052825a9
700528 gesendet -> 18

2015.11.08 18:28:27.564 5: SW: 010a0013a90370052825a99d
2015.11.08 18:28:27.586 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9067006030200f0
700603 received -> Antwort auf 17

2015.11.08 18:28:27.587 5: SW: 06
2015.11.08 18:28:27.588 5: ZWDongle_0 dispatch 000400a9067006030200f0
2015.11.08 18:28:27.588 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:067006030200f0
2015.11.08 18:28:27.595 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:28.595 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370052825a99d
2015.11.08 18:28:28.595 5: SW: 010a0013a90370052825a99d
CAN für 700528 -> resend

2015.11.08 18:28:28.597 5: ACK received, WaitForAck=>2 for 010a0013a90370052825a99d
2015.11.08 18:28:28.613 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:28.613 5: SW: 06
2015.11.08 18:28:28.614 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:28.631 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:28.631 5: SW: 06
2015.11.08 18:28:28.633 5: device ack reveived, removing 010a0013a90370052825a99d from dongle sendstack
2015.11.08 18:28:28.633 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:28.633 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:28.633 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:28.633 5: ZWDongle_Write 00 13a9037005c925a9
7005c9 gesendet -> 19

2015.11.08 18:28:28.633 5: SW: 010a0013a9037005c925a97c
2015.11.08 18:28:28.650 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9057006280100
700628 received -> Antwort auf 18

2015.11.08 18:28:28.650 5: SW: 06
2015.11.08 18:28:28.651 5: ZWDongle_0 dispatch 000400a9057006280100
2015.11.08 18:28:28.652 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:057006280100
2015.11.08 18:28:28.653 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:29.653 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a9037005c925a97c
2015.11.08 18:28:29.653 5: SW: 010a0013a9037005c925a97c
CAN für 7005c9 -> resend

2015.11.08 18:28:29.655 5: ACK received, WaitForAck=>2 for 010a0013a9037005c925a97c
2015.11.08 18:28:29.667 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:29.667 5: SW: 06
2015.11.08 18:28:29.668 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:29.695 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:29.695 5: SW: 06
2015.11.08 18:28:29.696 5: device ack reveived, removing 010a0013a9037005c925a97c from dongle sendstack
2015.11.08 18:28:29.696 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:29.696 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:29.696 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:29.696 5: ZWDongle_Write 00 13a90370052925a9
700529 gesendet -> 20

2015.11.08 18:28:29.696 5: SW: 010a0013a90370052925a99c
2015.11.08 18:28:29.719 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9057006c90100
7006c9 received -> Antwort auf 19

2015.11.08 18:28:29.719 5: SW: 06
2015.11.08 18:28:29.720 5: ZWDongle_0 dispatch 000400a9057006c90100
2015.11.08 18:28:29.720 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:057006c90100
2015.11.08 18:28:29.723 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:30.723 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370052925a99c
2015.11.08 18:28:30.723 5: SW: 010a0013a90370052925a99c
CAN für 700529 -> resend

2015.11.08 18:28:30.725 5: ACK received, WaitForAck=>2 for 010a0013a90370052925a99c
2015.11.08 18:28:30.739 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:30.739 5: SW: 06
2015.11.08 18:28:30.740 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:30.767 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:30.767 5: SW: 06
2015.11.08 18:28:30.768 5: device ack reveived, removing 010a0013a90370052925a99c from dongle sendstack
2015.11.08 18:28:30.768 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:30.768 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:30.768 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:30.768 5: ZWDongle_Write 00 13a90370052d25a9
70052d gesendet -> 21

2015.11.08 18:28:30.768 5: SW: 010a0013a90370052d25a998
2015.11.08 18:28:30.790 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a906700629020014
700629 reveived -> Antwort auf 20

2015.11.08 18:28:30.790 5: SW: 06
2015.11.08 18:28:30.791 5: ZWDongle_0 dispatch 000400a906700629020014
2015.11.08 18:28:30.791 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:06700629020014
2015.11.08 18:28:30.793 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:31.793 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370052d25a998
2015.11.08 18:28:31.793 5: SW: 010a0013a90370052d25a998
CAN für 70052d -> resend

2015.11.08 18:28:31.796 5: ACK received, WaitForAck=>2 for 010a0013a90370052d25a998
2015.11.08 18:28:31.809 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:31.809 5: SW: 06
2015.11.08 18:28:31.810 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:31.826 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:31.826 5: SW: 06
2015.11.08 18:28:31.827 5: device ack reveived, removing 010a0013a90370052d25a998 from dongle sendstack
2015.11.08 18:28:31.827 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:31.827 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:31.827 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:31.827 5: ZWDongle_Write 00 13a9037005cc25a9
7005cc gesendet -> 22

2015.11.08 18:28:31.827 5: SW: 010a0013a9037005cc25a979
2015.11.08 18:28:31.841 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a90570062d0102
70062d received -> Antwort auf 21

2015.11.08 18:28:31.841 5: SW: 06
2015.11.08 18:28:31.843 5: ZWDongle_0 dispatch 000400a90570062d0102
2015.11.08 18:28:31.843 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:0570062d0102
2015.11.08 18:28:31.844 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:32.845 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a9037005cc25a979
2015.11.08 18:28:32.845 5: SW: 010a0013a9037005cc25a979
CAN für 7005cc -> resend

2015.11.08 18:28:32.847 5: ACK received, WaitForAck=>2 for 010a0013a9037005cc25a979
2015.11.08 18:28:32.860 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:32.860 5: SW: 06
2015.11.08 18:28:32.861 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:32.881 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000003
2015.11.08 18:28:32.881 5: SW: 06
2015.11.08 18:28:32.882 5: device ack reveived, removing 010a0013a9037005cc25a979 from dongle sendstack
2015.11.08 18:28:32.882 5: ZWDongle_0 dispatch 0013a9000003
2015.11.08 18:28:32.882 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.08 18:28:32.882 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:32.883 5: ZWDongle_Write 00 13a90370050225a9
700502 gesendet -> 23

2015.11.08 18:28:32.883 5: SW: 010a0013a90370050225a9b7
2015.11.08 18:28:32.902 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9057006cc0100
7006cc received -> Antwort auf 22

2015.11.08 18:28:32.902 5: SW: 06
2015.11.08 18:28:32.903 5: ZWDongle_0 dispatch 000400a9057006cc0100
2015.11.08 18:28:32.903 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:057006cc0100
2015.11.08 18:28:32.905 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.08 18:28:33.905 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013a90370050225a9b7
2015.11.08 18:28:33.905 5: SW: 010a0013a90370050225a9b7
CAN für 700502 -> resend

2015.11.08 18:28:33.909 5: ACK received, WaitForAck=>2 for 010a0013a90370050225a9b7
2015.11.08 18:28:33.919 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.08 18:28:33.919 5: SW: 06
2015.11.08 18:28:33.921 5: ZWDongle_0 dispatch 011301
2015.11.08 18:28:33.940 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013a9000002
2015.11.08 18:28:33.940 5: SW: 06
2015.11.08 18:28:33.941 5: device ack reveived, removing 010a0013a90370050225a9b7 from dongle sendstack
2015.11.08 18:28:33.941 5: ZWDongle_0 dispatch 0013a9000002
2015.11.08 18:28:33.942 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.08 18:28:33.942 4: ZWDongle_0 transmit OK for a9

2015.11.08 18:28:33.949 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400a9057006020100
700602 received -> Antwort auf 23

2015.11.08 18:28:33.949 5: SW: 06
2015.11.08 18:28:33.950 5: ZWDongle_0 dispatch 000400a9057006020100
2015.11.08 18:28:33.950 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:a9 ARG:057006020100


SEHR ungewöhnlich...

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 09 November 2015, 07:28:09
Hallo Andreas,
was mich bei Deinem Log wundert: Es gibt kein "select timeout".
Bei mir kommt nach 2(?) Sekunden ohne Antwort auf eine get-Abfrage (also auch set configRequestAll) ein select timeout und der Abfrageprozeß hängt so lange. Hast Du da etwas im Code geändert? Ich war deshalb gestern schon (mal wieder) drauf und dran mir eine Abschaffung von get zu wünschen.
Gruß, Christian
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 09 November 2015, 07:46:51
Hallo Krikan,

das Gerät ist per Batterie betrieben, also im WakeUp Modus. Für die Get-Befehle die dann im Sendestack lagern und nach der WakeUp-Notification abgearbeitet werden wird die ReadAnswerFn (von der diese "select timeout" Meldung stammt) nicht aufgerufen, da zu dem Zeitpunkt das System keine Ahnung mehr davon hat ob es ein Set oder ein Get war.

Die Unterscheidung zwischen Set- und Get-Befehl sollte auf gar keinen Fall ausgebaut werden. Wir müssen DRINGEND eine Alternative Lösung zu der ReadAnswerFn finden, die verursacht mMn aktuell die meisten Probleme. Bei mir kommt es immer wieder vor das diese Funktion aufgerufen wird bevor der Get-Befehl überhaupt versendet wurde, dann kommt es natürlich zu dem "select Timeout".

Leider habe ich gerade extreme Probleme mit meinem "Live"-System und mein Hauptrechner meinte gestern auch mal das der neu installiert werden müsse, daher wird es ein paar Tage dauern bis ich mir die Änderungen von Rudi angesehen habe um mir da eine Meinung bilden zu können.

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 09 November 2015, 07:57:21
Zitat von: A.Harrenberg am 09 November 2015, 07:46:51
das Gerät ist per Batterie betrieben, also im WakeUp Modus. Für die Get-Befehle die dann im Sendestack lagern und nach der WakeUp-Notification abgearbeitet werden wird die ReadAnswerFn (von der diese "select timeout" Meldung stammt) nicht aufgerufen, da zu dem Zeitpunkt das System keine Ahnung mehr davon hat ob es ein Set oder ein Get war.
OK, das habe ich nicht bedacht. Habe gestern nur mit netzbetriebenen Geräten probiert. WakeUp-Gerät probiere ich dann später noch mal aus.

ZitatDie Unterscheidung zwischen Set- und Get-Befehl sollte auf gar keinen Fall ausgebaut werden.
Weil mir bekannt ist, dass Du das nicht willst und ich bisher wenig getestet habe, hatte ich mich erst einmal zurückgehalten. Und sah jetzt meine Chance.  ;) War wohl nichts. Ich habe für eine sinnvolle Entscheidungshilfe/-findung zu wenig Verständnis vom Code.

Gruß, Christian
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 09 November 2015, 20:49:58
Hallo Rudi,

ich habe Deine letzten Änderungen an ZWave bzw. ZWDongle noch nicht wirklich nachvollzogen, aber anscheinend kommt es jetzt sehr häufig vor das Antworten irgendwie "verzögert" ankommen. Kann es evtl. sein das Antworten vom Device durch die Umstellung irgendwie nicht mehr sofort ankommen sondern in einem Buffer "liegenbleiben" bis sie abgeholt werden?

Ich sehe das bei mir wenn ich "set <...> configRequestAll" mache, erkenne das aber auch in Logfiles vom DanaLock. Dort benötigen Antworten teilweise >2sekunden bzw. es kommen anscheinend gar keine mehr an.

Ich werde mir mal ein paar zusätzliche Meldungen für das Log einbauen, aber vielleicht hast Du ja schon eine Ahnung/Idee wo es klemmen könnte. Evtl. wird das ja auch durch Änderungen außerhalb von 10_ZWave.pm bzw. 00_ZWDongle.pm verursacht??

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: rudolfkoenig am 09 November 2015, 21:18:02
Passiert das auch, wenn du nur ein get absetzt?

Daten werden jetzt an dem Dongle zum Senden gegeben, wenn fuer die vorherige Nachricht ein 0013xxyy eintrifft. D.h. es kann immer nur eine gesendete Nachricht unbeantwortet beim Dongle sein. Wenn die Report-Nachricht der device die naechste Dongle-Nachricht stoert, dann ist das natuerlich doof, und wir muessen wieder ein Wait einbauen. Leider schicken manche Geraete auf bestimmte get kein Antwort, deswegen weiss ich nicht, wie lange ich warten muss.

Bei mir habe ich uebrigens keine Probleme mit configRequestAll, weder mit WAKE_UP, noch ohne.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 09 November 2015, 21:19:20
Hallo Rudi,

ich verstehe es nicht... Ich habe das jetzt gerade noch ca. 10 Mal gemacht (configRequestAll) und es lief jedesmal komplett durch und alle 23 Antworten kamen an...
Es gibt natürlich noch die üblichen CAN-Msg weil es ja Get-Befehle sind und der nächste Befehl schon vor der Antwort gesendet wird, aber nach einem Resend geht es dann.

Ich habe nicht die geringste Ahnung was da gestern los war bzw. was dann mit dem Log von dem DanaLock los ist...
Hast Du noch eine Idee?

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 09 November 2015, 21:26:04
Hi Rudi,
Zitat von: rudolfkoenig am 09 November 2015, 21:18:02
Passiert das auch, wenn du nur ein get absetzt?

Daten werden jetzt an dem Dongle zum Senden gegeben, wenn fuer die vorherige Nachricht ein 0013xxyy eintrifft. D.h. es kann immer nur eine gesendete Nachricht unbeantwortet beim Dongle sein. Wenn die Report-Nachricht der device die naechste Dongle-Nachricht stoert, dann ist das natuerlich doof, und wir muessen wieder ein Wait einbauen. Leider schicken manche Geraete auf bestimmte get kein Antwort, deswegen weiss ich nicht, wie lange ich warten muss.

Bei mir habe ich uebrigens keine Probleme mit configRequestAll, weder mit WAKE_UP, noch ohne.
wie gesagt, momentan funktioniert es...

Was den Ablauf angeht mussen wir einen Weg finden bei GET-Befehlen auf die Antwort zu warten und das Triggern des Sendstacks (ProcessSendStack) dann erst beim Eintreffen der "richtigen" Nachricht auszulösen. Timeout ist hier natürlich das Problem, ich fürchte das man da schon so bis zu 5 sekunden zulassen müsste. Eintreffen der Nachricht sollte das ganze dann natürlich schneller abarbeiten ,-)

Sorry für das "Aufscheuchen", aber das Log war wirklich merkwürdig und das Log vom DanaLock zeigt auch deutliche Verzögerungen bzw. totales Ausbleiben der Antwort.

Gruß,
Andreas.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: krikan am 09 November 2015, 21:33:34
Bei mir ist bisher auch alles OK. Kann keine wirklichen Probleme feststellen.
Grübel nur über eine mögliche Laufzeitplanung der Telegramme zur Verbesserung der Reaktionsgeschwindigkeit. Beim "configRequestAll" habe ich den Eindruck, dass durch sofortiges Senden des nächsten Telegrammes nach 0013xx unnötige Verzögerungen durch CANs (Kollision Antwort - neues Telegramm) produziert werden.
Titel: Antw:Kommunikationsablauf ZWave
Beitrag von: A.Harrenberg am 09 November 2015, 21:59:44
Hi Krikan,

Zitat von: krikan am 09 November 2015, 21:33:34
Bei mir ist bisher auch alles OK. Kann keine wirklichen Probleme feststellen.
Grübel nur über eine mögliche Laufzeitplanung der Telegramme zur Verbesserung der Reaktionsgeschwindigkeit. Beim "configRequestAll" habe ich den Eindruck, dass durch sofortiges Senden des nächsten Telegrammes nach 0013xx unnötige Verzögerungen durch CANs (Kollision Antwort - neues Telegramm) produziert werden.
ja, das ist ja "mein Reden"... :-)
Übergangsweise würde da sicherlich eine Pause von ca. 0.2-0.3 sekunden helfen, aber dann würden auch SET-Befehle so lange warten was letztendlich sub-optimal wäre. (Und mein AETOC wäre kurz davor wieder einzuschlafen...)

Man könnte mal versuchen den Aufruf des Stacks nach Empfang der 0013 mit einem InternalTimer abzusetzen. Leider ist an der Stelle schon nicht mehr rauszubekommen ob es ein GET- oder SET-Befehl war und man würde in jedem Fall warten. Ich habe mir die Änderungen aber noch nicht richtig angesehen und wüsste daher so auf Anhieb nicht genau an welcher Stelle das hingehört.

Gruß,
Andreas.