IKEA recently updated their hub to now expose all of the connected devices over Matter, which is cool, it used to just be the lights. Even the motion detectors I have now also register as occupancy detecters, I have two of them, a newer VALLHORN that seems to work just fine, and then also a slightly older model that takes CR2032 batteries, the 2nd generation TRADFRI model. Yet for some reason the latter is now rapidly draining the batteries, it takes two CR2032 cells and drains them in 2-3 days, this started after this update came. I tried disabling the device in the Matter integration in HA but it still drained out completely.
Just wondering if there are any suggestions as to why this is, or if it’s a bug in the Matter server.
The root cause is likely to be the new hub integration asking for RF device status too often, too many ZigBee status requests, and hence too much battery drain. This should be cached.
It will be a bug, but no idea how to diagnose nor configure less polling as I only use HA ZHA directly.
Any controls on poll or sleep time?
(hub to device, motion is sent device to hub immediately)
Similar issues draining RF battery devices have happened on openHAB, ZHA, and even Z-Wave. Normally, battery devices have a long polling time so they save battery and sleep.
Sounds like it could also likely be a bug in the new hub (DRIGERA?) firmware causing the TRADFRI device to have to stay awake or poll more often — could be completely unrelated to HA. I would try excluding and re-adding the TRADFRI to the updated hub to see if it makes any difference.
As far a I can tell, a Zigbee hub cannot force a sleepy end device to wake up. The SED turns off its radio so the hub can’t send it anything, it has to wake itself. It might be forced to wake more often if the hub sends unexpected/bad data, pointing to a hub firmware problem. I’ve also had Z-wave devices that forgot(?) to go back to sleep and drained their battery (so now I have an automation to watch for that); this just required a ping or manual wake-up request (pressing the button) to put it back to sleep and was not due to a hub or HA bug.
Also if they are new batteries, they may just “run low”. I put two 2032s in a sensor this summer that drained to 10% in two weeks, but have remained at 10% for two months now. Battery percentage calculation is not an exact science, even devices reporting 0% remaining can function normally for several months.
Yes, very true. The TRĂ…DFRI 5-button remotes were infamous for crap battery life (fixed by new firmware 2.3.080 last year), and random battery state. The newer RODRET 2-button has been a lot more reliable.
I get the point about the remote node being asleep, but have definitely seen battery life differences between both software stacks (openHAB Vs HA) and coordinators (Sonoff 3.0 and NC Yellow - not the aerial size difference, as many intermediate mains mesh routers).
Different default settings propagated to the remote nodes? Longer coordinator intervals meaning the remote node wakes up, sees no comms, so sleeps again?
I’d also agree the issue is likely in the IKEA hub firmware, and exclude / add has fixed some odd behaviour before…
