Did you solve it?
A vote of thanks from me.
I wanted one of my Aqara RTCGQ11LM sensors to have quicker response and re-detection rate. I could already set to 60 secs but wanted less.
For me the pencil method was best, I can solder but don’t have a bit small enough for this job, besides it was easier after taking off the battery cover, to slide down the PIR cover, and use the pencil with the PCB in situ.
I then changed the occupancy_timeout to 5 secs in the Zigbee2MQTT setting, and confirmed working, I’d checked before the mod that it wasn’t working below 60 secs.
Is the procedure for the older sensors still as per this comment? or has there been further developments that perhaps mean we don’t have to reset the cluster?
Those running Z2M or ZHA, does the hack still work for newer iterations of the RTCGQ11LM? I bought a bunch in February of this year and using deCONZ, only 1 out of 4 is cooling down after 5 seconds after applying both hardware and software mods. Wondering if I migrate to Z2M or ZHA, will I see consistent results with the above model?
Hi, is your Aqara model a newer purchase or an older one?
Various purchased dates, latest ones March 23, though the date on the battery cover of all of them is 2016, the reported firmware seems to vary though. They are all Z2M and all the ones I’ve pencil modded cool down after 5 secs, checked each one before the mod was 60 secs.
Nothing else needed to be done, just the mod.
Thanks for the info. I may just push ahead with converting from deCONZ to Z2M to gain better results with 5 sec cooldown.
Doesn’t mather what you use, if you can’t hardware mod it, software will not work… If you use Deconz, after hardware mod (pencil or solder) you also need to tell Deconz to use this new value…
- service: deconz.configure
data:
entity: binary_sensor.office_motion_sensor_presence
field: /config
data:
duration: 5
I did the hardware (pencil mod) and the service call but only worked for one out of the four I recently ordered.
This may help some people: I made an AppDaemon app to reset the sensor directly in ZHA. It’s called ResetZHASensor, you can find it here: GitHub - jaddel/ResetZHASensor: ResetZHASensor is an AppDaemon app for Home Assistant. It manages Aqara motion sensors in a Zigbee Home Automation (ZHA) setup, resetting sensor states directly in ZHA after a specified timeout to avoid 'ghost' motion events.
I have modded 2 RTCGQ11LM sensors, made the deconz configuration setting for 30 secs. It gets the movement, after 30 secs it clears off, but do not get any new movement triggers for an additional 30 seconds. So, whether you have the hardware mod or not, cooling time is always 60 seconds… Do you guys face this same problem?
Looking for help, as I can’t get it to work. My aqara sensor is soldered, and I’ve added the appdaemon app, and added the configuration to apps.yaml in the Apps folder (where the resetzhasensor folder i also located). Changed the entities and IEEE and restarted HA. It doesn’t work. It will clear after app. 60 seconds, not 5. Any input on why this could be?
Nice! I am trying to setup people counter for my shop and your solution looks great! Still running? Can you share more info?
To address the question, “How will the battery life be affected by this hack?”, I conducted measurements using the PPK2.
Without the hack :
The average idle consumption is about 4.07 µA (see bottom left).
When the device detects something, it consumes about 7.3*10-5 mAh (267.29 µC on the graph).
Note : A “detection” consumes about the same amount of energy as one minute of idle. So each time you trigger the motion sensor, the battery life is shortened by approximately one minute.
With the hack :
After the hack, the same amount of energy is used during detection (268.24 µC).
The average idle consumption is now about 4.24 µA.
So the idle power consumption has increased by approximately 4% after the hack.
Considering a typical CR2450 battery, which has a capacity of around 500 mAh, you can expect more than 10 years of battery life, even with the 4% increase caused by the hack.
Here are the key figures if you want to calculate battery life:
- Idle (with hack): 4.24 µA
- Idle (without hack): 4.07 µA
- Detection (with/without hack): 7.3*10-5 mAh
In my opinion, the hack is a good option because the drawbacks are negligible.
Your humble servant,
2 Likes
wow, thnx for this detailed investigation!!
This is working like a charm. Thank you very much!
I generated a Node-RED Flow for it. I have multiple motion sensors (~20). Maybe it’s useful for someone else:
I’m setting up a key value mapping in the function node, where I match entity_ids to their IEEE addresses.
[{"id":"313ee4fe9a14b40c","type":"server-state-changed","z":"85e1ab63.437258","name":"All Motion Sensors","server":"","version":5,"outputs":2,"exposeAsEntityConfig":"","entityId":"binary_sensor.motion_.*_motion","entityIdType":"regex","outputInitially":false,"stateType":"str","ifState":"on","ifStateType":"str","ifStateOperator":"is","outputOnlyOnStateChange":false,"for":"","forType":"num","forUnits":"minutes","ignorePrevStateNull":false,"ignorePrevStateUnknown":false,"ignorePrevStateUnavailable":false,"ignoreCurrentStateUnknown":false,"ignoreCurrentStateUnavailable":false,"outputProperties":[{"property":"payload","propertyType":"msg","value":"","valueType":"entityState"},{"property":"data","propertyType":"msg","value":"","valueType":"eventData"},{"property":"topic","propertyType":"msg","value":"","valueType":"triggerId"},{"property":"entity_id","propertyType":"msg","value":"","valueType":"triggerId"}],"x":190,"y":900,"wires":[["ae7428bf1d5d217e"],[]]},{"id":"ae7428bf1d5d217e","type":"function","z":"85e1ab63.437258","name":"return matching ieee addr of entity_id","func":"const sensorData = {\n \"binary_sensor.motion_dg_bad_ost_motion\": \"00:15:8d:00:xxx\",\n \"binary_sensor.motion_dg_flur_motion\": \"00:15:8d:00:xxxxx\",\n \"binary_sensor.motion_eg_esszimmer_nord_ost_motion\": \"00:15:8d:00:xxxxx\"\n};\n\n// Check if msg.entity_id exists and matches a key in the sensorData object\nif (msg.entity_id && sensorData[msg.entity_id]) {\n // Return the corresponding hex value for the given entity_id\n msg.ieee = sensorData[msg.entity_id];\n} else {\n // If the entity_id doesn't match, return an error or null value\n msg.ieee = null;\n}\n\nreturn msg;\n\n\n","outputs":1,"timeout":0,"noerr":0,"initialize":"","finalize":"","libs":[],"x":470,"y":900,"wires":[["4bec5b1948850d1c","6290021d322815d2"]]},{"id":"ec8ebd2921d814da","type":"inject","z":"85e1ab63.437258","name":"","props":[{"p":"payload"},{"p":"entity_id","v":"binary_sensor.motion_og_bad_motion","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":200,"y":960,"wires":[["ae7428bf1d5d217e"]]},{"id":"4bec5b1948850d1c","type":"delay","z":"85e1ab63.437258","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"allowrate":false,"outputs":1,"x":740,"y":900,"wires":[["dd5f1153e91f3aa0"]]},{"id":"6290021d322815d2","type":"debug","z":"85e1ab63.437258","name":"debug 18","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":640,"y":960,"wires":[]},{"id":"dd5f1153e91f3aa0","type":"api-call-service","z":"85e1ab63.437258","name":"Reset Motion $entity_id -> $ieee","server":"","version":5,"debugenabled":false,"domain":"zha","service":"set_zigbee_cluster_attribute","areaId":[],"deviceId":[],"entityId":[],"data":"{\t \"ieee\": msg.ieee,\t \"endpoint_id\": 1,\t \"cluster_id\": 1280,\t \"cluster_type\": \"in\",\t \"attribute\": 2,\t \"value\": 0 \t} \t","dataType":"jsonata","mergeContext":"","mustacheAltTags":false,"outputProperties":[],"queue":"none","x":970,"y":900,"wires":[["8c3d343b074c5a64"]]},{"id":"8c3d343b074c5a64","type":"debug","z":"85e1ab63.437258","name":"debug 19","active":false,"tosidebar":true,"console":false,"tostatus":false,"complete":"true","targetType":"full","statusVal":"","statusType":"auto","x":880,"y":960,"wires":[]}]