Abarbeitung des WakeUp-Sendstacks wird in Einzelfällen unterbrochen

krikan · 16 März 2016, 20:23:06

Bin ideenlos, außer WNMI_delay noch weiter runter zu setzen. Ich habe auch richtig verstanden, dass das bei allen MS 6 so ist!?

Da A.Harrenberg leider bis Anfang Mai abwesend ist, müssen wir wohl selbst suchen. Ich besorge mir nächste Woche Batterien für meinen MS 6, wenn keine Ideen/Lösung mehr kommen, und experimentiere dann mit.

rudolfkoenig · 16 März 2016, 20:39:15

Was mich erstaunt ist, dass die NO_ACK Meldung vom Controller 7925ms nach Senden des Nachrichts ankommt. Das ist mAn selbst bei den maximal moeglichen 15 Hops zu lang, die Nachrichten werden in meinem langsamen 40kHz Netz unter 10ms (typisch ist 6-8) von einem Knoten zum naechsten weitergeleitet, 7925ms reicht also fuer ueber 1000 Nachrichten. FHEM hat die Geduld jedenfalls viel frueher verloren

@scooty: Du hast nicht versehentlich ein CUL zur Verfuegung?

scooty · 16 März 2016, 21:08:26

Zitat von: rudolfkoenig am 16 März 2016, 20:39:15
@scooty: Du hast nicht versehentlich ein CUL zur Verfuegung?

So gerne ich helfen würde, leider nein.

Andreas

krikan · 20 März 2016, 11:47:16

Zitat von: rudolfkoenig am 12 März 2016, 16:04:24
Ich habe die fortlaufenden callbackIds implementiert, d.h. der Sendstack akzeptiert nur ACKs mit dem zum Nachricht passenden callbackid.

Ich habe die Aenderung mit dem KFOB und dem as6 getestet, sowohl mit dem zme Dongle als auch mit dem ZWCUL. Bei beidem get versionClassAll geuebt, beim as6 auch set und get configAll. Den "overflow" habe ich auch getestet: 00 wird als callbackid (CB) nicht vergeben, nur Werte zwischen 1 und ff. Ich habe keine Fehler gesehen, allerdings ist die Aenderung tiefgreifend, und koennte irgendwo Seiteneffekte haben.

Hallo Rudi!
Vielen Dank!

Habe Deine Änderung getestet. Im Normalbetrieb finde ich keine Auffälligkeiten, alles Bestens.

Die komischen Telegramm-Doppelungen durch stromlos machen der Router und das vom mir vermutete künstliche Erzeugen der ExplorerFrames funktioniert jetzt nicht mehr. Konnte ich sonst problemlos reproduzieren; jetzt sind die Abläufe dann unauffällig.

Abrufe mit devspec für "normale" Befehle funktionieren problemlos. Bei versionClassAll und associationAll werden sofort mehrere Telegramme per SW ans Dongle geschickt und der Ablauf ist dann gestört. War mMn vorher auch so und ist OK. Nur fürs Protokoll

.

Den Ablauf bei CAN verstehe ich nicht so ganz. Im folgenden Log kommt wiederkehrend ein CAN, aber es wird nichts erneut empfangen, sondern nur 1 Sekunden Pause entsteht. Hatte ich ein paar Mal. Die Kommunikation und Ergebnisse sind mMn aber in Ordnung:

Code Auswählen

