Battery status updates

[TC1]

Hi Wim,

I'm using Aqara temp/humidity sensors, they are fantastic and inexpensive workhorses. Like many Zigbee devices, they pre-programmed to only report data when an internal sensor changes value.

As you can see below, I've got one that is operating fine, but the battery value has not been updated since inclusion. I know that the lithium coin cells have long operating life and will tend to report 100% until they fall off dramatically one day.



My question is this: I've check the device definition in HS4 and made sure that "Last Change Time Updates on Status Change Only" is unchecked on both the parent and battery child device, yet as you can see the time doesn't change. Is there something that can be done in deConz to program a cluster to make sure that battery updates are sent along with the other data reports?

[tenholde]

Hi Wim,

I'm using Aqara temp/humidity sensors, they are fantastic and inexpensive workhorses. Like many Zigbee devices, they pre-programmed to only report data when an internal sensor changes value.

As you can see below, I've got one that is operating fine, but the battery value has not been updated since inclusion. I know that the lithium coin cells have long operating life and will tend to report 100% until they fall off dramatically one day.



My question is this: I've check the device definition in HS4 and made sure that "Last Change Time Updates on Status Change Only" is unchecked on both the parent and battery child device, yet as you can see the time doesn't change. Is there something that can be done in deConz to program a cluster to make sure that battery updates are sent along with the other data reports?

Same problem here.

[w.vuyk]

Tony,

deCONZ does send the report on battery devices. But the plugin checks if the value of the battery changes. If it does, it will update the device, but only if it does.

To compensate for that, in HS3 the plugin would update the time on the parent device if the plugin received proof the device was still reporting. It would not update the battery device time as the value did not change. This was working fine, created for SDJHealth from SteveMSJ for battery devices. And the HS4 plugin still does this, but it shows up for converted devices only.

You always can double check on the properties tab/JowiHue in the JSON to see this.

For very unclear reasons the device time in HS4 does not show last update time anymore on newly created (parent) devices. So this effectively removed the possibility to show the device is alive. I do not like how this develops, but see no other way then to move the update from device level to battery level. But my bones say nay

Wim

[TC1]

This is a big problem.

Use case: Aqara Door/Window sensors. I've got some on Windows that in theory will never be open for months (central AC and heat) and it's critical to know if these devices are still alive/working for both auto-HVAC events (turn off HVAC if someone opens window) and security events (check all windows and doors).

So what you are telling me is that these devices will look "dead" if they are untouched for any length of time?

[w.vuyk]

They do not in HS3, but due to HS4 not updating the device holder (parent) anymore, yes they would, unless the battery goes to another level. Or the device becomes unreachable in deCONZ, this would also change the device to unreachable. At the end nothing to worry as the status is accurate still, but I understand your issue here, which again was correct in HS3, by showing the time the device reported itself earlier. Will update this in the next version

[TC1]

Just so I'm understanding correctly, zigbee battery devices (in HS4) that go unused for some time will have updated timestamps for the battery child device as the physical device reports battery levels?

[w.vuyk]

but see no other way then to move the update from device level to battery level.

That is what I said.

[TC1]

Ok, thanks. I was about to place a big order for z-wave window sensors and throw out all my zigbee ones.
I love the Aqara window sensors because they are smaller than any Z-wave ones currently being sold. But as a security/risk management professional, it's essential there's an process and audit trail to prove the device is still alive/working.

Appreciate your efforts and understanding on this.