Communication periodicity of battery-powered devices (Popp Thermostatic Valve)

[Freddy2es]

I am working with a bunch of Popp Thermostatic Valves, which are battery powered. As a result, the devices go back to sleep after each communication and makes things complicated when I want to modify the setpoint as I need to wait for them to be alive again to get the actuation message sent.

In a specific scenario, even at a cost of replacing the batteries more often, I need the setpoint to be updated ASAP and, in order to do that, I configured the Wake Up attribute with the minimum value (60 seconds). However, it still looks like the device communicates when there a change big enough in the Air temperature and not every minute (that's what the manufacturer told us in a response to a ticket we created in its website).

So, using the node-red-zwave-js plugin and with the maximum debug level enabled, I saw some exchanges in a period of time. The debug output can be found here. Sorry for using an external paste service but the text is too long and I don't want to start removing stuff without knowing what I'm doing. Why can't we attach files btw?

As you can imagine, I don't know the details of the Z-Wave protocol, but I can see three WakeUpCCWakeUpNotification, each one of them reporting different values for the Air temperature, and during this time I tried a couple times to change the setpoint to 22, then to 21 and again to 22. All the changes were executed delayed, when the device woke up (as expected). Based on the timmings, it looks like the distance between WakeUp notifications is around 5 minutes.

What I'd like to know is if the Wake Up attribute (don't remember the exact command class) that can be configured with the fronted really does what is expected to do or there's another criteria used to decide when to communicate, either based on (big enough) changes of the Air temperature or using another configuration attribute that I don't know.

Actually related to these "other attributes", I've opened a thread in the nodered forum here. I'll try to update it if I can in parallel.

Regards

[Freddy2es]

Just to clarify, the manufacturer is Danfoss / Popp and the reference in the database is this

My guess is that the Wake Up attribute only configures the reading periodicity of the Air temperature, but unless the value changes enough, no communication is established. I've seen something similar in non-battery-powered devices (for example a MCOHOME CO2 + temperature + humidity multisensor IIRC).

Regards

[AlCalzone]

Battery powered devices are usually in a deep sleep state where they won't receive or respond to commands. Every once in a while, they wake up for a few seconds, so others can send them commands, e.g. to change configuration. This is announced with a WakeUpCCWakeUpNotification. The wake up interval you can configure only influences how often such a wakeup happens - the lower, the more often it wakes up, but the faster the battery gets drained.

Some devices send an updated state right before this wakeup notification, but this is an implementation choice, not a requirement or guarantee. Battery-powered devices are free to send reports while asleep, e.g. motion sensors which would burn through batteries otherwise.

TL;DR: The wakeup interval can have an influence on sensor reports, but more often than not, it does not.

[Freddy2es]

Well, based on the reply received from the technical support service of the manufacturer of this specific model,

The Popp thermostat with Z-Wave is very similar to the Danfoss LC13. The device is a sleeping device with a wake-up interval. The wake-up interval can be set from 0 to 1800, but note that only 300 steps are accepted. With each wake up the thermostat transmits the changed information.

According to this, and even though apparently the WakeUp interval can be configured with a minimum value of 60, it looks like the 5-minute delay between each update I detected while logging the output of the library makes sense. What's weird is that you don't get an error response when you set 60 while it should, but overall, I think the database of devices should be updated to take this into consideration.

Regards