2016.03.19 21:42:13.468 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass ASSOCIATION
2016.03.19 21:42:13.473 5: ZWDongle_Write 00131a038613852584 (e345c452)
2016.03.19 21:42:13.477 5: SW: 010a00131a0386138525844e
2016.03.19 21:42:13.507 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass CONFIGURATION
2016.03.19 21:42:13.535 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass FIRMWARE_UPDATE_MD
2016.03.19 21:42:13.561 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass MANUFACTURER_PROPRIETARY
2016.03.19 21:42:13.587 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass MANUFACTURER_SPECIFIC
2016.03.19 21:42:13.615 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass METER
2016.03.19 21:42:13.641 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass POWERLEVEL
2016.03.19 21:42:13.665 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass PROTECTION
2016.03.19 21:42:13.688 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SCENE_ACTIVATION
2016.03.19 21:42:13.716 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SENSOR_MULTILEVEL
2016.03.19 21:42:13.741 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SWITCH_BINARY
2016.03.19 21:42:13.767 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SWITCH_MULTILEVEL
2016.03.19 21:42:13.790 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass VERSION
2016.03.19 21:42:13.847 5: ACK received, WaitForAck=>2 for 010a00131a0386138525844e
2016.03.19 21:42:13.849 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:13.851 5: SW: 06
2016.03.19 21:42:13.857 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:13.882 4: ZWDongle_Read ZWDongle_0: rcvd 00138400, sending ACK
2016.03.19 21:42:13.885 5: SW: 06
2016.03.19 21:42:13.890 5: device ack reveived, removing 010a00131a0386138525844e from dongle sendstack
2016.03.19 21:42:13.895 5: ZWDongle_0 dispatch 00138400
2016.03.19 21:42:13.900 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:84
2016.03.19 21:42:13.903 4: ZWDongle_0 transmit OK for CB 84, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:13.925 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486148502, sending ACK
2016.03.19 21:42:13.927 5: SW: 06
2016.03.19 21:42:13.933 5: ZWDongle_0 dispatch 0004001a0486148502
2016.03.19 21:42:13.937 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486148502 CB:00
2016.03.19 21:42:13.948 5: ZWDongle_Write 00131a038613702585 (e345c452)
2016.03.19 21:42:13.953 5: SW: 010a00131a038613702585ba
2016.03.19 21:42:13.971 5: ACK received, WaitForAck=>2 for 010a00131a038613702585ba
2016.03.19 21:42:13.973 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:13.976 5: SW: 06
2016.03.19 21:42:13.981 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:13.997 4: ZWDongle_Read ZWDongle_0: rcvd 00138500, sending ACK
2016.03.19 21:42:13.999 5: SW: 06
2016.03.19 21:42:14.002 5: device ack reveived, removing 010a00131a038613702585ba from dongle sendstack
2016.03.19 21:42:14.006 5: ZWDongle_0 dispatch 00138500
2016.03.19 21:42:14.009 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:85
2016.03.19 21:42:14.011 4: ZWDongle_0 transmit OK for CB 85, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:14.031 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147001, sending ACK
2016.03.19 21:42:14.033 5: SW: 06
2016.03.19 21:42:14.038 5: ZWDongle_0 dispatch 0004001a0486147001
2016.03.19 21:42:14.041 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147001 CB:00
2016.03.19 21:42:14.048 5: ZWDongle_Write 00131a0386137a2586 (e345c452)
2016.03.19 21:42:14.051 5: SW: 010a00131a0386137a2586b3
2016.03.19 21:42:14.063 5: ACK received, WaitForAck=>2 for 010a00131a0386137a2586b3
2016.03.19 21:42:14.066 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:14.067 5: SW: 06
2016.03.19 21:42:14.072 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:14.083 4: ZWDongle_Read ZWDongle_0: rcvd 00138600, sending ACK
2016.03.19 21:42:14.084 5: SW: 06
2016.03.19 21:42:14.088 5: device ack reveived, removing 010a00131a0386137a2586b3 from dongle sendstack
2016.03.19 21:42:14.091 5: ZWDongle_0 dispatch 00138600
2016.03.19 21:42:14.095 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:86
2016.03.19 21:42:14.097 4: ZWDongle_0 transmit OK for CB 86, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:14.113 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147a01, sending ACK
2016.03.19 21:42:14.115 5: SW: 06
2016.03.19 21:42:14.120 5: ZWDongle_0 dispatch 0004001a0486147a01
2016.03.19 21:42:14.125 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147a01 CB:00
2016.03.19 21:42:14.133 5: ZWDongle_Write 00131a038613912587 (e345c452)
2016.03.19 21:42:14.137 5: SW: 010a00131a03861391258759
2016.03.19 21:42:14.150 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:15.091 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147a01, sending ACK
2016.03.19 21:42:15.094 5: SW: 06
2016.03.19 21:42:15.099 5: ZWDongle_0 dispatch 0004001a0486147a01
2016.03.19 21:42:15.104 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147a01 CB:00
2016.03.19 21:42:15.113 5: ZWDongle_Write 00131a038613722588 (e345c452)
2016.03.19 21:42:15.117 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861391258759
2016.03.19 21:42:15.120 5: SW: 010a00131a03861391258759
2016.03.19 21:42:15.137 5: ACK received, WaitForAck=>2 for 010a00131a03861391258759
2016.03.19 21:42:15.140 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:15.142 5: SW: 06
2016.03.19 21:42:15.148 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:15.164 4: ZWDongle_Read ZWDongle_0: rcvd 00138700, sending ACK
2016.03.19 21:42:15.167 5: SW: 06
2016.03.19 21:42:15.170 5: device ack reveived, removing 010a00131a03861391258759 from dongle sendstack
2016.03.19 21:42:15.174 5: ZWDongle_0 dispatch 00138700
2016.03.19 21:42:15.177 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:87
2016.03.19 21:42:15.180 4: ZWDongle_0 transmit OK for CB 87, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:15.188 5: SW: 010a00131a038613722588b5
2016.03.19 21:42:15.198 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486149101, sending ACK
2016.03.19 21:42:15.200 5: SW: 06
2016.03.19 21:42:15.205 5: ZWDongle_0 dispatch 0004001a0486149101
2016.03.19 21:42:15.208 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486149101 CB:00
2016.03.19 21:42:15.216 5: ZWDongle_Write 00131a038613322589 (e345c452)
2016.03.19 21:42:15.223 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:16.238 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a038613722588b5
2016.03.19 21:42:16.241 5: SW: 010a00131a038613722588b5
2016.03.19 21:42:16.252 5: ACK received, WaitForAck=>2 for 010a00131a038613722588b5
2016.03.19 21:42:16.255 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:16.257 5: SW: 06
2016.03.19 21:42:16.262 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:16.276 4: ZWDongle_Read ZWDongle_0: rcvd 00138800, sending ACK
2016.03.19 21:42:16.278 5: SW: 06
2016.03.19 21:42:16.282 5: device ack reveived, removing 010a00131a038613722588b5 from dongle sendstack
2016.03.19 21:42:16.286 5: ZWDongle_0 dispatch 00138800
2016.03.19 21:42:16.289 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:88
2016.03.19 21:42:16.292 4: ZWDongle_0 transmit OK for CB 88, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:16.302 5: SW: 010a00131a038613322589f4
2016.03.19 21:42:16.314 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147201, sending ACK
2016.03.19 21:42:16.316 5: SW: 06
2016.03.19 21:42:16.322 5: ZWDongle_0 dispatch 0004001a0486147201
2016.03.19 21:42:16.325 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147201 CB:00
2016.03.19 21:42:16.333 5: ZWDongle_Write 00131a03861373258a (e345c452)
2016.03.19 21:42:16.340 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:17.352 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a038613322589f4
2016.03.19 21:42:17.354 5: SW: 010a00131a038613322589f4
2016.03.19 21:42:17.365 5: ACK received, WaitForAck=>2 for 010a00131a038613322589f4
2016.03.19 21:42:17.368 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:17.370 5: SW: 06
2016.03.19 21:42:17.374 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:17.386 4: ZWDongle_Read ZWDongle_0: rcvd 00138900, sending ACK
2016.03.19 21:42:17.388 5: SW: 06
2016.03.19 21:42:17.392 5: device ack reveived, removing 010a00131a038613322589f4 from dongle sendstack
2016.03.19 21:42:17.396 5: ZWDongle_0 dispatch 00138900
2016.03.19 21:42:17.399 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:89
2016.03.19 21:42:17.401 4: ZWDongle_0 transmit OK for CB 89, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:17.410 5: SW: 010a00131a03861373258ab6
2016.03.19 21:42:17.421 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143202, sending ACK
2016.03.19 21:42:17.423 5: SW: 06
2016.03.19 21:42:17.429 5: ZWDongle_0 dispatch 0004001a0486143202
2016.03.19 21:42:17.432 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143202 CB:00
2016.03.19 21:42:17.442 5: ZWDongle_Write 00131a03861375258b (e345c452)
2016.03.19 21:42:17.449 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:18.461 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861373258ab6
2016.03.19 21:42:18.464 5: SW: 010a00131a03861373258ab6
2016.03.19 21:42:18.478 5: ACK received, WaitForAck=>2 for 010a00131a03861373258ab6
2016.03.19 21:42:18.481 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:18.483 5: SW: 06
2016.03.19 21:42:18.489 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:18.503 4: ZWDongle_Read ZWDongle_0: rcvd 00138a00, sending ACK
2016.03.19 21:42:18.506 5: SW: 06
2016.03.19 21:42:18.510 5: device ack reveived, removing 010a00131a03861373258ab6 from dongle sendstack
2016.03.19 21:42:18.514 5: ZWDongle_0 dispatch 00138a00
2016.03.19 21:42:18.518 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8a
2016.03.19 21:42:18.520 4: ZWDongle_0 transmit OK for CB 8a, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:18.530 5: SW: 010a00131a03861375258bb1
2016.03.19 21:42:18.543 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147301, sending ACK
2016.03.19 21:42:18.545 5: SW: 06
2016.03.19 21:42:18.550 5: ZWDongle_0 dispatch 0004001a0486147301
2016.03.19 21:42:18.554 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147301 CB:00
2016.03.19 21:42:18.565 5: ZWDongle_Write 00131a0386132b258c (e345c452)
2016.03.19 21:42:18.571 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:19.575 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861375258bb1
2016.03.19 21:42:19.577 5: SW: 010a00131a03861375258bb1
2016.03.19 21:42:19.587 5: ACK received, WaitForAck=>2 for 010a00131a03861375258bb1
2016.03.19 21:42:19.590 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:19.592 5: SW: 06
2016.03.19 21:42:19.597 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:19.610 4: ZWDongle_Read ZWDongle_0: rcvd 00138b00, sending ACK
2016.03.19 21:42:19.612 5: SW: 06
2016.03.19 21:42:19.616 5: device ack reveived, removing 010a00131a03861375258bb1 from dongle sendstack
2016.03.19 21:42:19.619 5: ZWDongle_0 dispatch 00138b00
2016.03.19 21:42:19.623 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8b
2016.03.19 21:42:19.626 4: ZWDongle_0 transmit OK for CB 8b, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:19.634 5: SW: 010a00131a0386132b258ce8
2016.03.19 21:42:19.644 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147502, sending ACK
2016.03.19 21:42:19.647 5: SW: 06
2016.03.19 21:42:19.650 5: ZWDongle_0 dispatch 0004001a0486147502
2016.03.19 21:42:19.654 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147502 CB:00
2016.03.19 21:42:19.661 5: ZWDongle_Write 00131a03861331258d (e345c452)
2016.03.19 21:42:19.667 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:20.679 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a0386132b258ce8
2016.03.19 21:42:20.681 5: SW: 010a00131a0386132b258ce8
2016.03.19 21:42:20.694 5: ACK received, WaitForAck=>2 for 010a00131a0386132b258ce8
2016.03.19 21:42:20.697 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:20.699 5: SW: 06
2016.03.19 21:42:20.704 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:20.717 4: ZWDongle_Read ZWDongle_0: rcvd 00138c00, sending ACK
2016.03.19 21:42:20.719 5: SW: 06
2016.03.19 21:42:20.722 5: device ack reveived, removing 010a00131a0386132b258ce8 from dongle sendstack
2016.03.19 21:42:20.726 5: ZWDongle_0 dispatch 00138c00
2016.03.19 21:42:20.729 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8c
2016.03.19 21:42:20.731 4: ZWDongle_0 transmit OK for CB 8c, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:20.738 5: SW: 010a00131a03861331258df3
2016.03.19 21:42:20.750 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486142b01, sending ACK
2016.03.19 21:42:20.752 5: SW: 06
2016.03.19 21:42:20.757 5: ZWDongle_0 dispatch 0004001a0486142b01
2016.03.19 21:42:20.760 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486142b01 CB:00
2016.03.19 21:42:20.770 5: ZWDongle_Write 00131a03861325258e (e345c452)
2016.03.19 21:42:20.775 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:21.786 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861331258df3
2016.03.19 21:42:21.788 5: SW: 010a00131a03861331258df3
2016.03.19 21:42:21.797 5: ACK received, WaitForAck=>2 for 010a00131a03861331258df3
2016.03.19 21:42:21.800 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:21.801 5: SW: 06
2016.03.19 21:42:21.807 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:21.820 4: ZWDongle_Read ZWDongle_0: rcvd 00138d00, sending ACK
2016.03.19 21:42:21.821 5: SW: 06
2016.03.19 21:42:21.826 5: device ack reveived, removing 010a00131a03861331258df3 from dongle sendstack
2016.03.19 21:42:21.829 5: ZWDongle_0 dispatch 00138d00
2016.03.19 21:42:21.832 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8d
2016.03.19 21:42:21.834 4: ZWDongle_0 transmit OK for CB 8d, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:21.841 5: SW: 010a00131a03861325258ee4
2016.03.19 21:42:21.851 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143102, sending ACK
2016.03.19 21:42:21.853 5: SW: 06
2016.03.19 21:42:21.858 5: ZWDongle_0 dispatch 0004001a0486143102
2016.03.19 21:42:21.860 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143102 CB:00
2016.03.19 21:42:21.868 5: ZWDongle_Write 00131a03861326258f (e345c452)
2016.03.19 21:42:21.873 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:22.886 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861325258ee4
2016.03.19 21:42:22.888 5: SW: 010a00131a03861325258ee4
2016.03.19 21:42:22.900 5: ACK received, WaitForAck=>2 for 010a00131a03861325258ee4
2016.03.19 21:42:22.902 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:22.905 5: SW: 06
2016.03.19 21:42:22.910 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:22.923 4: ZWDongle_Read ZWDongle_0: rcvd 00138e00, sending ACK
2016.03.19 21:42:22.925 5: SW: 06
2016.03.19 21:42:22.930 5: device ack reveived, removing 010a00131a03861325258ee4 from dongle sendstack
2016.03.19 21:42:22.934 5: ZWDongle_0 dispatch 00138e00
2016.03.19 21:42:22.937 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8e
2016.03.19 21:42:22.940 4: ZWDongle_0 transmit OK for CB 8e, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:22.948 5: SW: 010a00131a03861326258fe6
2016.03.19 21:42:22.960 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486142501, sending ACK
2016.03.19 21:42:22.962 5: SW: 06
2016.03.19 21:42:22.967 5: ZWDongle_0 dispatch 0004001a0486142501
2016.03.19 21:42:22.971 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486142501 CB:00
2016.03.19 21:42:22.981 5: ZWDongle_Write 00131a038613862590 (e345c452)
2016.03.19 21:42:22.990 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:24.004 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861326258fe6
2016.03.19 21:42:24.007 5: SW: 010a00131a03861326258fe6
2016.03.19 21:42:24.020 5: ACK received, WaitForAck=>2 for 010a00131a03861326258fe6
2016.03.19 21:42:24.024 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:24.026 5: SW: 06
2016.03.19 21:42:24.032 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:24.050 4: ZWDongle_Read ZWDongle_0: rcvd 00138f00, sending ACK
2016.03.19 21:42:24.058 5: SW: 06
2016.03.19 21:42:24.062 5: device ack reveived, removing 010a00131a03861326258fe6 from dongle sendstack
2016.03.19 21:42:24.066 5: ZWDongle_0 dispatch 00138f00
2016.03.19 21:42:24.070 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:8f
2016.03.19 21:42:24.073 4: ZWDongle_0 transmit OK for CB 8f, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:24.083 5: SW: 010a00131a03861386259059
2016.03.19 21:42:24.102 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486142603, sending ACK
2016.03.19 21:42:24.104 5: SW: 06
2016.03.19 21:42:24.110 5: ZWDongle_0 dispatch 0004001a0486142603
2016.03.19 21:42:24.113 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486142603 CB:00
2016.03.19 21:42:24.121 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.19 21:42:25.132 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a03861386259059
2016.03.19 21:42:25.135 5: SW: 010a00131a03861386259059
2016.03.19 21:42:25.147 5: ACK received, WaitForAck=>2 for 010a00131a03861386259059
2016.03.19 21:42:25.151 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.19 21:42:25.152 5: SW: 06
2016.03.19 21:42:25.158 5: ZWDongle_0 dispatch 011301
2016.03.19 21:42:25.173 4: ZWDongle_Read ZWDongle_0: rcvd 00139000, sending ACK
2016.03.19 21:42:25.176 5: SW: 06
2016.03.19 21:42:25.179 5: device ack reveived, removing 010a00131a03861386259059 from dongle sendstack
2016.03.19 21:42:25.182 5: ZWDongle_0 dispatch 00139000
2016.03.19 21:42:25.186 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:90
2016.03.19 21:42:25.188 4: ZWDongle_0 transmit OK for CB 90, target ZWave_SWITCH_MULTILEVEL_26
2016.03.19 21:42:25.203 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486148601, sending ACK
2016.03.19 21:42:25.206 5: SW: 06
2016.03.19 21:42:25.212 5: ZWDongle_0 dispatch 0004001a0486148601
2016.03.19 21:42:25.215 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486148601 CB:00

