Battery device wakeup parameters

[apella12]

Mostly to see if I could do it and to find issues if I couldn’t, I have installed zwave-js-ui as an alternative Zwave provider for my openHAB installation on an Rpi4 - 2GB. The goal was to be able to leave all my rules (and other home automation elements) alone and use the zwave-js-ui to duplicate everything I was doing with the OH Zwave binding. Additionally, I was also interested the zwave-js-ui features available without having to unplug the zstick and use Simplicity Studio. I did have to make minor modifications in some rules, but pretty much mission accomplished.
With a limited time on zwave-js-us, I’m not judging these are problems. There could be valid reasons. There also could be parameter changes that I’m not yet aware of to address these differences.
Related to battery device wake-ups. (I did a PR last year on the OH zwave binding to improve battery device performance, so have a little knowledge).

1. Time - Since active power use is greater than 10^4 times sleep power use, every fraction of a second helps. In OH, the stock binding has a 0.5 second minimum and locally I used 0.25 seconds. Using the guideline of 10 frames a second, 2-3 queued commands can be handled in 0.25 seconds. Also I have a few of these Sensative strips that have an enclosed battery, so I try to take it easy on them. Anyway, it appears from my event logs that zwave-js has a 1 second minimum wake time. Can this be adjusted down?
2. Awake queued commands - I have my battery device wake interval set to daily (86400). It seems there is some default frequency for battery level (128) and wakeup parameters (132), but do not have enough data to determine exactly what it is. I did find the parameter to poll the battery level more frequently, if needed. What seems unusual to me is why the wake parameters are even polled on wakeup at all. In OH those are considered static parameters, like configuration (112), so this seems unnecessary. Can the wakeup parameters be excluded from the wakeup queue for all battery devices?

[AlCalzone]

There's not really a hard reason for the 1s awake time, more of a gut feeling. I'd accept a PR to make this configurable with a driver option, like we do with other timeouts.
The 1000ms is currently hardcoded here:

node-zwave-js/packages/zwave-js/src/lib/driver/Driver.ts

Line 5518 in ef0adbb

setTimeout(() => sendNodeToSleep(node), 1000).unref(),

---

What seems unusual to me is why the wake parameters are even polled on wakeup at all

This comes from the specifications:

CL:0084.01.52.03.1 A controlling node SHOULD read the Wake Up Interval of a supporting node when the delays between
Wake Up periods are larger than what was last set at the supporting node.

The driver remembers (in memory) when the last wakeup was and compares that with the configured wakeup interval. If the time since the last wakeup is more than 5 minutes longer than expected, the interval is queried again.
Seems to me there's something wrong when this happens on every wakeup for you. Driver logs may give a hint.

[apella12]

Thanks for the feedback. If I decide to stick with zwave-js beyond the testing I'm doing, I'll look at a PR. It will take some time for me to understand by looking at the other configurable timeouts.

My experience with zwave device clocks is that they are highly inaccurate. I have a powered Aeotec plug that loses about a minute per hour. I'll examine my devices, but highly suspect they are losing over the threshold every day. Two thoughts; since the spec says SHOULD, not MUST I do not think you would be jeopardizing certification without this. However, I could see a variable parameter based on a 1% error, so a daily wake could allow up to 864 seconds, while a 8 hour wake interval would be close the the current 5 minutes. Again I could look at that in the future. For now with the minimum wake a 1 second it is basically moot (battery power-wise) anyway

[AlCalzone]

1% error, so a daily wake could allow up to 864 seconds

That sounds reasonable too.

[apella12]

I'm going to close this as I have all the information I need.

FTR - I tracked the actual wake intervals of my battery devices over several days. I can say the internal clocks are pretty bad for some devices and would not be encompassed with even a 1% cap. (The zooz zse-29v2 loses about an hour and a half each day and one of my sensative door sensors gains an hour a day-but is not 132 polled as only longer is tracked). Anyway my concern is moot anyway with a one second minimum "wake" as that command typically takes way less than 100ms.

Thanks for your answers