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?
Nothing for me.
This device, the “lumi.sensor_motion.aq2”, don’t support bind/report, so there is nothing to set.
The device just send a global report every hour (55 mn for you) with all informations, can be a problem in the DDF but in this situation not possible you are the only one with the problem.
And there is the problem on only 1 devices and all are using same setting, same DDF.
If I would like to change the interval - just for testing purposes to see if the trigger interval also changes - what value/section would need to be changed?
And for the records: we are at least two affected users (which reported this here and even discovered this before, so likely much more) It was working totally fine with older deCONZ versions (same sensor at the same place with the same environment, only battery and software changed) so it still feels like „software might have introduced it, software might fix it“ - at least give it a try.
It’s the problem, it’s not possible on this device, lot of Xiaomi/Aqara device don’t support bind/report, i’s native on te firmware and not modifiable.
It was working totally fine with older deCONZ versions
Ha, the issue happen after a deconz update ?
Honnestly, I have lost the issues deconz history, so much changes on lasts versions, with improvements and new issues.
But a device that can be included without problem, working but having bad report during the periodic Xiaomi report, and with others device still working, I realy don’t have idea where it can come.
If you have time, you can enable logs to catch device return, I can explain how to do. But you will see if the problem is from the device or not, if it’s from the device itself, nothing to do.
Hi All, thanks for the answers,
i do not know if i understand everything, so i hope its not annoying…
a) as far as i understand : its something on the sensors and as you cannot address the sensors it is not changeable.
b) what surprises me that there is no difference to a true “TRUE-Motion”-Signal if i get the full message from the sensors via a deconz/phoscon II/nodered-setup. Or is there anything deconz / node-red is not showing from the message the sensor sends?
c) i wrote aqara - and will post the answer
thanks and best regards
It’s possible with command line or the GUI.
As the error only happen every 55mn, you can try with the GUI and a good timing, because logs will be a lot of talkative.
With the GUI, deconz/help/debug view
With command line deCONZ command line parameters · dresden-elektronik/deconz-rest-plugin Wiki · GitHub
Need to use APS+APS_l2 as flag
It will log ALL raw zigbee request from zigbee side, without deconz intervention, for exemple
APS-DATA.indication mean it’s from the device, else it’s APS-DATA.request
cluster: 0x8031 : here need to have 0x0406
srcAddr: 0x40FF, here need to have your device adress.
asdu is the usefull part, I will decode it, but if i m right it will finish by 01 if detection or 00 for a report without detection.
To find the line easily you can add other flag like “DDF”
(Properbly off-topic: I was surprised that the srcAddr in the control-signal was different to the srcAddr - signals of the same sensor yesterday night - as i cannot trigger the sensor now (it is remote) - did i make a mistake or is there an explanation?)
Yes, effectively, not normal you haven’t the same srcAddr, and few chance you have 2 sensors with 0xB7D9 and 0xB7D8, but easy to check, if I m right there is a device list in deconz.
But about your report
18da0a00001801
0x18 is the data type and 0x01 is the value, so we can see it’s the device that sending a presence detection, it’s from the zigbee network itself, the problem is not from deconz.
Super strange. Yesterday I replaced the motion sensor by an identical one (same model/series, maybe a bit newer production year/month and of course a new battery - but I ruled out the battery before) by first deleting the old one in Phoscon and then pairing the new one, naming it the same and making sure all entities in HA are the same.
I monitored the behaviour of the sensor last night and - so far so good in terms of: not a single ghost motion detection. Let’s see if this is a permanent thing.
I could not find any difference in terms of version etc. so I’m really wondering what makes the difference here. TBH I’m happy for now but also quite skeptical (dont’ reaaaally trust the current status yet) if this is a permanent “fix”, looking at
the fact there’s no logical explanation for the improvement by replacing the hardware with an identical one
the fact the issue appeared out of nowhere last year.
It is already stowed away without battery etc. … only if you urgently need that cluster information I would repair it once again. Did not backup those information before unfortunately.