Habe es nur ein Mal per Zufall geschafft den Ablauf durcheinanderzubringen, indem ich "apt-get dist-upgrade" während der Befehlsabsetzung aufgerufen habe. Dadurch habe ich einen ählichen Ablauf wie vorher durch "stromlos machen" von Routern bekommen. Nach dem "no response from device, removing" werden die 0013-ACK den falschen Telegrammen zugeordnet. Wollte es Dir nicht vorenthalten, obwohl die Entstehung mehr als grenzwertig ist.

Code Auswählen

2016.03.20 10:30:15.284 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass ASSOCIATION
2016.03.20 10:30:15.297 5: ZWDongle_Write 00131a03861385250e (e345c452)
2016.03.20 10:30:15.312 5: SW: 010a00131a03861385250ec4
2016.03.20 10:30:15.376 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass CONFIGURATION
2016.03.20 10:30:15.412 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass FIRMWARE_UPDATE_MD
2016.03.20 10:30:15.470 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass MANUFACTURER_PROPRIETARY
2016.03.20 10:30:15.526 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass MANUFACTURER_SPECIFIC
2016.03.20 10:30:15.569 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass METER
2016.03.20 10:30:15.611 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass POWERLEVEL
2016.03.20 10:30:15.668 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass PROTECTION
2016.03.20 10:30:15.712 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SCENE_ACTIVATION
2016.03.20 10:30:15.753 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SENSOR_MULTILEVEL
2016.03.20 10:30:15.811 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SWITCH_BINARY
2016.03.20 10:30:15.864 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass SWITCH_MULTILEVEL
2016.03.20 10:30:15.922 2: ZWave get ZWave_SWITCH_MULTILEVEL_26 versionClass VERSION
2016.03.20 10:30:16.048 5: ACK received, WaitForAck=>2 for 010a00131a03861385250ec4
2016.03.20 10:30:16.051 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:16.053 5: SW: 06
2016.03.20 10:30:16.068 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:16.150 4: ZWDongle_Read ZWDongle_0: rcvd 00130e00, sending ACK
2016.03.20 10:30:16.152 5: SW: 06
2016.03.20 10:30:16.166 5: device ack reveived, removing 010a00131a03861385250ec4 from dongle sendstack
2016.03.20 10:30:16.170 5: ZWDongle_0 dispatch 00130e00
2016.03.20 10:30:16.184 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:0e
2016.03.20 10:30:16.186 4: ZWDongle_0 transmit OK for CB 0e, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:16.219 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486148502, sending ACK
2016.03.20 10:30:16.224 5: SW: 06
2016.03.20 10:30:16.235 5: ZWDongle_0 dispatch 0004001a0486148502
2016.03.20 10:30:16.245 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486148502 CB:00
2016.03.20 10:30:16.267 5: ZWDongle_Write 00131a03861370250f (e345c452)
2016.03.20 10:30:16.278 5: SW: 010a00131a03861370250f30
2016.03.20 10:30:16.310 5: ACK received, WaitForAck=>2 for 010a00131a03861370250f30
2016.03.20 10:30:16.316 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:16.321 5: SW: 06
2016.03.20 10:30:16.331 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:16.384 4: ZWDongle_Read ZWDongle_0: rcvd 00130f00, sending ACK
2016.03.20 10:30:16.387 5: SW: 06
2016.03.20 10:30:16.390 5: device ack reveived, removing 010a00131a03861370250f30 from dongle sendstack
2016.03.20 10:30:16.397 5: ZWDongle_0 dispatch 00130f00
2016.03.20 10:30:16.400 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:0f
2016.03.20 10:30:16.403 4: ZWDongle_0 transmit OK for CB 0f, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:16.447 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147001, sending ACK
2016.03.20 10:30:16.449 5: SW: 06
2016.03.20 10:30:16.464 5: ZWDongle_0 dispatch 0004001a0486147001
2016.03.20 10:30:16.468 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147001 CB:00
2016.03.20 10:30:16.486 5: ZWDongle_Write 00131a0386137a2510 (e345c452)
2016.03.20 10:30:16.489 5: SW: 010a00131a0386137a251025
2016.03.20 10:30:16.515 5: ACK received, WaitForAck=>2 for 010a00131a0386137a251025
2016.03.20 10:30:16.518 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:16.519 5: SW: 06
2016.03.20 10:30:16.529 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:16.564 4: ZWDongle_Read ZWDongle_0: rcvd 00131000, sending ACK
2016.03.20 10:30:16.566 5: SW: 06
2016.03.20 10:30:16.570 5: device ack reveived, removing 010a00131a0386137a251025 from dongle sendstack
2016.03.20 10:30:16.572 5: ZWDongle_0 dispatch 00131000
2016.03.20 10:30:16.586 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:10
2016.03.20 10:30:16.588 4: ZWDongle_0 transmit OK for CB 10, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:16.643 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147a01, sending ACK
2016.03.20 10:30:16.655 5: SW: 06
2016.03.20 10:30:16.660 5: ZWDongle_0 dispatch 0004001a0486147a01
2016.03.20 10:30:16.674 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147a01 CB:00
2016.03.20 10:30:16.682 5: ZWDongle_Write 00131a038613912511 (e345c452)
2016.03.20 10:30:16.697 5: SW: 010a00131a038613912511cf
2016.03.20 10:30:16.711 5: ACK received, WaitForAck=>2 for 010a00131a038613912511cf
2016.03.20 10:30:16.724 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:16.727 5: SW: 06
2016.03.20 10:30:16.744 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:16.767 4: ZWDongle_Read ZWDongle_0: rcvd 00131100, sending ACK
2016.03.20 10:30:16.769 5: SW: 06
2016.03.20 10:30:16.785 5: device ack reveived, removing 010a00131a038613912511cf from dongle sendstack
2016.03.20 10:30:16.788 5: ZWDongle_0 dispatch 00131100
2016.03.20 10:30:16.791 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:11
2016.03.20 10:30:16.804 4: ZWDongle_0 transmit OK for CB 11, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:16.827 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486149101, sending ACK
2016.03.20 10:30:16.829 5: SW: 06
2016.03.20 10:30:16.845 5: ZWDongle_0 dispatch 0004001a0486149101
2016.03.20 10:30:16.849 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486149101 CB:00
2016.03.20 10:30:16.875 5: ZWDongle_Write 00131a038613722512 (e345c452)
2016.03.20 10:30:16.879 5: SW: 010a00131a0386137225122f
2016.03.20 10:30:18.259 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131a0386137225122f
2016.03.20 10:30:18.261 5: SW: 010a00131a0386137225122f
2016.03.20 10:30:18.287 5: ACK received, WaitForAck=>2 for 010a00131a0386137225122f
2016.03.20 10:30:18.296 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:18.302 5: SW: 06
2016.03.20 10:30:18.308 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:18.321 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:18.327 5: SW: 06
2016.03.20 10:30:18.337 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:18.346 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.20 10:30:18.395 4: ZWDongle_Read ZWDongle_0: rcvd 00131200, sending ACK
2016.03.20 10:30:18.399 5: SW: 06
2016.03.20 10:30:18.413 5: device ack reveived, removing 010a00131a0386137225122f from dongle sendstack
2016.03.20 10:30:18.416 5: ZWDongle_0 dispatch 00131200
2016.03.20 10:30:18.420 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:12
2016.03.20 10:30:18.422 4: ZWDongle_0 transmit OK for CB 12, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:18.445 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147201, sending ACK
2016.03.20 10:30:18.447 5: SW: 06
2016.03.20 10:30:18.466 5: ZWDongle_0 dispatch 0004001a0486147201
2016.03.20 10:30:18.469 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147201 CB:00
2016.03.20 10:30:18.487 5: ZWDongle_Write 00131a038613322513 (e345c452)
2016.03.20 10:30:18.490 5: SW: 010a00131a0386133225136e
2016.03.20 10:30:18.527 5: ACK received, WaitForAck=>2 for 010a00131a0386133225136e
2016.03.20 10:30:18.530 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:18.531 5: SW: 06
2016.03.20 10:30:18.546 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:39.325 4: no response from device, removing 010a00131a0386133225136e from dongle sendstack
2016.03.20 10:30:39.374 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_26 after 5s for sentget:131a038613322513
2016.03.20 10:30:39.379 5: ZWDongle_Write 00131a038613732514 (e345c452)
2016.03.20 10:30:39.383 5: SW: 010a00131a03861373251428
2016.03.20 10:30:41.073 4: ZWDongle_Read ZWDongle_0: rcvd 00131300, sending ACK
2016.03.20 10:30:41.085 5: SW: 06
2016.03.20 10:30:41.094 5: device ack reveived, removing 010a00131a03861373251428 from dongle sendstack
2016.03.20 10:30:41.097 5: ZWDongle_0 dispatch 00131300
2016.03.20 10:30:41.100 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:13
2016.03.20 10:30:41.103 4: ZWDongle_0 transmit OK for CB 13, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:41.137 4: ZWDongle_Read ZWDongle_0: rcvd 00131300, sending ACK
2016.03.20 10:30:41.138 5: SW: 06
2016.03.20 10:30:41.156 5: ZWDongle_0 dispatch 00131300
2016.03.20 10:30:41.160 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:13
2016.03.20 10:30:41.162 4: ZWDongle_0 transmit OK for CB 13, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:41.180 4: ZWDongle_Read ZWDongle_0: rcvd 00131300, sending ACK
2016.03.20 10:30:41.183 5: SW: 06
2016.03.20 10:30:41.199 5: ZWDongle_0 dispatch 00131300
2016.03.20 10:30:41.202 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:13
2016.03.20 10:30:41.215 4: ZWDongle_0 transmit OK for CB 13, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:41.222 4: ZWDongle_Read ZWDongle_0: rcvd 00131300, sending ACK
2016.03.20 10:30:41.235 5: SW: 06
2016.03.20 10:30:41.240 5: ZWDongle_0 dispatch 00131300
2016.03.20 10:30:41.254 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:13
2016.03.20 10:30:41.256 4: ZWDongle_0 transmit OK for CB 13, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:41.274 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143202, sending ACK
2016.03.20 10:30:41.276 5: SW: 06
2016.03.20 10:30:41.280 5: ZWDongle_0 dispatch 0004001a0486143202
2016.03.20 10:30:41.286 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143202 CB:00
2016.03.20 10:30:41.305 5: ZWDongle_Write 00131a038613752515 (e345c452)
2016.03.20 10:30:41.309 5: SW: 010a00131a0386137525152f
2016.03.20 10:30:41.326 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143202, sending ACK
2016.03.20 10:30:41.329 5: SW: 06
2016.03.20 10:30:41.346 5: ZWDongle_0 dispatch 0004001a0486143202
2016.03.20 10:30:41.350 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143202 CB:00
2016.03.20 10:30:41.370 5: ZWDongle_Write 00131a0386132b2516 (e345c452)
2016.03.20 10:30:41.388 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143202, sending ACK
2016.03.20 10:30:41.390 5: SW: 06
2016.03.20 10:30:41.406 5: ZWDongle_0 dispatch 0004001a0486143202
2016.03.20 10:30:41.410 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143202 CB:00
2016.03.20 10:30:41.430 5: ZWDongle_Write 00131a038613312517 (e345c452)
2016.03.20 10:30:41.449 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486143202, sending ACK
2016.03.20 10:30:41.453 5: SW: 06
2016.03.20 10:30:41.470 5: ZWDongle_0 dispatch 0004001a0486143202
2016.03.20 10:30:41.484 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486143202 CB:00
2016.03.20 10:30:41.492 5: ZWDongle_Write 00131a038613252518 (e345c452)
2016.03.20 10:30:41.514 5: ACK received, WaitForAck=>2 for 010a00131a0386137525152f
2016.03.20 10:30:41.516 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:41.517 5: SW: 06
2016.03.20 10:30:41.522 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:41.526 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:41.528 5: SW: 06
2016.03.20 10:30:41.544 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:44.079 4: no response from device, removing 010a00131a0386137525152f from dongle sendstack
2016.03.20 10:30:44.081 5: SW: 010a00131a0386132b251672
2016.03.20 10:30:44.602 4: ZWDongle_Read ZWDongle_0: rcvd 00131400, sending ACK
2016.03.20 10:30:44.614 5: SW: 06
2016.03.20 10:30:44.624 5: device ack reveived, removing 010a00131a0386132b251672 from dongle sendstack
2016.03.20 10:30:44.627 5: ZWDongle_0 dispatch 00131400
2016.03.20 10:30:44.631 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:14
2016.03.20 10:30:44.643 4: ZWDongle_0 transmit OK for CB 14, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:44.651 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147301, sending ACK
2016.03.20 10:30:44.653 5: SW: 06
2016.03.20 10:30:44.669 5: ZWDongle_0 dispatch 0004001a0486147301
2016.03.20 10:30:44.676 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147301 CB:00
2016.03.20 10:30:44.692 5: ZWDongle_Write 00131a038613262519 (e345c452)
2016.03.20 10:30:44.705 5: SW: 010a00131a03861331251769
2016.03.20 10:30:44.717 5: ACK received, WaitForAck=>2 for 010a00131a03861331251769
2016.03.20 10:30:44.723 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:44.729 5: SW: 06
2016.03.20 10:30:44.739 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:44.750 4: ZWDongle_Read ZWDongle_0: rcvd 00131500, sending ACK
2016.03.20 10:30:44.756 5: SW: 06
2016.03.20 10:30:44.762 5: device ack reveived, removing 010a00131a03861331251769 from dongle sendstack
2016.03.20 10:30:44.770 5: ZWDongle_0 dispatch 00131500
2016.03.20 10:30:44.779 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:15
2016.03.20 10:30:44.785 4: ZWDongle_0 transmit OK for CB 15, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:44.801 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486147502, sending ACK
2016.03.20 10:30:44.805 5: SW: 06
2016.03.20 10:30:44.816 5: ZWDongle_0 dispatch 0004001a0486147502
2016.03.20 10:30:44.820 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486147502 CB:00
2016.03.20 10:30:44.839 5: ZWDongle_Write 00131a03861386251a (e345c452)
2016.03.20 10:30:44.854 5: SW: 010a00131a03861325251872
2016.03.20 10:30:44.875 5: ACK received, WaitForAck=>2 for 010a00131a03861325251872
2016.03.20 10:30:44.877 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:44.879 5: SW: 06
2016.03.20 10:30:44.885 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:46.942 5: SW: 010a00131a03861326251970
2016.03.20 10:30:49.456 4: ZWDongle_Read ZWDongle_0: rcvd 00131600, sending ACK
2016.03.20 10:30:49.457 5: SW: 06
2016.03.20 10:30:49.461 5: device ack reveived, removing 010a00131a03861326251970 from dongle sendstack
2016.03.20 10:30:49.465 5: ZWDongle_0 dispatch 00131600
2016.03.20 10:30:49.468 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:16
2016.03.20 10:30:49.471 4: ZWDongle_0 transmit OK for CB 16, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:49.504 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486142b01, sending ACK
2016.03.20 10:30:49.506 5: SW: 06
2016.03.20 10:30:49.511 5: ZWDongle_0 dispatch 0004001a0486142b01
2016.03.20 10:30:49.524 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486142b01 CB:00
2016.03.20 10:30:49.532 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.20 10:30:49.544 5: ACK received, WaitForAck=>2 for 010a00131a03861386251ad3
2016.03.20 10:30:49.547 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.20 10:30:49.549 5: SW: 06
2016.03.20 10:30:49.554 5: ZWDongle_0 dispatch 011301
2016.03.20 10:30:49.558 4: ZWDongle_Read ZWDongle_0: rcvd 00131800, sending ACK
2016.03.20 10:30:49.560 5: SW: 06
2016.03.20 10:30:49.575 5: device ack reveived, removing 010a00131a03861386251ad3 from dongle sendstack
2016.03.20 10:30:49.578 5: ZWDongle_0 dispatch 00131800
2016.03.20 10:30:49.582 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:18
2016.03.20 10:30:49.595 4: ZWDongle_0 transmit OK for CB 18, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:49.602 4: ZWDongle_Read ZWDongle_0: rcvd 00131800, sending ACK
2016.03.20 10:30:49.615 5: SW: 06
2016.03.20 10:30:49.620 5: ZWDongle_0 dispatch 00131800
2016.03.20 10:30:49.635 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:18
2016.03.20 10:30:49.638 4: ZWDongle_0 transmit OK for CB 18, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:49.655 4: ZWDongle_Read ZWDongle_0: rcvd 00131800, sending ACK
2016.03.20 10:30:49.657 5: SW: 06
2016.03.20 10:30:49.667 5: ZWDongle_0 dispatch 00131800
2016.03.20 10:30:49.671 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:18
2016.03.20 10:30:49.684 4: ZWDongle_0 transmit OK for CB 18, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:49.690 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.20 10:30:49.693 4: ZWDongle_Read ZWDongle_0: rcvd 00131800, sending ACK
2016.03.20 10:30:49.705 5: SW: 06
2016.03.20 10:30:49.715 5: ZWDongle_0 dispatch 00131800
2016.03.20 10:30:49.719 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:18
2016.03.20 10:30:49.721 4: ZWDongle_0 transmit OK for CB 18, target ZWave_SWITCH_MULTILEVEL_26
2016.03.20 10:30:49.739 4: ZWDongle_Read ZWDongle_0: rcvd 0004001a0486142501, sending ACK
2016.03.20 10:30:49.741 5: SW: 06
2016.03.20 10:30:49.752 5: ZWDongle_0 dispatch 0004001a0486142501
2016.03.20 10:30:49.757 4: CMD:APPLICATION_COMMAND_HANDLER ID:1a ARG:0486142501 CB:00

