Autor Thema: Kommunikationsablauf ZWave  (Gelesen 5239 mal)

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23112
Antw:Kommunikationsablauf ZWave
« Antwort #15 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.

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6867
Antw:Kommunikationsablauf ZWave
« Antwort #16 am: 08 November 2015, 15:12:33 »
Danke für den Umbau.

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?

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23112
Antw:Kommunikationsablauf ZWave
« Antwort #17 am: 08 November 2015, 15:24:56 »
Habe Komma durch Leerzeichen ersetzt.

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #18 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #19 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6867
Antw:Kommunikationsablauf ZWave
« Antwort #20 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

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #21 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6867
Antw:Kommunikationsablauf ZWave
« Antwort #22 am: 09 November 2015, 07:57:21 »
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.

Zitat
Die 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

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #23 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 23112
Antw:Kommunikationsablauf ZWave
« Antwort #24 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.

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #25 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #26 am: 09 November 2015, 21:26:04 »
Hi Rudi,
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6867
Antw:Kommunikationsablauf ZWave
« Antwort #27 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.

Offline A.Harrenberg

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1632
Antw:Kommunikationsablauf ZWave
« Antwort #28 am: 09 November 2015, 21:59:44 »
Hi Krikan,

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.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY