[Gelöst] timeToAck bei WAKE_UP-Geräten

Begonnen von krikan, 05 Juli 2016, 20:43:51

Vorheriges Thema - Nächstes Thema

krikan

Bei den WAKE_UP-Geräten habe ich regelmäßg timeToAck-Wert von über 2 Sekunden, die mMn aber nicht korrekt sind.

Aus dem nachfolgenden Log ergibt sich bspw. ein timeToAck von rund 0,020 für die WakeupNoMoreInformation-Nachricht, jedoch weist Internal timeToAck eine Zeit von 2,033 auf. Wenn ich das Attribut WNMI_delay auf bspw. 1.0 setze, sind die timeToAck-Werte immer knapp über 1 Sek.

Kann es sein, dass bei der Berechnung von timeToAck der WNMI_delay einen Einfluß hat?

list
Internals:
   DEF        e345c452 74
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     44
   NAME       ZWave_SENSOR_NOTIFICATION_74
   NR         304
   STATE      30.5 C
   TYPE       ZWave
   ZWDongle_0_MSGCNT 44
   ZWDongle_0_RAWMSG 0004004a1e8f010403800364097105000000ff07080005310503011106310501220131
   ZWDongle_0_TIME 2016-07-05 20:31:50
   homeId     e345c452
   isWakeUp   1
   lastMsgSent 1467743443.61409
   nodeIdHex  4a
   timeToAck  2.033
   Readings:
     2016-07-03 09:28:45   CMD             ZW_APPLICATION_UPDATE
     2016-07-05 20:31:50   alarm           HomeSecurity: Motion Detection, Unknown Location, arg 00
     2016-07-02 19:52:14   alarmEventSupported_AccessControl (22) Window/Door is open, (23) Window/Door is closed
     2016-07-02 19:52:14   alarmEventSupported_HomeSecurity (3) Tampering - product covering removed, (8) Motion Detection - Unknown Location
     2016-07-02 19:52:14   alarmTypeSupported AccessControl HomeSecurity
     2016-07-02 11:29:06   assocGroup_1    Max 8 Nodes ZWDongle_0
     2016-07-02 11:29:06   assocGroup_2    Max 8 Nodes
     2016-07-02 11:29:06   assocGroups     2
     2016-07-05 20:31:50   battery         100 %
     2016-07-05 20:31:50   luminance       17 %
     2016-07-02 11:27:12   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor
     2016-07-02 11:27:12   modelConfig     philio/pst02.xml
     2016-07-02 11:27:12   modelId         013c-0002-000c
     2016-07-02 11:29:14   state           TRANSMIT_NO_ACK
     2016-07-05 20:31:50   temperature     30.5 C
     2016-07-05 20:30:45   transmit        OK
     2016-07-05 20:30:43   wakeup          notification
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 temperature
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

2016.07.05 20:30:43.611 4: ZWDongle_Read ZWDongle_0: rcvd 0004004a028407 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.07.05 20:30:43.612 5: SW: 06
2016.07.05 20:30:43.613 5: ZWDongle_0 dispatch 0004004a028407
2016.07.05 20:30:43.613 4: CMD:APPLICATION_COMMAND_HANDLER ID:4a ARG:028407 CB:00
2016.07.05 20:30:45.626 5: ZWDongle_Write 00134a0284082508 (e345c452)
2016.07.05 20:30:45.627 5: SW: 010900134a02840825080c
2016.07.05 20:30:45.629 5: ACK received, WaitForAck=>2 for 010900134a02840825080c
2016.07.05 20:30:45.630 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.05 20:30:45.630 5: SW: 06
2016.07.05 20:30:45.632 5: ZWDongle_0 dispatch 011301
2016.07.05 20:30:45.644 4: ZWDongle_Read ZWDongle_0: rcvd 00130800 (request ZW_SEND_DATA), sending ACK
2016.07.05 20:30:45.644 5: SW: 06
2016.07.05 20:30:45.646 5: device ack reveived, removing 010900134a02840825080c from dongle sendstack
2016.07.05 20:30:45.646 5: ZWDongle_0 dispatch 00130800
2016.07.05 20:30:45.646 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:08
2016.07.05 20:30:45.646 4: ZWDongle_0 transmit OK for CB 08, target ZWave_SENSOR_NOTIFICATION_74

rudolfkoenig

Danke fuer den Hinweis.

timeToAck speicherte in diesem Fall die Zeit von der zuletzt gesendete "echte" Nachricht an das Geraet bis zum ACK auf das wakeupNoMoreInformation, weil WNMI nicht ueber den Stack laeuft.

Habs gefixt, indem ich auch beim Senden der WNMI lastMsgSent gesetzt habe.

krikan

Danke!

Bei mir im Netz stelle ich fest, dass timeToAck für einen bestimmten Node immer relativ gleich ist. Nur ab und zu gibt es Ausreißer: Dann ist der Wert 4x-10x so hoch. Eine Ursache sehe ich nicht (keine CANs,..). Bei einer Auswertung nur des letzten Wertes von timeToAck eines Nodes wären bei meinem Netz falsche Schlußfolgerungen möglich. Keine Ahnung, ob die Ausreißer nur bei mir Auftreten.