Gruß, Christian

rudolfkoenig · 21 März 2016, 11:16:01

ZitatDen Ablauf bei CAN verstehe ich nicht so ganz. Im folgenden Log kommt wiederkehrend ein CAN, aber es wird nichts erneut empfangen, sondern nur 1 Sekunden Pause entsteht. Hatte ich ein paar Mal. Die Kommunikation und Ergebnisse sind mMn aber in Ordnung:

Ich habe eine Theorie (keine wirkliche Erklaereung): wenn der Dongle gerade was empfaengt, dann liefert er CAN zurueck.
Das empfangene Paket kann aber fuer jemanden anderen bestimmt sein, oder beschaedigt, oder nur Rauschen und das wird nicht nach oben gemeldet. Wir koennten den CAN Timeout von 1sek aendern, bin aber noch nocht ueberzeugt, ob das was hilft.

krikan · 21 März 2016, 11:48:43

ZitatWir koennten den CAN Timeout von 1sek aendern, bin aber noch nocht ueberzeugt, ob das was hilft.

Würde es erst mal so lassen. Der Ablauf ist mMn jetzt prima. Habe das alles nur dokumentiert, falls ich mit meinen Einschätzung falsch liege. Habe gestern auch bereits mit dem eigentlichen Topic Wakeup-Sendstack probiert und bisher ist alles gut

