Abarbeitung des WakeUp-Sendstacks wird in Einzelfällen unterbrochen

Begonnen von krikan, 01 März 2016, 21:56:44

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten1 2 3 ... 8
Benutzer-Aktionen

krikan

01 März 2016, 21:56:44 Letzte Bearbeitung: 04 März 2016, 11:06:01 von krikan
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)
Code Auswählen
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.
Code Auswählen
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

krusi

#1
02 März 2016, 04:20:07
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

A.Harrenberg

#2
02 März 2016, 07:36:46
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

#3
02 März 2016, 07:47:56 Letzte Bearbeitung: 02 März 2016, 11:08:42 von krikan
@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.

A.Harrenberg

#4
02 März 2016, 08:10:53
Hi Christian,

wenn ich das eben richtig gesehen habe startet das angehängte Log ja früher, sollte reichen.

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

krikan

#5
02 März 2016, 19:58:46
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
Code Auswählen
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:
Code Auswählen
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

A.Harrenberg

#6
02 März 2016, 22:59:21 Letzte Bearbeitung: 02 März 2016, 23:01:24 von A.Harrenberg
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
Code Auswählen
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...)
Code Auswählen
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.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

#7
02 März 2016, 23:21:10
Hi Christian,

kannst Du mal ein paar Zeilen in 10_ZWave.pm auskommentieren und mal ein paar Tests damit machen?

Code Auswählen
  } 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

#8
03 März 2016, 09:46:55
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
Code Auswählen
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...)
Code Auswählen
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...

A.Harrenberg

#9
03 März 2016, 09:53:32
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

#10
03 März 2016, 20:31:45
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:
Code Auswählen
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.


A.Harrenberg

#11
03 März 2016, 20:39:14
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

#12
03 März 2016, 20:49:59
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

A.Harrenberg

#13
03 März 2016, 20:58:00
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

#14
03 März 2016, 21:16:37
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....
Drucken
Nach oben Seiten1 2 3 ... 8
Benutzer-Aktionen