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.
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:
Con:
2) Use App Deamon Add-On
Details:
Pro:
Con:
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:
Con:
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
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:
Con:
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:
Con:
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!