.

Offtopic: Versuche immer mit ZWCul über separaten Computer mitzuloggen (40k und 100K gleichzeitig); mMn fehlen aber immer Telegramme gerade in den Extremsituationen. Könnte 9,6k noch eine Rolle spielen? Dachte das würde nicht mehr genutzt.

rudolfkoenig · 21 März 2016, 12:04:48

Ich habe den Eindruck, dass manche Geraete (KFOB) bei Nicht-Erreichbarkeit ueber 100k manchmal auch andere Frequenzen testen. Der ASS6 scheint die letzte Antwort-Frequenz zu merken, und antwortet damit. Es sei denn, ich druecke den Knopf zum Umschalten auf dem Geraet, was ein NIF aussendet (doofes Patent): das wird prinzipiell nur mit 9.6 geschickt.

Zitat40k und 100K gleichzeitig

Sind das zwei Empfaenger oder hast du einen neuen Trick auf Lager?

Achtung: mehrere Antennen nebeneinander stoeren sich gegenseitig beim Empfang, deswegen steht in jedem FS20 Beiblatt, dass die Geraete nicht naeher als 30cm nebeneinander stehen sollten. Das habe ich bei FS20 experimentell auch nachgewiesen :/

krikan · 21 März 2016, 12:29:28

Zitat von: rudolfkoenig am 21 März 2016, 12:04:48
Sind das zwei Empfaenger oder hast du einen neuen Trick auf Lager?

