Zwave battery drain: handling of device wakeup message with 1 second delay ("sleepDelay = 1000")

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

Looking at ZWaveNode.java there is

// 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.
  • The device takes about 40 mA while it is awake.

I would open an issue against the zwave binding for this problem.

@chris: is it appropriate to open an issue?

With best regards,
Gert

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 :slight_smile:

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.

Thanks,
Gert

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:

  1. ZW100 Engineering Spec, parameters 40 and 111/112/113 (though, for parameters 111/112/113 this description is somewhat disguised)
  2. Confirmation by Aeotec Field Application Engineer Aotec multisensor 6 doesn't pick up parameter changes - #71 by ccheng-aeotec
  3. 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.

Some screenshots:

Besides, in the UI the maximum wakeup period that can be set for a ZW100 is 3600 s.

Best regards,
Gert

Please provide a log file (deug) showing this.

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.

Please provide a log file (deug) showing this.

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.

Regards,
Gert

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.

So here is the log that clarifies everything :slight_smile:

zw100_node_63_sensor_reporting.log (435.1 KB)

The node to look at is Node 63 (the log contains other devices too). Node 63 is a ZW100 with firmware 1.13.

The device is configured to provide data on temperature, humidity and light (parameter 101 “Group 1 Perodic Reports”).

Here a summary from the log:

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

@chris, hope that log brings us in sync :slight_smile:
Gert

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, …).

With best regards,
Gert

1 Like