Hallo!
Seit ca. einer Woche suche ich (erfolglos) die Ursache und Systematik für ein Stoppen der Abarbeitung des Wakeup-Sendstacks bei meinen WakeUp-Geräten. Erkenne nicht, ob das ein Modul-Problem ist oder in meinem System begründet ist.
Wenn der WakeUp-Sendstack relativ voll ist, stoppt die Abarbeitung des WakeUp-Sendstacks ohne für mich erkennbare Gründe, obwohl der WakeUp-Sendstack noch Befehle enthält. Eine wakeupNoMoreInformation wird von FHEM beim Stoppen der Abarbeitung auch nicht verschickt. Das Phänomen stelle ich bei der Abfrage von "get <device> versionClassAll" fest. Kann aber nicht ausschließen, dass es auch bei anderen Befehlen auftritt.
Beim folgenden Beispiel (leider ohne attr mscelog) waren diverse Abfragen unter anderem auch von versionClassAll im WakeUp-Sendstack. Die Kommunikation mit dem Sensor bricht mit der Log-Zeile "2016.03.01 20:43:39 2: ZWave get ZWave_GARAGE_DOOR_31 versionClass SENSOR_BINARY" ab. Ein Schreiben des Befehls nach ZWDongle steht dort nicht. (vollständiges Log der Kommunikation hängt an)
2016.03.01 20:43:38 2: ZWave get ZWave_GARAGE_DOOR_31 versionClass VERSION
2016.03.01 20:43:38 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.01 20:43:39 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00131f03861372251f27
2016.03.01 20:43:39 5: SW: 010a00131f03861372251f27
2016.03.01 20:43:39 5: ACK received, WaitForAck=>2 for 010a00131f03861372251f27
2016.03.01 20:43:39 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.01 20:43:39 5: SW: 06
2016.03.01 20:43:39 5: ZWDongle_0 dispatch 011301
2016.03.01 20:43:39 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131f00
2016.03.01 20:43:39 5: SW: 06
2016.03.01 20:43:39 5: device ack reveived, removing 010a00131f03861372251f27 from dongle sendstack
2016.03.01 20:43:39 5: ZWDongle_0 dispatch 00131f00
2016.03.01 20:43:39 4: CMD:ZW_SEND_DATA ID:00 ARG:
2016.03.01 20:43:39 4: ZWDongle_0 transmit OK for 1f
2016.03.01 20:43:39 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001f0486147202
2016.03.01 20:43:39 5: SW: 06
2016.03.01 20:43:39 5: ZWDongle_0 dispatch 0004001f0486147202
2016.03.01 20:43:39 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:0486147202
2016.03.01 20:43:39 2: ZWave get ZWave_GARAGE_DOOR_31 versionClass SENSOR_BINARY
2016.03.01 20:44:03 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001f0a8f0101063105012200dc
Das "list" des Devices sieht nach dem Ende der Kommunikation wie nachfolgend wiedergegeben aus. Man erkennt, dass noch etwas im WakeUp-Sendstack steht. Zudem auch am Attribut vclasses einige fehlende Class-Versionen.
Internals:
DEF e345c452 31
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 121
NAME ZWave_GARAGE_DOOR_31
NR 273
STATE 3 %
TYPE ZWave
ZWDongle_0_MSGCNT 121
ZWDongle_0_RAWMSG 0004001f0a8f0101063105012200d7
ZWDongle_0_TIME 2016-03-01 20:45:59
homeId e345c452
isWakeUp 1
lastMsgSent 1456861418.25762
nodeIdHex 1f
Readings:
2016-02-27 16:23:06 CMD ZW_APPLICATION_UPDATE
2016-02-28 14:58:23 SEND_DATA failed:00
2016-03-01 18:39:37 alarm HomeSecurity: Tampering, product covering removed, arg 00
2016-02-25 18:39:23 alarmSupported 01c0
2016-02-28 15:04:08 assocGroup_1 Max 8 Nodes ZWDongle_0
2016-02-28 15:04:09 assocGroup_2 Max 8 Nodes
2016-02-28 14:58:03 assocGroups 2
2016-03-01 18:39:13 battery 100 %
2016-03-01 20:43:26 configAutoReportBatteryTime 12
2016-03-01 20:43:26 configAutoReportDoorWindowStateTime 12
2016-03-01 20:43:27 configAutoReportIlluminationTime 12
2016-03-01 20:43:27 configAutoReportTemperatureTime 12
2016-03-01 20:43:27 configAutoReportTickInterval 30
2016-03-01 20:43:28 configBasicSetLevel 255
2016-03-01 20:43:28 configCustomerFunction 4
2016-03-01 20:43:29 configIlluminationDifferentialReport 0
2016-03-01 20:43:29 configLightThreshold 99
2016-03-01 20:43:29 configMultiSensorFunctionSwitch 4
2016-03-01 20:43:30 configOperationMode 8
2016-03-01 20:43:30 configPIRReDetectIntervalTime 3
2016-03-01 20:43:31 configPIRSensitivity 80
2016-03-01 20:43:31 configTemperatureDifferentialReport 1
2016-03-01 20:43:31 configTurnOffLightTime 4
2016-03-01 18:39:13 luminance 3 %
2016-02-25 21:46:48 model Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor
2016-02-25 21:46:48 modelConfig philio/pst02.xml
2016-02-25 21:46:48 modelId 013c-0002-000c
2016-02-28 12:31:47 neighborList ZWDongle_0 ZWave_SWITCH_MULTILEVEL_4 ZWave_SWITCH_BINARY_6 ZWave_SWITCH_MULTILEVEL_26 ZWave_SWITCH_MULTILEVEL_27
2016-02-28 15:04:08 reportedState open
2016-02-28 15:04:08 state open
2016-03-01 20:45:59 temperature 21.5 C
2016-03-01 20:43:39 transmit OK
2016-02-25 21:45:59 version Lib 3 Prot 3.95 App 1.17 HW 1 FWCounter 1 FW 1.15
2016-02-26 21:03:29 versionClass_20 00
2016-02-26 20:56:17 versionClass_7a 02
2016-02-07 11:06:25 versionClass_85 02
2016-02-26 21:03:27 versionClass_ef 01
2016-03-01 20:43:26 wakeup notification
2016-02-28 14:30:56 wakeupIntervalCapabilitiesReport min 1800 max 432000 default 86400 step 1800
2016-03-01 20:43:32 wakeupReport interval 86400 target 1
SendStack:
sentackget:131f03861372251f
get:131f03861386251f
get:131f03861330251f
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
room ZWave
stateFormat luminance
vclasses ZWAVEPLUS_INFO:2 BATTERY:1 BATTERY:1 ALARM:4 ASSOCIATION:2 CONFIGURATION:1 MANUFACTURER_SPECIFIC:2
Vielleicht übersehe ich etwas oder jemand hat Ideen, woran das liegen könnte.
Gruß, Christian
edit: Betreff des Threads geändert
Hallo Chrisitian,
kann dich zumindest mal beruhigen: es liegt nicht an deinem System - habe seit einer Woche ebenfalls massive Probleme mit den Wakeup-Geräten.
Allerdings muss hierzu nicht einmal der Sendstack voll sein: aktuell gibt es bei Sensoren welche bisher Problemlos kommuniziert hatten und vom Empfang her einwandfrei positioniert sind ständig TRANSMIT_NO_ACK-Meldungen.
Zuerst war ich froh, dass mittlerweile nun wieder die Get NeighborList-Befehle bei Wakeup-Geräten funktionieren - dafür hängt sich jetzt aber die Kommunikation regelmäßig bereits bei einem Get smstatus auf.
Die Ursache habe ich auch noch nicht gefunden, werde evtl. heute mal eine alte Version einspielen um die Sache zu verifizieren und zumindest einen halbwegs "normalen" Betrieb herzustellen.
Gruß Frank
Hallo Christian,
am Log fallen mir zwei Sachen auf:
a) Es gibt ein CAN am Anfang, das ist aber NICHT die Reaktion auf das gerade ausgelöste GET, das wurde ja noch gar nicht vesandt. Mir ist da nicht klar wie das passieren konnte... Eigentlich warten wir doch auf die Antwort bevor die nächste Nachricht ausgelöst/verschickt wird. Also woher kommt dann das CAN? Hierzu muss ich mir mal Dein Log genauer ansehen und auch die ganzen letzten Änderungen von Rudi nachvollziehen. Dazu komme ich aber frühestens am Do. oder Fr.
b.) Durch das CAN wird eine Nachricht erneut verschickt, nach deren Beendigung wird dann bereits der nächste Befehl ausgelöst. Hier scheint der Ablauf des SendStacks durcheinander zu kommen. Durch das erfolgreiche Versenden wird hier anscheinend bereits der nächste Befehl "freigegeben", obwohl der vorherige noch gar nicht bearbeitet wurde.
Falls das am Do/Fr noch aktuell ist versuche ich das mal mit meinem Multisensor nachzustellen (scheint ja ein generelles Problem zu sein) und schau mir das mal genauer an.
Gruß,
Andreas.
@krusi/Frank
Kommunikationsprobleme in Form von TRANSIT_NO_ACK kann ich nicht feststellen, sondern trotz ACK wird die Abarbeitung des WakeUp-Sendstacks unterbrochen. Meine Netze sind stabil. Ich kann mir auch nicht vorstellen, dass eine Änderung der letzten Woche in den Modulen einen ursächlichen Zusammenhang mit Deinem Problem hat. Ich sehe bei mir auch keinen zwingende Verbindung mit einer Moduländerung. Mir ist das Thema letzte Woche aufgefallen und seitdem suche ich.
Gehe also davon aus, dass wir unterschiedlichen Probleme/Ursachen auf der Spur sind.
@Andreas
Bewusst habe ich es bei 2 unterschiedlichen Wakeup-Geräten festgestellt und reproduziert bekommen. Grundproblem: es ist nicht immer so und ich kann nicht defintiv einen Weg zum Nachstellen aufzeigen. Aufgefallen und reproduziert habe ich es bei versionClassAll-Abfragen. Deinen CAN-Hinweis müsste ich mir nach mal anschauen. Logs davor habe ich auch, wenn ihr die braucht.
Hi Christian,
wenn ich das eben richtig gesehen habe startet das angehängte Log ja früher, sollte reichen.
Gruß,
Andreas.
Nachdem ich Andreas CAN-Hinweis verfolgte und bei den Problemfällen diese bisher häufig auftauchten, habe ich jetzt ein merkwürdiges Beispiel ohne CAN. Verarbeitung des WakeUp-Sendstacks wird einfach unterbrochen. Auffälligkeiten in der Kommunikation erkenne ich nicht, die dazu führen könnten. Warum stoppt die Abarbeitung des WakeUp-Sendstack nach "2016.03.02 19:37:42.877 4: ZWDongle_0 transmit OK for 2c"? FHEM-Server zeigt auch keine Aussetzer/Freezes o.ä. Hardwareprobleme kann ich zwar nicht ausschließen, aber mittlerweile habe ich daran meine Zweifel.
Log
2016.03.02 19:36:06.897 2: ZWave get ZWave_WALL_CONTROLLER_44 associationGroups
2016.03.02 19:36:10.684 2: ZWave get ZWave_WALL_CONTROLLER_44 associationGroupName 1
2016.03.02 19:36:17.271 2: ZWave get ZWave_WALL_CONTROLLER_44 associationGroups
2016.03.02 19:36:21.414 2: ZWave get ZWave_WALL_CONTROLLER_44 basicStatus
2016.03.02 19:36:26.610 2: ZWave get ZWave_WALL_CONTROLLER_44 battery
2016.03.02 19:36:31.405 2: ZWave get ZWave_WALL_CONTROLLER_44 configAutoReportBatteryTime
2016.03.02 19:36:31.426 2: ZWave get ZWave_WALL_CONTROLLER_44 configBasicSetOffLevel
2016.03.02 19:36:31.443 2: ZWave get ZWave_WALL_CONTROLLER_44 configBasicSetOnLevel
2016.03.02 19:36:31.458 2: ZWave get ZWave_WALL_CONTROLLER_44 configCustomerFunction
2016.03.02 19:36:31.473 2: ZWave get ZWave_WALL_CONTROLLER_44 configSceneHoldingReport
2016.03.02 19:36:47.033 2: ZWave get ZWave_WALL_CONTROLLER_44 version
2016.03.02 19:36:52.833 2: ZWave get ZWave_WALL_CONTROLLER_44 wakeupInterval
2016.03.02 19:36:56.953 2: ZWave get ZWave_WALL_CONTROLLER_44 wakeupIntervalCapabilities
2016.03.02 19:37:03.127 2: ZWave get ZWave_WALL_CONTROLLER_44 zwavePlusInfo
2016.03.02 19:37:08.262 2: ZWave get ZWave_WALL_CONTROLLER_44 versionClass ZWAVEPLUS_INFO
2016.03.02 19:37:41.254 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004002c028407
2016.03.02 19:37:41.260 5: SW: 06
2016.03.02 19:37:41.271 5: ZWDongle_0 dispatch 0004002c028407
2016.03.02 19:37:41.283 4: CMD:APPLICATION_COMMAND_HANDLER ID:2c ARG:028407
2016.03.02 19:37:41.295 5: ZWDongle_Write 00132c028505252c (e345c452)
2016.03.02 19:37:41.298 5: SW: 010900132c028505252c42
2016.03.02 19:37:41.658 5: ACK received, WaitForAck=>2 for 010900132c028505252c42
2016.03.02 19:37:41.661 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.02 19:37:41.663 5: SW: 06
2016.03.02 19:37:41.668 5: ZWDongle_0 dispatch 011301
2016.03.02 19:37:41.686 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00132c00
2016.03.02 19:37:41.688 5: SW: 06
2016.03.02 19:37:41.693 5: device ack reveived, removing 010900132c028505252c42 from dongle sendstack
2016.03.02 19:37:41.697 5: ZWDongle_0 dispatch 00132c00
2016.03.02 19:37:41.702 4: CMD:ZW_SEND_DATA ID:00 ARG:
2016.03.02 19:37:41.704 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:37:41.721 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004002c03850602
2016.03.02 19:37:41.723 5: SW: 06
2016.03.02 19:37:41.729 5: ZWDongle_0 dispatch 0004002c03850602
2016.03.02 19:37:41.733 4: CMD:APPLICATION_COMMAND_HANDLER ID:2c ARG:03850602
2016.03.02 19:37:41.753 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
2016.03.02 19:37:41.763 5: ZWDongle_Write 00132c03590101252c (e345c452)
2016.03.02 19:37:41.767 5: SW: 010a00132c03590101252c99
2016.03.02 19:37:42.051 5: ACK received, WaitForAck=>2 for 010a00132c03590101252c99
2016.03.02 19:37:42.054 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.02 19:37:42.056 5: SW: 06
2016.03.02 19:37:42.060 5: ZWDongle_0 dispatch 011301
2016.03.02 19:37:42.074 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00132c00
2016.03.02 19:37:42.076 5: SW: 06
2016.03.02 19:37:42.080 5: device ack reveived, removing 010a00132c03590101252c99 from dongle sendstack
2016.03.02 19:37:42.083 5: ZWDongle_0 dispatch 00132c00
2016.03.02 19:37:42.087 4: CMD:ZW_SEND_DATA ID:00 ARG:
2016.03.02 19:37:42.089 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:37:42.105 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004002c0c590201084c6966654c696e65
2016.03.02 19:37:42.106 5: SW: 06
2016.03.02 19:37:42.111 5: ZWDongle_0 dispatch 0004002c0c590201084c6966654c696e65
2016.03.02 19:37:42.115 4: CMD:APPLICATION_COMMAND_HANDLER ID:2c ARG:0c590201084c6966654c696e65
2016.03.02 19:37:42.125 5: ZWDongle_Write 00132c028505252c (e345c452)
2016.03.02 19:37:42.130 5: SW: 010900132c028505252c42
2016.03.02 19:37:42.446 5: ACK received, WaitForAck=>2 for 010900132c028505252c42
2016.03.02 19:37:42.449 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.02 19:37:42.451 5: SW: 06
2016.03.02 19:37:42.457 5: ZWDongle_0 dispatch 011301
2016.03.02 19:37:42.476 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00132c00
2016.03.02 19:37:42.478 5: SW: 06
2016.03.02 19:37:42.483 5: device ack reveived, removing 010900132c028505252c42 from dongle sendstack
2016.03.02 19:37:42.486 5: ZWDongle_0 dispatch 00132c00
2016.03.02 19:37:42.491 4: CMD:ZW_SEND_DATA ID:00 ARG:
2016.03.02 19:37:42.493 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:37:42.510 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004002c03850602
2016.03.02 19:37:42.513 5: SW: 06
2016.03.02 19:37:42.519 5: ZWDongle_0 dispatch 0004002c03850602
2016.03.02 19:37:42.523 4: CMD:APPLICATION_COMMAND_HANDLER ID:2c ARG:03850602
2016.03.02 19:37:42.542 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
2016.03.02 19:37:42.550 5: ZWDongle_Write 00132c022002252c (e345c452)
2016.03.02 19:37:42.556 5: SW: 010900132c022002252ce0
2016.03.02 19:37:42.835 5: ACK received, WaitForAck=>2 for 010900132c022002252ce0
2016.03.02 19:37:42.837 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.02 19:37:42.840 5: SW: 06
2016.03.02 19:37:42.846 5: ZWDongle_0 dispatch 011301
2016.03.02 19:37:42.861 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00132c00
2016.03.02 19:37:42.863 5: SW: 06
2016.03.02 19:37:42.867 5: device ack reveived, removing 010900132c022002252ce0 from dongle sendstack
2016.03.02 19:37:42.871 5: ZWDongle_0 dispatch 00132c00
2016.03.02 19:37:42.874 4: CMD:ZW_SEND_DATA ID:00 ARG:
2016.03.02 19:37:42.877 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:48:09.484 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001b06310504220000
list mit dem noch offenen WakeUp-Sendstack:
Internals:
DEF e345c452 44
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 94
NAME ZWave_WALL_CONTROLLER_44
NR 299
STATE TRANSMIT_NO_ACK
TYPE ZWave
ZWDongle_0_MSGCNT 94
ZWDongle_0_RAWMSG 0004002c03850602
ZWDongle_0_TIME 2016-03-02 19:37:42
homeId e345c452
isWakeUp 1
lastMsgSent 1456943862.56077
nodeIdHex 2c
Readings:
2016-03-02 19:37:42 assocGroupName_01 LifeLine
2016-03-02 19:19:04 assocGroup_1 Max 8 Nodes ZWDongle_0
2016-03-02 19:19:05 assocGroup_2 Max 8 Nodes
2016-03-02 19:37:42 assocGroups 2
2016-03-02 19:19:02 battery 100 %
2016-02-27 14:23:19 cSceneDimEnd 1
2016-03-02 07:13:03 cSceneSet 1
2016-03-02 19:18:59 configAutoReportBatteryTime 12
2016-03-02 19:19:00 configBasicSetOffLevel 0
2016-03-02 19:19:00 configBasicSetOnLevel 99
2016-03-02 19:19:01 configCustomerFunction 0
2016-03-02 19:19:01 configSceneHoldingReport Disabled
2016-03-02 19:15:09 model Philio Technology Corporation PSR04 Smart Color Button
2016-03-02 19:15:09 modelConfig philio/psr04.xml
2016-03-02 19:15:09 modelId 013c-0009-0022
2016-03-02 19:19:35 state TRANSMIT_NO_ACK
2016-03-02 19:37:42 transmit OK
2016-02-27 20:46:29 version Lib 3 Prot 4.5 App 1.5 HW 1 FWCounter 1 FW 1.4
2016-03-02 19:19:06 versionClass_20 00
2016-03-02 19:10:13 versionClass_ef 01
2016-03-02 19:37:41 wakeup notification
2016-03-02 19:19:03 wakeupIntervalCapabilitiesReport min 1800 max 432000 default 86400 step 1800
2016-03-02 19:19:03 wakeupReport interval 86400 target 1
2016-03-02 19:19:03 zwavePlusInfo version:01 role:PortableSlave node:Z-Wave+Node installerIcon:1600 userIcon:1600
SendStack:
sentackget:132c022002252c
get:132c028002252c
get:132c0370050a252c
get:132c03700501252c
get:132c03700502252c
get:132c03700519252c
get:132c0370051a252c
get:132c028611252c
get:132c028405252c
get:132c028409252c
get:132c025e01252c
get:132c0386135e252c
get:132c03850201252c
get:132c03850201252c
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BATTERY ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD CENTRAL_SCENE MARK BASIC
room ZWave
vclasses
Hallo Christian,
in der Tat merkwürdig...
a.) woher kommen die "ZWave get ZWave_WALL_CONTROLLER_44 association 1"? Die sind am Anfang nicht in der Auflistung der Befehle die auf dem Stack gelegt wurden. Sind die noch davor, oder sind das sogar noch Überreste die schon auf dem Stack lagen?
b.) Der Befehl kommt zwei Mal:
2016.03.02 19:37:41.753 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
2016.03.02 19:37:42.542 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
nach dem Zweiten bleibt er dann auch "hängen"...
c.) Im Stack "hängt" noch ein
SendStack:
sentackget:132c022002252c
, obwohl ein "2016.03.02 19:37:42.867 5: device ack reveived, removing 010900132c022002252ce0 from dongle sendstack" im Log erscheint.
d.) auf den letzten Befehl kommt keine Antwort (oder FHEM erkennt keine...)
2016.03.02 19:37:42.877 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:48:09.484 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001b06310504220000
EDIT: speichern statt Vorschau geklickt...
Ohne das jetzt noch mal mit dem aktuellen Stand des Codes nachzuvollziehen ist das MEGA-merkwürdig.
Ich versuch mal ein paar ConfigRequestAll auf den Multisensor, mal schauen was da passiert.
Gruß,
Andreas.
Hi Christian,
kannst Du mal ein paar Zeilen in 10_ZWave.pm auskommentieren und mal ein paar Tests damit machen?
} elsif($cmd eq "ZW_APPLICATION_UPDATE" && $arg =~ m/....(..)..(.*)$/) {
my ($type6,$classes) = ($1, $2);
my $ret = ZWave_SetClasses($homeId, $id, $type6, $classes);
my $hash = $modules{ZWave}{defptr}{"$homeId $id"};
if($hash) {
#~ if(ZWave_isWakeUp($hash)) {
#~ ZWave_wakeupTimer($hash, 1);
#~ ZWave_processSendStack($hash, "next");
#~ }
if(!$ret) {
readingsSingleUpdate($hash, "CMD", $cmd, 1); # forum:20884
return $hash->{NAME};
}
}
return $ret;
Das ist die Stelle an der bei dem ApplikationUpdate so getan wird als wäre es eine WakeUp-Notification. Dadurch beginnt FHEM direkt mit Senden, während der Sensor noch fleißig seine Report senden will. Das führte bei mir gerade zu ein paar CAN-Messages und das ganze ist genauso wie bei Dir stehengeblieben.
Das passt jetzt erst mal nur auf das erste von Dir geschilderte Fehlerbild, der Fall ohne CAN bleibt erst mal weiter eine Denksportaufgabe...
Gruß,
Andreas.
P.S.: @Rudi, Ich weiss das dies für einige Nodes wie z.B. diese KEYFOB Dinger, dennoch finde ich das dies nicht gemäß der Spezifikation ist. Falls das hier helfen sollte das NICHT zu machen, sollte man es vielleicht per Default ausschalten und per Attribut wählbar machen.
Zitata.) woher kommen die "ZWave get ZWave_WALL_CONTROLLER_44 association 1"? Die sind am Anfang nicht in der Auflistung der Befehle die auf dem Stack gelegt wurden. Sind die noch davor, oder sind das sogar noch Überreste die schon auf dem Stack lagen?
Die kommen mMn aus "get <device> assocationAll" und stehen als "get ZWave_WALL_CONTROLLER_44 associationGroups" auf dem Sendstack . Der Sendstack war vorher leer.
Zitatb.) Der Befehl kommt zwei Mal:
2016.03.02 19:37:41.753 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
2016.03.02 19:37:42.542 2: ZWave get ZWave_WALL_CONTROLLER_44 association 1
nach dem Zweiten bleibt er dann auch "hängen"...
Laut Sendstack habe ich die 2x abgerufen. Ob dadurch Probleme mit dem Hook entstehen, kann ich nicht nachvollziehen.
Zitat
c.) Im Stack "hängt" noch ein
SendStack:
sentackget:132c022002252c
, obwohl ein "2016.03.02 19:37:42.867 5: device ack reveived, removing 010900132c022002252ce0 from dongle sendstack" im Log erscheint.
Genau darum habe ich Zweifel, dass es an meiner Hardware liegt.
Zitatd.) auf den letzten Befehl kommt keine Antwort (oder FHEM erkennt keine...)
2016.03.02 19:37:42.877 4: ZWDongle_0 transmit OK for 2c
2016.03.02 19:48:09.484 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004001b06310504220000
Das verstehe ich nicht. Mit "ZWDongle_0 transmit OK for 2c" ist doch eine Kommunikation abgeschlossen. Die nächste Log-Zeile habe ich nur aufgenommen, um die Unterbrechung der Sendstack-Abarbeitung aufzuzeigen.
Weitere Tests heute abend...
Hi,
ich denke auch das der erste Ansatz zur Analyse bei c.) liegt...
Für d.) wäre es mal interessant gleichzeitig mit dem ZWCul zu sniffen ob da wirklich nichts gesendet wird oder ob FHEM einfach nichts entgegennimmt. Könntest Du mal den ZWCul mitlaufen lassen?
Das mit dem "associationAll" hätte ich mir natürlich selber denken können. ,-)
Gruß,
Andreas.
Habe jetzt mal mein System gewechselt: Notebook, Windows, andere ZWave-Stick, FHEM nur mit einem Zwave-Sensor. Ergebnis entspricht dem Threaderöffnungsbeitrag. Abarbeitung des Sendstack wird abgebrochen. Letzter Eintrag im Log ein get-Befehl und Schreiben auf ZWDongle fehlt.
list nach dem Abbruch:
Internals:
CFGFN
DEF c16c11c4 4
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 67
NAME ZWave_SENSOR_NOTIFICATION_4
NR 83
STATE wakeupInterval 86400 01
TYPE ZWave
ZWDongle_0_MSGCNT 67
ZWDongle_0_RAWMSG 000400041e8f010403800364097105000000ff07080005310503010706310501220113
ZWDongle_0_TIME 2016-03-03 20:08:58
homeId c16c11c4
isWakeUp 1
lastMsgSent 1457031854.5038
nodeIdHex 04
Readings:
2016-03-03 20:08:58 alarm HomeSecurity: Motion Detection, Unknown Location, arg 00
2016-03-03 20:04:10 assocGroup_1 Max 8 Nodes ZWDongle_0
2016-03-03 20:04:15 assocGroup_2 Max 8 Nodes
2016-03-03 20:03:42 assocGroups 2
2016-03-03 20:08:58 battery 100 %
2016-03-03 20:03:42 configAutoReportBatteryTime 12
2016-03-03 20:03:42 configAutoReportDoorWindowStateTime 12
2016-03-03 20:03:43 configAutoReportIlluminationTime 12
2016-03-03 20:03:43 configAutoReportTemperatureTime 12
2016-03-03 20:03:46 configAutoReportTickInterval 30
2016-03-03 20:03:49 configBasicSetLevel 255
2016-03-03 20:03:52 configCustomerFunction 4
2016-03-03 20:03:55 configIlluminationDifferentialReport 0
2016-03-03 20:02:21 configLightThreshold 99
2016-03-03 20:02:21 configMultiSensorFunctionSwitch 4
2016-03-03 20:03:58 configOperationMode 8
2016-03-03 20:04:01 configPIRReDetectIntervalTime 3
2016-03-03 20:02:22 configPIRSensitivity 80
2016-03-03 20:02:22 configTemperatureDifferentialReport 1
2016-03-03 20:04:01 configTurnOffLightTime 4
2016-03-03 20:08:58 luminance 7 %
2016-03-03 19:58:13 model Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor
2016-03-03 19:58:13 modelConfig philio/pst02.xml
2016-03-03 19:58:13 modelId 013c-0002-000c
2016-03-03 19:58:11 state wakeupInterval 86400 01
2016-03-03 20:08:58 temperature 27.5 C
2016-03-03 20:04:16 transmit OK
2016-03-03 20:03:42 wakeup notification
2016-03-03 20:04:07 wakeupIntervalCapabilitiesReport min 1800 max 432000 default 86400 step 1800
2016-03-03 20:04:09 wakeupReport interval 1800 target 1
2016-03-03 20:04:14 zwavePlusInfo version:01 role:SleepingReportingSlave node:Z-Wave+Node installerIcon:0c07 userIcon:0c07
SendStack:
get:1304038613852504
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
room ZWave
vclasses ZWAVEPLUS_INFO:2 BATTERY:1 ALARM:4
Log hängt an.
Hardware ist damit mMn nahezu ausgeschlossen. Nur der Sensor ist im Vergleich zum Eröffnungsbeitrag gleich. Der dürfte doch nicht zum Stoppen der Sendstack-Abarbeitung führen. Ein anderes ZWave-Gerät war nicht angeschlossen/inkludiert, so dass die Telegramme ausschließlich vom Controller und einem Sensor kommen.
Ich verstehe es nicht.
Hi Christian,
ich habe gerade mal angefangen das zu untersuchen. Ich kann das mit dem Multisensor auch einfach nachstellen, ausgelöst wird das bei mir aber durch das Senden direkt nach dem ApplicationUpdate. Dadurch erhalte ich recht viele CAN und irgendwann bleibt es genau so stehen wie bei Dir.
Wenn ich das aus dem Code rausnehme und erst nach der WakeUp-Notification sende ist alles i.O.
Ich vermute das der Weg bis zum Hängenbleiben bei uns unterschiedlich ist, das eigentliche Hängenbleiben wird aber aber vermutlich den gleichen Grund haben.
Ich pflaster jetzt gerade mal die 10_ZWave.pm mit Logmeldungen voll, dann mach ich (aber wohl erst morgen) noch ein paar weitere Tests und schau mal gleichzeitig mit dem ZWCul ob da wirklich nichts mehr passiert...
Gruß,
Andreas.
Hallo Andreas,
werde auch noch mal mit Deiner vorgeschlagenen Auskommentierung in 10_ZWave.pm probieren. Wird aber heute auch nichts mehr.
Ich bin mir nur nicht mehr im Klaren, wofür APPLICATION_UPDATE notwendig ist/war und wann es kommt.
Gruß, Christian
Hi,
soweit ich das verstanden habe ist das eine Art NodeInfo-Message die "unsolicited" versendet werden kann.
Soweit ich das abgespeichert habe senden die KFOB-Fernbedienungen keinen vernünftigen WakeUp und das war eine "Notlösung" um mit den Dinger zu kommunizieren.
Ich hatte das damals schon mal bemerkt und wollte das eigentlich raushaben, aber Ihr beide wolltet das drinnen lassen weil Ihr es braucht.
Mit der Auskommentierung sollten die CAN-Nachrichten verschwinden, aber dennoch sollte der SendStack nicht so stehenbleiben. Und Du hast ja auch ein Log in dem das ohne CAN-Msg passiert.
Mal sehen ob ich aus den ganzen Debug-Nachrichten jetzt irgendwas erkennen kann. Da da auch Timer mit im Spiel sind könnte das "interessant" werden ,-)
Gruß,
Andreas.
Zitataber Ihr beide wolltet das drinnen lassen weil Ihr es braucht.
Meine Gedächtnisstütze, die Forums-Suche, findet dazu leider nichts und ich kann mich daran selbst nicht erinnern :( .
Bei ozw finde ich zu APPLICATION_UPDATE auf die Schnelle nur Infos, dass damit das ZWave-Gerät dem Controller eine Änderung/Aktualisierung mitteilt. Was soll der Controller/Software rausfinden. Vorläufer von Statusrückmeldungen? Zusammenhang zu Wakeup erkenne ich nicht.
Die InternalTimer hatte ich auch schon im Verdacht und meine Rudi hatte damals etwas zu einer eventuell notwendigen Anpassung/Änderung geschrieben....
Kann eine Ausprägung dieses Problems sein, dass der Sendstack mehrere Aufwach-Vorgänge benötigt bis er abgearbeitet ist? So ist es bei mir - bisher dachte ich, dass muss so sein, weil die WakeUp-Geräte einfach nicht lange genug wach bleiben.
Hi,
hier mal ein erster "Befund":
Der "normaler" Ablauf ist so wie im ersten Block (bis zur Leerzeile) beim Versenden von 70052a, der Befehl wird aus dem SendStack versendet, und als "sent" markiert. Sobald das ACK da ist wird es als "sentAckGet" markiert. Nach dem Eintreffen der Anwort wird der Eintrag und der Timer entfernt.
Dann wird 700527 gesendet, aber dabei kommt bei mir die WakeUp-Notification "dazwischen" und der Sendstack macht anscheinend weiter als wäre das die Antwort auf das abgeschickte GET, (was es natürlich nicht ist). Dann wird im Sendstack der nächste GET 70052e freigegeben, ist aber noch nicht vom Dongle verschickt., dann kommt die CAN-Msg vom Dongle und die 700527 wird noch mal versendet, obwohl die nach meinem Verständnis zu dem Zeitpunkt bereits aus dem Stack entfernt sein sollte.
Ich werde mir dann als nächsten den Stack mal etwas genauer ansehen um festzustellen ob der "070527" wirklich schon aus dem Stack raus war oder doch noch oben drauf lag...
Mann kann auf jeden Fall schon mal erkennen das eine "unsolicited" Msg in einer solchen Abfragefolge das System irgendwie aus dem Tritt und zum Stolpern bringt. Ist auf jeden Fall ein interessantes Problem ::)
2016.03.03 21:03:10.719 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052a25ab
2016.03.03 21:03:10.720 5: ZWDongle_Write 0013ab0370052a25ab (e015dfed)
2016.03.03 21:03:10.720 5: SW: 010a0013ab0370052a25ab9f
2016.03.03 21:03:10.721 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.03 21:03:10.721 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
2016.03.03 21:03:10.723 5: ACK received, WaitForAck=>2 for 010a0013ab0370052a25ab9f
2016.03.03 21:03:10.738 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 21:03:10.738 5: SW: 06
2016.03.03 21:03:10.740 5: ZWDongle_0 dispatch 011301
2016.03.03 21:03:10.774 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.03 21:03:10.775 5: SW: 06
2016.03.03 21:03:10.776 5: device ack reveived, removing 010a0013ab0370052a25ab9f from dongle sendstack
2016.03.03 21:03:10.776 5: ZWDongle_0 dispatch 0013ab000002
2016.03.03 21:03:10.776 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.03 21:03:10.776 4: ZWDongle_0 transmit OK for ab
2016.03.03 21:03:10.776 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called
2016.03.03 21:03:10.776 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.03 21:03:10.776 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.03 21:03:10.776 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
2016.03.03 21:03:10.808 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab0570062a010a
2016.03.03 21:03:10.808 5: SW: 06
2016.03.03 21:03:10.809 5: ZWDongle_0 dispatch 000400ab0570062a010a
2016.03.03 21:03:10.809 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:0570062a010a
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.03 21:03:10.809 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052725ab
2016.03.03 21:03:10.809 5: ZWDongle_Write 0013ab0370052725ab (e015dfed)
2016.03.03 21:03:10.809 5: SW: 010a0013ab0370052725ab92
2016.03.03 21:03:10.810 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.03 21:03:10.810 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
2016.03.03 21:03:10.834 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab028407
2016.03.03 21:03:10.834 5: SW: 06
2016.03.03 21:03:10.836 5: ZWDongle_0 dispatch 000400ab028407
2016.03.03 21:03:10.836 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052e25ab
2016.03.03 21:03:10.836 5: ZWDongle_Write 0013ab0370052e25ab (e015dfed)
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.03 21:03:10.836 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
2016.03.03 21:03:10.838 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.03 21:03:11.839 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013ab0370052725ab92
2016.03.03 21:03:11.839 5: SW: 010a0013ab0370052725ab92
2016.03.03 21:03:11.842 5: ACK received, WaitForAck=>2 for 010a0013ab0370052725ab92
2016.03.03 21:03:11.855 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 21:03:11.855 5: SW: 06
2016.03.03 21:03:11.856 5: ZWDongle_0 dispatch 011301
2016.03.03 21:03:11.879 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.03 21:03:11.879 5: SW: 06
2016.03.03 21:03:11.880 5: device ack reveived, removing 010a0013ab0370052725ab92 from dongle sendstack
2016.03.03 21:03:11.880 5: ZWDongle_0 dispatch 0013ab000002
2016.03.03 21:03:11.880 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.03 21:03:11.880 4: ZWDongle_0 transmit OK for ab
2016.03.03 21:03:11.880 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called
2016.03.03 21:03:11.880 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.03 21:03:11.880 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.03 21:03:11.880 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
2016.03.03 21:03:11.880 5: SW: 010a0013ab0370052e25ab9b
2016.03.03 21:03:11.911 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab057006270114
2016.03.03 21:03:11.911 5: SW: 06
Das Log geht dann noch zwei mal mit CAN-Msg so weiter und dann bleibt das auch stehen:
2016.03.03 21:03:13.967 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013ab037005cb25ab7e
2016.03.03 21:03:13.967 5: SW: 010a0013ab037005cb25ab7e
2016.03.03 21:03:13.971 5: ACK received, WaitForAck=>2 for 010a0013ab037005cb25ab7e
2016.03.03 21:03:13.988 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 21:03:13.988 5: SW: 06
2016.03.03 21:03:13.989 5: ZWDongle_0 dispatch 011301
2016.03.03 21:03:14.006 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.03 21:03:14.006 5: SW: 06
2016.03.03 21:03:14.007 5: device ack reveived, removing 010a0013ab037005cb25ab7e from dongle sendstack
2016.03.03 21:03:14.007 5: ZWDongle_0 dispatch 0013ab000002
2016.03.03 21:03:14.007 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.03 21:03:14.007 4: ZWDongle_0 transmit OK for ab
2016.03.03 21:03:14.007 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called
2016.03.03 21:03:14.007 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.03 21:03:14.007 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.03 21:03:14.007 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
2016.03.03 21:03:14.027 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab067006cb020000
2016.03.03 21:03:14.027 5: SW: 06
2016.03.03 21:03:14.028 5: ZWDongle_0 dispatch 000400ab067006cb020000
2016.03.03 21:03:14.028 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:067006cb020000
Gruß,
Andreas.
Hi,
Zitat von: 9zehn75 am 03 März 2016, 21:36:28
Kann eine Ausprägung dieses Problems sein, dass der Sendstack mehrere Aufwach-Vorgänge benötigt bis er abgearbeitet ist? So ist es bei mir - bisher dachte ich, dass muss so sein, weil die WakeUp-Geräte einfach nicht lange genug wach bleiben.
das ist definitiv richtig beobachtet. Wenn der "hängenbleibt" liegen noch die restlichen Befehle auf dem Stack. Beim nächsten WakeUp macht er irgendwie weiter. Wie FHEM dabei mit dem eigentlich bereits versendeten Befehl (ohne Antwort) oben auf dem Stack umgeht habe ich mir noch nicht angeschaut.
Normalerweise arbeiten die WakeUp-Geräte den SendStack komplett ab bevor FHEM sie dann wieder schlafen schickt.
Die Theorie ist: Gerät wacht auf und schickt eine WakeUp-Notification zum Dongle. Der schaut nach ob Befehle für das Geräte vorhanden sind, wenn ja werden die alle verschickt. Wenn dann keine Befehle mehr da sind, oder es gar keine gebeben hat, dann schickt das Dongle eine WNMI-Nachricht (WakeUp No More Information) welche dem Gerät sagt das es wieder schlafen gehen kann/soll. Die Geräte sollen laut Spezifikation auch ohne diese Nachricht nach einer bestimmten Zeit wieder einschlafen um Batterie zu sparen, dummerweise gibt es keine festgelegte Zeit, und das macht dann anscheinend jeder wie er will.
Hierbei ist der AEOTEC MultiSensor anscheinend von Narkolepsie befallen, der schläft ultraschnell (~0.2 sek) wieder ein, während andere Geräte da in der Größenordnung von 2 Sekunden oder noch mehr liegen.
Gruß,
Andreas.
Hi Christian,
Zitat von: krikan am 03 März 2016, 20:31:45
Log hängt an.
auch in Deinem Log finden sich SEHR merkwürdige Sachen:
2016.03.03 20:03:43.180 5: ZWDongle_Write 0013040370050d2504 (c16c11c4)
2016.03.03 20:03:43.180 5: SW: 010a0013040370050d2504b8
2016.03.03 20:03:43.186 5: ACK received, WaitForAck=>2 for 010a0013040370050d2504b8
2016.03.03 20:03:43.286 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:43.287 5: SW: 06
2016.03.03 20:03:43.289 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:43.296 2: ZWave get ZWave_SENSOR_NOTIFICATION_4 zwavePlusInfo
2016.03.03 20:03:43.297 4: ZWDongle_ReadAnswer arg:zwavePlusInfo regexp:^00040004..5e
2016.03.03 20:03:43.300 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000003
2016.03.03 20:03:43.300 5: SW: 06
2016.03.03 20:03:43.302 5: device ack reveived, removing 010a0013040370050d2504b8 from dongle sendstack
2016.03.03 20:03:43.303 5: ZWDongle_0 dispatch 001304000003
2016.03.03 20:03:43.303 4: CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.03.03 20:03:43.303 4: ZWDongle_0 transmit OK for 04
2016.03.03 20:03:43.304 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040570060d010c
2016.03.03 20:03:43.304 5: SW: 06
2016.03.03 20:03:43.306 5: ZWDongle_0 dispatch 000400040570060d010c
2016.03.03 20:03:43.306 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0570060d010c
Hier gibt es mitten in der Ausführung der ganzen config Befehle eine zwavePlusInfo Abfrage, die sogar eine ReadAnswerFn aufruft, allerdings erkenne ich nicht wo/wann die überhaupt abgesetzt wird...
2016.03.03 20:03:43.307 5: ZWDongle_Write 001304037005142504 (c16c11c4)
2016.03.03 20:03:43.307 5: SW: 010a001304037005142504a1
2016.03.03 20:03:43.313 5: ACK received, WaitForAck=>2 for 010a001304037005142504a1
2016.03.03 20:03:46.315 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:46.315 5: SW: 06
2016.03.03 20:03:46.317 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:46.317 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:46.317 5: SW: 06
2016.03.03 20:03:46.319 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:46.319 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:46.319 5: SW: 06
2016.03.03 20:03:46.321 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:46.321 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:46.321 5: SW: 06
2016.03.03 20:03:46.323 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:46.323 4: no response from device, removing 010a001304037005142504a1 from dongle sendstack
2016.03.03 20:03:46.324 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000002
2016.03.03 20:03:46.324 5: SW: 06
2016.03.03 20:03:46.327 5: ZWDongle_0 dispatch 001304000002
2016.03.03 20:03:46.327 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.03 20:03:46.327 4: ZWDongle_0 transmit OK for 04
2016.03.03 20:03:46.328 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000405700614011e
2016.03.03 20:03:46.328 5: SW: 06
2016.03.03 20:03:46.330 5: ZWDongle_0 dispatch 0004000405700614011e
2016.03.03 20:03:46.330 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:05700614011eHier geht es dann "richtig" durcheinander...
auf das SW: gibt es haufenweise ACK, dennoch kommt dann ein "no response from device, removing...." (Der Befehl dazu war ein 700514)
Danach kommt dann das ACK von der Node und auch dann "oh Wunder" kommt die Antwort auf die 700514 -> 700614
Das gleich wiederholt sich dann mit einer 700502 und der Antwort 700602
2016.03.03 20:03:46.331 5: ZWDongle_Write 001304037005022504 (c16c11c4)
2016.03.03 20:03:46.331 5: SW: 010a001304037005022504b7
2016.03.03 20:03:46.336 5: ACK received, WaitForAck=>2 for 010a001304037005022504b7
2016.03.03 20:03:49.338 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:49.338 5: SW: 06
2016.03.03 20:03:49.339 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:49.340 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:49.340 5: SW: 06
2016.03.03 20:03:49.343 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:49.343 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:49.344 5: SW: 06
2016.03.03 20:03:49.346 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:49.346 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.03 20:03:49.346 5: SW: 06
2016.03.03 20:03:49.349 5: ZWDongle_0 dispatch 011301
2016.03.03 20:03:49.349 4: no response from device, removing 010a001304037005022504b7 from dongle sendstack
2016.03.03 20:03:49.350 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001304000002
2016.03.03 20:03:49.350 5: SW: 06
2016.03.03 20:03:49.352 5: ZWDongle_0 dispatch 001304000002
2016.03.03 20:03:49.352 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.03 20:03:49.353 4: ZWDongle_0 transmit OK for 04
2016.03.03 20:03:49.353 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040570060201ff
2016.03.03 20:03:49.353 5: SW: 06
2016.03.03 20:03:49.355 5: ZWDongle_0 dispatch 000400040570060201ff
2016.03.03 20:03:49.355 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0570060201ffDanach wird es dann noch "bunter", obwohl keine Antwort kommt wird der nächste Befehl verabreitet und damit ist das ganze dann nicht mehr synchron, später tauchen dann auch wieder "no response" und CAN auf.
Ich verstehe es auch noch nicht, mich würde aber interessieren woher die mehrfachen ACK kommen...
Gruß,
Andreas.
Zitat von: A.Harrenberg am 03 März 2016, 22:11:29
Hier gibt es mitten in der Ausführung der ganzen config Befehle eine zwavePlusInfo Abfrage, die sogar eine ReadAnswerFn aufruft, allerdings erkenne ich nicht wo/wann die überhaupt abgesetzt wird...
Mein Verdacht: Ich habe "get <device> zwavePlusInfo" als letzten Befehl im Menü ausgewählt und abgesetzt. WakeupNotification war schon gekommen und Befehl wird dazwischen geschoben. Bin zwar nicht ganz sicher, könnte aber vom zeitlichen Verlauf passen.
Irgendwie kommen mir wieder die CallbackIds in den Sinn...
Hi Christian,
CallBackIDs könnte man noch mal probieren abzusetzen und schauen was da von den Nodes zurückkommt. Ich hatte das damals mal ganz kurz gemacht und irgendwie abgespeichert das die dummerweise nicht immer mit zurückkommen...
Aber soetwas wie "expected Answer" wäre machbar, wenn man z.B. so einen Get-Befehl mit "700502" verschickt, weiss man ja das die Antwort eine "700602" sein muss...
Bevor wir das hier aber "weiterentwickeln" sollten wir erst einmal den Hintergrund der momentanen Probleme erkennen und fixen. Ich habe nur leider momentan nicht so viel Zeit wie ich gerne hätte und dann bin ich demnächst auch noch bis Ende April weg ;-)
Gruß,
Andreas.
Denke nicht, dass das Problem so brennend ist und eine sofortige Lösung braucht. Also keine Hetze. Rudi wird sicherlich irgendwann wieder mehr Zeit haben und seinen Input brauchen wir auch.
Hi,
Zitat von: krikan am 03 März 2016, 22:50:13
Denke nicht, dass das Problem so brennend ist und eine sofortige Lösung braucht. Also keine Hetze. Rudi wird sicherlich irgendwann wieder mehr Zeit haben und seinen Input brauchen wir auch.
Irgendwie finde ich schon das dies ein schwerwiegendes Problem ist und möglichst schnell behoben werden sollte.
Ich vermute ein grundsätzliches Problem das auch im Normalbetrieb auftreten kann, durch die Massenabfertigung mit WU-Stack aber verstärkt auftritt.
Ob sich das dann einfach/schnell beheben lässt wissen wir natürlich erst wenn wir die eigentliche Ursache gefunden haben. Ich suche so lange und intensiv es meine freie Zeit zulässt, wenn es nicht bis zu meinem Urlaub gelöst ist dann eben später.
Mal sehen was das WE bringt.
Gruß,
Andreas.
Gesendet von meinem LIFETAB_S785X mit Tapatalk
Hi,
ich kann zwar nichts zur Lösung beitragen, aber bei mir passiert das gerade auch. (JFYI)
Save config
Unsorted
ZWave
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
DEF d344759d 27
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 871
NAME Fib_Sensor
NR 24
STATE closed
TYPE ZWave
ZWAVE1_MSGCNT 871
ZWAVE1_RAWMSG 0004101b063105012200ca
ZWAVE1_TIME 2016-03-04 01:20:32
homeId d344759d
isWakeUp 1
lastMsgSent 1457041250.999
nodeIdHex 1b
Readings:
2016-03-03 22:40:50 CMD ZW_APPLICATION_UPDATE
2016-02-26 17:53:28 UNPARSED SENSOR_MULTILEVEL 063101070a000b
2016-03-04 00:13:30 alarm_type_00 level ff node 1b seconds 0
2016-02-21 23:34:22 assocGroup_1 Max 5 Nodes ZWAVE1
2016-02-21 23:34:22 assocGroup_2 Max 5 Nodes
2016-02-21 23:34:22 assocGroup_3 Max 1 Nodes ZWAVE1
2016-02-21 23:34:17 assocGroups 3
2016-03-04 00:13:34 basicSet 00
2016-03-03 22:33:29 battery 100 %
2016-02-27 15:25:40 configAmbientIlluminationLevelAbove83 1000
2016-02-27 15:25:40 configAmbientIlluminationLevelBelow82 100
2016-02-27 15:25:40 configBASICOFFCommandFrameValue 0
2016-02-27 15:25:40 configBASICONCommandFrameValue 255
2016-02-27 15:25:41 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-03-03 22:40:51 configIlluminationReportThreshold 25
2016-02-27 15:25:41 configIlluminationReportsInterval 0
2016-02-27 15:25:41 configIntervalOfTemperatureMeasuring 900
2016-03-03 22:34:45 configLEDBrightness 20
2016-03-03 22:33:55 configLEDIndicatingTamperAlarm LEDDoesNotIndicateTamperAlarm
2016-02-27 15:25:41 configLEDSignalingMode LongBlinkWhite
2016-02-27 15:25:41 configMaximumTemperatureResultingInRed87 28
2016-02-27 15:25:42 configMinimumTemperatureResultingIn86 18
2016-02-27 15:25:42 configMotionAlarmCancellationDelay 10
2016-02-27 15:25:42 configMotionSensorSBlindTime2 15
2016-02-27 15:25:42 configMotionSensorSSensitivity 10
2016-02-27 15:25:42 configNightDay 200
2016-02-27 15:25:42 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-02-27 15:25:42 configPIRSensorSPulseCounter 1
2016-02-27 15:25:43 configPIRSensorSWindowTime 2
2016-02-27 15:25:43 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-02-27 15:25:43 configTamperAlarmCancellationDelay 30
2016-02-27 15:25:43 configTamperOperatingModes Tamper
2016-02-27 15:25:43 configTamperSensitivity 15
2016-02-27 15:25:43 configTemperatureOffset 0
2016-02-27 15:25:43 configTemperatureReportThreshold 10
2016-02-27 15:25:43 configTemperatureReportsInterval 0
2016-03-03 23:15:49 luminance 2 Lux
2016-02-21 20:02:36 model FIBARO System FGMS001 Motion Sensor
2016-02-21 20:02:36 modelConfig fibaro/fgms.xml
2016-02-21 20:02:36 modelId 010f-0800-1001
2016-03-04 00:13:34 reportedState closed
2016-03-04 00:13:34 state closed
2016-03-04 01:20:32 temperature 20.2 C
2016-03-03 22:40:53 transmit OK
2016-03-03 05:44:52 wakeup notification
SendStack:
get:131b028002251b
get:131b028002251b
get:131b028002251b
get:131b028505251b
get:131b028505251b
set:131b05700451010c251b
get:131b03700551251b
set:131b05700451010c251b
set:131b05700451010c251b
set:131b05700451010b251b
set:131b05700451010c251b
get:131b03700551251b
set:131b05700451010a251b
get:131b03700551251b
get:131b03700551251b
Attributes:
IODev ZWAVE1
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM MARK SENSOR_BINARY SENSOR_MULTILEVEL SENSOR_ALARM BASIC
room ZWave
Habe gestern zwischen 23-00Uhr ein paar Einstellungen der config-Parameter ausprobiert (vor allem Blinkverhalten und Helligkeitsanpassung der LED).
Habe dann so 3-4 mal den Sensor manuell aufgeweckt um die Parameter zu setzen. Hat auch funktioniert. Aber nach ein paar mal, wurden plötzlich nichtsmehr gesetzt, und die Befehle landeten im sendstack.
Auch die Werte werden seitdem nicht mehr übermittelt.
ZitatAuch die Werte werden seitdem nicht mehr übermittelt.
Wenn jetzt gar keine Werte mehr kommen, tippe ich auf einen andere Ursache. Dongle hängt o.ä.; würde Dongle mal stromlos machen und/oder Server-Computer stromlos und neu starten.
verbose 5-Logs hast Du vermutlich nicht, oder?
Bei meinem/unserem Problem der Unterbrechung der Sendstack-Abarbeitung funktioniert der Meldungsempfang vom Sensor weiterhin und der Sendstack wird später bei der nächsten WakeupNotification mEn weiter abgearbeitet.
Zitat von: A.Harrenberg am 03 März 2016, 21:52:36
Hi,das ist definitiv richtig beobachtet. Wenn der "hängenbleibt" liegen noch die restlichen Befehle auf dem Stack. Beim nächsten WakeUp macht er irgendwie weiter. Wie FHEM dabei mit dem eigentlich bereits versendeten Befehl (ohne Antwort) oben auf dem Stack umgeht habe ich mir noch nicht angeschaut.
Normalerweise arbeiten die WakeUp-Geräte den SendStack komplett ab bevor FHEM sie dann wieder schlafen schickt.
Die Theorie ist: Gerät wacht auf und schickt eine WakeUp-Notification zum Dongle. Der schaut nach ob Befehle für das Geräte vorhanden sind, wenn ja werden die alle verschickt. Wenn dann keine Befehle mehr da sind, oder es gar keine gebeben hat, dann schickt das Dongle eine WNMI-Nachricht (WakeUp No More Information) welche dem Gerät sagt das es wieder schlafen gehen kann/soll. Die Geräte sollen laut Spezifikation auch ohne diese Nachricht nach einer bestimmten Zeit wieder einschlafen um Batterie zu sparen, dummerweise gibt es keine festgelegte Zeit, und das macht dann anscheinend jeder wie er will.
Das erklärt einiges. Bei meinen WU-Geräten dauert es zum Teil Tage (Aufwachen alle 12 Stunden) bis alle gewünschten Readings befüllt sind. Dachte schon, es liegt an mir...
Zitat von: A.Harrenberg am 03 März 2016, 22:11:29
Danach wird es dann noch "bunter", obwohl keine Antwort kommt wird der nächste Befehl verabreitet und damit ist das ganze dann nicht mehr synchron, später tauchen dann auch wieder "no response" und CAN auf.
Ich habe schon mehrfach beobachtet, dass im "STATE" von WU-Geräte Stati stehen, die dort eigentlich nicht hindürfen (z.B. die Rückmeldung auf "get wakeupInterval"). Das könnte dann auch daran liegen, oder?
ZitatDas erklärt einiges. Bei meinen WU-Geräten dauert es zum Teil Tage (Aufwachen alle 12 Stunden) bis alle gewünschten Readings befüllt sind. Dachte schon, es liegt an mir...
Bin ein wenig vorsichtig, das hier festgestellte Problem auf alle Problemfälle zu übertragen und damit zu generalisieren. Man müsste sich die Logs von Deinem Problem genau anschauen. Die Unterbrechnung der Abarbeitung des Sendstacks tritt nicht immer auf. Bei mir ist der weitaus häufigere Fall eine korrekte und komplette Abarbeitung des Sendstacks. Das Problem tritt im Wesentlichen auch nur bei sehr vollem Sendstack oder Störungen durch andere Geräte auf. Insbesondere wenn Du noch die Repeater einsetzt oder das Netz nach einer Entfernung nicht komplett neu aufgebaut wurde, zweifele ich sehr stark an einer Parallele.
ZitatIch habe schon mehrfach beobachtet, dass im "STATE" von WU-Geräte Stati stehen, die dort eigentlich nicht hindürfen (z.B. die Rückmeldung auf "get wakeupInterval"). Das könnte dann auch daran liegen, oder?
Behaupte: Nein
Andreas, wenn ich hier bei Problemanalyse irgendwie helfen kann, gib bitte Bescheid. Mir fehlen momentan die Ideen/Ansatzpunkte.
Gruß, Christian
Hi Christian,
ich acker gerade ein mit Debug-messages gespicktes Logfile ab um erst einmal zu verstehen was Rudi da mit den beiden ProcessSendStack Funktionen in der 00_ZWDongle.pm und 10_ZWave.pm eigentlich so anstellt ,-)
Wenn ich das dann mal durchhabe und evtl. die eine oder andere Debug-message noch ergänzt habe könnte es sein das ich ein weiteres Log aus einem anderen Szenario brauche.
Es scheint ja mehrere Möglichkeiten zu geben in dieses "Anhalten" reinlaufen zu können und wir sollten sicherstellen das es im Code die gleiche Ursache hat und wir hier nicht mit zwei verschiedenen Problemen kämpfen.
Ohne das bisher im Detail nachvollzogen zu haben fürchte ich das hier die "unsolicited" Nachrichten von der Node die in eine solche Abfrage reingeraten (also zwischen get und dem report) den Sendstack aushebelt und der dann neue Nachrichten zu früh freigibt wodurch dann jede Menge CAN auftreten. An welcher Stelle dann allerdings die Ausführung stoppt habe ich noch nicht begriffen, da ja da auch immer ein Timer mit gestartet wird der dann zumindest einen Fehler ausgeben sollte.
Da ich heute nicht mehr so viel Zeit habe werde ich mich wahrscheinlich frühestens morgen mal melden. Da wäre ich bei Bedarf dann auch ohne Dein Angebot auf Dich zugekommen ;-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 05 März 2016, 09:44:26
Da ich heute nicht mehr so viel Zeit habe werde ich mich wahrscheinlich frühestens morgen mal melden. Da wäre ich bei Bedarf dann auch ohne Dein Angebot auf Dich
Ok, also einfach melden. Hinweis: Morgen bin ich nur stark eingeschränkt erreichbar.
Zitat von: krikan am 04 März 2016, 10:38:48
Bin ein wenig vorsichtig, das hier festgestellte Problem auf alle Problemfälle zu übertragen und damit zu generalisieren. Man müsste sich die Logs von Deinem Problem genau anschauen. Die Unterbrechnung der Abarbeitung des Sendstacks tritt nicht immer auf. Bei mir ist der weitaus häufigere Fall eine korrekte und komplette Abarbeitung des Sendstacks. Das Problem tritt im Wesentlichen auch nur bei sehr vollem Sendstack oder Störungen durch andere Geräte auf. Insbesondere wenn Du noch die Repeater einsetzt oder das Netz nach einer Entfernung nicht komplett neu aufgebaut wurde, zweifele ich sehr stark an einer Parallele.
Behaupte: Nein
Das Netz mit meinen Repeatern gibt es nicht mehr. Ich habe alle Geräte entfernt, FHEM gelöscht, neu installiert, alle Geräte neu inkludiert (ohne Repeater) und alles neu eingerichtet. Seitdem habe ich nur noch die o.g. Probleme. Die auch nicht immer. Besonders voller Sendstack könnte passen. Habe aber im Moment keine Zeit, dem intensiver nachzugehen.
Diese Geschichte ist auf meinem Stack irgendwie nach unten gerutscht. Ihr seid ja ganz fleissig gewesen, ich habe aber trotzdem den Eindruck, dass es noch nicht erledigt ist. :)
Zum Log aus Beitrag #1:
- der Dongle meint, die gleiche Antwort auf "get version XX" oefters presentieren zu muessen. Ich vermute, dass der PST02 den Ack der Dongle nicht gehoert hat, und deswegen die Nachricht wiederholt hat.
- Theorie: da der Dongle gerade was empfaengt, will nichts zum Schicken entgegennehmen, deswegen ein CAN.
- Mit der wiederholten Nachricht kommt erstens der Sendstack aus dem Tritt, weil FHEM glaubt eine Antwort auf die naechste Frage (der wg. CAN abgeblockt wurde) bekommen zu haben. Deswegen wurden einige "get version" Anfragen nicht verschickt.
- warum Befehle auf dem Stack bleiben, kann ich nicht wirklich erklaeren, evtl. schlaeft der PST02 wg. dem CAN-Resend-Timout selbst ein.
- Um das Problem zu fixen muesste ich:
1. DeviceUnabhaengige CallbackIds einfuehren (ich hoer schon das "endlich" :) ), und die Antwort mit dem Letzten vergleichen zu koennen.
2. Falls ein CAN von einer Nachricht gefolgt wird, dann Senden sofort wiederholen / nicht warten.
Zum Log aus Beitrag #5:
- hier ist alles perfekt bis zur vorletzten Zeile.
- danach haette eine Antwort auf "get basicStatus" eintreffen muessen, da es nicht eintraf, ist die Verarbeitung stehengeblieben.
- bei nicht batteriebetriebenen Geraeten gibts nach 5 Sek. en NO_ACK, und es geht weiter. Da das default WNMI 2 Sekunden ist, wird dieser Mechanismus bei Batteriebetriebenen nicht aktiviert.
- ich wuesste nicht, wie/was ich hier fixen soll.
@Andreas / Beitrag #6:
- Christian hat "get associationAll" ausgeloest. Der packt ein "get associationGroups" auf dem stack, und setzt den Hook. Wenn eine Antwort kommt, dann wird ein "get association 1" auf dem Stack gelegt, usw.
@Andreas / Beitrag #7:
- Keyfob sendet in der Tat ein Application-Update, wenn man alle 4 Knoepfe und dann #2 drueckt. Das verwende ich zum Simulieren eines Batteriebetriebenen Geraetes. Ich weiss nicht, wieso das hier stoeren sollte, und wage zu wetten, dass bei Christian nichts aendern wird.
@Christian / Beitrag #8:
ZitatLaut Sendstack habe ich die 2x abgerufen. Ob dadurch Probleme mit dem Hook entstehen, kann ich nicht nachvollziehen.
Habs geschaut, ich behaupte das sollte kein Problem sein.
Log aus Beitrag #10:
Hier sind viele (11) CANs, ist also eine verschaerfte Variante des ersten Logs: dein PST02 hoert schlecht :)
Wenn ich nichts von euch hoere, dann versuche ich morgen meinen Vorschlag umzusetzen. Ist leider nicht ganz trivial.
ZitatZum Log aus Beitrag #1:
- warum Befehle auf dem Stack bleiben, kann ich nicht wirklich erklaeren, evtl. schlaeft der PST02 wg. dem CAN-Resend-Timout selbst ein.
Glaube ich nicht, laut Specs schläft der erst 10 Sekunden nach der letzten Nachricht ein, wenn kein WNMI geschickt wird. Nach meiner Erinnerung habe ich das damals bei den SECURITY-Tests für Andreas auch mal so praktisch festgestellt.
ZitatLog aus Beitrag #10:
Hier sind viele (11) CANs, ist also eine verschaerfte Variante des ersten Logs: dein PST02 hoert schlecht :)
Zweifel :) . Vielleicht löst sich das nach Deinen Änderungen von alleine, ansonsten habe ich noch eine Idee, die auch Problem aus #5 lösen könnte. Jedoch den Komplexitätsgrad enorm steigert. Stichwort: Telegrammlaufzeitverhersage -> habe ich mir bei ozw und zway wie im anderen Thread angekündigt mal angesehen.
ZitatWenn ich nichts von euch hoere, dann versuche ich morgen meinen Vorschlag umzusetzen. Ist leider nicht ganz trivial.
Ich bin jetzt ruhig. ;)
Hi Rudi,
Callbacks wären schön... ;-)
Zitat@Andreas / Beitrag #7:
- Keyfob sendet in der Tat ein Application-Update, wenn man alle 4 Knoepfe und dann #2 drueckt. Das verwende ich zum Simulieren eines Batteriebetriebenen Geraetes. Ich weiss nicht, wieso das hier stoeren sollte, und wage zu wetten, dass bei Christian nichts aendern wird.
Was hier bei meinem Multisensor "stört" ist die Tatsache das FHEM schon bei dem APPLICATION_UPDATE anfängt zu senden, der Sensor aber erst mal seine Meldungen loswerden will und DANACH dann die WUN schickt. Durch das gleichzeitige Senden kommt es zu CAN Msg. Irgendwann bleibt dann der SendStack hängen, das ist aber ein anderes Problem, das ja anscheinend auch ohne CAN Msg ausgelöst werden kann.
Wenn jetzt Wunschkonzert wäre würde ich mir wünschen das standardmäßig der WU-Stack NICHT bei APPLIKATION_UPDATE geöffnet wird, sondern wirklich erst mit der WUN und das bei besonderen Geräte das für APPLIKATION_UPDATE per Attribut freigeschaltet werden kann falls nötig. Aber das ist hier eher untergeordnet. Das Grundproblem das der Stack hängenbleibt müssen wir erst noch richtig verstehen...
Ich bin mir nicht ganz sicher, ich hatte damals nur ganz kurz mit den Callback-IDs gespielt aber irgendwie abgespeichert das die eben NICHT immer (oder gar nicht?) zurückgesendet wurden. Bevor Du hier viel Aufwand in einen Umbau steckst sollte erst mal klar sein das die Antworten von den Nodes auch wirklich die übergebene Callback-ID nutzen.
Ein anderer Ansatzpunkt wäre aus meiner Sicht für jeden Befehl eine etwas spezifischere Regexp für die Antwort zu definieren. Momentan wird ja alles was von der Node kommt als Antwort auf das get akzeptiert/interpretiert. Eigentlich weiß man man bei jedem Befehl ja welche CC und welchen Report-Code man als Antwort erwartet. Damit könnte man besser entscheiden ob das die erwartete Antwort oder eine "unsolicited" Msg ist.
Ich bin mir bei einigen von den CAN Msg auch nicht sicher auf was die sich eigentlich beziehen und ob dann die richtige Nachricht erneut verschickt wird. Im Log von Christian war so ein Fall bei dem ich eigentlich davon ausgegangen wäre das die Nachricht schon vom Stack verschwunden sein sollte...
Ich hab' mein Log noch nicht bis zu der interessanten Stelle durchgeschaut, ich mach' morgen früh damit weiter und melde mich sobald ich da was neue rausgefunden habe.
Und wie immer bist Du deutlich schneller als wir ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 05 März 2016, 23:30:36
Ich bin mir nicht ganz sicher, ich hatte damals nur ganz kurz mit den Callback-IDs gespielt aber irgendwie abgespeichert das die eben NICHT immer (oder gar nicht?) zurückgesendet wurden. Bevor Du hier viel Aufwand in einen Umbau steckst sollte erst mal klar sein das die Antworten von den Nodes auch wirklich die übergebene Callback-ID nutzen.
Wollte ja ruhig sein, aber: jetzt rede ihm die CallbackIds bloß nicht wieder aus ;)
Zur Sache:
Mir ist unbekannt, dass die CalbackIDs bei ZW_SEND_DATA nicht immer kommen. Die CallbackIDs sind doch laut zwapi Pflicht und in allen Beschreibungen und selbst in Musterabläufen enthalten. Bei ozw und z-way Logs ist mir letzte Woche dazu auch nichts untergekommen, worüber ich gestolpert bin. Es wird in den Logs alles über die CallbackIDs verfolgt. Eigentlich bin ich mir relativ sicher, dass wir auf CallbakIDs setzen können. Hast Du denn noch Anhaltspunkte, wo das Problem damals lag?
Hi,
ich will das Rudi ja nicht ausreden...
Ich wollte nur sagen das man da erst mal die IDs einfügt und schaut ob die zurückkommen bevor man den ganzen Ablauf damit steuert und die dann doch nicht bei jedem Gerät oder Befehl kommen...
Ich kann wirklich nicht mehr sagen was ich das damals alles so mit den IDs gemacht habe. Kann auch gut sein das ich das ich das jetzt aus dem Gedächtnis mit irgendeinem anderen Problem vermische. Ich bin nämlich auch ziemlich sicher das OZW beim Ablauf die Callbackids verwendet und diese "exepected answer" Meldungen damit erzeugt.
Spannend wird dann wieder die Frage wieweit sich das ganze dann mit SECURITY verträgt...
Wobei CRC16 Nachrichten oder Multi-CMD Nachrichten könnten auch noch interessant werden, da hier eine Kapselung stattfindet bzw. mehrere Befehle zusammengefasst werden. Wobei ich bei Multi-Cmd aber der Meinung bin das die nicht als Antwort auf ein Get kommen, sondern nur als "unsolicited" Statusmeldung.
Gruß,
Andreas.
Hi,
hier jetzt wie angedroht meine Analyse... WIe immer recht länglich ,-)
Ich bin mir jetzt nicht mehr ganz so sicher ob das Problem von Christian (ohne die CAN) und das was ich hier bei mir vorfinde letztendlich das gleiche Grundproblem hat.
Aber ich bin mir jetzt ziemlich sicher das Senden nach APPLICATION_UPDATE eine schlechte Idee ist...
Testbedingungen: AEOTEC Multisensor, Batteriebetrieb -> WakeUpModus, "get configAll" im WU-Stack, dann manuell auf den "Knopf" gedrückt
- > APPLICATION_UPDATE wird gesendet, später wird aber auch eine WUN gesendet, die dann das ganze "Chaos" auslöst, da beim Empfang der WUN der SendStack erneut im Modus "next" geöffnet wird und eine neue Nachricht freigeben wird, obwohl ja bereits eine Kommunikation läuft.
2016.03.05 09:11:02.202 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984ab120421015e86725985737184803031707aef5a
2016.03.05 09:11:02.203 5: SW: 06
2016.03.05 09:11:02.204 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:02.204 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
2016.03.05 09:11:02.204 4: CMD:ZW_APPLICATION_UPDATE ID:ab ARG:120421015e86725985737184803031707aef5a
# Application_Update received
2016.03.05 09:11:02.204 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <next> from ZWave_Parse (WU / APPLICATION_UPDATE)
# Trigger by Application Update
ZWave_processSendStack wird also über APPLICATION_UPDATE getriggert, danach werden etliche GET-Befehle aus der configAll Anfrage sauber abgearbeitet.
In dem Logabschnitt unten kann man dann sehen das mitten in die Kommunikation die WUN kommt und den ZWave_processSendStack mit "next" startet. Zu dem Zeitpunkt ist die Antwort auf ein "get 70052a" noch offen und es wird ein "get 700527" zusätzlich abgesetzt.
Ab da ist der Ablauf "asynchron" und es kommt zu den CAN Messages:
In Kurzform:
get 70052a
WUN
get 700527 released and send
70062a received
70052e released
CAN
1s timeout
700527 resend
70052e send
700627 received
CAN
1s timeout
70052e resend
7005cb released and send
70062e received
CAN
1s timeout
7005cb resend
7006cb received
Stack arbeitet danach nicht weiter da anscheinend $hash->{wakeupAlive} nicht mehr gesetzt ist. Hier ist dann die nächste Auffälligkeit, ich habe noch weitere Logs gemacht in denen ich den Status abgefragt habe, und der ist bereits nach dem ersten CAN nicht mehr aktiv! Nach meinem Verständnis müsste dann doch eigentlich der WU-Stack wieder aktiv werden, oder?
Bei den beiden anderen CAN waren zu dem Zeitpunkt zwei Nachrichten offen, sodass hier die Abfrage auf das wakeupAlive nicht greift...
WNMI ist auf 0.3 sekunden gesetzt...
Eine weitere Auffälligkeit ist das der Sensor auch nach dem Timout von 1 sekunde weiter antwortet und NICHT eingeschlafen ist. Das ist ja gerade die Besonderheit von dem Ding das da sonst nach weniger als 0.3 sekunden schon ein NO_ACK kommt.
Das werde ich mir noch mal genauer anschauen, ich denke das ich da damals einen voreiligen Schluss gezogen habe und das der Sensor nach dem Applikation_UPDATE bereits so schnell einschläft, nach der WUN aber dann doch vielleicht länger wach bleibt. Zumindest würde das so einiges erklären...
2016.03.05 09:11:03.041 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <msg> from ZWave_Parse (no WU)
# ZW
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: msg
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.05 09:11:03.042 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052a25ab
2016.03.05 09:11:03.042 5: ZWDongle_Write 0013ab0370052a25ab (e015dfed)
2016.03.05 09:11:03.042 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Write
# ZWD
2016.03.05 09:11:03.042 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.042 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.042 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:03.042 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:03.042 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab0370052a25ab9f
2016.03.05 09:11:03.042 5: SW: 010a0013ab0370052a25ab9f
# get 70052a
2016.03.05 09:11:03.043 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:03.043 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.05 09:11:03.043 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
#exit ZW
2016.03.05 09:11:03.044 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.044 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.044 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.044 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.044 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.044 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.047 1: ZWDongle_0: ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:03.047 5: ACK received, WaitForAck=>2 for 010a0013ab0370052a25ab9f
2016.03.05 09:11:03.047 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.047 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.047 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.047 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.047 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.047 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.065 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.05 09:11:03.065 5: SW: 06
2016.03.05 09:11:03.066 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:03.066 5: ZWDongle_0 dispatch 011301
2016.03.05 09:11:03.066 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.066 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.066 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.066 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.066 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.067 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.107 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab028407
# WUN
2016.03.05 09:11:03.107 5: SW: 06
2016.03.05 09:11:03.108 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:03.108 5: ZWDongle_0 dispatch 000400ab028407
2016.03.05 09:11:03.108 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <next> from ZWave_Parse (WU)
# start of ZW due to WUN -> new command to be released!
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: next
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.05 09:11:03.108 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052725ab
2016.03.05 09:11:03.109 5: ZWDongle_Write 0013ab0370052725ab (e015dfed)
2016.03.05 09:11:03.109 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Write
# ZWD
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
# not typicall -> waitForAck is typically not set at this stage for a new command but it is still set from the ongoing communication
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.109 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
# marking WHICH command as sent?
2016.03.05 09:11:03.109 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
# exit ZW
2016.03.05 09:11:03.109 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.109 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.135 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000008
2016.03.05 09:11:03.135 5: SW: 06
2016.03.05 09:11:03.136 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:03.136 5: device ack reveived, removing 010a0013ab0370052a25ab9f from dongle sendstack
2016.03.05 09:11:03.136 5: ZWDongle_0 dispatch 0013ab000008
2016.03.05 09:11:03.136 4: CMD:ZW_SEND_DATA ID:00 ARG:0008
2016.03.05 09:11:03.136 4: ZWDongle_0 transmit OK for ab
2016.03.05 09:11:03.136 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <ack> from ZWave_Parse
# ZW
2016.03.05 09:11:03.136 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: ack
2016.03.05 09:11:03.136 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:03.136 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:03.136 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
# exit ZW
2016.03.05 09:11:03.136 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.136 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.136 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.136 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:03.136 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:03.136 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab0370052725ab92
2016.03.05 09:11:03.136 5: SW: 010a0013ab0370052725ab92
# get 700527 -> two commands are "open"
2016.03.05 09:11:03.138 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:03.161 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab0570062a010a
2016.03.05 09:11:03.161 5: SW: 06
2016.03.05 09:11:03.162 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:03.162 5: ZWDongle_0 dispatch 000400ab0570062a010a
2016.03.05 09:11:03.162 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:0570062a010a
#answer 70062a -> answer for first command received w/o CAN, only this command is open now...
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <msg> from ZWave_Parse (no WU)
# ZW
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: msg
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.05 09:11:03.162 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab0370052e25ab
2016.03.05 09:11:03.162 5: ZWDongle_Write 0013ab0370052e25ab (e015dfed)
2016.03.05 09:11:03.163 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Write
# ZWD
2016.03.05 09:11:03.163 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.163 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.163 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.163 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.163 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.163 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.05 09:11:03.163 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
# exit ZW
2016.03.05 09:11:03.164 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.164 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.164 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.164 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.164 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.164 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:03.165 4: ZWDongle_Read ZWDongle_0: CAN received
# CAN received -> 70062a??
2016.03.05 09:11:03.165 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:03.166 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:03.166 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:03.166 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:03.166 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:03.166 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
# no communication "open" as CAN was received, no resend so far...
# ZWD called by timer!
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack, WaitForAck==1 and dt > 1 sec.
2016.03.05 09:11:04.167 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013ab0370052725ab92
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:04.167 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab0370052725ab92
2016.03.05 09:11:04.167 5: SW: 010a0013ab0370052725ab92
# resend 700527 -> answer was already received -> 70052a should have been sent instead...
2016.03.05 09:11:04.168 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:04.169 1: ZWDongle_0: ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:04.169 5: ACK received, WaitForAck=>2 for 010a0013ab0370052725ab92
2016.03.05 09:11:04.169 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:04.169 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.169 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.169 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:04.169 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:04.169 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:04.183 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.05 09:11:04.183 5: SW: 06
2016.03.05 09:11:04.184 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:04.184 5: ZWDongle_0 dispatch 011301
2016.03.05 09:11:04.184 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:04.184 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.184 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.184 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:04.184 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:04.184 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:04.211 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.05 09:11:04.211 5: SW: 06
2016.03.05 09:11:04.212 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:04.212 5: device ack reveived, removing 010a0013ab0370052725ab92 from dongle sendstack
2016.03.05 09:11:04.212 5: ZWDongle_0 dispatch 0013ab000002
2016.03.05 09:11:04.212 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 09:11:04.212 4: ZWDongle_0 transmit OK for ab
2016.03.05 09:11:04.212 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <ack> from ZWave_Parse
# ZW
2016.03.05 09:11:04.212 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: ack
2016.03.05 09:11:04.212 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:04.212 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:04.212 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
# exit ZW
2016.03.05 09:11:04.212 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:04.212 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.212 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.212 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:04.212 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:04.212 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab0370052e25ab9b
2016.03.05 09:11:04.212 5: SW: 010a0013ab0370052e25ab9b
# get 70052e -> two commands open, answer for resend of 700527 is still open (has just arrived...)
2016.03.05 09:11:04.213 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# eixt ZWD
2016.03.05 09:11:04.245 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab057006270114
2016.03.05 09:11:04.245 5: SW: 06
2016.03.05 09:11:04.246 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:04.246 5: ZWDongle_0 dispatch 000400ab057006270114
2016.03.05 09:11:04.247 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:057006270114
# answer 700627 (from resend)
2016.03.05 09:11:04.247 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <msg> from ZWave_Parse (no WU)
# ZW
2016.03.05 09:11:04.248 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:04.248 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.248 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.248 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:04.248 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:04.248 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:04.250 4: ZWDongle_Read ZWDongle_0: CAN received
# CAN received 70052e??
2016.03.05 09:11:04.250 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:04.250 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:04.250 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:04.250 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:04.250 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:04.250 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
# ZWD called by timer!
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack, WaitForAck==1 and dt > 1 sec.
2016.03.05 09:11:05.250 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013ab0370052e25ab9b
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:05.250 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab0370052e25ab9b
2016.03.05 09:11:05.250 5: SW: 010a0013ab0370052e25ab9b
# get 70052e (resend)
2016.03.05 09:11:05.251 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:05.251 1: ZWDongle_0: ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:05.251 5: ACK received, WaitForAck=>2 for 010a0013ab0370052e25ab9b
2016.03.05 09:11:05.252 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:05.252 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.252 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.252 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.252 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:05.252 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:05.266 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.05 09:11:05.267 5: SW: 06
2016.03.05 09:11:05.268 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:05.268 5: ZWDongle_0 dispatch 011301
2016.03.05 09:11:05.268 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:05.268 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.268 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.268 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.268 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:05.268 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:05.285 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.05 09:11:05.285 5: SW: 06
2016.03.05 09:11:05.286 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:05.286 5: device ack reveived, removing 010a0013ab0370052e25ab9b from dongle sendstack
2016.03.05 09:11:05.286 5: ZWDongle_0 dispatch 0013ab000002
2016.03.05 09:11:05.286 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 09:11:05.286 4: ZWDongle_0 transmit OK for ab
2016.03.05 09:11:05.286 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <ack> from ZWave_Parse
# ZW
2016.03.05 09:11:05.286 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: ack
2016.03.05 09:11:05.286 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:05.287 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:05.287 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack going to remove Timer
2016.03.05 09:11:05.287 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack Timer removed
2016.03.05 09:11:05.287 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack type: get msg: 13ab037005cb25ab
2016.03.05 09:11:05.287 5: ZWDongle_Write 0013ab037005cb25ab (e015dfed)
2016.03.05 09:11:05.287 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Write
# ZWD
2016.03.05 09:11:05.287 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.287 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.287 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:05.287 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:05.287 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab037005cb25ab7e
2016.03.05 09:11:05.287 5: SW: 010a0013ab037005cb25ab7e
# get 7005cb
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:05.288 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack marking as sent in sendstack
2016.03.05 09:11:05.288 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack leaving processSendStack
# exit ZW
2016.03.05 09:11:05.288 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:05.288 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:05.323 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab0570062e0100
2016.03.05 09:11:05.323 5: SW: 06
2016.03.05 09:11:05.324 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:05.324 5: ZWDongle_0 dispatch 000400ab0570062e0100
2016.03.05 09:11:05.324 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:0570062e0100
# answer 70062e (from resend)
2016.03.05 09:11:05.325 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <msg> from ZWave_Parse (no WU)
# ZW
2016.03.05 09:11:05.326 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:05.326 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.326 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.326 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.326 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:05.326 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:05.335 4: ZWDongle_Read ZWDongle_0: CAN received
# CAN
2016.03.05 09:11:05.335 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:05.335 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:05.335 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:05.335 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:05.335 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:05.335 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
# ZWD called by timer!
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack, WaitForAck==1 and dt > 1 sec.
2016.03.05 09:11:06.335 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013ab037005cb25ab7e
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:06.335 1: ZWDongle_0: Dongle_processSendStack, send msg 010a0013ab037005cb25ab7e
2016.03.05 09:11:06.335 5: SW: 010a0013ab037005cb25ab7e
# get 7005cb (resend)
2016.03.05 09:11:06.337 1: ZWDongle_0: Dongle_processSendStack, start timer for ZWDongle_ProcessSendStack +1s
# exit ZWD
2016.03.05 09:11:06.338 1: ZWDongle_0: ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:06.338 5: ACK received, WaitForAck=>2 for 010a0013ab037005cb25ab7e
2016.03.05 09:11:06.338 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:06.338 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:06.338 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:06.338 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:06.338 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:06.338 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:06.351 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.05 09:11:06.351 5: SW: 06
2016.03.05 09:11:06.352 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:06.352 5: ZWDongle_0 dispatch 011301
2016.03.05 09:11:06.352 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:06.352 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:06.352 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:06.352 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist gesetzt
2016.03.05 09:11:06.352 1: ZWDongle_0: Dongle_processSendStack, no_resend and no no_response, going to start timer
2016.03.05 09:11:06.352 1: ZWDongle_0: Dongle_processSendStack, timer started +1s
# exit ZWD
2016.03.05 09:11:06.386 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2016.03.05 09:11:06.386 5: SW: 06
2016.03.05 09:11:06.388 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:06.388 5: device ack reveived, removing 010a0013ab037005cb25ab7e from dongle sendstack
2016.03.05 09:11:06.388 5: ZWDongle_0 dispatch 0013ab000002
2016.03.05 09:11:06.388 4: CMD:ZW_SEND_DATA ID:00 ARG:0002
2016.03.05 09:11:06.388 4: ZWDongle_0 transmit OK for ab
2016.03.05 09:11:06.388 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <ack> from ZWave_Parse
# ZW
2016.03.05 09:11:06.388 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack called with ackType: ack
2016.03.05 09:11:06.388 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack sendstack not empty
2016.03.05 09:11:06.388 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack entry sent
2016.03.05 09:11:06.388 1: ZWave_SENSOR_MULTILEVEL_171: processSendStack get / ack detected, set sentackget, leaving processSendStack
# exit ZW
2016.03.05 09:11:06.388 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
# ZWD
2016.03.05 09:11:06.388 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:06.388 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:06.388 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:06.388 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:06.388 1: ZWDongle_0: Dongle_processSendStack, <return>
# exit ZWD
2016.03.05 09:11:06.429 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab067006cb020000
2016.03.05 09:11:06.429 5: SW: 06
2016.03.05 09:11:06.430 1: ZWDongle_0: device ACK received, calling ZWDongle_shiftSendStack
2016.03.05 09:11:06.430 5: ZWDongle_0 dispatch 000400ab067006cb020000
2016.03.05 09:11:06.430 4: CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:067006cb020000
# answer 7006cb (from resend)
2016.03.05 09:11:06.431 1: ZWave_SENSOR_MULTILEVEL_171: calling ZWave_processSendStack with <msg> from ZWave_Parse (no WU)
# ZW
# ???
# ZWave_processSendStack($hash, "msg") if(!ZWave_isWakeUp($hash) || $hash->{wakeupAlive});
# -> wakeupAlive no longer active?
2016.03.05 09:11:06.431 1: ZWDongle_0: calling ZWDongle_ProcessSendStack from ZWDongle_Read
2016.03.05 09:11:06.431 1: ZWDongle_0: Dongle_processSendStack called, going to remove timer
2016.03.05 09:11:06.431 1: ZWDongle_0: Dongle_processSendStack timer removed
2016.03.05 09:11:06.431 1: ZWDongle_0: Dongle_processSendStack, WaitForAck ist nicht gesetzt
2016.03.05 09:11:06.431 1: ZWDongle_0: Dongle_processSendStack, check for <return>
2016.03.05 09:11:06.431 1: ZWDongle_0: Dongle_processSendStack, <return>
Ich sehe für dieses Problem (ich zweifle mittlerweile das Christians Problem die gleiche Ursache hat...) folgende Ansatzpunkte:
a.) Senden nach APPLICATION_UPDATE nicht standardmäßig, sondern nur für besondere Geräte (z.B . die KFOBs)
b.) Falls doch nach APPLICATION_UPDATE gesendet wird, Abfrage bei Eintreffen der WUN um "doppeltes" Öffnen des SendStacks zu verhindern
Mich macht in dem Log aber stutzig das da noch etliche Befehle hin-und-her gehen, obwohl doch wakeupAlive gar nicht mehr gesetzt ist...
Außerdem wird gar kein WUNMI abgesetzt...
Gruß,
Andreas.
- der KFOB sendet direct nach Application-Update eine WN, ich habe den wake-up code beim Application-Update auskommentiert. Kann man zum kuenstlichen Erzeugen der CAN Probleme aktivieren.
- ein globales/fortlaufendes callbackId kommt doch nicht (ich hoere gerade: buuuuh). Der Dongle sendet nur fuer den 0013-er ACK diese ID zurueck, und da ich nicht vorhabe, an einem Geraet mehr als eine Nachricht ohne 0013-er Ack zu senden, ist die bisher verwendete NodeId als callbackId genausogut.
- bei allen Nachrichten, die direkt vom Geraet kommen, ist callbackId 0, und auch nach Durchsicht der uebrigen Bits bekomme ich nichts vom Dongle, was mir beim Identifizieren einer Wiederholung helfen koennte: Der Code im ZWave_processSendStack bleibt erstmal gleich.
Im Log / CMD: Zeile wird ab sofort callbackId mit CB: ausgegeben, vielleicht entdeckt ihr was anderes.
- Ab sofort sendet FHEM Befehle erneut an den Dongle, wenn der Dongle eine "richtige" Nachricht (kein Ack) meldet. Das behebt hoffentlich das Unterbrechen der Abarbeitung.
Hi Rudi,
Zitat von: rudolfkoenig am 06 März 2016, 13:42:26
- der KFOB sendet direct nach Application-Update eine WN, ich habe den wake-up code beim Application-Update auskommentiert. Kann man zum kuenstlichen Erzeugen der CAN Probleme aktivieren.
Ok, das hilft schon mal. Aus irgendeinem Grund habt Ihr beide aber darauf bestanden das so zu lassen weil es für irgendeinen Sonderfall benötigt wurde... Ich krieg' das aber aus dem Gedächtnis nicht mehr hin. Na ja, wenn es wirklich so war wird es ja jetzt auffallen.
Zitat von: rudolfkoenig am 06 März 2016, 13:42:26
- ein globales/fortlaufendes callbackId kommt doch nicht (ich hoere gerade: buuuuh). Der Dongle sendet nur fuer den 0013-er ACK diese ID zurueck, und da ich nicht vorhabe, an einem Geraet mehr als eine Nachricht ohne 0013-er Ack zu senden, ist die bisher verwendete NodeId als callbackId genausogut.
War mir doch so als ob das damals bei mir auch nicht das gewünschte Ergebnis gezeigt hat. Schade, wäre (relativ) einfach zu nutzen gewesen...
Und "buuuh" kriegst Du von mir dafür nicht, habe das ja befürchtet.
Zitat von: rudolfkoenig am 06 März 2016, 13:42:26
- bei allen Nachrichten, die direkt vom Geraet kommen, ist callbackId 0, und auch nach Durchsicht der uebrigen Bits bekomme ich nichts vom Dongle, was mir beim Identifizieren einer Wiederholung helfen koennte: Der Code im ZWave_processSendStack bleibt erstmal gleich.
Im Log / CMD: Zeile wird ab sofort callbackId mit CB: ausgegeben, vielleicht entdeckt ihr was anderes.
Bei der Lektüre der Application Guideline bekomme ich auch den Eindruck das die Callback-IDs für allem für die Dongle-, bzw. Node-interne Programmierung gedacht sind und nicht für die globale Kommunikation da sind.
Ich werde das mit CB: mal beobachten, denke aber nicht das dabei was neues rauskommt.
Was ist denn mit meinem Ansatz die Regexp für get spezifischer zu generieren? Würde bedeuten das man beim Senden schon z.B. mit ":" angehängt die Regexp mitgibt die auf die erwartete Antwort passt. Damit müsste es möglich sein unsolicited Nachrichten von den erwarteten Antworten unterscheiden zu können.
Zitat von: rudolfkoenig am 06 März 2016, 13:42:26
- Ab sofort sendet FHEM Befehle erneut an den Dongle, wenn der Dongle eine "richtige" Nachricht (kein Ack) meldet. Das behebt hoffentlich das Unterbrechen der Abarbeitung.
Hmm, hier bin ich nicht sicher ob das für alle Möglichkeiten, wann eine Nachricht eintreffen kann, die richtige Lösung ist... Das kann ich mir in meinem kleinen Kopf nicht alles vorstellen...
Müsste nicht eigentlich verhindert werden das "unsolicited Messages" den (ZWave|ZWDongle)_(p|P)rocessSendStack aufrufen? Die CAN-Nachricht die bei so einem Fall auftreten kann lässt sich ja nicht vermeiden und wird ja vom SendStack auch problemlos verkraftet.
Gruß,
Andreas.
ZitatWas ist denn mit meinem Ansatz die Regexp für get spezifischer zu generieren?
Ich habe eine einfache Variante davon eingebaut: bei einem get wird die Klasse der gesendeten Anfrage mit der Klasse der empfangenen Nachricht verglichen. Das hilft leider nicht beim Fehler waehrend "get configAll". Ein genaueres Regexp ist mAn nur sehr aufwendig zu erstellen.
Hi Rudi,
Zitat von: rudolfkoenig am 06 März 2016, 19:43:52
Ich habe eine einfache Variante davon eingebaut: bei einem get wird die Klasse der gesendeten Anfrage mit der Klasse der empfangenen Nachricht verglichen. Das hilft leider nicht beim Fehler waehrend "get configAll". Ein genaueres Regexp ist mAn nur sehr aufwendig zu erstellen.
werde ich mir im Laufe der Woche mal ansehen.
Ob genauere Regexp wirklich so aufwändig sind glaube ich erst mal nicht ,-)
Ich könnte mir vorstellen das man einfach an alle GET-Befehle per Trennzeichen (":") die Regexp mit zum Senden übergibt. Der SendStack müsste das dann für das eigentlich Senden abschneiden und für den Aufruf der ReadAnswerFn wieder abfragen.
Aber während eines configAll wird wohl kaum eine unsolicited Nachricht mit der config-classe kommen. Die werden mMn nicht unsolicited versendet, von daher müsste das auch so ausreichen.
Gruß,
Andreas.
Zitat von: rudolfkoenig am 06 März 2016, 13:42:26.
- ein globales/fortlaufendes callbackId kommt doch nicht (ich hoere gerade: buuuuh). Der Dongle sendet nur fuer den 0013-er ACK diese ID zurueck, und da ich nicht vorhabe, an einem Geraet mehr als eine Nachricht ohne 0013-er Ack zu senden, ist die bisher verwendete NodeId als callbackId genausogut.
Habe die geänderten Module zuerst einmal mit einem netzbetriebenen Gerät getestet.
Dazu habe ich den Befehl "get <device> versionClassAll" abgesetzt. Nach meinem Verständnis wird hier im unten gezeigten Logausschnitt nach einer Nachricht ohne 0013-er Ack eine neue Nachricht verschickt. Das komplette Log habe ich angehängt, da der ganze Ablauf mMn wichtig ist. Der Ärger geht schon spätestens bei 2x 0013-er ACK um 11:32:04.175 los. Dort scheint es eine automatisches Resend durch den Controller gegeben zu haben. Wegen fehlender fortlaufender Callback-ID :) kann ich aber nicht definitiv feststellen, was vom Gerät mehrfach empfangen, d.h. welche genaue Nachricht mit 0013er-ACK bestätigt wurde. AUswertung von versionClass 73 wird bspw. 4x empfangen.
Eventuell habe ich einen Verständnisproblem, aber bevor ich das am WakeUp-Geräten probiere, wäre es schön, wenn ihr mal einen Blick darauf werfen würdet und mich belehrt. Danke, Christian
2016.03.07 11:32:08.540 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.07 11:32:08.544 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.07 11:32:08.547 5: SW: 010a00130403861332250467
2016.03.07 11:32:08.557 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147301
2016.03.07 11:32:08.558 5: SW: 06
2016.03.07 11:32:08.563 5: ZWDongle_0 dispatch 000400040486147301
2016.03.07 11:32:08.566 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147301 CB:00
2016.03.07 11:32:08.586 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.07 11:32:08.590 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.07 11:32:08.593 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130403861332250467
2016.03.07 11:32:08.595 5: SW: 010a00130403861332250467
2016.03.07 11:32:08.604 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147301
2016.03.07 11:32:08.606 5: SW: 06
2016.03.07 11:32:08.611 5: ZWDongle_0 dispatch 000400040486147301
2016.03.07 11:32:08.614 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147301 CB:00
Das list zum obigen Log. Das Attribut vclasses zeigt die Merkwürdigkeit im Sendeverlauf mMn:
Internals:
CHANGED
DEF e345c452 4
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 5
NAME ZWave_SWITCH_MULTILEVEL_4
NR 240
STATE Blind 0 Slat 0
TYPE ZWave
ZWDongle_0_MSGCNT 5
ZWDongle_0_RAWMSG 0004000406310504220000
ZWDongle_0_TIME 2016-03-07 12:52:02
homeId e345c452
isWakeUp
lastMsgSent 1457347101.15657
nodeIdHex 04
Readings:
2016-03-06 20:26:04 SEND_DATA failed:00
2016-01-03 20:49:48 UNPARSED MANUFACTURER_SPECIFIC 0a7205010e000800020000
2016-02-10 19:12:33 assocGroup_1 Max 16 Nodes
2016-02-10 19:12:22 assocGroup_2 Max 16 Nodes
2016-02-10 19:12:28 assocGroup_3 Max 1 Nodes ZWDongle_0
2016-02-10 19:12:27 assocGroups 3
2016-03-06 21:47:37 configEnergyReports 10
2016-03-06 21:47:37 configForcedRollerShutterCalibration Default
2016-03-06 21:47:37 configInRollerBlindModeOrVenetianBlind17 10
2016-03-06 21:47:37 configInVenetianBlindModeTheParameter12 150
2016-03-06 21:47:43 configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
2016-03-06 21:47:43 configMotorOperationDetection 10
2016-03-06 21:47:43 configMotorOperationTime 240
2016-03-06 21:47:46 configPeriodicPowerOrEnergyReports 3600
2016-03-06 21:47:46 configPowerReports 10
2016-03-06 21:47:52 configReportsType BlindPositionReportsSentToThe1
2016-03-06 21:47:52 configResponseToFloodingAlarm NoReaction
2016-03-06 21:47:52 configResponseToGeneralAlarm CloseBlind
2016-03-06 21:47:52 configResponseToSmokeCOOrCO2Alarm NoReaction
2016-03-06 21:47:52 configResponseToTemperatureAlarm OpenBlind
2016-03-06 21:47:53 configRollerShutterOperatingModes VenetianBlindModeWithPositioning
2016-03-06 21:47:53 configScenesAssociationsActivation AssociationsActivation
2016-03-06 21:47:53 configSelfMeasurement SelfMeasurementInactive
2016-03-06 21:47:53 configSetLamellasBackToPrevious13 LamellasReturnToPreviouslySet1
2016-03-06 21:47:54 configSwitchType MomentarySwitches
2016-03-07 12:51:03 energy 0.1 kWh
2016-03-07 11:38:21 meterSupported type: energy scales: 0:kWh, 2:W resetable: yes
2016-02-18 09:04:41 model FIBARO System FGRM222 Roller Shutter Controller 2
2016-02-18 09:04:41 modelConfig fibaro/fgrm222.xml
2016-02-18 09:04:41 modelId 010f-0301-1001
2016-02-28 12:30:30 neighborList ZWave_SWITCH_BINARY_6 ZWave_SENSOR_BINARY_18 ZWave_SWITCH_MULTILEVEL_26 ZWave_SWITCH_MULTILEVEL_27 ZWave_GARAGE_DOOR_31 ZWave_SENSOR_MULTILEVEL_43 ZWave_WALL_CONTROLLER_44
2016-02-28 18:52:20 position Blind 0 Slat 0
2016-03-07 12:52:02 power 0.0 W
2016-03-06 21:56:09 reportedState off
2016-03-07 11:32:12 state TRANSMIT_NO_ACK
2016-03-07 11:38:21 transmit OK
2016-02-18 19:04:22 version Lib 3 Prot 3.52 App 22.22
2015-12-23 19:56:12 versionClass_47 00
2015-12-23 19:59:52 versionClass_70 01
2016-02-07 10:53:01 versionClass_85 02
Attributes:
IODev ZWDongle_0
classes MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY
event-on-change-reading .*
room ZWave
stateFormat position
vclasses MANUFACTURER_SPECIFIC:1 VERSION:1 CONFIGURATION:1 ASSOCIATION:2 SWITCH_BINARY:1 POWERLEVEL:1 POWERLEVEL:1 POWERLEVEL:1 POWERLEVEL:1 SWITCH_BINARY:1 MANUFACTURER_PROPRIETARY:1 PROTECTION:2
Habe jetzt noch ein wenig mit netzbetriebenen Geräten experimentiert und ZWave-Infos gelesen. Ich komme zu folgenden theoretischen Überlegungen:
Werden viele Nachrichten für einen Node abgesetzt, dann kann es aufgrund von "Netzstörungen" mMn nicht sichergestellt werden, dass 0013er-ACK ohne fortlaufende CallbackID zur korrekten Verarbeitung des Stacks führen.
Es ist mMn derzeit bei NodeID=CallbackID nicht sicher feststellbar, ob eine eintreffende 0013er-ACK zur letzten verschickten oder einer vorherigen Nachricht des Nodes gehört. Die Telegrammlaufzeiten sind unterschiedlich, so dass ACK zeitversetzt eintreffen können und es gibt auch automatiche Wiederholungen durch den Controller, die FHEM nicht mitbekommt. Mir ist nicht bekannt, dass der Controller bei erfolgreichen Wiederholungen automatische Filterung vornimmt.
Ordnet man ein 0013er-ACK immer der letzten Nachricht zu, dann werden evtl. Nachrichten als ordnungsgemäß verschickt deklariert, die nie beim Node angekommen sind (könnte auf obiges Log für "get versionClass Meter zutreffen). Das 0013er-ACK könnte nämlich für einen vorherigen Befehl durch Wiederhoungsversuche oder unterschiedliche Telegrammlaufzeiten sein. Diese Verluste sind -vermutlich auch gerade bei SECURITY- unschön.
Der andere Fall sind mehrfach eintreffenden Antwort-Nachrichten auf einen Befehl an eine Node. Wenn man über die eindeutige CallbackID feststellen könnte, wie oft ein Befehl beim Node eingetroffen ist, könnte man die herausfiltern. Momentan halte ich das aber für unnötig.
Hoffe meine Gedankengänge sind nachvollziehbar. Gegenargumente sind willkommen, aber momentan ist das für mich die plausibelste Begründung für meine Beobachtungen.
Gruß, Christian
PS: Der Aktor im letzten Log reagiert auf die versionClass MARK - Abfrage nie; ist bei allen meinen FGRM-222 so.
ZitatEs ist mMn derzeit bei NodeID=CallbackID nicht sicher feststellbar, ob eine eintreffende 0013er-ACK zur letzten verschickten oder einer vorherigen Nachricht des Nodes gehört.
Ja, ja, aber! :)
FHEM darf nur eine Nachricht rausschicken, was nicht per ACK bestaetigt wurde.
Fuer unaufgeforderte Nachrichten vom Geraet kriegt FHEM auch kein ACK.
Falls ich was nicht kapiert habe, bitte geduldig mit mir sein :)
ZitatFuer unaufgeforderte Nachrichten vom Geraet kriegt FHEM auch kein ACK.
Das ist mir klar, die habe ich nicht betrachtet.
Zitat von: rudolfkoenig am 07 März 2016, 15:47:58
Ja, ja, aber! :)
FHEM darf nur eine Nachricht rausschicken, was nicht per ACK bestaetigt wurde.
Falls ich was nicht kapiert habe, bitte geduldig mit mir sein :)
Also habe ich schlecht erklärt, denn das "aber" passt nicht, da mir das auch klar ist.
Voraussetzung: "viele" anstehende/verschickte Nachrichten von FHEM hintereinander an einen Node
Es ist in FHEM kein Bezug zwischen versandter Nachricht und dem 0013er-ACK gegeben, außer der Annahme, das ein 0013er-ACK immer zur letzten versandten Nachricht des Nodes gehört und 0013er-ACK für eine von FHEM per ZWDongle_Write versandte Nachricht nur genau einmal eintrifft.
Diese Annahme ist aber mMn falsch:
- Nachrichten werden automatisch vom Controller mehrfach (direkt, Route, Explorer Frames bis zu 7(?)x) verschickt ohne dass FHEM diesen mehrfachen Versand feststellen kann. Es gibt dann evtl. mehrfache 0013er-ACK für eine Nachricht, die FHEM fälschlich einer anderen nachfolgenden Nachricht an den Node zuordnet.
- Nachrichten können verschiedene Routen nehmen und also auch Telegrammlaufzeiten unterschiedlich sein.
In Kombination führen die beiden obigen Punkte bei vielen Nachrichten an eine Node zu einem Zuordnungsproblem und -fehlern, gerade wenn auch noch NO_ACK oder andere Probleme auftreten.
Danke auch für Deine Geduld :) . Hoffe, dass ich keine Gedankenfehler habe, aber irgendwie bin ich mir relativ sicher oder habe mich verrannt....
Ok, ich glaube ich habs inzwischen auch verstanden.
- um 11:32:04.062 wird "get versionClass SWITCH_BINARY" rausgeschickt
- es kommen 2(!) ACKs (00130400) rein, in einer Sekunde Abstand. Theorie: die ACK wird vom Zielgeraet auf unterschiedlichen Routes geschickt, und es kommen mehrere Telegramme an. Der Stick reicht alle weiter, und meint, Duplikatserkennung ist Aufgabe der hoeheren Schichten. Wir koennten die Callbackids fortlaufend nummerieren, um ACK-Duplikatserkennung zu machen, leider wuerde das in diesem Fall (get) nichts aendern, da das naechste Befehl sowieso erst nach einem "richtigen" Message bzw. seit gestern eins mit der gleichen Klasse weitergeht. Falls man eine Menge von sets hat, dann wuerde die fortlaufende Nummerierung verhindern, dass mehr als ein Befehl weitergeschickt wird. Das macht die Sache vermutlich etwas besser, allerdings sollte das Problem im ZWDongle-Stack abgefangen sein, insofern erwarte ich nach einem Umbau keine wesentliche Besserung. Wenn ich falsch liegen sollte, bitte mich aufklaeren.
- auf die um 11:32:05.226 verschickte Frage nach "get versionClass POWERLEVEL" gibt es innerhalb von 150ms 4 Antworten. Theorie: die Antwort wurde auf mindestens 4 Routes erfolgreich zugestellt. Leider reicht der Dongle die vorhandene Seriennummer nicht weiter, so dass FHEM diese Nachrichten nicht als Duplikat erkennen kann.
- ZWave_versionClassAllGet fuegt beim Empfang einer Anwort ein Class:Version Token zu vclasses, und generiert die naechste get Frage.
Das geht in diesem Fall fuerchterlich schief. EIch habe jetzt die Funktion umgebaut: es werden alle gets am Anfang schon ins Stack gepackt, und beim Empfang wird der passende Token erneuert. Nebeneffekte: vclasses ist alphabetisch sortiert, "get versionClass XX" erzeugt kein Reading mehr, sondern modifiziert vclasses.
- Was mich wundert: dieses Problem sollte mit der aktuellen ZWave_processSendStack Aenderung eher ent- als verschaerft worden sein.
- ich filtere jetzt MARK in ZWave_versionClassAllGet raus.
- die Meldung
Zitat"my" variable $msg masks earlier declaration in same scope at ./FHEM/10_ZWave.pm line 3579, <$fh> line 24.
habe ich entfernt.
Entweder ist die Duplikatserkennung Aufgabe von FHEM (dann fehlt aber die Seriennummer aus dem Funktelegramm, Bug im ZWDongle-Protokoll), oder ist das die Aufgabe von ZWDongle, dann ist dein Dongle (oder viele?) fehlerhaft. Alternativ muss man dem Dongle sagen, dass er Duplikate filtert, oder die Seriennummer weitergibt, ich weiss aber nicht, wo man das aktiviert.
Btw. bisher filtern wir im ZWCUL auch keine Duplikate, aber wir koennten! :)
ZitatDer Stick reicht alle weiter, und meint, Duplikatserkennung ist Aufgabe der hoeheren Schichten.
Habe ich gerade im INS (Softwarearchitektur) auch so gefunden.
Zitatleider wuerde das in diesem Fall (get) nichts aendern, da das naechste Befehl sowieso erst nach einem "richtigen" Message bzw. seit gestern eins mit der gleichen Klasse weitergeht.
OK, habe also bei get übersehen, dass zusätzlich zu 0013er-ACK auch auf eine Antwort nichtr blockierend gewartet wird. Also bei get demnach unproblematisch. Korrekt?
Zitat- auf die um 11:32:05.226 verschickte Frage nach "get versionClass POWERLEVEL" gibt es innerhalb von 150ms 4 Antworten. Theorie: die Antwort wurde auf mindestens 4 Routes erfolgreich zugestellt. Leider reicht der Dongle die vorhandene Seriennummer nicht weiter, so dass FHEM diese Nachrichten nicht als Duplikat erkennen kann.
Das könnte man mit fortlaufender CallbackID verhindern, ist aber unnötig. (Ja ja, verabschiede mich langsam wieder von der fortlaufenden ID :) )
Zitatdieses Problem sollte mit der aktuellen ZWave_processSendStack Aenderung eher ent- als verschaerft worden sein.
Eventuell wegen härterer Testbedingungen/-methoden ;) : Größeres Netz; kenne den Weg, welchen Aktor ich hier ausschalten muss, um künstlich Explorer Frames zu erzeugen.
ZitatEntweder ist die Duplikatserkennung Aufgabe von FHEM (dann fehlt aber die Seriennummer aus dem Funktelegramm, Bug im ZWDongle-Protokoll), oder ist das die Aufgabe von ZWDongle, dann ist dein Dongle (oder viele?) fehlerhaft. Alternativ muss man dem Dongle sagen, dass er Duplikate filtert, oder die Seriennummer weitergibt, ich weiss aber nicht, wo man das aktiviert.
Genau das hat mich erst auch stutzig gemacht und stolpern lassen.
Aber, INS scheint vorzuschreiben, dass FHEM es machen muss.
Nur warum gibt es dann die Seriennummer bei ZWCul....
Letzter Strohhalm 8):
Zitat2(!) ACKs (00130400) rein, in einer Sekunde Abstand. Theorie: die ACK wird vom Zielgeraet auf unterschiedlichen Routes geschickt, und es kommen mehrere Telegramme an. Der Stick reicht alle weiter, und meint, Duplikatserkennung ist Aufgabe der hoeheren Schichten. Wir koennten die Callbackids fortlaufend nummerieren, um ACK-Duplikatserkennung zu machen, leider wuerde das in diesem Fall (get) nichts aendern, da das naechste Befehl sowieso erst nach einem "richtigen" Message bzw. seit gestern eins mit der gleichen Klasse weitergeht.
Geringfügig andere Telegrammlaufzeiten: Wenn das 1. ACK hereinkommt gefolgt als nächstes von einer "richtigen" Message, dann würde doch die nächste Nachricht des Nodes verschickt. Wenn nun erst das 2. ACK von der vorherigen Nachricht ankommt, dann gilt die Nachricht als ordnungsgemäß, obwohl vom falschen ACK bestätigt. Ob die Nachricht ankommt ist dann vollkommen unbekannt. Also Abarbeitung durcheinander. -> Verhinderung nur durch fortlaufende CallbackID
Die Prüfung auf richtige Klasse ist hier und in den anderen "xyzAll"-Fällen dann auch zu wenig und wir sind bei Andreas stärker Prüfung. Die würde aber komplexer.
ZitatNur warum gibt es dann die Seriennummer bei ZWCul....
Weil ZWCUL auf dem fortlaufenden Zahl im Telegramm (1-15, wir geben das als SN: aus in ZWCUL) zugreifen kann. Das Wird aber vom ZWDongle verschwiegen, und "unser" CallbackId kommt nur fuer die ACKs zurueck, aber nie fuer die Antworten auf die gets. Die kommen immer mit CB:0
Dein "letzter Strohhalm" ist zwar esoterisch aber richtig. Ich sehe schon, ich werde erst Ruhe kriegen, wenn ich den fortlaufenden CallbackId eingebaut hab :)
Hi,
ich wollte nur mal sagen das ich nichts dazu sage ,-)
Ihr seid ja ganz schön fleissig. Ich werde diese Woche wohl eher nicht mehr zum Testen kommen, und danach bin ich dann wie gesagt so bis Anfang Mai weg.
Gruß,
Andreas
Zitat von: rudolfkoenig am 07 März 2016, 18:08:28
zwar esoterisch aber richtig. Ich sehe schon, ich werde erst Ruhe kriegen, wenn ich den fortlaufenden CallbackId eingebaut hab :)
Habe länger über esoterisch grübeln müssen ;D , aber da Andreas nichts sagt, muss ich wohl alleine weitermachen.
Warum dieser Thread entstand:
Ich wollte endlich den KEYFOB per SECURITY einbinden. Im Produktiv-Netz funktionieren der KEYFOB und der PST01 mit SECURITY aber nicht zufriedenstellend. KEYFOB wahrscheinlich wegen der Ortsveränderungen deutlich schlechter als PST01. Es kommt immer wieder zu Stockungen in der Abarbeitung, die ich auf irgendein Chaos beim Ablauf der Kommunikation zurückführe. Hinweise zu Problemen in der Ablaufsteuerung der Telegramme bei SECURITY gibt es ja bereits mehrere und die betroffenen Geräte waren jeweils WakeUp-Geräte. Also habe ich mir den WakeUp-Sendstack ohne SECURITY vorgenommen und die hier angesprochenen Merkwürdigkeiten festgestellt. Die eingecheckten Änderungen zum Wakeup können aber mMn das SECURITY-Problem nicht gelöst haben. Darum habe ich heute eine Ebene tiefer mit den netzbetriebenen Geräten getestet und befürchte aus den Beobachtungen Probleme im Ablauf, die normalerweise (ohne SECURITY) nicht so schlimm sind, bei SECURITY aber vermutlich zum Abbruch führen.
Vermute eben, dass die fehlende Duplikatserkennung und ggfs. falsche ACK-Zuordnung mit zu den SECURITY Problemen führen. Definitives Wissen ist nicht vorhanden. Ich weiß ja noch nicht einmal, ob die obige 1. 0013er-ACK nicht tatsächlich die 2. 0013er ACK für den vorherigen get-Befehl ist ;) ; vermute, es ist nicht so.
Rudi, wenn meine Gedankengänge tatsächlich daneben liegen, dann bitte Klartext. Und eigentlich gehe ich davon aus, dass Du sowieso nichts einbaust nur um Deine Ruhe zu kriegen. :) "Nein" ist immer OK und Du hast Deine Ruhe.
Gruß, Christian
Hi,
eine kleine Bemerkung doch noch von mir. Ich habe gerade mal meine ganzen Debug-Zeilen wieder rausgenommen und ein paar Mal gespielt, bisher ohne Probleme. Als ich das Senden nach APPLICATION_UPDATE wieder aktiviert habe konnte ich einmal einen Hänger provozieren, dabei ist mir aber eingefallen das ich noch mal das WNMI bei dem Multisensor prüfen wollte.
Und was soll ich sagen, wenn man nicht nach dem APPLICATION_UPDATE sendet sondern nur nach WU, dann funktioniert sogar ein 5 sekunden WNMI-delay! D.h. die "Besonderheit" des Sensors mit dem schnellen Einschlafen gilt nur wenn er gar nicht wirklich wach ist ,-)
Ich lasse das bei mir jetzt mal auf 2 sekunden stehen und schaue ob das auch über längere Zeit funktioniert.
Gruß,
Andreas.
P.S.: Danke Rudi!
Zitat von: rudolfkoenig am 07 März 2016, 17:04:26
- ZWave_versionClassAllGet fuegt beim Empfang einer Anwort ein Class:Version Token zu vclasses, und generiert die naechste get Frage.
Das geht in diesem Fall fuerchterlich schief. Ich habe jetzt die Funktion umgebaut: es werden alle gets am Anfang schon ins Stack gepackt, und beim Empfang wird der passende Token erneuert. Nebeneffekte: vclasses ist alphabetisch sortiert, "get versionClass XX" erzeugt kein Reading mehr, sondern modifiziert vclasses.
Hallo Rudi,
Die versionClassAll-Abfrage wird für Classes die im Attribut classes 2 (vor und hinter MARK) oder mehrmals (defekter NIF-> FGRM222) vorkommen, mehrfach ausgeführt. Bin mir nicht sicher, ob das so sein muss. Habe mal per copy und paste Deine Duplikatslöschung von ein paar Zeilen tiefer kopiert, damit jede Class nur 1x abgefragt wird. Meine Tests damit waren erfolgreich. Der Patch hängt an. Bitte kontrolliere den Patch, da ich nicht behaupten kann, alles zu durchblicken. Wollte aber auch mal direkt Code liefern. ;)
Gruß, Christian
Dein Patch ist einwandfrei, habs eingecheckt.
Zitathabs eingecheckt.
Danke, Rudi.
Zitat von: rudolfkoenig am 07 März 2016, 17:04:26
da das naechste Befehl sowieso erst nach einem "richtigen" Message bzw. seit gestern eins mit der gleichen Klasse weitergeht. Falls man eine Menge von sets hat, dann wuerde die fortlaufende Nummerierung verhindern, dass mehr als ein Befehl weitergeschickt wird. Das macht die Sache vermutlich etwas besser, allerdings sollte das Problem im ZWDongle-Stack abgefangen sein, insofern erwarte ich nach einem Umbau keine wesentliche Besserung. Wenn ich falsch liegen sollte, bitte mich aufklaeren.
Weg von CallbackId: Wenn ich Deine zitierte Aussage korrekt verstanden habe, dann dürften doch die Abläufe in nachfolgenden Logs nicht auftreten!? Es wird jeweils eine neue Nachricht per ZWDongle_Write/SW verschickt, obwohl überhaupt noch keine "richtige" Message als Antwort auf letzte ZWDongle_Write/SW eingetroffen ist. Denn 0013er-ACK ist doch keine "richtige" Nachricht.
2016.03.08 12:31:27.085 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.08 12:31:27.089 5: SW: 010a00130403861370250425
2016.03.08 12:31:27.115 5: ACK received, WaitForAck=>2 for 010a00130403861370250425
2016.03.08 12:31:27.118 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.08 12:31:27.120 5: SW: 06
2016.03.08 12:31:27.135 5: ZWDongle_0 dispatch 011301
2016.03.08 12:31:27.157 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.08 12:31:27.159 5: SW: 06
2016.03.08 12:31:27.174 5: device ack reveived, removing 010a00130403861370250425 from dongle sendstack
2016.03.08 12:31:27.177 5: ZWDongle_0 dispatch 00130400
2016.03.08 12:31:27.180 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.08 12:31:27.183 4: ZWDongle_0 transmit OK for 04
2016.03.08 12:31:29.457 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.08 12:31:29.459 5: SW: 06
2016.03.08 12:31:29.465 5: ZWDongle_0 dispatch 00130400
2016.03.08 12:31:29.469 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.08 12:31:29.471 4: ZWDongle_0 transmit OK for 04
2016.03.08 12:31:29.489 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.08 12:31:29.503 5: SW: 010a0013040386137a25042f2016.03.08 13:01:23.807 5: SW: 010a00131a03861391251ac4
2016.03.08 13:01:23.819 5: ACK received, WaitForAck=>2 for 010a00131a03861391251ac4
2016.03.08 13:01:23.822 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.08 13:01:23.824 5: SW: 06
2016.03.08 13:01:23.829 5: ZWDongle_0 dispatch 011301
2016.03.08 13:01:23.917 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00131a00
2016.03.08 13:01:23.919 5: SW: 06
2016.03.08 13:01:23.923 5: device ack reveived, removing 010a00131a03861391251ac4 from dongle sendstack
2016.03.08 13:01:23.926 5: ZWDongle_0 dispatch 00131a00
2016.03.08 13:01:23.929 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:1a
2016.03.08 13:01:23.931 4: ZWDongle_0 transmit OK for 1a
2016.03.08 13:01:23.940 5: ZWDongle_Write 00131a03861372251a (e345c452)
2016.03.08 13:01:23.944 5: SW: 010a00131a03861372251a27Das sind jeweils Auszüge aus "versionClassAll"-Abfragen. Habe die im normalen Betrieb abgesetzt.
Beim 1. Log gibt es Wiederholungen bei 0013-ACK. Vorher sieht das Log sauber aus.
Beim 2. Log war vorher ZW_SEND_DATA mit "transmit queue overflow" (ZWDongle_0 dispatch 011300) gescheitert und ab da ist es mMn durcheinander.
Rest der Logs kann ich bei Bedarf auch liefern, mir geht es aber erst einmal nur darum, ob ich Deine Aussage richtig verstanden habe. Oder gibt es bei versionClassAll eine Sonderbehandlung, die ich nicht erkenne?
ZitatBeim 1. Log gibt es Wiederholungen bei 0013-ACK. Vorher sieht das Log sauber aus.
Stimmt, duerfte nicht passieren. Die Nachrichten werden bei mir mit < 10ms weitergeschickt, ich frage mich, wie du die 2.5 Sekunden hingekriegt hast. Jaja, ich stll schon noch auf fortlaufende IDs um, bei so einem Chaos ist das sicher angebracht :) Kannst du bitte vorne in ZWave_processSendStack ein
Log 4, "processSendStack ".$ss->[0];einfuegen, und es nochmal probieren?
ZitatBeim 2. Log war vorher ZW_SEND_DATA mit "transmit queue overflow" (ZWDongle_0 dispatch 011300) gescheitert und ab da ist es mMn durcheinander.
Huch: woher weisst du das mit "transmit queue overflow" ?
Zitatwoher weisst du das mit "transmit queue overflow" ?
INS/OZW
01 13 00/01Bei einem Response (01), auch bei ZW_SEND_DATA (13), ist der Rückgabewert von 01 der "Gut"-Fall und 00 der "Schlecht"-Fall (s. auch 00_ZWDongle.pm). Dokumentiert ist für ZW_SEND_DATA nur der Schlechtfall 00 mit "if transmit queue overflow".
Bei einem Request (00) ist das Schema bspw. "00 13 xx 00/01" der Rückgabewerte für Gut/Schlecht bzw. Wahr/Falsch genau umgedreht. Warum auch immer.
Zitat
Die Nachrichten werden bei mir mit < 10ms weitergeschickt, ich frage mich, wie du die 2.5 Sekunden hingekriegt hast.
Das ist sicherlich der Normalfall mit wenigen Routern und Geräten an festen Positionen. Der Node vom 1. Log ist aber nur über min. 2 Router-Zwischenstationen erreichbar, schließe ich aus örtlicher Lage und den Ergebnissen von ZW_AreNodesNeighbours. Wenn dann noch mehrfache Sendeversuche und Explorer Frames dazukommen, sind 2.5 Sekunden zumindest laut ozw-Mailing List nicht ungewöhnlich. Habe es schon 3 oder 4x so durch Zwischen-Router stromlos machen hinbekommen und probiere es mit Deiner Log-Ergänzung auch noch mal. Habe auch schon probiert mit ZWCul mitzuloggen, um meine Theorie bestätigen zu können. Gelingt mir aber nicht sauber.
Die Class CRC_16_ENCAP führt heute bei "versionClassAll" zu dieser Warnung:
2016.03.08 20:56:01.639 1: PERL WARNING: Argument "CRC_16_ENCAP" isn't numeric in sprintf at ./FHEM/10_ZWave.pm line 1604.
2016.03.08 20:56:01.642 3: stacktrace:
2016.03.08 20:56:01.645 3: main::__ANON__ called by ./FHEM/10_ZWave.pm (1604)
2016.03.08 20:56:01.648 3: main::ZWave_versionClassGet called by (eval 270) (1)
2016.03.08 20:56:01.651 3: (eval) called by ./FHEM/10_ZWave.pm (840)
2016.03.08 20:56:01.654 3: main::ZWave_Cmd called by ./FHEM/10_ZWave.pm (923)
2016.03.08 20:56:01.657 3: main::ZWave_SCmd called by ./FHEM/10_ZWave.pm (928)
2016.03.08 20:56:01.659 3: main::ZWave_Get called by ./FHEM/10_ZWave.pm (1624)
2016.03.08 20:56:01.662 3: main::ZWave_versionClassAllGet called by (eval 265) (1)
2016.03.08 20:56:01.665 3: (eval) called by ./FHEM/10_ZWave.pm (840)
2016.03.08 20:56:01.668 3: main::ZWave_Cmd called by ./FHEM/10_ZWave.pm (923)
2016.03.08 20:56:01.671 3: main::ZWave_SCmd called by ./FHEM/10_ZWave.pm (928)
2016.03.08 20:56:01.673 3: main::ZWave_Get called by fhem.pl (3148)
2016.03.08 20:56:01.676 3: main::CallFn called by fhem.pl (1638)
2016.03.08 20:56:01.678 3: main::CommandGet called by fhem.pl (1067)
2016.03.08 20:56:01.681 3: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2185)
2016.03.08 20:56:01.684 3: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (713)
2016.03.08 20:56:01.687 3: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (446)
2016.03.08 20:56:01.689 3: main::FW_Read called by fhem.pl (3148)
2016.03.08 20:56:01.691 3: main::CallFn called by fhem.pl (654)
2016.03.08 20:56:01.694 2: ZWave get ZWave_SENSOR_BINARY_18 versionClass CRC_16_ENCAP
Nächste Problem :-[
Ich weiß jetzt wieder, warum APPLICATION_UPDATE wie wakeupNotification behandelt wurde. Der Fibaro FGMS-001 signalisiert über ZW_APPLICATION_UPDATE ein manuelles wakeup. Ein wakeupNotfication kommt nicht. Derzeit kann man den also nicht manuell aufwecken, was mehr als schlecht ist. Und das wird vermutlich noch mehr Geräte treffen
2016.03.08 21:42:41.477 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984120f042001308485808f567286708e319c
2016.03.08 21:42:41.483 5: SW: 06
2016.03.08 21:42:41.488 5: ZWDongle_0 dispatch 004984120f042001308485808f567286708e319c
2016.03.08 21:42:41.492 4: CMD:ZW_APPLICATION_UPDATE ID:12 ARG:0f042001308485808f567286708e319c CB:84
Andreas, wie sieht beim Aeotec Multisensor 6 das störende APPLICATION_UPDATE aus, das nicht zum wakeUp des Sensors führt?
Habe es schon gefunden, hattest Du schon gepostet:
2016.03.05 09:11:02.204 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
Unterschied???
Hi,
Zitat von: krikan am 08 März 2016, 21:53:33
Nächste Problem :-[
Ich weiß jetzt wieder, warum APPLICATION_UPDATE wie wakeupNotification behandelt wurde. Der Fibaro FGMS-001 signalisiert über ZW_APPLICATION_UPDATE ein manuelles wakeup. Ein wakeupNotfication kommt nicht. Derzeit kann man den also nicht manuell aufwecken, was mehr als schlecht ist. Und das wird vermutlich noch mehr Geräte treffen
ich sag' doch Ihr wolltet das behalten...
Ich wäre aber wie gesagt dann doch dafür das bei diesen Geräten per Attribut zu aktivieren, es entspricht ja nun wirklich nicht der Spezifikation.
Zitat von: krikan am 08 März 2016, 21:53:33
Andreas, wie sieht beim Aeotec Multisensor 6 das störende APPLICATION_UPDATE aus, das nicht zum wakeUp des Sensors führt?
Das Problem ist ja zum einen das die WUN auch noch kommt und alles durcheinander bringt und das der Sensor wenn er nach dem APPLICATION_UPDATE kommuniziert so schnell wieder einschläft, da er ja offiziell gar nicht eingeschlafen ist.
Ich habe mir das noch nicht soo genau angesehen, aber wenn der Stack leer ist müsste der eigentlich eine WNMI bekommen BEVOR er die WUN verschickt hat...
Argl, können die sich nicht einfach mal an die eigenen Regeln halten?
Ich habe gerade noch mal das Senden nach APPLICATION_UPDATE noch mal aktiviert und bekomme danach trotz der ganzen Änderugen immer noch Fehler (getestet mit configAll). CAN und no_response und es werden teilweise configs nicht empfangen, der Sendstack ist danach aber leer... Das ist auch nicht schön...
Nur mit WUN scheint es aber einwandfrei zu funktionieren. Na ja, ich kann mich leider nicht wirklich darum kümmern und vertrau mal ganz auf euch! ,-)
Gruß,
Andreas.
Zitat von: A.Harrenberg am 08 März 2016, 22:40:20
Ich wäre aber wie gesagt dann doch dafür das bei diesen Geräten per Attribut zu aktivieren, es entspricht ja nun wirklich nicht der Spezifikation.
Bei welchen Geräten entspricht das nicht der Spezifikation? Bisher hatten wir die Probleme meines Wissen nach nur mit dem Aeotec Multisensor 6 :P . Also sollten wir dem doch ein Attribut verpassen. ozw nimmt ZW_APPLICATION_UPDATE auch als wakeUp-Kennzeichen. Also ganz so falsch können wir nicht liegen. :)
Zitat von: rudolfkoenig am 08 März 2016, 17:31:39
Kannst du bitte vorne in ZWave_processSendStack ein
Log 4, "processSendStack ".$ss->[0];
einfuegen, und es nochmal probieren?
Habe das so gemacht:
sub
ZWave_processSendStack($$;$)
{
my ($hash,$ackType, $omsg) = @_;
my $ss = $hash->{SendStack};
return if(!$ss);
Log 4, "processSendStack ".$ss->[0];
Das ist aber vermutlich nicht OK, da ich den Log-Eintrag nie bekomme...
Hi Christian,
Zitat von: krikan am 08 März 2016, 22:55:15
Bei welchen Geräten entspricht das nicht der Spezifikation? Bisher hatten wir die Probleme meines Wissen nach nur mit dem Aeotec Multisensor 6 :P . Also sollten wir dem doch ein Attribut verpassen. ozw nimmt ZW_APPLICATION_UPDATE auch als wakeUp-Kennzeichen. Also ganz so falsch können wir nicht liegen. :)
das war wohl eher ironisch gemeint, oder? Auch wenn OZW das als WU interpretiert bedeutet ja nicht das es so richtig bzw. konform ist.
Wenn es Geräte gibt die konform eine WUN melden wenn man sie manuell aufweckt (nach dem sie APPLICATION_UPDATE gesendet haben) und welche die bei manuellem Aufwecken nur APPLICATION_UPDATE aber keine WUN melden fällt es mir leicht zu entscheiden wer der Sonderfall ist und das Attribut bekommen sollte ;-)
Letztendlich ist es (mir) aber egal, es sollte mMn aber konfigurierbar sein. Kann sein das es vielleicht sogar mehr Geräte gibt die das "falsch" machen als solche die es "richtig" machen. Da das bisherige Verhalten der "Standard" war, könnte es aus User Sicht auch wirklich besser sein das Attribut einzuführen wenn der bisherige Standard eben nicht mehr gilt.
Problematisch an der Sache sind ja zwei Sachen. Die Sensoren senden meist nach dem APPLICATION_UPADATE noch ein paar Statuswerte, wenn FHEM da direkt anfängt zu senden sind die CAN vorprogrammiert. Das zweite ist das Einschlafen, das ja vielleicht in wirklichkeit auch nur "ignorieren" auf Seite des Sensors ist?
Aber wie gesagt, ganz egal, ich hätte das nur gerne konfigurierbar, ob man das ein- oder ausschalten muss ist egal.
Gruß,
Andreas.
Zitatdas war wohl eher ironisch gemeint, oder? Auch wenn OZW das als WU interpretiert bedeutet ja nicht das es so richtig bzw. konform ist.
Ja und nein. Ich habe keine Ahnung, ob ozw es richtig macht und ich mag bei meinem Nachwuchs die Aussage "Der macht das aber auch" nicht ;). Ehrlicherweise müsste ich mir den Ablauf in ozw dann genauer anschauen. Mir fällt nur auf, dass es bisher nie Probleme mit dem Thema gab außer beim AEOTEC MS 6. Lösung ist mir ebenfalls egal :) Nur ist es mMn besser dem Sonderfall das Attribut zu geben als dem Regelfall. Was Regelfall/Sonderfall ist, müsste man noch herausfinden. Meine derzeitige Vermutung kennst Du. ;)
Habe bisher nicht wahrgenommen, dass APPLICATION_UPDATE eine unsolicited Message ist. Dem scheint ja beim MS 6 so zu sein. Ich hatte APPLICATION_UPDATE, das den NIF beinhaltet, als manuell angeforderte Nachricht betrachtet. In meinem Gedankengang ist das die gleiche Nachricht, die auch bei der Inklusion verschickt wird und dann ist der Sensor auch länger wach. Aber das sind alles nicht erprobte und hinterfragte Schlußfolgerungen. Hast Du weitere Infos dazu?
Hi Christian,
Zitat von: krikan am 09 März 2016, 08:02:26
Ja und nein. Ich habe keine Ahnung, ob ozw es richtig macht und ich mag bei meinem Nachwuchs die Aussage "Der macht das aber auch" nicht ;). Ehrlicherweise müsste ich mir den Ablauf in ozw dann genauer anschauen. Mir fällt nur auf, dass es bisher nie Probleme mit dem Thema gab außer beim AEOTEC MS 6. Lösung ist mir ebenfalls egal :) Nur ist es mMn besser dem Sonderfall das Attribut zu geben als dem Regelfall. Was Regelfall/Sonderfall ist, müsste man noch herausfinden. Meine derzeitige Vermutung kennst Du. ;)
meine kennst du auch :-)
Wie gesagt, technisch ist es egal wie herum man das Attribut anwenden würde, das wäre eine Glaubensfrage.
Keine Probleme gab es wahrscheinlich bisher nur deshalb weil nur sehr selten so viele Nachrichten im Stack liegen und das erst mit ConfigAll so "einfach" ist. Von der Spezifikation ist recht klar das man auf ein WUN warten soll bis man was sendet, die APPLICATION_UPDATE ist mMn etwas das ein Update bzw. eine Änderung im NIF ankündigen soll. Aber das Ding ist leider sehr schlecht dokumentiert, hier ist mehr raten als wissen vorhanden...
Zitat von: krikan am 09 März 2016, 08:02:26
Habe bisher nicht wahrgenommen, dass APPLICATION_UPDATE eine unsolicited Message ist. Dem scheint ja beim MS 6 so zu sein. Ich hatte APPLICATION_UPDATE, das den NIF beinhaltet, als manuell angeforderte Nachricht betrachtet. In meinem Gedankengang ist das die gleiche Nachricht, die auch bei der Inklusion verschickt wird und dann ist der Sensor auch länger wach. Aber das sind alles nicht erprobte und hinterfragte Schlußfolgerungen. Hast Du weitere Infos dazu?
Also eine Nachricht die per Taster ausgelöst wird und nicht mehr (Funk-) Anfrage ist für mich "unsolicited" ;-) Jedenfalls aus Sicht des Empfängers. Das ist definitiv keine Antwort auf eine Frage.
WARUM APPLICATION_UPDATE überhaupt versendet wird ist mir nicht klar, meine Geräte senden jeweils den gleichen Block wie bei der Inklusion.
Jedenfalls ist die ganze Diskussion müssig, für den FGMS braucht Ihr das, also muss es wieder rein. Da das bisher das Standardverhalten war (und OZW es auch so macht) ist es wahrscheinlich besser das auch so als Standard drin zu lassen. Falls ich Rudi überzeugen kann dann hätte ich gerne ein Attribut um das auszblenden. ,-)
Wenn ich wieder zurück bin werde ich mir mal diese ganzen Application Dokumente ansehen und schauen ob wir da mehr zu diesen Themen finden können.
Gruß,
Andreas.
Nach durchlesen eurer Argumente:
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.
Andreas kann sich damit troesten, dass er jetzt kein WNMI_delay mehr braucht.
ZitatDas ist aber vermutlich nicht OK, da ich den Log-Eintrag nie bekomme...
Sorry, klar: Log haengt vom global verbose ab, und das ist per default 3. Versuch mal an gleicher Stelle mit:
Log 1, "processSendStack ".$ss->[0];ZitatPERL WARNING: Argument "CRC_16_ENCAP" isn't numeric in sprintf at ./FHEM/10_ZWave.pm line 1604.
Habs gefixt.
ZitatDokumentiert ist für ZW_SEND_DATA nur der Schlechtfall 00 mit "if transmit queue overflow".
D.h. bei FHEM stand in so einem Fall im Log:
ZitatERROR: cannot SEND_DATA to XXX: 00
Habe das 00 nach "transmit queue overflow" geaendert.
Hi Rudi,
Zitat von: rudolfkoenig am 09 März 2016, 09:19:08
Nach durchlesen eurer Argumente:Andreas kann sich damit troesten, dass er jetzt kein WNMI_delay mehr braucht.
ist ja eher das durch das Senden der Statusnachrichten nach APPLICATION_UPDATE und dem Sender der WUN vom Sensor, das "verfrühte" Senden von FHEM gestört wird.
Ich bekomme ja nach wie vor CAN und no_response Nachrichten wenn nach APPLICATION_UPDATE gesendet wird. Ob ich ein WNMI_delay brauche oder ein NO_ACK auf die WNMI bekomme weil das Ding schon eingeschlafen ist, ist mir herzlich egal. Das hat ja keine funktionale Auswirkung. Wenn aber durch das Durcheinander sogar Nachrichten verlorengehen, dann ist das was ganz anderes.
Aber schon mal Danke für das ganze hin-und-her bauen. Ich kann mir das aber dann erst im Mai richtig anschauen.
Gruß,
Andreas.
Danke für die Codeanpassungen.
Habe gerade Schnelltest mit Log-Änderung gemacht. Das 2x 0013-ACK habe ich noch nicht nachstellen können, da mir die Zeit fehlt. Hier mal ein Log bei dem nach dem ersten CAN mit fast 1Sek Pause(?) nach meinem Eindruck alles durcheinander läuft. Frage mich auch, ob ein zu stark belasteter FHEM-Server auf den seltsamen Ablauf Einluß haben könnte.
2016.03.09 13:31:32.005 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass ASSOCIATION
2016.03.09 13:31:32.010 1: processSendStack get:1304038613852504
2016.03.09 13:31:32.015 5: ZWDongle_Write 001304038613852504 (e345c452)
2016.03.09 13:31:32.022 5: SW: 010a001304038613852504d0
2016.03.09 13:31:32.061 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass CONFIGURATION
2016.03.09 13:31:32.094 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass FIRMWARE_UPDATE_MD
2016.03.09 13:31:32.122 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 13:31:32.148 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 13:31:32.174 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_SPECIFIC
2016.03.09 13:31:32.200 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 13:31:32.223 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 13:31:32.244 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass POWERLEVEL
2016.03.09 13:31:32.266 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass PROTECTION
2016.03.09 13:31:32.289 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SCENE_ACTIVATION
2016.03.09 13:31:32.313 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 13:31:32.342 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 13:31:32.370 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.401 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.431 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 13:31:32.456 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_MULTILEVEL
2016.03.09 13:31:32.477 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass VERSION
2016.03.09 13:31:32.535 5: ACK received, WaitForAck=>2 for 010a001304038613852504d0
2016.03.09 13:31:32.537 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:32.539 5: SW: 06
2016.03.09 13:31:32.544 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:32.566 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:32.568 5: SW: 06
2016.03.09 13:31:32.572 5: device ack reveived, removing 010a001304038613852504d0 from dongle sendstack
2016.03.09 13:31:32.575 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:32.579 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:32.581 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:32.587 1: processSendStack sentget:1304038613852504
2016.03.09 13:31:32.598 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 13:31:32.600 5: SW: 06
2016.03.09 13:31:32.605 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 13:31:32.610 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 13:31:32.616 1: processSendStack sentackget:1304038613852504
2016.03.09 13:31:32.622 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.09 13:31:32.628 5: SW: 010a00130403861370250425
2016.03.09 13:31:32.643 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.09 13:31:33.572 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 13:31:33.574 5: SW: 06
2016.03.09 13:31:33.580 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 13:31:33.583 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 13:31:33.588 1: processSendStack sentget:1304038613702504
2016.03.09 13:31:33.593 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.09 13:31:33.597 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130403861370250425
2016.03.09 13:31:33.598 5: SW: 010a00130403861370250425
2016.03.09 13:31:33.611 5: ACK received, WaitForAck=>2 for 010a00130403861370250425
2016.03.09 13:31:33.613 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:33.615 5: SW: 06
2016.03.09 13:31:33.619 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:33.664 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:33.667 5: SW: 06
2016.03.09 13:31:33.670 5: device ack reveived, removing 010a00130403861370250425 from dongle sendstack
2016.03.09 13:31:33.673 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:33.676 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:33.678 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:33.683 1: processSendStack sentget:13040386137a2504
2016.03.09 13:31:33.687 5: SW: 010a0013040386137a25042f
2016.03.09 13:31:33.698 5: ACK received, WaitForAck=>2 for 010a0013040386137a25042f
2016.03.09 13:31:33.700 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:33.702 5: SW: 06
2016.03.09 13:31:33.707 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:33.719 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147001
2016.03.09 13:31:33.721 5: SW: 06
2016.03.09 13:31:33.725 5: ZWDongle_0 dispatch 000400040486147001
2016.03.09 13:31:33.728 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147001 CB:00
2016.03.09 13:31:33.734 1: processSendStack sentackget:13040386137a2504
2016.03.09 13:31:33.739 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 13:31:33.743 4: no response from device, removing 010a0013040386137a25042f from dongle sendstack
2016.03.09 13:31:33.745 5: SW: 010a001304038613912504c4
2016.03.09 13:31:33.758 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 13:31:33.761 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:33.762 5: SW: 06
2016.03.09 13:31:33.767 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:33.774 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:33.775 1: processSendStack sentget:1304038613912504
2016.03.09 13:31:33.780 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 13:31:34.146 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:34.148 5: SW: 06
2016.03.09 13:31:34.152 5: device ack reveived, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 13:31:34.155 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:34.159 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:34.162 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:34.168 1: processSendStack sentget:1304038613912504
2016.03.09 13:31:34.172 5: SW: 010a001304038613912504c4
2016.03.09 13:31:34.187 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 13:31:34.189 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:34.191 5: SW: 06
2016.03.09 13:31:34.196 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:34.807 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486149101
2016.03.09 13:31:34.809 5: SW: 06
2016.03.09 13:31:34.814 5: ZWDongle_0 dispatch 000400040486149101
2016.03.09 13:31:34.818 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486149101 CB:00
2016.03.09 13:31:34.823 1: processSendStack sentackget:1304038613912504
2016.03.09 13:31:34.829 5: ZWDongle_Write 001304038613722504 (e345c452)
2016.03.09 13:31:34.833 4: no response from device, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 13:31:34.836 5: SW: 010a00130403861372250427
2016.03.09 13:31:34.851 5: ACK received, WaitForAck=>2 for 010a00130403861372250427
2016.03.09 13:31:34.854 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:34.856 5: SW: 06
2016.03.09 13:31:34.861 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:34.868 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:34.870 1: processSendStack sentget:1304038613722504
2016.03.09 13:31:34.875 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.09 13:31:34.916 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:34.919 5: SW: 06
2016.03.09 13:31:34.923 5: device ack reveived, removing 010a00130403861372250427 from dongle sendstack
2016.03.09 13:31:34.926 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:34.930 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:34.932 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:34.938 1: processSendStack sentget:1304038613322504
2016.03.09 13:31:34.943 5: SW: 010a00130403861332250467
2016.03.09 13:31:34.955 5: ACK received, WaitForAck=>2 for 010a00130403861332250467
2016.03.09 13:31:34.957 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:34.958 5: SW: 06
2016.03.09 13:31:34.963 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:35.524 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:35.526 5: SW: 06
2016.03.09 13:31:35.529 5: device ack reveived, removing 010a00130403861332250467 from dongle sendstack
2016.03.09 13:31:35.532 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:35.535 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:35.538 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:35.543 1: processSendStack sentackget:1304038613322504
2016.03.09 13:31:35.549 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.09 13:31:35.555 5: SW: 010a00130403861332250467
2016.03.09 13:31:35.569 5: ACK received, WaitForAck=>2 for 010a00130403861332250467
2016.03.09 13:31:35.572 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:35.574 5: SW: 06
2016.03.09 13:31:35.578 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:36.053 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:36.056 5: SW: 06
2016.03.09 13:31:36.060 5: device ack reveived, removing 010a00130403861332250467 from dongle sendstack
2016.03.09 13:31:36.063 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:36.066 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:36.068 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:36.075 1: processSendStack sentget:1304038613322504
2016.03.09 13:31:40.563 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613322504
2016.03.09 13:31:40.566 1: processSendStack sentackget:1304038613322504
2016.03.09 13:31:40.571 5: ZWDongle_Write 001304038613732504 (e345c452)
2016.03.09 13:31:40.576 5: SW: 010a00130403861373250426
2016.03.09 13:31:40.589 5: ACK received, WaitForAck=>2 for 010a00130403861373250426
2016.03.09 13:31:40.593 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:40.595 5: SW: 06
2016.03.09 13:31:40.600 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:40.629 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:40.630 5: SW: 06
2016.03.09 13:31:40.634 5: device ack reveived, removing 010a00130403861373250426 from dongle sendstack
2016.03.09 13:31:40.637 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:40.639 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:40.642 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:40.647 1: processSendStack sentget:1304038613732504
2016.03.09 13:31:45.588 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613732504
2016.03.09 13:31:45.591 1: processSendStack sentackget:1304038613732504
2016.03.09 13:31:45.596 5: ZWDongle_Write 001304038613752504 (e345c452)
2016.03.09 13:31:45.600 5: SW: 010a00130403861375250420
2016.03.09 13:31:45.615 5: ACK received, WaitForAck=>2 for 010a00130403861375250420
2016.03.09 13:31:45.617 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:45.619 5: SW: 06
2016.03.09 13:31:45.623 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:45.651 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:45.652 5: SW: 06
2016.03.09 13:31:45.656 5: device ack reveived, removing 010a00130403861375250420 from dongle sendstack
2016.03.09 13:31:45.659 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:45.661 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:45.664 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:45.668 1: processSendStack sentget:1304038613752504
2016.03.09 13:31:45.748 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147502
2016.03.09 13:31:45.750 5: SW: 06
2016.03.09 13:31:45.756 5: ZWDongle_0 dispatch 000400040486147502
2016.03.09 13:31:45.759 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147502 CB:00
2016.03.09 13:31:45.765 1: processSendStack sentackget:1304038613752504
2016.03.09 13:31:45.770 5: ZWDongle_Write 0013040386132b2504 (e345c452)
2016.03.09 13:31:45.775 5: SW: 010a0013040386132b25047e
2016.03.09 13:31:45.790 5: ACK received, WaitForAck=>2 for 010a0013040386132b25047e
2016.03.09 13:31:45.793 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:45.795 5: SW: 06
2016.03.09 13:31:45.800 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:46.366 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142b01
2016.03.09 13:31:46.368 5: SW: 06
2016.03.09 13:31:46.372 5: ZWDongle_0 dispatch 000400040486142b01
2016.03.09 13:31:46.376 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142b01 CB:00
2016.03.09 13:31:46.381 1: processSendStack sentget:13040386132b2504
2016.03.09 13:31:46.387 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.09 13:31:46.392 4: no response from device, removing 010a0013040386132b25047e from dongle sendstack
2016.03.09 13:31:46.395 5: SW: 010a00130403861331250464
2016.03.09 13:31:46.413 5: ACK received, WaitForAck=>2 for 010a00130403861331250464
2016.03.09 13:31:46.417 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011300
2016.03.09 13:31:46.419 5: SW: 06
2016.03.09 13:31:46.425 5: ZWDongle_0 dispatch 011300
2016.03.09 13:31:46.434 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_4: 00
2016.03.09 13:31:46.437 1: processSendStack sentget:1304038613312504
2016.03.09 13:31:46.444 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.09 13:31:46.465 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:46.468 5: SW: 06
2016.03.09 13:31:46.472 5: device ack reveived, removing 010a00130403861331250464 from dongle sendstack
2016.03.09 13:31:46.477 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:46.481 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:46.485 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:46.491 1: processSendStack sentget:1304038613312504
2016.03.09 13:31:46.497 5: SW: 010a00130403861331250464
2016.03.09 13:31:46.514 5: ACK received, WaitForAck=>2 for 010a00130403861331250464
2016.03.09 13:31:46.517 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:46.519 5: SW: 06
2016.03.09 13:31:46.524 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:48.550 4: no response from device, removing 010a00130403861331250464 from dongle sendstack
2016.03.09 13:31:51.455 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613312504
2016.03.09 13:31:51.457 1: processSendStack sentackget:1304038613312504
2016.03.09 13:31:51.463 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:51.469 5: SW: 010a00130403861325250470
2016.03.09 13:31:51.484 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:51.704 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:51.706 5: SW: 06
2016.03.09 13:31:51.711 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:51.781 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:51.783 5: SW: 06
2016.03.09 13:31:51.789 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:51.792 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:51.797 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:51.800 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:51.807 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:52.601 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:31:52.603 5: SW: 06
2016.03.09 13:31:52.608 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:31:52.611 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:31:52.613 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:31:56.480 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentackget:1304038613252504
2016.03.09 13:31:56.486 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:56.490 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:56.495 5: SW: 010a00130403861325250470
2016.03.09 13:31:56.506 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:56.508 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:56.510 5: SW: 06
2016.03.09 13:31:56.515 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:57.025 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:57.028 5: SW: 06
2016.03.09 13:31:57.031 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:57.035 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:57.038 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:57.040 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:57.046 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:57.165 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142501
2016.03.09 13:31:57.167 5: SW: 06
2016.03.09 13:31:57.174 5: ZWDongle_0 dispatch 000400040486142501
2016.03.09 13:31:57.178 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142501 CB:00
2016.03.09 13:31:57.186 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:57.192 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.09 13:31:57.197 5: SW: 010a00130403861325250470
2016.03.09 13:31:57.217 5: ACK received, WaitForAck=>2 for 010a00130403861325250470
2016.03.09 13:31:57.220 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:57.222 5: SW: 06
2016.03.09 13:31:57.228 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:57.359 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 13:31:57.361 5: SW: 06
2016.03.09 13:31:57.365 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.09 13:31:57.369 5: ZWDongle_0 dispatch 00130400
2016.03.09 13:31:57.373 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 13:31:57.375 4: ZWDongle_0 transmit OK for 04
2016.03.09 13:31:57.381 1: processSendStack sentget:1304038613252504
2016.03.09 13:31:57.408 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486142501
2016.03.09 13:31:57.410 5: SW: 06
2016.03.09 13:31:57.415 5: ZWDongle_0 dispatch 000400040486142501
2016.03.09 13:31:57.418 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142501 CB:00
2016.03.09 13:31:57.424 1: processSendStack sentackget:1304038613252504
2016.03.09 13:31:57.429 5: ZWDongle_Write 001304038613262504 (e345c452)
2016.03.09 13:31:57.432 5: SW: 010a00130403861326250473
2016.03.09 13:31:57.447 5: ACK received, WaitForAck=>2 for 010a00130403861326250473
2016.03.09 13:31:57.449 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:31:57.451 5: SW: 06
2016.03.09 13:31:57.455 5: ZWDongle_0 dispatch 011301
2016.03.09 13:31:59.976 4: no response from device, removing 010a00130403861326250473 from dongle sendstack
2016.03.09 13:32:02.447 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613262504
2016.03.09 13:32:02.449 1: processSendStack sentget:1304038613262504
2016.03.09 13:32:02.456 5: ZWDongle_Write 001304038613862504 (e345c452)
2016.03.09 13:32:02.461 5: SW: 010a001304038613862504d3
2016.03.09 13:32:02.476 5: ACK received, WaitForAck=>2 for 010a001304038613862504d3
2016.03.09 13:32:02.696 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 13:32:02.698 5: SW: 06
2016.03.09 13:32:02.703 5: ZWDongle_0 dispatch 011301
2016.03.09 13:32:04.127 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:04.129 5: SW: 06
2016.03.09 13:32:04.133 5: device ack reveived, removing 010a001304038613862504d3 from dongle sendstack
2016.03.09 13:32:04.136 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:04.140 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:04.142 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.488 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613862504
2016.03.09 13:32:12.490 1: processSendStack sentget:1304038613862504
2016.03.09 13:32:12.502 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.504 5: SW: 06
2016.03.09 13:32:12.510 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.514 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.516 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.527 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.528 5: SW: 06
2016.03.09 13:32:12.533 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.536 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.537 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.547 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.549 5: SW: 06
2016.03.09 13:32:12.554 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.558 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.560 2: ZWDongle_0 transmit NO_ACK for 04
2016.03.09 13:32:12.570 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130401
2016.03.09 13:32:12.571 5: SW: 06
2016.03.09 13:32:12.576 5: ZWDongle_0 dispatch 00130401
2016.03.09 13:32:12.578 4: CMD:ZW_SEND_DATA ID:01 ARG: CB:04
2016.03.09 13:32:12.580 2: ZWDongle_0 transmit NO_ACK for 04
So hier ein Log mit Ausschalten eines Routers während der Abfrage und 2x 0013-ACK: es geht seltsamerweise auch mit knapp 3 Sekunden Pause.
2016.03.09 18:09:03.073 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass ASSOCIATION
2016.03.09 18:09:03.076 1: processSendStack get:1304038613852504
2016.03.09 18:09:03.079 5: ZWDongle_Write 001304038613852504 (e345c452)
2016.03.09 18:09:03.083 5: SW: 010a001304038613852504d0
2016.03.09 18:09:03.110 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass CONFIGURATION
2016.03.09 18:09:03.137 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass FIRMWARE_UPDATE_MD
2016.03.09 18:09:03.164 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 18:09:03.191 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.09 18:09:03.218 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_SPECIFIC
2016.03.09 18:09:03.247 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 18:09:03.278 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.09 18:09:03.308 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass POWERLEVEL
2016.03.09 18:09:03.338 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass PROTECTION
2016.03.09 18:09:03.368 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SCENE_ACTIVATION
2016.03.09 18:09:03.395 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 18:09:03.417 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.09 18:09:03.438 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.460 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.481 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.09 18:09:03.504 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_MULTILEVEL
2016.03.09 18:09:03.525 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass VERSION
2016.03.09 18:09:03.587 5: ACK received, WaitForAck=>2 for 010a001304038613852504d0
2016.03.09 18:09:03.590 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:03.593 5: SW: 06
2016.03.09 18:09:03.599 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:03.616 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:03.618 5: SW: 06
2016.03.09 18:09:03.622 5: device ack reveived, removing 010a001304038613852504d0 from dongle sendstack
2016.03.09 18:09:03.625 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:03.629 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:03.634 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:03.640 1: processSendStack sentget:1304038613852504
2016.03.09 18:09:03.658 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486148502
2016.03.09 18:09:03.660 5: SW: 06
2016.03.09 18:09:03.667 5: ZWDongle_0 dispatch 000400040486148502
2016.03.09 18:09:03.671 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.09 18:09:03.677 1: processSendStack sentackget:1304038613852504
2016.03.09 18:09:03.683 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.09 18:09:03.688 5: SW: 010a00130403861370250425
2016.03.09 18:09:03.705 5: ACK received, WaitForAck=>2 for 010a00130403861370250425
2016.03.09 18:09:03.707 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:03.709 5: SW: 06
2016.03.09 18:09:03.713 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:06.659 4: no response from device, removing 010a00130403861370250425 from dongle sendstack
2016.03.09 18:09:06.673 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.675 5: SW: 06
2016.03.09 18:09:06.680 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.684 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.686 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.691 1: processSendStack sentget:1304038613702504
2016.03.09 18:09:06.695 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.697 5: SW: 06
2016.03.09 18:09:06.702 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.706 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.708 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.714 1: processSendStack sentackget:1304038613702504
2016.03.09 18:09:06.718 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.09 18:09:06.723 5: SW: 010a0013040386137a25042f
2016.03.09 18:09:06.730 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:06.731 5: SW: 06
2016.03.09 18:09:06.736 5: device ack reveived, removing 010a0013040386137a25042f from dongle sendstack
2016.03.09 18:09:06.739 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:06.742 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:06.744 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:06.749 1: processSendStack sentget:13040386137a2504
2016.03.09 18:09:07.289 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400040486147001
2016.03.09 18:09:07.290 5: SW: 06
2016.03.09 18:09:07.295 5: ZWDongle_0 dispatch 000400040486147001
2016.03.09 18:09:07.299 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147001 CB:00
2016.03.09 18:09:07.304 1: processSendStack sentackget:13040386137a2504
2016.03.09 18:09:07.309 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.09 18:09:07.313 5: SW: 010a001304038613912504c4
2016.03.09 18:09:07.320 5: ACK received, WaitForAck=>2 for 010a001304038613912504c4
2016.03.09 18:09:07.323 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2016.03.09 18:09:07.325 5: SW: 06
2016.03.09 18:09:07.330 5: ZWDongle_0 dispatch 011301
2016.03.09 18:09:07.335 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130400
2016.03.09 18:09:07.336 5: SW: 06
2016.03.09 18:09:07.340 5: device ack reveived, removing 010a001304038613912504c4 from dongle sendstack
2016.03.09 18:09:07.343 5: ZWDongle_0 dispatch 00130400
2016.03.09 18:09:07.347 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.09 18:09:07.349 4: ZWDongle_0 transmit OK for 04
2016.03.09 18:09:07.355 1: processSendStack sentget:1304038613912504
Habe versucht mit anderem PC und ZWCul mitzuloggen. Das gelingt mir komischerweise nicht; empfängt nur sehr vereinzelt Nachrichten. Eventuell weil Router und Dongle 100k; Ziel-Gerät 40k.
Heißt das, mein hier (https://forum.fhem.de/index.php/topic,49752.msg415257.html#msg415257) beschriebenes Problem ist möglicherweise gar keins, weil meine Fenstersensoren sehr wohl aufwachen, sich aber nicht per WUN melden, sondern nur mit APPLICATION_UPDATE? Ich bin schon verzweifelt, weil ich bei keinem einzigen meiner elf Fenstersensoren einen manuellen Wake-Up hinbekommen...
Zitat von: 9zehn75 am 10 März 2016, 10:28:29
Heißt das, mein hier (https://forum.fhem.de/index.php/topic,49752.msg415257.html#msg415257) beschriebenes Problem ist möglicherweise gar keins, weil meine Fenstersensoren sehr wohl aufwachen, sich aber nicht per WUN melden, sondern nur mit APPLICATION_UPDATE? Ich bin schon verzweifelt, weil ich bei keinem einzigen meiner elf Fenstersensoren einen manuellen Wake-Up hinbekommen...
Nein.
APPLICATION_UPDATE führte nur bei einer 10_ZWave.pm, die ca. (ca. weil sorceforge streikt) vom 07.03.16-09.03.16 per update verteilt wurde, nicht zur Abarbeitung des Sendstacks. Vorher und aktuell ist alles in Ordnung.
Zum eigenlichen Topic eine positive Info: Habe gestern abend noch einmal intensiv die WakeUp-Sendstack-Abarbeitung mit dem PST02 ohne Router (Direktverbindung Controller/PST02) getestet. Eine Unterbrechung der Wakeup-Sendstack-Abarbeitung habe ich nur noch einmal erzeugen können, als ich ca. 80(!) Befehle auf den Stack gelegt habe. Ansonsten lief es immer problemlos durch.
Habe die beiden Sendstacks (ZWave/ZWDongle) angepasst:
- doppeltes ACK Bug vermutlich gefixt. Kann nicht testen, da ich die doppelten Acks nicht reproduzieren kann.
- bei 011300 (transmit queue overflow) Retry eingebaut. Das kann theoretisch zu Endlosschleife fuehren, wenn der Dongle nichts anderes antwortet, hoffentlich kommt das aber nicht vor. Wenn doch, dann bauen wir einen Zaehler ein :)
- das Retry-Verhalten bei CAN angepasst.
Ich kann damit beim KFOB ein halbwegs sauberes get versionClassAll verarbeiten. Deswegen halbwegs, weil der KFOB direkt nach Application-Update WUN und battery-report schickt, und da FHEM direkt nach Application-Update die erste Get Frage losschickt, kommt vom Dongle direkt ein CAN, weil WUN/battery gerade empfangen wird. Habe aber keine Idee, woran ich erkennen soll, dass ich erst spaeter senden darf. Bis auf diesem CAN (mAn Schoenheitsfehler) laeuft aber die komplette Abfrage schnell und fehlerfrei durch.
Zitat von: krikan am 10 März 2016, 10:38:58
Nein.
APPLICATION_UPDATE führte nur bei einer 10_ZWave.pm, die ca. (ca. weil sorceforge streikt) vom 07.03.16-09.03.16 per update verteilt wurde, nicht zur Abarbeitung des Sendstacks. Vorher und aktuell ist alles in Ordnung.
Aber das war doch auch gar nicht mein Problem. Mein Problem war (und ist), dass meine Fibaro Fenstersensoren kein WUN senden, wenn ich sie manuell aufwecke. Der Sendstack wird aber scheinbar trotzdem abgearbeitet (was ich aber nicht bemerkte, weil ich immer auf eine WUN wartete).
Zitat von: 9zehn75 am 10 März 2016, 12:56:41
Aber das war doch auch gar nicht mein Problem. Mein Problem war (und ist), dass meine Fibaro Fenstersensoren kein WUN senden, wenn ich sie manuell aufwecke. Der Sendstack wird aber scheinbar trotzdem abgearbeitet (was ich aber nicht bemerkte, weil ich immer auf eine WUN wartete).
Dann mißverstehe ich Dich. Willst Du wissen, ob APPLICATION_UPDATE einer WUN entspricht? Ja, so vermuten wir das. FHEM behandelt APPLICATION_UPDATE deshalb seit langem (mit der 3tägigen Unterbrechung) wie wakeup notification. Genauen Unterschied kennen wir nicht.
@Rudi: Danke
Zitat von: krikan am 10 März 2016, 13:11:57
Dann mißverstehe ich Dich. Willst Du wissen, ob APPLICATION_UPDATE einer WUN entspricht? Ja, so vermuten wir das. FHEM behandelt APPLICATION_UPDATE deshalb seit langem (mit der 3tägigen Unterbrechung) wie wakeup notification. Genauen Unterschied kennen wir nicht.
Ja, genau das war mein Problem. Ich habe stundenlang versucht, bei meinen Fenstersensoren per manuellem Wakeup eine WUN hinzubekommen. Meine damalige Schlussfolgerung war, dass ich sie nicht aufgeweckt bekomme (, weil ich nicht wusste, dass APPLICATION_UPDATE einer WUN entspricht.
Daher hatte ich in oben in Bezug genommenen Beitrag geschrieben:
ZitatIch habe alle Repeater aus meinem Netz geworfen und die Devices in fhem gelöscht. Nun gibt es nur noch einen Controller. Dann habe ich einen Fenstersensor abgebaut und sitze nun seit einer Stunde hier und teste. Wannimmer ich versuche ihn manuell zu wecken, erscheint in seinem Log eine Meldung wie die Folgende:
2016-02-23_21:01:49 Fenster_Keller_Waesche CMD: ZW_APPLICATION_UPDATE
Jetzt bin ich froh, dass scheinbar das WU klappt, nur eben nicht per WUN quittiert wird.
Ich versuche, mich nächstes Mal klarer auszudrücken...
Zitat von: 9zehn75 am 10 März 2016, 16:55:05
Ich versuche, mich nächstes Mal klarer auszudrücken...
Und ich aufmerksamer zu lesen...
Btw.: Öffne am Besten in einem 2. Fenster einen Event Monitor bei solchen Arbeiten. Im "list" erkennst Du auch, ob im Wakeup-Sendstack noch was offen ist. Aber vermutlich ist Dir das jetzt auch schon alles bekannt.
Vorweg: In meinem Tests haben sich die neuen Modul-Fassungen als sehr, sehr stabil erwiesen. Auch wenn ich mich wieder einmal mit den Extremen auseinandersetze. :)
Zitat von: rudolfkoenig am 10 März 2016, 11:42:21
- bei 011300 (transmit queue overflow) Retry eingebaut.
011300 habe ich in 1,5 Stunden Dauerlast kein einziges mehr bekommen. Mit der "alten" Fassung kam das regelmäßig bei Last.
Zitatdoppeltes ACK Bug vermutlich gefixt. Kann nicht testen, da ich die doppelten Acks nicht reproduzieren kann.
Ich kann auch 4x 0013-ACK erzeugen und habe dabei festgestellt, dass auch nach 10(!) Sekunden noch die angeforderte Nachricht kommen kann (Antwort auf 010a001304038613852504d0 ab 18:56:37.930 ff.). Verstehen kann ich einen solch langen Zeitraum zwischen Abfrage und Antwort überhaupt nicht.
Es werden einige Nachrichten nicht per SW verschickt, da anscheinend die 0013-ACKs nicht der richtigen Nachricht zugeordnet werden können (18:57:05.993 ff).
Ganzes Log:
2016.03.10 18:56:26.849 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass ASSOCIATION
2016.03.10 18:56:26.852 5: ZWDongle_Write 001304038613852504 (e345c452)
2016.03.10 18:56:26.867 5: SW: 010a001304038613852504d0
2016.03.10 18:56:26.931 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass CONFIGURATION
2016.03.10 18:56:26.993 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass FIRMWARE_UPDATE_MD
2016.03.10 18:56:27.039 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_PROPRIETARY
2016.03.10 18:56:27.094 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass MANUFACTURER_SPECIFIC
2016.03.10 18:56:27.166 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass METER
2016.03.10 18:56:27.236 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass POWERLEVEL
2016.03.10 18:56:27.290 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass PROTECTION
2016.03.10 18:56:27.335 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SCENE_ACTIVATION
2016.03.10 18:56:27.382 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SENSOR_MULTILEVEL
2016.03.10 18:56:27.436 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_BINARY
2016.03.10 18:56:27.487 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass SWITCH_MULTILEVEL
2016.03.10 18:56:27.542 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 versionClass VERSION
2016.03.10 18:56:27.670 5: ACK received, WaitForAck=>2 for 010a001304038613852504d0
2016.03.10 18:56:27.673 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:56:27.695 5: SW: 06
2016.03.10 18:56:27.700 5: ZWDongle_0 dispatch 011301
2016.03.10 18:56:37.186 4: no response from device, removing 010a001304038613852504d0 from dongle sendstack
2016.03.10 18:56:37.189 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613852504
2016.03.10 18:56:37.197 5: ZWDongle_Write 001304038613702504 (e345c452)
2016.03.10 18:56:37.200 5: SW: 010a00130403861370250425
2016.03.10 18:56:37.911 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:37.924 5: SW: 06
2016.03.10 18:56:37.927 5: device ack reveived, removing 010a00130403861370250425 from dongle sendstack
2016.03.10 18:56:37.930 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:37.943 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:37.945 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:37.952 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:37.965 5: SW: 06
2016.03.10 18:56:37.970 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:37.984 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:37.986 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:37.992 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:38.005 5: SW: 06
2016.03.10 18:56:38.010 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:38.025 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:38.027 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:38.045 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:38.047 5: SW: 06
2016.03.10 18:56:38.052 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:38.056 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:38.057 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:38.079 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486148502, sending ACK
2016.03.10 18:56:38.081 5: SW: 06
2016.03.10 18:56:38.095 5: ZWDongle_0 dispatch 000400040486148502
2016.03.10 18:56:38.098 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.10 18:56:38.116 5: ZWDongle_Write 0013040386137a2504 (e345c452)
2016.03.10 18:56:38.120 5: SW: 010a0013040386137a25042f
2016.03.10 18:56:38.129 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486148502, sending ACK
2016.03.10 18:56:38.131 5: SW: 06
2016.03.10 18:56:38.145 5: ZWDongle_0 dispatch 000400040486148502
2016.03.10 18:56:38.149 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.10 18:56:38.169 5: ZWDongle_Write 001304038613912504 (e345c452)
2016.03.10 18:56:38.186 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486148502, sending ACK
2016.03.10 18:56:38.188 5: SW: 06
2016.03.10 18:56:38.194 5: ZWDongle_0 dispatch 000400040486148502
2016.03.10 18:56:38.198 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.10 18:56:38.217 5: ZWDongle_Write 001304038613722504 (e345c452)
2016.03.10 18:56:38.233 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486148502, sending ACK
2016.03.10 18:56:38.235 5: SW: 06
2016.03.10 18:56:38.246 5: ZWDongle_0 dispatch 000400040486148502
2016.03.10 18:56:38.249 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148502 CB:00
2016.03.10 18:56:38.267 5: ZWDongle_Write 001304038613322504 (e345c452)
2016.03.10 18:56:38.272 5: ACK received, WaitForAck=>2 for 010a0013040386137a25042f
2016.03.10 18:56:38.285 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:56:38.286 5: SW: 06
2016.03.10 18:56:38.290 5: ZWDongle_0 dispatch 011301
2016.03.10 18:56:50.594 4: no response from device, removing 010a0013040386137a25042f from dongle sendstack
2016.03.10 18:56:50.597 5: SW: 010a001304038613912504c4
2016.03.10 18:56:50.602 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:1304038613322504
2016.03.10 18:56:50.607 5: ZWDongle_Write 001304038613732504 (e345c452)
2016.03.10 18:56:50.629 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:50.631 5: SW: 06
2016.03.10 18:56:50.648 5: device ack reveived, removing 010a001304038613912504c4 from dongle sendstack
2016.03.10 18:56:50.652 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:50.656 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:50.658 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:50.688 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486147001, sending ACK
2016.03.10 18:56:50.690 5: SW: 06
2016.03.10 18:56:50.694 5: ZWDongle_0 dispatch 000400040486147001
2016.03.10 18:56:50.697 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147001 CB:00
2016.03.10 18:56:50.714 5: ZWDongle_Write 001304038613752504 (e345c452)
2016.03.10 18:56:50.718 5: SW: 010a00130403861372250427
2016.03.10 18:56:50.735 5: ACK received, WaitForAck=>2 for 010a00130403861372250427
2016.03.10 18:56:50.738 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:56:50.740 5: SW: 06
2016.03.10 18:56:50.754 5: ZWDongle_0 dispatch 011301
2016.03.10 18:56:50.767 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:56:50.774 5: SW: 06
2016.03.10 18:56:50.782 5: device ack reveived, removing 010a00130403861372250427 from dongle sendstack
2016.03.10 18:56:50.790 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:56:50.799 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:56:50.804 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:56:50.822 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486147a01, sending ACK
2016.03.10 18:56:50.827 5: SW: 06
2016.03.10 18:56:50.839 5: ZWDongle_0 dispatch 000400040486147a01
2016.03.10 18:56:50.848 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147a01 CB:00
2016.03.10 18:56:50.873 5: ZWDongle_Write 0013040386132b2504 (e345c452)
2016.03.10 18:56:50.883 5: SW: 010a00130403861332250467
2016.03.10 18:56:50.896 5: ACK received, WaitForAck=>2 for 010a00130403861332250467
2016.03.10 18:56:50.898 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:56:50.901 5: SW: 06
2016.03.10 18:56:50.915 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:04.825 4: no response from device, removing 010a00130403861332250467 from dongle sendstack
2016.03.10 18:57:04.826 5: SW: 010a00130403861373250426
2016.03.10 18:57:04.834 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_4 after 5s for sentget:13040386132b2504
2016.03.10 18:57:04.837 5: ZWDongle_Write 001304038613312504 (e345c452)
2016.03.10 18:57:05.836 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:05.837 5: SW: 06
2016.03.10 18:57:05.840 5: device ack reveived, removing 010a00130403861373250426 from dongle sendstack
2016.03.10 18:57:05.843 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:05.856 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:05.857 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:05.863 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486149101, sending ACK
2016.03.10 18:57:05.875 5: SW: 06
2016.03.10 18:57:05.879 5: ZWDongle_0 dispatch 000400040486149101
2016.03.10 18:57:05.881 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486149101 CB:00
2016.03.10 18:57:05.898 5: ZWDongle_Write 001304038613252504 (e345c452)
2016.03.10 18:57:05.901 5: SW: 010a00130403861375250420
2016.03.10 18:57:05.924 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.10 18:57:05.927 5: ACK received, WaitForAck=>2 for 010a00130403861375250420
2016.03.10 18:57:05.929 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:57:05.930 5: SW: 06
2016.03.10 18:57:05.946 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:05.949 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:05.950 5: SW: 06
2016.03.10 18:57:05.964 5: device ack reveived, removing 010a00130403861375250420 from dongle sendstack
2016.03.10 18:57:05.966 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:05.968 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:05.970 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:05.988 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:05.989 5: SW: 06
2016.03.10 18:57:05.993 5: device ack reveived, removing 010a0013040386132b25047e from dongle sendstack
2016.03.10 18:57:05.996 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:05.998 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:06.000 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:06.015 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:06.016 5: SW: 06
2016.03.10 18:57:06.024 5: device ack reveived, removing 010a00130403861331250464 from dongle sendstack
2016.03.10 18:57:06.026 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:06.028 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:06.030 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:06.045 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:06.046 5: SW: 06
2016.03.10 18:57:06.055 5: device ack reveived, removing 010a00130403861325250470 from dongle sendstack
2016.03.10 18:57:06.057 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:06.060 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:06.061 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:06.076 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486143202, sending ACK
2016.03.10 18:57:06.078 5: SW: 06
2016.03.10 18:57:06.084 5: ZWDongle_0 dispatch 000400040486143202
2016.03.10 18:57:06.087 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486143202 CB:00
2016.03.10 18:57:06.092 5: ZWDongle_Write 001304038613262504 (e345c452)
2016.03.10 18:57:06.106 5: SW: 010a00130403861326250473
2016.03.10 18:57:06.115 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486143202, sending ACK
2016.03.10 18:57:06.116 5: SW: 06
2016.03.10 18:57:06.124 5: ZWDongle_0 dispatch 000400040486143202
2016.03.10 18:57:06.127 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486143202 CB:00
2016.03.10 18:57:06.132 5: ZWDongle_Write 001304038613862504 (e345c452)
2016.03.10 18:57:06.157 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486143202, sending ACK
2016.03.10 18:57:06.158 5: SW: 06
2016.03.10 18:57:06.162 5: ZWDongle_0 dispatch 000400040486143202
2016.03.10 18:57:06.165 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486143202 CB:00
2016.03.10 18:57:06.185 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486143202, sending ACK
2016.03.10 18:57:06.187 5: SW: 06
2016.03.10 18:57:06.190 5: ZWDongle_0 dispatch 000400040486143202
2016.03.10 18:57:06.204 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486143202 CB:00
2016.03.10 18:57:06.208 5: ACK received, WaitForAck=>2 for 010a00130403861326250473
2016.03.10 18:57:06.210 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:57:06.212 5: SW: 06
2016.03.10 18:57:06.221 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:06.234 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:57:06.236 5: SW: 06
2016.03.10 18:57:06.240 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:14.256 4: no response from device, removing 010a00130403861326250473 from dongle sendstack
2016.03.10 18:57:14.258 5: SW: 010a001304038613862504d3
2016.03.10 18:57:15.149 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:15.150 5: SW: 06
2016.03.10 18:57:15.165 5: device ack reveived, removing 010a001304038613862504d3 from dongle sendstack
2016.03.10 18:57:15.167 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:15.170 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:15.172 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:15.186 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486147301, sending ACK
2016.03.10 18:57:15.187 5: SW: 06
2016.03.10 18:57:15.195 5: ZWDongle_0 dispatch 000400040486147301
2016.03.10 18:57:15.197 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486147301 CB:00
2016.03.10 18:57:15.201 4: ZWDongle_Read ZWDongle_0: CAN received
2016.03.10 18:57:15.213 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:57:15.215 5: SW: 06
2016.03.10 18:57:15.219 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:15.222 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:15.234 5: SW: 06
2016.03.10 18:57:15.238 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:15.240 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:15.242 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:15.257 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486142603, sending ACK
2016.03.10 18:57:15.258 5: SW: 06
2016.03.10 18:57:15.262 5: ZWDongle_0 dispatch 000400040486142603
2016.03.10 18:57:15.274 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486142603 CB:00
2016.03.10 18:57:15.279 4: ZWDongle_Read ZWDongle_0: rcvd 011301, sending ACK
2016.03.10 18:57:15.280 5: SW: 06
2016.03.10 18:57:15.295 5: ZWDongle_0 dispatch 011301
2016.03.10 18:57:26.077 4: ZWDongle_Read ZWDongle_0: rcvd 00130400, sending ACK
2016.03.10 18:57:26.078 5: SW: 06
2016.03.10 18:57:26.094 5: ZWDongle_0 dispatch 00130400
2016.03.10 18:57:26.097 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:04
2016.03.10 18:57:26.098 4: ZWDongle_0 transmit OK for 04
2016.03.10 18:57:26.103 4: ZWDongle_Read ZWDongle_0: rcvd 000400040486148601, sending ACK
2016.03.10 18:57:26.106 5: SW: 06
2016.03.10 18:57:26.109 5: ZWDongle_0 dispatch 000400040486148601
2016.03.10 18:57:26.125 4: CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0486148601 CB:00
Zitat von: krikan am 10 März 2016, 21:27:12
Es werden einige Nachrichten nicht per SW verschickt, da anscheinend die 0013-ACKs nicht der richtigen Nachricht zugeordnet werden können (18:57:05.993 ff).
011301-Prüfung fehlt bei den nicht versandten Nachrichten ganz.
Noch mal zum letzten Log:
Da ich die langen Pausen im Log nicht verstehe und immer auch noch Hardware-/Systemprobleme befürchte, habe ich diese Nacht das Modul "perfmon" laufen lassen. Es sind keine "freezes" angefallen. Hatte ich bald auch nicht anders erwartet, da ich solche langen Pausen zwischen den Nachrichten bisher im system noch nicht beobachtet hatte und auch nur dieses eine Mal festgestellt habe. Also betrachte ich das Log als Ausnahme. Ich erkenne im Log keine fehlenden (verschluckten) Nachrichten, so dass ich das Log als falsch/fehlerhaft verwerfen kann. Für mein Verständnis ist die Nachrichtenabfolge/Logeintragfolge logisch nachvollziehbar nur die Zeitstempel machen mich stutzig.
Zitat011301-Prüfung fehlt bei den nicht versandten Nachrichten ganz.
Stimmt. Falls wir das brauchen, werde ich es einbauen. Als naechstes kommt aber die fortlaufende CallbackId.
Zitat von: rudolfkoenig am 11 März 2016, 09:10:18
Stimmt. Falls wir das brauchen, werde ich es einbauen.
Brauchen? Tendiere zu unnötig, Hauptsache der Fehlerfall 011300 wird mit Resend behandelt.
Im Übrigen hast Du die nächsten ca. 1,5 Wochen wegen anderweitiger Verpflichtung Ruhe vor meinen Extremtests :) .
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 zusammen,
anbei, wie von Christian hier (https://forum.fhem.de/index.php/topic,50874.msg425609.html#msg425609) angeregt, ein paar Infos/logs mit gesetztem Attribut "noWakeupForApplicationUpdate" bei einem Aeotec Multisensor 6, bei dem es bei einem wakeup zu NO_ACKS kommt:
List:
Internals:
DEF d79c8805 86
IODev ZW_Dongle
LASTInputDev ZW_Dongle
MSGCNT 242
NAME ZWave_SENSOR_MULTILEVEL_86
NR 581
STATE nomotion
TYPE ZWave
ZW_Dongle_MSGCNT 242
ZW_Dongle_RAWMSG 00040056028407
ZW_Dongle_TIME 2016-03-16 17:29:23
homeId d79c8805
isWakeUp 1
lastMsgSent 1458145763.4927
nodeIdHex 56
Readings:
2016-02-24 13:09:27 CMD ZW_APPLICATION_UPDATE
2016-03-16 16:32:48 alarm HomeSecurity: Previous Events cleared, arg 0000
2016-02-14 12:18:32 assocGroup_1 Max 5 Nodes ZW_Dongle
2016-02-14 12:18:32 assocGroups 1
2016-03-16 17:29:23 battery 100 %
2016-02-14 09:02:45 configBatteryReportingThreshold 5
2016-02-14 09:02:45 configCommandOptions BinarySensorReport
2016-02-14 09:02:45 configEnableDisableLockConfiguration Disable
2016-02-14 09:02:45 configEnableMotionSensor EnabledLevel1MinimumSensitivity
2016-02-14 10:18:51 configGroup1Interval 900
2016-02-14 09:02:45 configGroup1Reports 241
2016-02-14 09:02:45 configGroup2Interval 3600
2016-02-14 09:02:45 configGroup2Reports 0
2016-02-14 09:02:45 configGroup3Interval 3600
2016-02-14 09:02:46 configGroup3Reports 0
2016-02-14 09:02:46 configHumidityCalibration 0
2016-02-14 09:02:46 configHumidityReportingThreshold 5
2016-02-14 09:02:46 configLowBattery 20
2016-02-14 09:02:46 configLowTempAlarm Disabled
2016-02-14 09:02:46 configLuminanceCalibration 0
2016-02-19 13:32:30 configLuminanceReportingThreshold 100
2016-02-19 09:57:30 configOnTime 45
2016-02-14 09:02:46 configReportingThreshold Enabled
2016-02-14 09:02:46 configTemperatureCalibration 218
2016-02-14 09:02:46 configTemperatureReportingThreshold 5
2016-02-14 09:02:46 configUVReportingThreshold 2
2016-02-14 09:02:46 configUltravioletCalibration 0
2016-02-14 09:02:46 configWakeUp10MinutesOnPowerOn Yes
2016-03-16 17:29:21 fp_TempHumMot 13.6 C / 26 % / nomotion
2016-03-16 17:29:22 humidity 26 %
2016-03-16 16:59:22 humidity_num 26
2016-03-16 17:29:23 luminance 6657 Lux
2016-02-14 08:59:12 model Aeotec MultiSensor 6
2016-02-14 08:59:12 modelConfig aeotec/multisensor6.xml
2016-02-14 08:59:12 modelId 0086-0002-0064
2016-03-16 16:32:48 reportedState closed
2016-03-16 17:19:32 state TRANSMIT_NO_ACK
2016-03-16 17:29:21 temperature 13.6 C
2016-03-16 17:29:21 temperature_num 13.6
2016-03-16 17:19:32 transmit NO_ACK
2016-03-16 17:29:23 ultraviolet 1 UV
2016-02-16 11:35:30 version Lib 3 Prot 4.5 App 1.6 HW 100 FWCounter 0
2016-03-16 17:29:23 wakeup notification
2016-02-17 09:10:52 wakeupIntervalCapabilitiesReport min 240 max 3600 default 3600 step 60
2016-03-14 13:39:23 wakeupReport interval 600 target 1
Attributes:
IODev ZW_Dongle
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL ALARM WAKE_UP BATTERY SENSOR_BINARY SENSOR_MULTILEVEL CONFIGURATION FIRMWARE_UPDATE_MD MARK DEVICE_RESET_LOCALLY
comment classes: WAKE_UP BATTERY
secureclasses: WAKE_UP ASSOCIATION_GRP_INFO
devStateIcon motion:people_sensor@green nomotion:people_sensor@red
event-on-change-reading state,alarm,humidity,luminance,temperature,ultraviolet,battery
event-on-update-reading wakeup
eventMap open:motion closed:nomotion
noWakeupForApplicationUpdate 1
room ZWave
stateFormat reportedState
userReadings fp_TempHumMot:temperature|humidity|state {ReadingsVal($name,"temperature","1")." / ".ReadingsVal($name,"humidity","1")." / ".InternalVal($name,"STATE","nomotion");;},
temperature_num:temperature {ReadingsNum($name,"temperature","1");;},
humidity_num:humidity {ReadingsNum($name,"humidity","1");;}
Log verbose 5 (wakeup um 17:29:23, sind noch ein paar weitere ZWave-Ereignisse beim loggen aufgetreten):
2016.03.16 17:29:01.066 4: ZWDongle_Read ZW_Dongle: rcvd 0004000d06310504220000, sending ACK
2016.03.16 17:29:01.067 5: SW: 06
2016.03.16 17:29:01.069 5: ZW_Dongle dispatch 0004000d06310504220000
2016.03.16 17:29:01.069 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:06310504220000 CB:00
2016.03.16 17:29:15.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000050000900000041, sending ACK
2016.03.16 17:29:15.491 5: SW: 06
2016.03.16 17:29:15.494 5: ZW_Dongle dispatch 0004003912600d01033202213400000050000900000041
2016.03.16 17:29:15.495 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000050000900000041 CB:00
2016.03.16 17:29:21.932 4: ZWDongle_Read ZW_Dongle: rcvd 0004005606310501220088, sending ACK
2016.03.16 17:29:21.932 5: SW: 06
2016.03.16 17:29:21.934 5: ZW_Dongle dispatch 0004005606310501220088
2016.03.16 17:29:21.935 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:06310501220088 CB:00
2016.03.16 17:29:22.407 4: ZWDongle_Read ZW_Dongle: rcvd 0004005605310505011a, sending ACK
2016.03.16 17:29:22.408 5: SW: 06
2016.03.16 17:29:22.409 5: ZW_Dongle dispatch 0004005605310505011a
2016.03.16 17:29:22.410 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:05310505011a CB:00
2016.03.16 17:29:23.209 4: ZWDongle_Read ZW_Dongle: rcvd 0004005603800364, sending ACK
2016.03.16 17:29:23.210 5: SW: 06
2016.03.16 17:29:23.212 5: ZW_Dongle dispatch 0004005603800364
2016.03.16 17:29:23.213 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:03800364 CB:00
2016.03.16 17:29:23.291 4: ZWDongle_Read ZW_Dongle: rcvd 00040056063105030a1a01, sending ACK
2016.03.16 17:29:23.292 5: SW: 06
2016.03.16 17:29:23.294 5: ZW_Dongle dispatch 00040056063105030a1a01
2016.03.16 17:29:23.295 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:063105030a1a01 CB:00
2016.03.16 17:29:23.410 4: ZWDongle_Read ZW_Dongle: rcvd 000400560531051b0101, sending ACK
2016.03.16 17:29:23.410 5: SW: 06
2016.03.16 17:29:23.412 5: ZW_Dongle dispatch 000400560531051b0101
2016.03.16 17:29:23.412 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:0531051b0101 CB:00
2016.03.16 17:29:23.489 4: ZWDongle_Read ZW_Dongle: rcvd 00040056028407, sending ACK
2016.03.16 17:29:23.489 5: SW: 06
2016.03.16 17:29:23.491 5: ZW_Dongle dispatch 00040056028407
2016.03.16 17:29:23.491 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:028407 CB:00
2016.03.16 17:29:24.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000042000900000050, sending ACK
2016.03.16 17:29:24.491 5: SW: 06
2016.03.16 17:29:24.493 5: ZW_Dongle dispatch 0004003912600d01033202213400000042000900000050
2016.03.16 17:29:24.493 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000042000900000050 CB:00
2016.03.16 17:29:25.528 5: ZWDongle_Write 00135602840825c0 (d79c8805)
2016.03.16 17:29:25.530 5: SW: 010900135602840825c0d8
2016.03.16 17:29:25.535 5: ACK received, WaitForAck=>2 for 010900135602840825c0d8
2016.03.16 17:29:25.542 4: ZWDongle_Read ZW_Dongle: rcvd 011301, sending ACK
2016.03.16 17:29:25.543 5: SW: 06
2016.03.16 17:29:25.544 5: ZW_Dongle dispatch 011301
2016.03.16 17:29:27.564 4: no response from device, removing 010900135602840825c0d8 from dongle sendstack
2016.03.16 17:29:29.462 2: ZWave set WGEG_ENTF off
2016.03.16 17:29:29.463 5: ZWDongle_Write 00131b0325010025c1 (d79c8805)
2016.03.16 17:29:29.465 5: SW: 010a00131b0325010025c13e
2016.03.16 17:29:29.734 5: ACK received, WaitForAck=>2 for 010a00131b0325010025c13e
2016.03.16 17:29:29.735 4: ZWDongle_Read ZW_Dongle: rcvd 011301, sending ACK
2016.03.16 17:29:29.735 5: SW: 06
2016.03.16 17:29:29.737 5: ZW_Dongle dispatch 011301
2016.03.16 17:29:29.747 4: ZWDongle_Read ZW_Dongle: rcvd 0013c1000013, sending ACK
2016.03.16 17:29:29.747 5: SW: 06
2016.03.16 17:29:29.749 5: device ack reveived, removing 010a00131b0325010025c13e from dongle sendstack
2016.03.16 17:29:29.750 5: ZW_Dongle dispatch 0013c1000013
2016.03.16 17:29:29.750 4: CMD:ZW_SEND_DATA ID:00 ARG:0013 CB:c1
2016.03.16 17:29:29.750 4: ZW_Dongle transmit OK for CB c1, target WGEG_ENTF
2016.03.16 17:29:30.399 4: ZWDongle_Read ZW_Dongle: rcvd 0004001b06310504220000, sending ACK
2016.03.16 17:29:30.400 5: SW: 06
2016.03.16 17:29:30.401 5: ZW_Dongle dispatch 0004001b06310504220000
2016.03.16 17:29:30.402 4: CMD:APPLICATION_COMMAND_HANDLER ID:1b ARG:06310504220000 CB:00
2016.03.16 17:29:33.636 4: ZWDongle_Read ZW_Dongle: rcvd 0013c10101a0, sending ACK
2016.03.16 17:29:33.637 5: SW: 06
2016.03.16 17:29:33.639 5: ZW_Dongle dispatch 0013c10101a0
2016.03.16 17:29:33.640 4: CMD:ZW_SEND_DATA ID:01 ARG:01a0 CB:c1
2016.03.16 17:29:33.641 2: ZW_Dongle transmit NO_ACK for CB c1, target WGEG_ENTF
2016.03.16 17:29:42.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000051000900000041, sending ACK
2016.03.16 17:29:42.491 5: SW: 06
2016.03.16 17:29:42.493 5: ZW_Dongle dispatch 0004003912600d01033202213400000051000900000041
2016.03.16 17:29:42.494 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000051000900000041 CB:00
2016.03.16 17:29:51.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000005a000900000051, sending ACK
2016.03.16 17:29:51.492 5: SW: 06
2016.03.16 17:29:51.494 5: ZW_Dongle dispatch 0004003912600d0103320221340000005a000900000051
2016.03.16 17:29:51.495 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000005a000900000051 CB:00
2016.03.16 17:29:59.102 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000b30009000000a7, sending ACK
2016.03.16 17:29:59.103 5: SW: 06
2016.03.16 17:29:59.105 5: ZW_Dongle dispatch 0004003a12600d010632022134000000b30009000000a7
2016.03.16 17:29:59.106 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000b30009000000a7 CB:00
2016.03.16 17:30:00.056 2: ZWave set SZOG_LURE on
2016.03.16 17:30:00.057 5: ZWDongle_Write 00134007600d01022501FF25c2 (d79c8805)
2016.03.16 17:30:00.059 5: SW: 010e00134007600d01022501FF25c2f7
2016.03.16 17:30:00.064 3: SZOG_LURE on-for-timer 1800
2016.03.16 17:30:00.107 5: ACK received, WaitForAck=>2 for 010e00134007600d01022501FF25c2f7
2016.03.16 17:30:00.107 4: ZWDongle_Read ZW_Dongle: rcvd 011301, sending ACK
2016.03.16 17:30:00.108 5: SW: 06
2016.03.16 17:30:00.109 5: ZW_Dongle dispatch 011301
2016.03.16 17:30:00.113 4: ZWDongle_Read ZW_Dongle: rcvd 0013c2000002, sending ACK
2016.03.16 17:30:00.114 5: SW: 06
2016.03.16 17:30:00.115 5: device ack reveived, removing 010e00134007600d01022501FF25c2f7 from dongle sendstack
2016.03.16 17:30:00.116 5: ZW_Dongle dispatch 0013c2000002
2016.03.16 17:30:00.116 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:c2
2016.03.16 17:30:00.117 4: ZW_Dongle transmit OK for CB c2, target SZOG_SLL_00
2016.03.16 17:30:09.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000048000900000058, sending ACK
2016.03.16 17:30:09.492 5: SW: 06
2016.03.16 17:30:09.494 5: ZW_Dongle dispatch 0004003912600d01033202213400000048000900000058
2016.03.16 17:30:09.495 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000048000900000058 CB:00
2016.03.16 17:30:17.102 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d0106320221340000009c0009000000ad, sending ACK
2016.03.16 17:30:17.103 5: SW: 06
2016.03.16 17:30:17.105 5: ZW_Dongle dispatch 0004003a12600d0106320221340000009c0009000000ad
2016.03.16 17:30:17.105 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d0106320221340000009c0009000000ad CB:00
2016.03.16 17:30:18.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000003b000900000048, sending ACK
2016.03.16 17:30:18.492 5: SW: 06
2016.03.16 17:30:18.494 5: ZW_Dongle dispatch 0004003912600d0103320221340000003b000900000048
2016.03.16 17:30:18.495 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000003b000900000048 CB:00
2016.03.16 17:30:35.102 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000b5000900000093, sending ACK
2016.03.16 17:30:35.103 5: SW: 06
2016.03.16 17:30:35.105 5: ZW_Dongle dispatch 0004003a12600d010632022134000000b5000900000093
2016.03.16 17:30:35.105 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000b5000900000093 CB:00
2016.03.16 17:30:36.491 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000004600090000003b, sending ACK
2016.03.16 17:30:36.491 5: SW: 06
2016.03.16 17:30:36.493 5: ZW_Dongle dispatch 0004003912600d0103320221340000004600090000003b
2016.03.16 17:30:36.494 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000004600090000003b CB:00
2016.03.16 17:30:42.556 1: Perfmon: possible freeze starting at 17:30:41, delay is 1.555
2016.03.16 17:30:54.490 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000006600090000004c, sending ACK
2016.03.16 17:30:54.491 5: SW: 06
2016.03.16 17:30:54.493 5: ZW_Dongle dispatch 0004003912600d0103320221340000006600090000004c
2016.03.16 17:30:54.493 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000006600090000004c CB:00
Hallo Andreas,
könntest Du mal mit dem Attribut WNMI_delay auf 1 Sekunde oder weniger probieren. Mir fällt sonst momentan nichts auf.
Danke, Christian
WNMI_delay 1
Wakeup um 18:19:23h
NO_ACK um 18:19:32.379
2016.03.16 18:19:12.498 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000004900090000003d, sending ACK
2016.03.16 18:19:12.498 5: SW: 06
2016.03.16 18:19:12.500 5: ZW_Dongle dispatch 0004003912600d0103320221340000004900090000003d
2016.03.16 18:19:12.501 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000004900090000003d CB:00
2016.03.16 18:19:21.498 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000040000900000049, sending ACK
2016.03.16 18:19:21.499 5: SW: 06
2016.03.16 18:19:21.501 5: ZW_Dongle dispatch 0004003912600d01033202213400000040000900000049
2016.03.16 18:19:21.501 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000040000900000049 CB:00
2016.03.16 18:19:21.911 4: ZWDongle_Read ZW_Dongle: rcvd 000400560631050122002e, sending ACK
2016.03.16 18:19:21.911 5: SW: 06
2016.03.16 18:19:21.913 5: ZW_Dongle dispatch 000400560631050122002e
2016.03.16 18:19:21.914 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:0631050122002e CB:00
2016.03.16 18:19:22.390 4: ZWDongle_Read ZW_Dongle: rcvd 00040056053105050127, sending ACK
2016.03.16 18:19:22.391 5: SW: 06
2016.03.16 18:19:22.392 5: ZW_Dongle dispatch 00040056053105050127
2016.03.16 18:19:22.393 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:053105050127 CB:00
2016.03.16 18:19:23.248 4: ZWDongle_Read ZW_Dongle: rcvd 00040056063105030a01eb, sending ACK
2016.03.16 18:19:23.249 5: SW: 06
2016.03.16 18:19:23.251 5: ZW_Dongle dispatch 00040056063105030a01eb
2016.03.16 18:19:23.252 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:063105030a01eb CB:00
2016.03.16 18:19:23.426 4: ZWDongle_Read ZW_Dongle: rcvd 00040056028407, sending ACK
2016.03.16 18:19:23.426 5: SW: 06
2016.03.16 18:19:23.428 5: ZW_Dongle dispatch 00040056028407
2016.03.16 18:19:23.428 4: CMD:APPLICATION_COMMAND_HANDLER ID:56 ARG:028407 CB:00
2016.03.16 18:19:24.451 5: ZWDongle_Write 00135602840825d8 (d79c8805)
2016.03.16 18:19:24.453 5: SW: 010900135602840825d8c0
2016.03.16 18:19:24.458 5: ACK received, WaitForAck=>2 for 010900135602840825d8c0
2016.03.16 18:19:24.465 4: ZWDongle_Read ZW_Dongle: rcvd 011301, sending ACK
2016.03.16 18:19:24.465 5: SW: 06
2016.03.16 18:19:24.467 5: ZW_Dongle dispatch 011301
2016.03.16 18:19:26.481 4: no response from device, removing 010900135602840825d8c0 from dongle sendstack
2016.03.16 18:19:29.111 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000c7000900000095, sending ACK
2016.03.16 18:19:29.111 5: SW: 06
2016.03.16 18:19:29.113 5: ZW_Dongle dispatch 0004003a12600d010632022134000000c7000900000095
2016.03.16 18:19:29.114 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000c7000900000095 CB:00
2016.03.16 18:19:30.751 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000048000900000040, sending ACK
2016.03.16 18:19:30.752 5: SW: 06
2016.03.16 18:19:30.753 5: ZW_Dongle dispatch 0004003912600d01033202213400000048000900000040
2016.03.16 18:19:30.754 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000048000900000040 CB:00
2016.03.16 18:19:32.373 4: ZWDongle_Read ZW_Dongle: rcvd 0013d8010318, sending ACK
2016.03.16 18:19:32.374 5: SW: 06
2016.03.16 18:19:32.378 5: ZW_Dongle dispatch 0013d8010318
2016.03.16 18:19:32.378 4: CMD:ZW_SEND_DATA ID:01 ARG:0318 CB:d8
2016.03.16 18:19:32.379 2: ZW_Dongle transmit NO_ACK for CB d8, target ZWave_SENSOR_MULTILEVEL_86
2016.03.16 18:19:32.439 4: ZWDongle_Read ZW_Dongle: rcvd 00040028063105012200ba, sending ACK
2016.03.16 18:19:32.439 5: SW: 06
2016.03.16 18:19:32.441 5: ZW_Dongle dispatch 00040028063105012200ba
2016.03.16 18:19:32.441 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105012200ba CB:00
2016.03.16 18:19:32.993 4: ZWDongle_Read ZW_Dongle: rcvd 00040028053105050133, sending ACK
2016.03.16 18:19:32.993 5: SW: 06
2016.03.16 18:19:32.995 5: ZW_Dongle dispatch 00040028053105050133
2016.03.16 18:19:32.996 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:053105050133 CB:00
2016.03.16 18:19:34.303 4: ZWDongle_Read ZW_Dongle: rcvd 0004002803800364, sending ACK
2016.03.16 18:19:34.304 5: SW: 06
2016.03.16 18:19:34.306 5: ZW_Dongle dispatch 0004002803800364
2016.03.16 18:19:34.306 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:03800364 CB:00
2016.03.16 18:19:34.711 4: ZWDongle_Read ZW_Dongle: rcvd 00040028063105030a0089, sending ACK
2016.03.16 18:19:34.712 5: SW: 06
2016.03.16 18:19:34.714 5: ZW_Dongle dispatch 00040028063105030a0089
2016.03.16 18:19:34.714 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:063105030a0089 CB:00
2016.03.16 18:19:34.953 4: ZWDongle_Read ZW_Dongle: rcvd 000400280531051b0100, sending ACK
2016.03.16 18:19:34.954 5: SW: 06
2016.03.16 18:19:34.956 5: ZW_Dongle dispatch 000400280531051b0100
2016.03.16 18:19:34.956 4: CMD:APPLICATION_COMMAND_HANDLER ID:28 ARG:0531051b0100 CB:00
2016.03.16 18:19:39.498 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000005b000900000048, sending ACK
2016.03.16 18:19:39.499 5: SW: 06
2016.03.16 18:19:39.500 5: ZW_Dongle dispatch 0004003912600d0103320221340000005b000900000048
2016.03.16 18:19:39.501 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000005b000900000048 CB:00
2016.03.16 18:19:39.646 4: ZWDongle_Read ZW_Dongle: rcvd 0004000b03300300, sending ACK
2016.03.16 18:19:39.646 5: SW: 06
2016.03.16 18:19:39.648 5: ZW_Dongle dispatch 0004000b03300300
2016.03.16 18:19:39.649 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:03300300 CB:00
2016.03.16 18:19:39.702 4: ZWDongle_Read ZW_Dongle: rcvd 0004000b03200100, sending ACK
2016.03.16 18:19:39.703 5: SW: 06
2016.03.16 18:19:39.704 5: ZW_Dongle dispatch 0004000b03200100
2016.03.16 18:19:39.705 4: CMD:APPLICATION_COMMAND_HANDLER ID:0b ARG:03200100 CB:00
2016.03.16 18:19:47.112 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000930009000000b5, sending ACK
2016.03.16 18:19:47.113 5: SW: 06
2016.03.16 18:19:47.115 5: ZW_Dongle dispatch 0004003a12600d010632022134000000930009000000b5
2016.03.16 18:19:47.115 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000930009000000b5 CB:00
2016.03.16 18:19:48.499 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d0103320221340000004800090000005b, sending ACK
2016.03.16 18:19:48.499 5: SW: 06
2016.03.16 18:19:48.501 5: ZW_Dongle dispatch 0004003912600d0103320221340000004800090000005b
2016.03.16 18:19:48.502 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d0103320221340000004800090000005b CB:00
2016.03.16 18:19:57.389 4: ZWDongle_Read ZW_Dongle: rcvd 0004005d03300300, sending ACK
2016.03.16 18:19:57.390 5: SW: 06
2016.03.16 18:19:57.392 5: ZW_Dongle dispatch 0004005d03300300
2016.03.16 18:19:57.393 4: CMD:APPLICATION_COMMAND_HANDLER ID:5d ARG:03300300 CB:00
2016.03.16 18:19:57.589 4: ZWDongle_Read ZW_Dongle: rcvd 0004005d0a7105000000ff07000000, sending ACK
2016.03.16 18:19:57.590 5: SW: 06
2016.03.16 18:19:57.591 5: ZW_Dongle dispatch 0004005d0a7105000000ff07000000
2016.03.16 18:19:57.592 4: CMD:APPLICATION_COMMAND_HANDLER ID:5d ARG:0a7105000000ff07000000 CB:00
2016.03.16 18:19:58.923 4: ZWDongle_Read ZW_Dongle: rcvd 0004005f03300300, sending ACK
2016.03.16 18:19:58.924 5: SW: 06
2016.03.16 18:19:58.926 5: ZW_Dongle dispatch 0004005f03300300
2016.03.16 18:19:58.926 4: CMD:APPLICATION_COMMAND_HANDLER ID:5f ARG:03300300 CB:00
2016.03.16 18:19:59.125 4: ZWDongle_Read ZW_Dongle: rcvd 0004005f0a7105000000ff07000000, sending ACK
2016.03.16 18:19:59.125 5: SW: 06
2016.03.16 18:19:59.127 5: ZW_Dongle dispatch 0004005f0a7105000000ff07000000
2016.03.16 18:19:59.128 4: CMD:APPLICATION_COMMAND_HANDLER ID:5f ARG:0a7105000000ff07000000 CB:00
2016.03.16 18:20:00.015 2: ZWave set HZKG_WWZP on
2016.03.16 18:20:00.017 5: ZWDongle_Write 00134f032501FF25d9 (d79c8805)
2016.03.16 18:20:00.019 5: SW: 010a00134f032501FF25d98d
2016.03.16 18:20:00.059 3: HZKG_WWZP on-for-timer 240
2016.03.16 18:20:00.103 5: ACK received, WaitForAck=>2 for 010a00134f032501FF25d98d
2016.03.16 18:20:00.104 4: ZWDongle_Read ZW_Dongle: rcvd 011301, sending ACK
2016.03.16 18:20:00.104 5: SW: 06
2016.03.16 18:20:00.106 5: ZW_Dongle dispatch 011301
2016.03.16 18:20:00.115 4: ZWDongle_Read ZW_Dongle: rcvd 0013d9000002, sending ACK
2016.03.16 18:20:00.116 5: SW: 06
2016.03.16 18:20:00.117 5: device ack reveived, removing 010a00134f032501FF25d98d from dongle sendstack
2016.03.16 18:20:00.118 5: ZW_Dongle dispatch 0013d9000002
2016.03.16 18:20:00.118 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:d9
2016.03.16 18:20:00.119 4: ZW_Dongle transmit OK for CB d9, target HZKG_WWZP
2016.03.16 18:20:00.241 4: ZWDongle_Read ZW_Dongle: rcvd 0004004f0e3202213400000010000100000000, sending ACK
2016.03.16 18:20:00.241 5: SW: 06
2016.03.16 18:20:00.243 5: ZW_Dongle dispatch 0004004f0e3202213400000010000100000000
2016.03.16 18:20:00.244 4: CMD:APPLICATION_COMMAND_HANDLER ID:4f ARG:0e3202213400000010000100000000 CB:00
2016.03.16 18:20:01.741 4: ZWDongle_Read ZW_Dongle: rcvd 0004004f0e320221340000003a000100000010, sending ACK
2016.03.16 18:20:01.742 5: SW: 06
2016.03.16 18:20:01.743 5: ZW_Dongle dispatch 0004004f0e320221340000003a000100000010
2016.03.16 18:20:01.744 4: CMD:APPLICATION_COMMAND_HANDLER ID:4f ARG:0e320221340000003a000100000010 CB:00
2016.03.16 18:20:03.242 4: ZWDongle_Read ZW_Dongle: rcvd 0004004f0e320221340000002c00010000003a, sending ACK
2016.03.16 18:20:03.242 5: SW: 06
2016.03.16 18:20:03.244 5: ZW_Dongle dispatch 0004004f0e320221340000002c00010000003a
2016.03.16 18:20:03.244 4: CMD:APPLICATION_COMMAND_HANDLER ID:4f ARG:0e320221340000002c00010000003a CB:00
2016.03.16 18:20:14.165 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000ab000900000098, sending ACK
2016.03.16 18:20:14.165 5: SW: 06
2016.03.16 18:20:14.167 5: ZW_Dongle dispatch 0004003a12600d010632022134000000ab000900000098
2016.03.16 18:20:14.168 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000ab000900000098 CB:00
2016.03.16 18:20:15.498 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000060000900000045, sending ACK
2016.03.16 18:20:15.499 5: SW: 06
2016.03.16 18:20:15.500 5: ZW_Dongle dispatch 0004003912600d01033202213400000060000900000045
2016.03.16 18:20:15.501 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000060000900000045 CB:00
2016.03.16 18:20:23.113 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000990009000000ab, sending ACK
2016.03.16 18:20:23.113 5: SW: 06
2016.03.16 18:20:23.115 5: ZW_Dongle dispatch 0004003a12600d010632022134000000990009000000ab
2016.03.16 18:20:23.116 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000990009000000ab CB:00
2016.03.16 18:20:24.499 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000044000900000060, sending ACK
2016.03.16 18:20:24.500 5: SW: 06
2016.03.16 18:20:24.501 5: ZW_Dongle dispatch 0004003912600d01033202213400000044000900000060
2016.03.16 18:20:24.502 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000044000900000060 CB:00
2016.03.16 18:20:32.111 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000ab000900000099, sending ACK
2016.03.16 18:20:32.112 5: SW: 06
2016.03.16 18:20:32.114 5: ZW_Dongle dispatch 0004003a12600d010632022134000000ab000900000099
2016.03.16 18:20:32.114 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000ab000900000099 CB:00
2016.03.16 18:20:33.499 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000066000900000044, sending ACK
2016.03.16 18:20:33.500 5: SW: 06
2016.03.16 18:20:33.501 5: ZW_Dongle dispatch 0004003912600d01033202213400000066000900000044
2016.03.16 18:20:33.502 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000066000900000044 CB:00
2016.03.16 18:20:41.111 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000980009000000ab, sending ACK
2016.03.16 18:20:41.112 5: SW: 06
2016.03.16 18:20:41.114 5: ZW_Dongle dispatch 0004003a12600d010632022134000000980009000000ab
2016.03.16 18:20:41.114 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000980009000000ab CB:00
2016.03.16 18:20:42.498 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000054000900000066, sending ACK
2016.03.16 18:20:42.499 5: SW: 06
2016.03.16 18:20:42.501 5: ZW_Dongle dispatch 0004003912600d01033202213400000054000900000066
2016.03.16 18:20:42.501 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000054000900000066 CB:00
2016.03.16 18:20:51.499 4: ZWDongle_Read ZW_Dongle: rcvd 0004003912600d01033202213400000060000900000054, sending ACK
2016.03.16 18:20:51.499 5: SW: 06
2016.03.16 18:20:51.501 5: ZW_Dongle dispatch 0004003912600d01033202213400000060000900000054
2016.03.16 18:20:51.502 4: CMD:APPLICATION_COMMAND_HANDLER ID:39 ARG:12600d01033202213400000060000900000054 CB:00
2016.03.16 18:20:54.058 1: Perfmon: possible freeze starting at 18:20:52, delay is 2.057
2016.03.16 18:20:59.113 4: ZWDongle_Read ZW_Dongle: rcvd 0004003a12600d010632022134000000bb0009000000a4, sending ACK
2016.03.16 18:20:59.113 5: SW: 06
2016.03.16 18:20:59.115 5: ZW_Dongle dispatch 0004003a12600d010632022134000000bb0009000000a4
2016.03.16 18:20:59.116 4: CMD:APPLICATION_COMMAND_HANDLER ID:3a ARG:12600d010632022134000000bb0009000000a4 CB:00
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.
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?
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
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:
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:00Habe 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.
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:00Gruß, Christian
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.
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.
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 :/
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 8)
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!?
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.
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:
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
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 ;)
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.
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.
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.
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).
Zitat von: rudolfkoenig am 22 März 2016, 13:10:07
AMS6 sich nach 0.1 Sekunden Schlafen legt
0.1 ist nicht notwendig.
WNMI_delay von 0.2 reichte sicher -> keine NO_ACK
WNMI_delay von 0.3 führte sporadisch zu NO_ACK
Möchte nicht grundsätzlich 0.1 einführen. Sowohl ozw als auch z-way führen Telegrammlaufzeitmessungen durch. Ich habe keine Ahnung, ob sich dadurch unter Umständen die 0.1 Sek. erhöhen. Hab zwar bei ozw und zway keine höheren Werte gesehen, aber ausschließen kann ich es nicht.
Nach nochmaligem Überdenken:
Keine Abschaffung von "noWakeupForApplicationUpdate". Ich kann bei manuellem Wakeup des AMS6 nicht ausschließen das ZW_APPLICATION_UPDATE und folgende empfangene Nachrichten vom Sensor mehr als 0.2 Sekunden brauchen und dann die WNMI verschickt, obwohl Sensor bereits schläft. -> NO_ACK wäre zwangsläufige Folge. Habe ich gestern zwar nicht festgestellt, würde aber gerne noch mal probieren. Oder kann ich das bereits anhand des Programmablaufs ausschließen (mMn nicht) ?
Fest steht aber für mich noWakeupForApplicationUpdate ist für den normalen Betrieb des AMS6 nicht notwendig.
WNMI_delay müsste entscheidend sein.
Das irritierende für mich ist auch, dass der AMS6 nach einem Empfang irgendeiner Nachricht nach wakeup notification den Wachzustand laut Log deutlich verlängert.
ZitatSowohl ozw als auch z-way führen Telegrammlaufzeitmessungen durch.
Wir ab sofort auch :), nennt sich timeToAck und ist ein Internal (nicht Reading/kein Event).
ZME zu 1m entfernten ASS6: 25ms
Goodway zu 8m entfernten AN158: 19ms
Goodway zu verrueckt (ueber 2 Ecken) angebundenen Sensor: 57ms.
Zitat von: rudolfkoenig am 22 März 2016, 15:20:01
Wir ab sofort auch :), nennt sich timeToAck und ist ein Internal (nicht Reading/kein Event).
Na, da hast Du Dir wieder etwas angetan ;) ; mich verwundern (besser verwirren) die Werte:
Bei den netzgebundenen Geräten habe ich ähnliche Werte bei timeToAck; höchster festgestellter Wert war bis jetzt 50ms.
Aber: die Wakeup-Geräte haben fast immer Werte um 250-300ms. Das habe ich sowohl am Raspi mit Vision zu 3 verschiedenen getesteten Wakeup-Geräten als auch unter Win mit ZME zu einem getesteten WakeUp-Gerät. Sieht so als wäre es immer so.
Die Hauptzeit wird immer zwischen den Log-Eintragen "SW.." und "ACK reveived.." verbraucht. Interessanterweise bei allen SW außer bei SW für WNMI. Muss das so sein? Bei den netzbetriebenen Geräten gibt es diese "Pausen" generell gar nicht.
Erkennbar im nachfolgenden Log:
2016.03.22 21:01:32.086 5: ZWDongle_0 dispatch 0004041f028407
2016.03.22 21:01:32.089 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:028407 CB:04
2016.03.22 21:01:32.097 5: ZWDongle_Write 00131f0280022583 (e345c452)
2016.03.22 21:01:32.101 5: SW: 010900131f0280022583dc
2016.03.22 21:01:32.384 5: ACK received, WaitForAck=>2 for 010900131f0280022583dc
2016.03.22 21:01:32.387 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.03.22 21:01:32.389 5: SW: 06
2016.03.22 21:01:32.394 5: ZWDongle_0 dispatch 011301
2016.03.22 21:01:32.410 4: ZWDongle_Read ZWDongle_0: rcvd 00138300 (request ZW_SEND_DATA), sending ACK
2016.03.22 21:01:32.412 5: SW: 06
2016.03.22 21:01:32.416 5: device ack reveived, removing 010900131f0280022583dc from dongle sendstack
2016.03.22 21:01:32.419 5: ZWDongle_0 dispatch 00138300
2016.03.22 21:01:32.422 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:83
2016.03.22 21:01:32.424 4: ZWDongle_0 transmit OK for CB 83, target ZWave_GARAGE_DOOR_31
2016.03.22 21:01:32.442 4: ZWDongle_Read ZWDongle_0: rcvd 0004001f03800364 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.03.22 21:01:32.444 5: SW: 06
2016.03.22 21:01:32.449 5: ZWDongle_0 dispatch 0004001f03800364
2016.03.22 21:01:32.452 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:03800364 CB:00
2016.03.22 21:01:34.160 5: ZWDongle_Write 00131f0284082584 (e345c452)
2016.03.22 21:01:34.163 5: SW: 010900131f0284082584d5
2016.03.22 21:01:34.174 5: ACK received, WaitForAck=>2 for 010900131f0284082584d5
2016.03.22 21:01:34.177 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.03.22 21:01:34.179 5: SW: 06
2016.03.22 21:01:34.184 5: ZWDongle_0 dispatch 011301
2016.03.22 21:01:34.197 4: ZWDongle_Read ZWDongle_0: rcvd 00138400 (request ZW_SEND_DATA), sending ACK
2016.03.22 21:01:34.199 5: SW: 06
2016.03.22 21:01:34.202 5: device ack reveived, removing 010900131f0284082584d5 from dongle sendstack
2016.03.22 21:01:34.206 5: ZWDongle_0 dispatch 00138400
2016.03.22 21:01:34.209 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:84
2016.03.22 21:01:34.211 4: ZWDongle_0 transmit OK for CB 84, target ZWave_GARAGE_DOOR_31
Zitat von: krikan am 22 März 2016, 22:35:47
Interessanterweise bei allen SW außer bei SW für WNMI.
Info vergessen:
Wenn ich einen Befehl per notify auf wakeup notification in den Wakeup-Sendstack lege, gibt es die "Pause" bei SW dafür auch nicht. Scheint nur für die bereits im Wakeup-Sendstack wartenden Nachrichten zu gelten.
Ich würde gerne hier noch mein Senf dazugeben.
transmit NO_ACKbeobachte ich schon länger in Verbindung mit meinen Danfoss LC13-014G0013.
Da allerdings die Routen stabil sind und im Moment alles Top läuft kümmere ich mich nicht drum.
Kristian du hast geschrieben:
ZitatDas 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)
Ich interpretiere das so das bei mehreren Befehlen nacheinander es keinen NO-ACK gibt.
Könnte man dann nicht z.B.
define Atdanfoss at +*00:30 get <name> battery,setpointTempZwei Anfragen losschicken.
Zumal in der Bedienungsanleitung des LC13 steht:
ZitatObwohl living connect Z auf einzelne Befehle reagiert, müssen immer mehrfache Befehle verwendet werden, um die zweijährige Batterielebensdauer zu gewährleisten
ZitatIch würde gerne hier noch mein Senf dazugeben.
Gerne doch. :) Nur die Warnung, dass hier im Thread mittlerweile Ausnahmesitutationen und Ausnahme-Geräte, aber Danfoss gehört mMn auch dazu, betrachtet werden.
ZitatIch interpretiere das so das bei mehreren Befehlen nacheinander es keinen NO-ACK gibt.
Bin mir nicht sicher, ob wir vom Gleichen schreiben.
Versuche meine zitierte Aussage einmal anders zu formulieren:
Wenn der MS6 die wakeup notification schickt und nicht innerhalb kürzester Zeit (0,1-0,4 Sek) eine Nachricht von FHEM bekommt, schläft er automatisch wieder ein. Da FHEM bei leerem Wakeup-Sendstack nach 2 Sek. als erste Nachricht die WNMI-Nachricht verschickt, endet diese beim bereits wieder schlafenden MS6 zwangsläufig im NO_ACK. Um dies zu verhindern, kann man mit dem Attribut "WNMI_delay" den Zeitraum von 2 Sek. verkürzen.
Sendet FHEM nach der wakeup notification direkt eine Nachricht an den MS6 (bspw. get battery), schläft dieser danach nicht nach 0,1-0,4 Sekunden wieder ein, sondern bleibt länger wach. Wie lange genau habe ich nicht ermittelt, sondern nur bis 1 Sekunde Pause zwischen erste und nächster Nachricht getestet. Dies lief sauber ohne NO_ACK durch.
Bei Danfoss könnte das gleiche Problem des schnellem Einschlafens nach wakeup notification wie beim MS6 vorliegen. Das NO_ACK spricht in Verbindung mit wartender Nachricht im Wakeup-Sendstack dafür:
ZitatDa allerdings die Routen stabil sind und im Moment alles Top läuft kümmere ich mich nicht drum.
NO_ACK könnte nur auf WNMI-Nachricht kommen.
Das könnte man testen, indem man WNMI_delay mit niedrigen Werten setzt und probiert, ob die NO_ACK dann verschwinden und eventuell dann sogar die "Danfass-at"-Lösung überflüssig wird. Das hängt aber mVn nicht mit mehreren Befehlen nacheinander zusammen und NO_ACK kann es auch bei mehreren Befehlen hintereinander geben. Den Auszug aus der Bedienungsanleitung begreife ich nicht.
Im Allgemeinen habe ich aufgrund meiner Feststellungen überlegt, ob wir nicht das WNMI-Delay bei allen Wakeup-Geräten im Standard deutlich heruntersetzen. Das ist bei den bisher selten gemeldeten Problemen mit dem 2 Sek. Standard natürlich gefährlich.
Hallo zusammen,
hat sich zum ursprünglichen Topic noch etwas ergeben? Seit ein paar Tagen beobachte ich bei meinen EUROtronic COMET Z Ventilen auf dem Sendstack nämlich das gleiche Problem. Es häufen sich die nicht verarbeiteten get's aus dem wakeup-Notify und die set Befehle für die Temperatur an.
Irgendwann endet das dann damit, dass dann gar keine Kommunikation mehr zwischen fhem und den Ventilen stattfindet. Bislang habe ich mir damit beholfen, dass ich dann den Raspi neugestartet habe bzw. auch die Batterien der Ventile rausgenommen habe. Das ist aber kein befriedigender Dauerzustand.
Welche Möglichkeiten bieten sich denn noch an? WNMI_delay, aber mit welchem Wert? sleep Befehl im notify zwischen den einzelnen gets? Ich bin ratlos...
Gerne kann ich auch mal ein ausführliches LOG protokollieren lassen und zur Verfügung stellen.
Beste Grüße
Torsten
Hi,
ich habe bisher keine prinzipiellen Probleme mit dem WakeUp-Stack festgestellt. Wenn das Problem bei Dir durch Neustarten des Raspi oder "Reset" der Ventile behoben wird, würde ich ja eher auf das Ventil oder den Raspi tippen...
WNMI_delay hilft in dem Zusammenhang nicht, das ist nur dazu da die "schlaf wieder ein, ich habe keine Nachrichten für Dich" Nachricht FRÜHER an das Gerät zu verschicken, falls dieses schneller einschläft als die 2 sekunden Default. In dem Fall würde dieser "schlaf ein" Befehl nicht beantwortet werden da das Gerät ja bereits schläft und es würde ein NO_ACK gemeldet werden.
Falls da Befehle auf dem Stack liegenbleiben sendet entweder das Gerät keine WakeUP-Notification mehr oder es klemmt irgendwo anders in der Kommunikation.
Hier würde ein Log mit verbose 5 und vor allem dem globalen attribut mseclog = 1 helfen das zu verstehen. Ich gehe aber davon aus das es sich hier um ein Problem mit diesem Thermostaten handelt, die Firmware dieser Dinger ist anscheinend nicht wirklich gut programmiert...
Gruß,
Andreas.
Hallo Andreas,
danke für Deine Antwort, dann muss ich mir wegen WNMI_delay keine Gedanken machen. Es wundert mich nur, da ich mit den Ventilen in den ersten Tagen keine Probleme hatte. Es gab aber auf dem Raspi in den letzten Tagen viele Updates, vielleicht hat es ja damit zu tun.
Habe jetzt mal das log mit verbose 5 und mseclog = 1 zugeschaltet. Das Ventil sendet schon ein wakeup und fhem startet dann auch das notify. Aber es bleiben dennoch sent und get Befehle auf dem stack "hängen". Vielleicht wirst Du oder die anderen Experten ja aus den log / dem list schlau.
Beste Grüße
Torsten
Log:
2016.10.16 21:12:15.941 5: Triggering E3.hk.HR.Bodenheizung (1 changes)
2016.10.16 21:12:15.942 5: Starting notify loop for E3.hk.HR.Bodenheizung, first event wakeup: notification
2016.10.16 21:12:15.959 5: Triggering E3.hk.HR.wakeup.nfy
2016.10.16 21:12:15.960 4: E3.hk.HR.wakeup.nfy exec get E3.hk.HR.Bodenheizung smStatus; get E3.hk.HR.Bodenheizung swmStatus; get E3.hk.HR.Bodenheizung setpoint 1; get E3.hk.HR.Bodenheizung thermostatMode; get E3.hk.HR.Bodenheizung battery
2016.10.16 21:12:15.961 5: Cmd: >get E3.hk.HR.Bodenheizung smStatus<
2016.10.16 21:12:15.964 3: ZWave get E3.hk.HR.Bodenheizung smStatus
2016.10.16 21:12:15.966 5: Cmd: >get E3.hk.HR.Bodenheizung swmStatus<
2016.10.16 21:12:15.968 3: ZWave get E3.hk.HR.Bodenheizung swmStatus
2016.10.16 21:12:15.969 5: Cmd: >get E3.hk.HR.Bodenheizung setpoint 1<
2016.10.16 21:12:15.973 3: ZWave get E3.hk.HR.Bodenheizung setpoint 1
2016.10.16 21:12:15.974 5: Cmd: >get E3.hk.HR.Bodenheizung thermostatMode<
2016.10.16 21:12:15.977 3: ZWave get E3.hk.HR.Bodenheizung thermostatMode
2016.10.16 21:12:15.978 5: Cmd: >get E3.hk.HR.Bodenheizung battery<
2016.10.16 21:12:15.981 3: ZWave get E3.hk.HR.Bodenheizung battery
2016.10.16 21:12:15.986 5: Heizungssteuerung: not on any display, ignoring notify
2016.10.16 21:12:16.100 5: Triggering E3.hk.HR.Bodenheizung (1 changes)
2016.10.16 21:12:16.101 5: Starting notify loop for E3.hk.HR.Bodenheizung, first event thermostatMode: heating
2016.10.16 21:12:16.104 5: Heizungssteuerung: not on any display, ignoring notify
2016.10.16 21:12:16.275 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:26.285 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:36.297 4: FRITZBOX StarGateAP2: Readout_Start.674 Skip fork process FRITZBOX_API_Check_Run
2016.10.16 21:12:40.006 4: Closing inactive connection WEB_192.168.6.11_49398
2016.10.16 21:12:40.007 4: Closing inactive connection WEB_192.168.6.11_49368
List des Ventils:
Internals:
DEF d14c12e6 14
IODev ZWAVE1
LASTInputDev ZWAVE1
MSGCNT 17
NAME E3.hk.HR.Bodenheizung
NR 105
STATE Status: <strong>heating</strong> / Ventil: <strong>42 %</strong></br>Temperatur: <strong>23.0 °C</strong></br>Solltemperatur: <strong> 19.5 °C</strong></br>Batterie: <strong>100 %</strong>
TYPE ZWave
ZWAVE1_MSGCNT 17
ZWAVE1_RAWMSG 0004000e064303012200c3
ZWAVE1_TIME 2016-10-16 21:09:49
ZWaveSubDevice no
homeId d14c12e6
isWakeUp 1
lastMsgSent 1476644978.02325
nodeIdHex 0e
Readings:
2016-10-16 20:19:13 ActValve 42
2016-10-16 20:49:29 IstTemp 23.0
2016-10-16 14:03:31 SEND_DATA failed:00
2016-10-16 21:09:49 SollTemp 19.5
2016-10-15 20:42:45 UNPARSED UNKNOWN_C4 02c407
2016-10-16 20:35:26 WunschTemp 00
2016-10-16 20:19:14 battery 100 %
2016-09-03 18:45:19 cmdGet wakeupInterval
2016-10-07 22:33:26 model EUROtronic EUR_COMETZ Wall Radiator Thermostat Valve Control
2016-10-07 22:33:26 modelConfig eurotronic/eur_cometz.xml
2016-10-07 22:33:26 modelId 0148-0002-0001
2016-07-10 19:00:27 neighborList GH.gt.ZS.Gartenbeleuchtung E1.wz.ZS.Tischleuchte E3.hk.ZS.Subwoofer
2016-07-10 19:02:50 neighborUpdate done
2016-10-16 20:19:13 reportedState dim 42
2016-10-16 21:09:49 setpointTemp 19.5 C heating
2016-10-16 20:19:13 state dim 42
2016-10-16 20:49:29 temperature 23.0 C
2016-10-16 20:19:14 thermostatMode heating
2016-07-03 16:39:46 thermostatSetpointSupported heating energySaveHeating
2016-10-16 20:49:30 timeToAck 0.449
2016-10-16 21:09:49 transmit NO_ACK
2016-10-16 21:09:38 wakeup notification
2016-07-03 16:39:46 wakeupIntervalCapabilitiesReport min 240 max 15728400 default 604672 step 240
2016-10-08 09:01:12 wakeupReport interval 600 target 1
SendStack:
sentget:130e03430201256c
get:130e024002256d
get:130e028002256e
get:130e0231042576
get:130e0226022577
get:130e034302012578
get:130e0240022579
get:130e028002257a
get:130e0286112580
get:130e0231042581
get:130e0226022582
get:130e034302012583
get:130e0240022584
get:130e0280022585
Attributes:
IODev ZWAVE1
alias Heizkörper Heimkino
classes BASIC SWITCH_MULTILEVEL SENSOR_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT NODE_NAMING BATTERY WAKE_UP MANUFACTURER_SPECIFIC VERSION
cmdIcon tmOff:general_aus@red tmHeating:general_an@green
group Heizung
icon sani_heating
room Heimkino,Übersicht
stateFormat Status: <strong>thermostatMode</strong> / Ventil: <strong>ActValve %</strong></br>Temperatur: <strong>IstTemp °C</strong></br>Solltemperatur: <strong> SollTemp °C</strong></br>Batterie: <strong>battery</strong>
userReadings IstTemp:temperature.* { sprintf ("%.1f", ReadingsVal("E3.hk.HR.Bodenheizung","temperature",0)) }, SollTemp:setpointTemp.* { sprintf ("%.1f", ReadingsVal("E3.hk.HR.Bodenheizung","setpointTemp",0)) }, ActValve:reportedState.* { if (ReadingsVal("E3.hk.HR.Bodenheizung","reportedState",0) eq "off") { "0" } else { my @a = split (" ", ReadingsVal("E3.hk.HR.Bodenheizung","reportedState",0));; $a[1] }}
vclasses BASIC:1 BATTERY:1 MANUFACTURER_SPECIFIC:1 NODE_NAMING:1 SENSOR_MULTILEVEL:4 SWITCH_MULTILEVEL:3 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 VERSION:1 WAKE_UP:2
webCmd tmOff:tmHeating
Hi,
kannst Du bitte bei dem ZWave_Dongle und dem Thermostat das verbose auch auf 5 setzen, so ist da zu wenig Info für mich drin...
Aber es gibt auf jeden Fall einen SEND_DATA failed Eintrag... Das ist schon mal nicht gut.
Gruß,
Andreas.