Trick? Habe technisch aufgerüstet und 2 Culs

Antennen sollten weit genug auseinander sein; sind mit USB-Verlängerungen am Notebook angeschlossen.
Blöderweise sind Zeitstempel zwischen Notebook und Raspi nicht deckungsgleich, so dass Abgleich der Logs mit Deinem geposteten "sort" nicht so einfach ist. Culs am Raspi anschließen überfordert diesen.

ZitatIch habe den Eindruck, dass manche Geraete (KFOB) bei Nicht-Erreichbarkeit ueber 100k manchmal auch andere Frequenzen testen

Das sehe ich genauso.

ZitatEs sei denn, ich druecke den Knopf zum Umschalten auf dem Geraet, was ein NIF aussendet (doofes Patent): das wird prinzipiell nur mit 9.6 geschickt.

Also gibt es prinzipiell auch noch 9,6 K Nachrichten. Das passt zur Befürchtung. In den Extremsituationen sieht es immer so aus, als fehlten Nachrichten, da ZWDongle empfängt und Culs nichts liefern. Oder die Culs kommen nicht mit!?

rudolfkoenig · 21 März 2016, 13:44:50

ZitatBlöderweise sind Zeitstempel zwischen Notebook und Raspi nicht deckungsgleich, so dass Abgleich der Logs mit Deinem geposteten "sort" nicht so einfach ist.

