I have a couple of Zigbee sensors that frequently go unavailable - most of them, AAA-powered. I used to think these types of batteries are no good, even for Zigbee sensors, and have been slowly replacing some door/window sensors with CR2032 versions…
Well, lately I also replaced some of those AAA with brand-new batteries, and a couple of days later… Unavailable.
Then I got a hunch: I opened the window, closed it again, and voila, the sensor is back online! Are they reporting 20% of battery? They are. But they’ve been working for a couple of days already.
These windows have been closed for days in a row because it has been nightmarish hot here in Rio and AC is on most of the day.
Is this kind of “dormant for too long” behavior expected? Or are my Zigbee sensors simply cheap and faulty?
And… yep, you guessed, they’re all generic Tuya devices. Hence, cheap and faulty.
Aqara is quite expensive on my end, and a bit harder to find on AliExpress - although I’ve been using their buttons and so far, mostly good experiences.
But if we go with the 20% battery hypothesis, would that make sense for the device to vanish, and once awoken get back to work normally for days in a row?
Not sure. I use Zigbee2MQTT and my sensors keep their last state even when the batteries die, though I think there may be a way to change this.
I have no idea how ZHA detects failed devices.
Maybe your devices stop sending polled data (lqi, battery, lux etc…) if the battery gets low, but they will send state data when the contacts open or close and HA marks then unavailable after a certain length of time without any updates?
The issue is that there are no standard for how a device is working on Zigbee.
Zigbee just provide a framework for it.
Some devices are set report each 6 hours, other each 12 hours and so on, and some devices only report when a change is happening.
The problem is that the ones making implementations for HA and other controlling systems have no way of knowing. If the developers set the timeout too long, then people will complain about not knowing earlier that their device was unavailable and maybe out of battery, and setting it too short and you get a number of false positives, like the ones you describe.
First of all: WHAT, there is something we could ask on the forum that @tom_l didn’t know the proper answer??? I’m in shock. The next step is the lampy guy getting lost as well! hahahaha
WallyR, you’re right! You gave me the idea to look into that block of weird ZHA settings I never ever touched. Guess what, there are configurable timeouts for mains and battery devices!
The default seems to be 6 hours without communication with battery things, and 2 hours for router-like devices.
I’ll pay closer attention to the unavailability of those devices and check if it would be feasible to increase my timeouts. I wonder if, on low battery, they get weaker and end up skipping some keepalive reports or similar stuff.
