I have a setup Conbee II and deCONZ with multiple Aqara/Xiaomi RTCGQ11LM motion sensors. After three years some of them start to send false positives. The false positives are identical with a „true“ message. The only hint that it is a false positive is, that it appears as a multiple of 55 minutes. (Message one at 12:00, message two at 12:55, message three at: 14:45).
The setup has over hundred sensors and i need only for just one more year, so i try not to touch the hardware…
There is a thread which adresses the problem, but offers a solution for another sensor.
In the internet was one propostion to update the firmware via OTAU. The problem ist, that Aqara does not provide updates nor the actual firmware / at least i could not find any. Maybe someone knows some upgrade firmware files or the original firmware file?
A second proposal (even if it was for the aqara vibration sensor not the motion sensor) was to set „occupancy_timeout“ to something else than 0. Does anybody know how to set „occupancy_timeout“ (or the equivalent) for the motion sensor in deCONZ and to which value?
Yeah, I have take a look fastly, no Firmware found (Have searched for the “lumi.sensor_motion.aq2”), so this solution is only able if you have the Xiaomi gateway, but not sure this firmware exist.
I m looking the device DDF (still for the “lumi.sensor_motion.aq2”), there is a “config/duration”, but not more options.
You can take a look direclty in deconz, on the cluster “0x0406”, and read all attributes (the device need to be awaked in same time) to see wich one are available.
For information, on Z2M the “occupancy_timeout” is in the cluster 0x0406, attribute 0x0010.
Called in deconz
<attribute id="0x0010" name="PIR Occupied To Unoccupied Delay" type="u16" range="0x00,0xfffe" access="rw" required="o" default="0x00">
<description>The PIROccupiedToUnoccupiedDelay attribute is 16-bits in length and specifies the time delay, in seconds, before the PIR sensor changes to its occupied state when the sensed area becomes unoccupied. This attribute, along with PIRUnoccupiedToOccupiedTime, may be used to reduce sensor 'chatter' when used in an area where occupation changes frequently.</description>
</attribute>
It’s the “config/delay” on some devices.
Edit:
Ok so it’s the “config/delay” by defaut for all device.
@p333 given the fact that you described having the devices running for nearly 3 years, your experience is 99% battery related. Xiaomi devices typically start acting up upon low battery values, so please change them.
Also, you will not find any firmware update for that device, as there is none and they also do not even have the ability to upgrade the firmware.
Lastly, the device also doesn’t offer to make any changes to the “occupancy” reporting interval, as it does not adhere to zigbee standard. The “going back to unoccupied state” is calculated after a sufficiently long time no new occupancy message was received. The usage of item config/duration has been introduced exactly for those very cases.
as i changed the batteries already and there is no software update available i guess i will have no solution for that problem. But thanks for the answers, its helpful that there is actually no solution to make it smoother. The zigbee-setup is still usefull so…
I have several of these (lumi.sensor_motion.aq2) and only ONE which acts exactly the same. Even this topic has been solved I decided to not create a duplicate one and hopefully some expert like @Smanar will have a look at this post shortly:
For quite some time it falsely detects presence every 55 minutes, at least during night / when it’s dark / when it’s cold - I really don’t know what’s the pattern, I just see the negative result: lights turning on every 55 minutes for no reason, and that’s outside of the house. Neighbours not funny bout that.
Running deCONZ v2.28.1 in HA addon v7.0.0 since 2024-09-01.
I checked the battery already and it still has constant 3.0 V (CR2450), even it is mounted in a rather cold area. Another one has the same voltage, so I did not swap it.
Any ideas left? Is the 55 minutes interval somewhere coded in a DDF or something like that?