Am besten ueberall NTP installieren und aktivieren.

ZitatOder die Culs kommen nicht mit!?

Wenn das stimmt, dann muessen wir noch an der ZWave-Konfiguration der CC1101 arbeiten. Obwohl ich bisher keine Probleme gemerkt habe.

krikan · 21 März 2016, 21:07:35

Zitat von: rudolfkoenig am 21 März 2016, 13:44:50
Am besten ueberall NTP installieren und aktivieren.

Puh, Thema NTP schaue ich mir bei Gelegenheit mal an.

Zurück zum Thema Wakeup-Sendstack und insb. "AEOTEC MS 6" mit Batteriebetrieb und meinen Ergebnissen aus Tests mit diesem Sensor:

ZW_APPLICATION_UPDATE wird nicht bei automatischem Wakeup vom Sensor verschickt. Dann kommt nur "wakeup notification". ZW_APPLICATION_UPDATE und anschließend wakeup notification kommt nur bei manuellem Wakeup per Geräte-Taster. Das machen aber auch andere Wakeup-Geräte. Nach meinem Tests erkenne ich keine Probleme in der Abarbeitung eines Sendstacks bei manuellem und automatischen Wakeup. Abarbeitung ist auch bei großem Wakeup-Sendstack ok. Darum (sorry, Andreas) halte ich das Attribut "noWakeupForApplicationUpdate" für überflüssig. Es kann nicht das NO_ACK-Problem beim automatischen Wakeup lösen und auch beim manuellem Wakeup erkenne ich keine Probleme.
Das Attribut "WNMI_delay" ist mMn eine Lösung zur Vermeidung des NO_ACK des Sensors. Mein Sensor schläft rund 0.2 Sek. nach erhalt der automatischen wakeup notification wieder ein, wenn er bis dahin keine Nachricht vom Controller erhalten hat. Die WNMI-Nachricht, die erst 2(?) Sekunden nach der wakeup notification von FHEM bei leerem Wakeup-Sendstack verschickt wird, endet daher immer mit NO_ACK. Wird von FHEM direkt nach der wakeup notification eine Nachricht (bspw. get <device> battery per notify) an den Sensor verschickt, ist er länger wach. Auch ein WMNI-Nachricht nach ca. 1 Sekunde wird vom Sensor noch mit einem ACK bestätigt. Also sollten die NO_ACK verschwinden, wenn man WMNI_DELAY auf 0.2 setzt oder eine andere Nachricht per notify/DOIF,.. bei einer wakeup notification verschickt. Laut einem Z-Way-Log, das ich habe, schickt Z-way Wakeup-Geräte bereits 0.1 Sekunden nach wakeup notification in den Schlaf zurück, wenn keine Nachricht im Wakeup-Sendstack liegt. (leider habe ich auf die Schnelle nur ein Log mit Wakeup-Gerät von Z-Way gefunden)

Wäre schön, wenn noch einer gegentesten könnte.

list mit config-Werten des Sensors:
Code Auswählen Erweitern
Internals: DEF e345c452 43 IODev ZWDongle_0 LASTInputDev ZWDongle_0 MSGCNT 95 NAME ZWave_SENSOR_MULTILEVEL_43 NR 296 STATE OK TYPE ZWave ZWDongle_0_MSGCNT 95 ZWDongle_0_RAWMSG 0004002b0a7105000000ff07030000 ZWDongle_0_TIME 2016-03-21 20:25:41 homeId e345c452 isWakeUp 1 lastMsgSent 1458588236.97187 nodeIdHex 2b Readings: 2016-03-21 18:47:54 CMD ZW_APPLICATION_UPDATE 2016-03-21 20:25:41 alarm HomeSecurity: Tampering, product covering removed, arg 0000 2016-03-21 18:51:59 assocGroup_1 Max 5 Nodes ZWDongle_0 2016-03-21 19:07:57 assocGroups 1 2016-03-21 20:04:02 basicSet ff 2016-03-21 20:23:58 battery 50 % 2016-03-21 18:35:44 configBatteryReportingThreshold 10 2016-03-21 18:35:44 configCommandOptions BasicSetDefault 2016-03-21 18:35:45 configEnableDisableLockConfiguration Disable 2016-03-21 18:35:45 configEnableMotionSensor EnabledLevel5MaximumSensitivity 2016-03-21 18:35:45 configGroup1Interval 3600 2016-03-21 18:35:46 configGroup1Reports 241 2016-03-21 18:35:46 configGroup2Interval 3600 2016-03-21 18:35:46 configGroup2Reports 0 2016-03-21 18:35:47 configGroup3Interval 3600 2016-03-21 18:35:47 configGroup3Reports 0 2016-03-21 18:35:48 configHumidityCalibration 0 2016-03-21 18:35:48 configHumidityReportingThreshold 10 2016-03-21 18:35:48 configLowBattery 20 2016-03-21 18:35:49 configLowTempAlarm Disabled 2016-03-21 18:35:49 configLuminanceCalibration 0 2016-03-21 18:35:49 configLuminanceReportingThreshold 100 2016-03-21 18:35:50 configOnTime 240 2016-03-21 18:35:50 configReportingThreshold Disabled 2016-03-21 18:35:52 configTemperatureCalibration 0 2016-03-21 18:35:52 configTemperatureReportingThreshold 20 2016-03-21 18:35:52 configUVReportingThreshold 2 2016-03-21 18:35:53 configUltravioletCalibration 0 2016-03-21 18:35:53 configWakeUp10MinutesOnPowerOn No 2016-03-21 18:32:11 config_9 256 2016-03-21 19:47:56 humidity 35 % 2016-03-21 19:47:58 luminance 3 Lux 2016-02-16 18:56:49 model Aeotec MultiSensor 6 2016-02-16 18:56:49 modelConfig aeotec/multisensor6.xml 2016-02-16 18:56:49 modelId 0086-0002-0064 2016-02-16 19:21:45 reportedState open 2016-03-21 20:08:12 state TRANSMIT_NO_ACK 2016-03-21 19:47:56 temperature 24.7 C 2016-03-21 20:23:59 transmit OK 2016-03-21 19:47:58 ultraviolet 0 UV 2016-02-16 19:38:33 version Lib 3 Prot 4.5 App 1.6 HW 100 FWCounter 0 2016-03-21 20:23:56 wakeup notification 2016-03-21 18:46:12 wakeupIntervalCapabilitiesReport min 240 max 3600 default 3600 step 60 2016-03-21 18:47:56 wakeupReport interval 240 target 1 Attributes: IODev ZWDongle_0 classes WAKE_UP ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY room ZWave stateFormat transmit vclasses ALARM:3 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

