I am currently trying to identify the reasons for short battery life on my Aeotec ZW100 sensors.
There I noted that the zwave binding takes approx. 1 second to react to a WAKEUP_NOTIFICATION with a WAKE_UP_NO_MORE_INFORMATION message:
2021-01-01 15:20:08.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 28: Is awake with 0 messages in the queue
2021-01-01 15:20:08.528 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 28: Start sleep timer at 1000ms
2021-01-01 15:20:08.529 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 28: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2021-01-01 15:20:08.542 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 28: Node Status event - Node is AWAKE
2021-01-01 15:20:08.545 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 28: Commands processed 1.
2021-01-01 15:20:08.546 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 28: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1667dba.
2021-01-01 15:20:08.548 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-01-01 15:20:08.549 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2021-01-01 15:20:08.551 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2021-01-01 15:20:08.553 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2021-01-01 15:20:09.029 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 28: WakeupTimerTask 0 Messages waiting, state DONE
2021-01-01 15:20:09.530 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 28: WakeupTimerTask 0 Messages waiting, state DONE
2021-01-01 15:20:09.531 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 28: No more messages, go back to sleep
2021-01-01 15:20:09.532 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 28: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
// Half the period to wait before telling a sleeping node to sleep again
private final int sleepDelay = 1000;
Could that be changed to send WAKE_UP_NO_MORE_INFORMATION without any delay (in case there are no more messages to be sent)?
With best regards,
Gert
Additional information, 02-Jan-2021:
After some more analysis, I belive that 1 second delay is the main reason for the battery drain of my Aeotec ZW100 devices: the cycle “send sensor data and wakeup” could be complete in roughly 200 ms; due to the 1 second delay the time the device is awake is more than 5 times as long.
Remarks:
For each sending of sensor data the ZW100 also does a wakeup. That’s a characteristic of the ZW100 device.
I don’t see the point here. This delay will make no real difference to the battery unless you are running the wakeup at a very high period.
The wakeup code does 2 iterations to ensure that it clears the queue and doesn’t go to sleep too quickly.
The issue is not that a device can process the information quickly - the issue is if OH can process the information. The wakeup time is there to allow OH rules etc to process any received data, and send a response before the binding goes to sleep.
@chris: first of all thank you for your quick response
I don’t see the point here. This delay will make no real difference to the battery unless you are running the wakeup at a very high period.
Well, for ZW100 there is one wakeup per sensor reporting cycle: in my case primarily temperature reports which are set e.g. to 10 minutes (i.e. one wakeup per 10 minutes).
Anyway, I have realized that the time the ZW100 draws 40 mA is significantly higher than the 1 second that is induced by the binding. More in the magnitude of 3 or 4 seconds (I would have to do some more precise measurements). Not sure what the device exectly is doing during this time, probably getting readings from its sensors.
Ok, so following your reply, I guess that we will have to live with that 1s delay.
Really? Normally wakeup is separate to sensor reporting - this is the first time I’ve seen this. Are you absolutely sure this is the case as it is definitely not standard for ZWave devices.
Wakeup is set separately - there is a configuration value to set the wakeup period in the device configuration and it should not be linked to sensor reporting.
Really? Normally wakeup is separate to sensor reporting - this is the first time I’ve seen this. Are you absolutely sure this is the case as it is definitely not standard for ZWave devices.
Yes, absolutely sure. References for this behaviour are:
ZW100 Engineering Spec, parameters 40 and 111/112/113 (though, for parameters 111/112/113 this description is somewhat disguised)
My own tests: no wakeup → no sensor reporting (exception: motion sensor notifications)
Wakeup is set separately - there is a configuration value to set the wakeup period in the device configuration and it should not be linked to sensor reporting.
Also for the ZW100 the ‘wakeup interval’ is configured separately from ‘report interval’ (and theshold reports). It is possible to set “report interval< wakeup interval”, but then the reports will only be done at the frequency of the wakeup. Details of this behaviour are described here.
This is NOT related to the wakeup. This is relating to reporting. Reporting is different and handled differently in the binding.
Again, this doesn’t appear to be related to wakeup.
Absolutely - this is my point. The wakeup and reporting are separate functions. The device will send different reports, and the binding will treat them separately.
I will provide a log file, lateron (I will make a new log file).
The log will show that with parameter settings “report interval 1200 s and wakeup interval 3600 s” the sensor reporting is done with an interval of 3600 s.
This is NOT related to the wakeup. This is relating to reporting. Reporting is different and handled differently in the binding.
The documentation says (more or less clearly) that sensor reporting is only done when a wakeup is done. Which is what I pointed at.
Documentation on parameter 40: “[…] If battery power, the Sensor will check the threshold when it is waken up.”
Documentation on parameter 111/112/113 (not very clearly described): “[…] You can also change the minimum interval time to 4 minutes via setting the interval value(3 bytes) to 240 in Wake Up Interval Set CC”
Again, this doesn’t appear to be related to wakeup.
This confirms the statements of the preceding posting. Again, this is confirmation that sensor reporting is only done when a wakeup is done.
Again, I read this differently to you. I’m just very surprised that this device is not compliant to ZWave standards. It’s very very surprising if you are correct as it means the wakeup is not working as normal and I’ve not come across any other devices from Aeon or others that do this.
Please provide about 1 hour of logging. Please also specify the device configuration - ie how the reports are meant to be sent, and what the wakeup period is set to.
There is no sensor reporting at 1200 s interval because sensor reporting is only done as part of the 3600 s wakeup interval.
I.e. for a use case of a temperature reporting every 10 minutes, the report interval and wakeup interval must be set down to 10 minutes.
Side remark: in ther time between the wakeups there are few alarm reports from people walking by (and battery low reports at the same time); these alarm reports are delivered immediately and are unrelated to the sensor reporting (= temperature, humidity, etc.).
Thanks. I think this is very surprising - I’ve not come across other devices that work like this.
I don’t really understand then why you can configure the device to report on change - if I set this up to report on change of (say) 1 deg, will it still only report that on a wakeup period? Seems pointless having these configurations then doesn’t it?
Does this also mean that the motion sensor will only work on a wakeup? Strange.
I was surprised too. So I was documenting the behaviour in this posting. And got confirmation by Aeotec in the subsequent posting.
Actually, at that time I checked the response time of the zwave binding to the device’s wakeup notification. And I was happy that the zwave binding did immediately responded with a “wake up no more information”. There was no 1 s delay at the good old times (about 5 years ago!).
I don’t really understand then why you can configure the device to report on change - if I set this up to report on change of (say) 1 deg, will it still only report that on a wakeup period?
Yes, exactly. Also threshold reporting only occurs at wakeup intervals.
Theshold reporting allows to reduce network traffic (and I assume this may also imply some battery savings). Only when a threshold is exceeded (checked by the device at each wakeup), then a report is sent out.
Does this also mean that the motion sensor will only work on a wakeup?
No, the motion sensor notifications are transmitted immediately, without any delay. But sensor reports are only transmitted on wakeup (temperature, humidity, …).
