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
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.
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.