krikan · 22 März 2016, 11:16:51

Zitat von: krikan am 21 März 2016, 21:07:35
Laut einem Z-Way-Log, das ich habe, schickt Z-way Wakeup-Geräte bereits 0.1 Sekunden nach wakeup notification in den Schlaf zurück, wenn keine Nachricht im Wakeup-Sendstack liegt.

Nachdem ich mich wunderte, dass das NO_ACK Problem beim AEOTEC Multisensor bei ozw nie gemeldet wurde, habe ich mir ozw noch mal angeschaut. Ozw verschickt laut Log auch nach rund 0.1 Sek. nach wakeup notification die WNMI-Nachricht an Wakeup-Geräte, wenn der Wakeup-Sendstack leer ist bzw. unmittelbar nach Abarbeitung des Wakeup-Sendstacks. Ich meine das war mal anders und befürchte, dass ich auch für eine Wartezeit bis Versand von WNMI war und Rudi nicht

. Das kann ich so wohl nicht mehr aufrechterhalten.

ozw bevorzugt die Kommunikation mit Wakeup-Geräten. Wenn Wakeup-Gerät eine wakeup notification sendet, werden Nachrichten an netzbetriebene Geräte zu Gunsten Wakeup-Geräten zurückgestellt.

Für mich ist es jetzt noch eindeutiger: erhebliche Verkürzung der Wartezeit für WNMI-Versand über Attribut WNMI_delay ist die Lösung für den AEOTEC Sensor, wenn wir nicht generell die Wartezeit bis WNMI-Versand verkürzen.

Die folgende commandref-Aussage halte ich für irreführend und bin für Abschaffung des entsprechenden Attributes:

ZitatnoWakeupForApplicationUpdate
some devices (notable the Aeotec Multisensor 6) are only awake after an APPLICATION UPDATE telegram for a very short time. If this attribute is set (recommended for the Aeotec Multisensor 6), the WakeUp-Stack is not processed after receiving such a message.

Gegenmeinungen sind -wie immer- willkommen

rudolfkoenig · 22 März 2016, 12:15:13

Bevor ich fuer zu viel Verwirrung mit Ein- und Ausbau von Attributen sorge, haette ich gerne eine weitere Meinung (Andreas?) oder jemanden, der das AMS6 ohne noWakeupForApplicationUpdate Attribut gruendlich getestet, und fuer OK gefunden hat.

A.Harrenberg · 22 März 2016, 12:26:19

Hi,

Zitat von: rudolfkoenig am 22 März 2016, 12:15:13
Bevor ich fuer zu viel Verwirrung mit Ein- und Ausbau von Attributen sorge, haette ich gerne eine weitere Meinung (Andreas?) oder jemanden, der das AMS6 ohne noWakeupForApplicationUpdate Attribut gruendlich getestet, und fuer OK gefunden hat.

ich habe leider momentan keine Zeit was zu testen. Ich bin auch ab Donnerstag mit einer kurzen Unterbrechung bis Ende April nicht zu erreichen...

Ich kann jetzt nur aus dem Gedächtnis sagen das bei manuellem Aufwecken auch einige Statusmeldungen übertragen werden bevor die WUN kommt. Wenn der Sendstack bereits während dieser Zeit abgearbeitet wird kam es bei mir immer zu CAN Nachrichten.

Anderes Topic:
Eine Verkürzung des WNMI_delay auf 0.1s müsste mal mit einem (komplexen) Notify geprüft werden. Wenn die Auswertung des Notify etwas dauern sollte könnte man hier den Sensor evtl. zu früh schlafen schicken...

Gruß,
Andreas.

krikan · 22 März 2016, 12:33:31

Zitat von: A.Harrenberg am 22 März 2016, 12:26:19
Hi,ich habe leider momentan keine Zeit was zu testen. Ich bin auch ab Donnerstag mit einer kurzen Unterbrechung bis Ende April nicht zu erreichen...

Schade. Dabei habe ich alles probiert

.

ZitatIch kann jetzt nur aus dem Gedächtnis sagen das bei manuellem Aufwecken auch einige Statusmeldungen übertragen werden bevor die WUN kommt. Wenn der Sendstack bereits während dieser Zeit abgearbeitet wird kam es bei mir immer zu CAN Nachrichten.

CANs, die ja nicht grds. schädlich sind, habe ich gestern beim MS6 nicht provozieren können.
ZW_APPLICATION_UPDATE kommt aber eben nur bei manuellen Wakeup.

ZitatEine Verkürzung des WNMI_delay auf 0.1s müsste mal mit einem (komplexen) Notify geprüft werden. Wenn die Auswertung des Notify etwas dauern sollte könnte man hier den Sensor evtl. zu früh schlafen schicken...

Ja, darum habe ich so meine Bedenken, aber Rudi weiß sicher mehr....

@scooty: Andreas, kannst Du mal bitte probieren? noWakeupForApplicationUpdate hatte bei Dir ja auch nicht geholfen.

rudolfkoenig · 22 März 2016, 13:10:07

Wenn das AMS6 sich nach 0.1 Sekunden Schlafen legt, dann kann man es hinter mehreren Router kaum abfragen oder konfigurieren.
Das WNMI_delay wird nach Abschicken der letzten Nachricht gemessen, damit ist es von der Anzahl der im Sendstack abgelegten Nachrichten unabhaengig. Das WNMI_delay sollte meiner Ansicht nach das Minimum sein von:
- eingestellte Wakeup-Zeit des Geraetes
- Zeit der Funkuebermittlung (Nachricht + Ack) und
- Dauer der aufwendigsten notify/DOIF/etc Berechnung in FHEM
Da die letzten beiden Punkte ueblicherweise unter 0.1s liegen, ist ein WNMI_delay von 0.1 meist akzeptabel (siehe ozw).