does this work for ZHA as well?
There will be no deconz.configure service with zha, so no.
2 Likes
Hi, I have made the hardware mod and can see in the Mi Home app that the motion sensor is triggering regularly. I also have the python script that resets the sensor state to off 5 seconds. However, I can’t see the sensor detecting motion in HA. It detects the first time but then you get the usual long wait until it detects again. I am using the Xiaomi Gateway integration (so not ZHA). Can anyone tell me if I need to do something else or if this hack just doesn’t work unless your using ZHA?
thanks
1 Like
Hi,
I have done the hardware mod on two of my sensors. Unfortunately, the same problem as ben.iffland. After I put the battery back in, the sensor works and passes the status every 5 seconds.
After a few hours, unfortunately, it no longer works.
The sensor detects a movement. After 5 seconds the status changes and then it takes about 60sec until a new movement is detected.
What are we doing wrong? I hope you can help.
Thanks
- alias: 'Xiaomi Aqara Motion Sensors duration fix'
trigger:
- platform: homeassistant
event: start
action:
- service: deconz.configure
data:
entity: binary_sensor.motion_schlafzimmer
field: "/config"
data: {"duration": 5}
Hi,
I have been reading all of the solutions in this thread and am a bit confused. Are you saying this is all I would need to fix the issue(and the HW fix of course), no Python scripts, just this Node-Red script. I am using ZHA, does that matter? I have not used Node-Red yet, but I will install it if this works.
Thanks
I am also using ZHA Integration and I only did the solder work and this Node Red entry.
Awesome, I’ll try installing Node-Red this weekend and give it a try. Hopefully this works, my wife is not happy with my sensor so far.
Thanks
This worked perfectly, thanks again.
For everyone using Z2M you can change the value inside the Z2M gui:
Have been looking for this, and didn’t realise it was a setting inside the gui of Z2M.
Hey people, I tried everything in this thread, it all worked well, but my question is… for example, a simple situation like turning on/off a light depending on motion…
If the device reports every 5 segundos that occupancy is “on” even if I reset it, it will trigger the light to turn on again right? How can I only turn the light on and off when they are supposed to?
Are you sure it turns on, Even if there is no motion?
Probably it sends „on“ every 5 seconds as long as there is motion.
Pleas test if the Sensor is still on, 90 seconds after the last motion.
This worked perfect for my motion sensors. Thanks
Sorry for the noob question. Does this still require the hardware mod?
No noob question, but yes it does. The hardware mod creates a test mode. This enables the device to honor the 5 sec setting.
1 Like
Hi there
I have the Aqara RTCGQ11LM connected via the Sonoff Zigbee dongle to a HASS docker container - ZHA.
I was about to do the mod and figured I may as well try resetting the state without it - and it works. The inherent issue that I mislike is that the sensor keeps going back to clear even when movement is detected, resulting in it’s state being on>off>on>off continuously. Is there a way to combat this, to lower the sensor cooldown without forcing the reset of the state?
If the mod wasn’t needed, is it possible I can simply change a setting? However with ZHA I don’t see any options for that. Do I need to move over to Zigbee2MQTT?
Thanks
Today I switched from ZHA to Z2M, I made the necessary HW modification on the RTCGQ11LM sensor, I set the occupancy_timeout to 5, but it doesn’t work the way I want it to. After detecting motion, it indicates that there is no more motion almost immediately. After that, however, you live again after at least 1 minute. can something be done about it?
Thought I share some updates on this thread since it is not long enough 
I have the Aqara RTCGQ11LM and XIAOMI RTCGQ01LM sensors connected via the Sonoff Zigbee E dongle to HASS O/S using ZHA integration.
Actually I tried to find an elegant solution that lets me choose the Motion reset timeout as well as Occupancy reset timeout with ZHA. It seems there are easy capabilities to accomplish this with Z2M GUI, but not with ZHA unfortunately as it is lengthy discussed since years in this thread. 
And I’m reluctant to switch everything over to Z2M, since ZHA is also the recommended Zigbee integration and all my devices are setup there.
From what I understand so far, those timeouts seem to be controlled by constants that are defined in the ZHA quirks and I wonder why there is no easier way to let users customize them? Especially since the defaults are quite long, especially for the occupancy with 10 minutes. I found this zigpy ticket, but it was closed with references to some options I summarize below:
I found following solutions and try to summarize them for people still suffering these timeout customization options with ZHA. Despite all those options, from what I learned is that you still have to make the HW hack on the sensor if you want short motion detection intervals. I learned that those devices are in a kind of ‘test’ mode at the beginning, allowing motion triggers every 5 seconds. After some time, it will switch to ‘default’ mode and allow motion triggers only every 60-70? seconds. Probably to save battery power on busy places. So don’t wonder if detection interval is short in the beginning, but does not work in the long term when you do not apply the HW hack. This might also be the reason why some people wrote that it works without the HW hack (it does, but only for limited time).
Following are the Timeout interval control options with ZHA that I found (not a complete list probably, but good to start off with latest HA 2023 versions):
1) Use python script that is triggered through automation to reset the state of the sensors in the HA state machine
Example script:
Example automation from Azertooth:
Pro:
- Can be applied to reset motion and occupancy
- Provides configuration granularity for each sensor (controllable through automation that triggers the script)
Con:
- Requires script setup and automation setup
- Can result in ghost state changes (probably still applicable, since device cluster motion state is not changed)
2) Use App Deamon Add-On
Details:
Pro:
- Simple setup
- Provides configuration granularity for each sensor
Con:
- Requires additional Add-On just to control ZHA sensor settings
- Can result in ghost state changes (probably still applicable?) as it also just modifies the state in the state machine
- No configuration for Occupancy timeout? At least its not documented and I haven’t tested it
3) Use automation to reset Zigbee cluster motion status attribute
This is one of the most elegant options I found so far, and is completely controllable for various sensors. An easy to use code example was provided by Fabian in another thread:
I modified that slightly to have it triggered only when specified sensors changed to On state (this avoids triggers when other sensor attributes change, so the condition check can be skipped):
alias: Motion Reset
trigger:
- platform: state
entity_id: binary_sensor.motion_1
to: "on"
- platform: state
entity_id: binary_sensor.motion_2
to: "on"
condition: []
action:
- delay:
seconds: 4
- service: zha.set_zigbee_cluster_attribute
data:
ieee: "{{ device_attr(trigger.entity_id, \"identifiers\") | first | last }}"
endpoint_id: 1
cluster_id: 1280
attribute: 2
value: "0"
mode: parallel
max: 10
Pro:
- Simple setup via HA automation
- Provides configuration granularity for each sensor (different automations or rules can be configured for different timeouts)
- No ghost state changes since the zigbee device status is modified, resulting in automatic state change
Con:
- No configuration for Occupancy timeout. At least I have neither found a way in internet search, nor found a corresponding attribute to reset occupancy status in the Occupancy cluster attributes of the device. I have no zigbee or quirks expert knowledge, but this led me to think that the occupancy timeout is just defined by the default zigpy reset constant, which user cannot change easily if they don’t want to create custom quirks or modify HA source code directly? On the other hand, it seems the older Xiaomi version of the sensor has 180s occupancy timeout, but the newer Aqara sensor shows 10 minutes occupancy timeout. However, that might be controlled via different quirk implementations. Seems that Aqara seems to use the default reset timeout as defined in zigpy:
zha-device-handlers/zhaquirks/__init__.py at 93ca50a22d9618170212f868d078b864ca7ba551 · zigpy/zha-device-handlers · GitHub
4) Use custom integration ha-constant-modifier
Details:
This option is also referred to in the zigpy issue, but I failed to use it in the past since it causes an exception when used due to changed HA configuration load routines. I don’t think this is still maintained by the owner (no change since 3 years). But modifying the ZHA quirk constants during startup seemed to be the most elegant way to me, and it also provides the option to define shorter occupancy timeouts.
After some investigations and modifications, I got an updated version of this component to work on HA 2023.10 and it works like a charm. I documented my changes in the issue:
With the updated ha-constant-modifier script, I can use following lines in configuration.yaml to modify the zha constants upon each HA start:
# Modify ZHA constant for Xiaomi Motion sensor reset
constant_modifier:
zhaquirks.xiaomi:
MotionCluster.reset_s: 4 # default 70
OccupancyCluster.reset_s: 180 # default 600
When it is successful, you should see following warnings in your HA core logs:
Logger: custom_components.constant_modifier
Source: custom_components/constant_modifier/init.py:69
Integration: HA constant modifier (documentation, issues)
First occurred: 14:09:30 (2 occurrences)
Last logged: 14:09:30
- Patched zhaquirks.xiaomi, MotionCluster.reset_s = 4 (was 70)
- Patched zhaquirks.xiaomi, OccupancyCluster.reset_s = 180 (was 600)
This works like a charm with HW hacked sensors, is reliable and without further modifications to automations or scripts (Unless a changed HA config load mechanism will break the custom component again).
Pro:
- Can be applied to reset motion and occupancy
- Most likely customizable to other ZHA device classes too (?)
- Avoids ghost states, since it modifies the used reset timeouts for the loaded built in ZHA quirks
Con:
- Does not work as is with latest HA 2023 releases. Sess issue description to modify the acript accordingly. Verify functionality via configuration test, there should not be exceptions from config tests.
- Does not provides configuration granularity for each sensor. Only per device class
5) Modify/Set the reset_s constants in the source quirks
As long as I did not find an easy way to accomplish this default constant modification with a custom quirk overwrite for the constants only, I used this option. I do not recommend it to others since it could break your HA setup. I just mentioned it to give you another option, but use it only if others don’t work for any reason. I built a shell script that I called on HA startup events, which makes the necessary changes in the source code. This is ugly and could potentially break the ZHA code when source will change. It also must be re-applied after each HA core update and will just come into effect after another restart of HA (after the update restart)
For those of you interested in this solution, here is the code when you have HA O/S and core is running in the container.
Use a File Editor integration such as VSC and create a shell script in your configuration folder or a subfolder, e.g. /config/set-motion-timeout.sh
#!/bin/bash
# set timer for Xiaomi and Aqara motion sensors in ZHA quirks file
# define default motion reset time in sec
DELAY=5
# define default occupancy reset time in sec
OCCRESET=180
# define quirks filename
FNAME=/usr/local/lib/python3.11/site-packages/zhaquirks/xiaomi/__init__.py
if [ ! -z "$1" ];
then
DELAY=$1
fi
if [ ! -z "$2" ];
then
OCCRESET=$2
fi
# Change Motion reset only once from original delay of 70 seconds
echo "Changing Motion Reset interval from default 70 to $DELAY seconds..."
sed -i "s/reset_s: int = 70.*/reset_s: int = $DELAY/g" $FNAME
cat $FNAME | grep -C 3 "reset_s: int = $DELAY"
result=$?
[[ $? -eq 0 ]] && echo "OK" || echo "Failed RC=$?"
# Add Occupancy reset only once
echo "Changing Occupancy Reset interval from default 600 to $OCCRESET seconds..."
[[ `cat $FNAME|grep "reset_s: int ="|wc -l` -eq 1 ]] && sed -i 's/"""Occupancy cluster."""/&\n\n reset_s: int = $OCCRESET/' $FNAME
cat $FNAME | grep -C 3 "reset_s: int = $OCCRESET"
result=$?
[[ $? -eq 0 ]] && echo "OK" || echo "Failed RC=$?"
exit $result
Disclaimer: The script was roughly tested to update the source file only once from the default up to HA 2023.10. However it may break in future if there are changes to the source quirks file.
Essentially it will modify the default reset_s setting for motion cluster:
And it will add a reset_s definition to the occupancy cluster, which will ensure that the quirk doesn’t use the default zigpy definition of 600 sec.:
To use the script put following lines to your configuration.yaml:
# Shell commands for system management
shell_command:
# Set reset intervals for Xiaomi/Aqara motion sensors
set_motion_reset: '/config/set-motion-timeout.sh "{{delay}}" "{{occreset}}"'
Create an automation that triggers to run the script now an then, e.g. on HA startup
alias: Startup -> Run Shell Commands
trigger:
- platform: homeassistant
event: start
condition: []
action:
- delay: "00:00:30"
- service: shell_command.set_motion_reset
alias: "Xiaomi Motion Sensor reset and Occupancy timeout change in source code"
data:
delay: 5
occreset: 180
enabled: false
mode: single
Note: The variable names as specified with data in the service call must match the variable names used in configuration.yaml when you specify the shell executable parameters. Optionally you can also skip using parameters in the service execution of the script and use the settings you specify in the script defaults.
Pro:
- Works for Motion Reset and Occupancy reset
Con:
- Modifies HA source code, which could break ZHA from start after future code changes.
- Not recommended approach, but may be used if others fail
2 Likes
I have the same problem, modded both 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 movements for an additional 30 seconds. So, whether you have the hardware mod or not, cooling time is always 60 seconds…
Thank you very much for this awesome summary. Extremely helpful!