Closed Nastras closed 1 year ago
This happens when the sensor changes state while deCONZ isn’t running. The Zigbee message for the state change doesn’t reach deCONZ and it continues to use the old state. Aqara sensors only send periodic reports every 50 minutes or so (through the Xiaomi special attribute), so it might take a while for deCONZ to catch up. Note that Aqara sensors are sleepy, their radio is off most of the time, so they cannot be queried when deCONZ starts.
This really is a limitation of the Aqara sensors (and, in all fairness, of most sensors). As workaround you might try:
I am experiencing this sometimes with my Aqara setup after reboots and I made the experience that opening and closing the respective window/door will in most cases fix this status error.
This happens when the sensor changes state while deCONZ isn’t running. The Zigbee message for the state change doesn’t reach deCONZ and it continues to use the old state. Aqara sensors only send periodic reports every 50 minutes or so (through the Xiaomi special attribute), so it might take a while for deCONZ to catch up. Note that Aqara sensors are sleepy, their radio is off most of the time, so they cannot be queried when deCONZ starts.
This really is a limitation of the Aqara sensors (and, in all fairness, of most sensors). As workaround you might try:
- Pressing the little button on the sensor to force the sensor to send an attribute report;
- Not changing the sensor state while rebooting the Pi;
- Try a different sensor. The new Hue contact sensors are light sleepers (they poll their parents every 5 seconds) and support configurable attribute reporting. I think we configure them to report every 5 minutes, and deCONZ could / should be able to read the status on startup, when the last update was more than 6 minutes ago. Haven’t tested this, though. And these sensors are at a different price point
Thank you very much for the detailed explanation. I will now turn off the Pi's automatic restart once a week. Fortunately, this is not absolutely necessary. Don't want to be woken up by the alarm system at night because the Pi restarts and the sensor sends an incorrect value to Homekit.
What surprises me is that this problem only appeared or was noticed by me after so many years 😅.
You might want to double-check if deCONZ shuts down cleanly. If not, it might not flush the latest device states to the database, causing it to show outdated values on restart.
Sorry for the late feedback. A bit stressful at the moment.
What is the best way to test if deconz is shutting down properly?
Check the deCONZ log (with the appropriate debug options enabled). It should show a flush of the database, just before deCONZ stops.
Btw: there is a thread on the phoscon forum for this problem: https://forum.phoscon.de/t/aqara-door-sensors-show-open-on-restart-of-deconz/3686
Check the deCONZ log (with the appropriate debug options enabled). It should show a flush of the database, just before deCONZ stops.
According to the forum it looks like it's a bug in deconz. I will check the days anyway as you described it. Thanks for your help 👌
Hi Erik, I have another question for you about a behavior where I don't know when it first occurred and why. I would be happy if you have a tip where I can start. The following problem my Aqara door sensors report a wrong status after a reboot of the Raspberry Pi for a certain time. Means if my Pi restarts at night and the sensor at the apartment door reports it is open for a short time although it is closed my alarm system goes on. This wrong state is also displayed in the web gui and Homekit. If you wait several minutes and the sensor reports its real state, everything is correct again. I have already tried to delete the affected sensors completely and add new ones. The error remains. The error is reproducible on two different systems.
Thank you and best regards!