I still have three of these round white Xiaomi motion sensors running in my setup, all of them originally bundled into early Mi Home / Aqara gateway starter kits from years back. If you’ve got one sitting in a drawer, or bought a secondhand lot on a local marketplace, it’s still perfectly usable in Home Assistant through Zigbee2MQTT, with nothing touching Xiaomi’s cloud. The catch is that its behavior is a little quirky compared to newer Aqara-branded motion sensors, and if you don’t know about the quirk going in, you’ll spend an evening debugging something that isn’t actually broken.
What the RTCGQ01LM is and why it’s still common
The RTCGQ01LM is Xiaomi’s original PIR motion sensor, the round one with the small dome lens. It predates the Aqara-branded RTCGQ11LM and RTCGQ14LM lines and it’s a much simpler device. Through Zigbee2MQTT it exposes four entities: battery (percentage), occupancy (binary), voltage (millivolts), and power_outage_count. That’s it. No illuminance surfaced in Z2M, no advanced presence detection, nothing configurable at the sensitivity level. It’s a basic PIR trigger with a battery report attached.
That simplicity is exactly why it’s still around. People bought bulk multi-packs of these years ago and never threw them out, and because they’re Zigbee end devices with no special firmware requirements, they’ll happily join any modern Zigbee2MQTT network today.
Pairing with Zigbee2MQTT
Put Zigbee2MQTT into pairing mode from the Home Assistant frontend or the Z2M web UI, then on the sensor itself hold the reset button for about 5 seconds until the blue LED starts blinking. That’s the documented method on the Zigbee2MQTT RTCGQ01LM device page and it works most of the time.
What I didn’t expect the first time was that the long hold didn’t take on one of my three units. The LED lit briefly and then went dark, and Z2M never saw a join request. A single short press of the same button worked instead. This isn’t a defect: the Z2M device page lists both approaches, noting that if the 5-second hold doesn’t trigger a join, you should try a single short press. And because these are battery-powered sensors that sleep aggressively, it can help to keep the unit awake through the join — press the button every second or two until Z2M finishes interviewing it. Try both press styles before you assume a unit is dead.
The 60-second motion lockout: why you can’t configure around it
This is the part of the RTCGQ01LM that trips people up. After the sensor reports motion, it hardware-ignores any further motion for 60 seconds. This isn’t a Zigbee2MQTT setting, a Home Assistant automation delay, or anything adjustable in the exposed entities. It’s built into the sensor itself, and no combination of Z2M options changes it.
Zigbee2MQTT’s default occupancy_timeout for this device is 90 seconds, and the device page is explicit that you shouldn’t set it below 60 seconds, precisely because of that hardware lockout. If you set occupancy_timeout to, say, 20 seconds thinking you’ll get snappier “no motion” transitions, what you actually get is a sensor that reports “clear” while someone is still standing in the room, because the PIR itself is asleep for a full minute after every trigger.
Worth knowing: if your lighting automation feels laggy or oddly timed compared to an Aqara P1 or RTCGQ11LM in the next room, this is almost always why. Those newer sensors don’t have the same fixed lockout window.
Setting occupancy_timeout correctly in Home Assistant
Given the hardware constraint above, I set occupancy_timeout to 90 seconds (the Z2M default) or higher, and build any “turn off faster” behavior into the automation instead of the sensor config. A representative automation:
automation:
- alias: "Hallway light off after RTCGQ01LM clear"
trigger:
- platform: state
entity_id: binary_sensor.hallway_motion_occupancy
to: "off"
for:
minutes: 2
action:
- service: light.turn_off
target:
entity_id: light.hallway
That for: minutes: 2 on the automation side gives you your buffer without fighting the sensor’s own timing. Trying to squeeze the delay out of occupancy_timeout just produces false “clear” states.
Battery: CR2450, not CR2032
The RTCGQ01LM takes a CR2450 coin cell. That’s a bigger, thicker cell than the CR2032 used in most of the Aqara-branded sensors I’ve written about on this site, so if you’re topping up a mixed drawer of Aqara and Xiaomi devices, don’t assume one battery size fits everything. Check the compartment before you order a bulk pack.
Avoiding the GZCGQ01LM mix-up
If you’re shopping for a replacement or a spare and search the model number, you’ll almost certainly run into the GZCGQ01LM as well. It looks similar in listings and the model code is close enough to cause mix-ups, but it’s a completely different product: a Xiaomi light/illuminance sensor, not a motion sensor. It has no occupancy entity at all. If a listing’s spec sheet mentions lux readings instead of occupancy, you’ve got the wrong device for this guide.
Mesh placement: end device only
The RTCGQ01LM is a Zigbee end device, not a router, same as most legacy Xiaomi sensors from this era (and same pattern you’ll see with old Centralite, GE, and Iris devices in other ecosystems). It depends entirely on a healthy router somewhere in range to relay its reports back to the coordinator.
In my experience, the vast majority of “sensor stopped reporting” complaints for this device trace back to one of three things: low linkquality (under 20), a low battery that’s started dropping packets before Z2M even flags it as low, or a router in the mesh path that doesn’t handle legacy Xiaomi devices well. If yours goes quiet, check linkquality and battery percentage in the Z2M device page before assuming it’s paired-out or dead.
RTCGQ01LM vs Aqara RTCGQ11LM / P1: which to buy today
If you already own an RTCGQ01LM, there’s no reason to replace it. It does one job, and it does it reliably once you understand the lockout. But if you’re buying new, I’d point you toward the Aqara P1 or RTCGQ11LM instead. The fixed 60-second re-trigger lockout on the original Xiaomi unit is the kind of limitation that only becomes obvious after you’ve lived with it for a few weeks, and the newer Aqara sensors don’t carry it forward. If you’re weighing that upgrade, our Aqara P1 motion sensor setup guide covers how it behaves in Zigbee2MQTT.
FAQ
Does the Xiaomi RTCGQ01LM need the Mi Home app to work with Home Assistant?
No. Once it’s paired to Zigbee2MQTT, it operates entirely over Zigbee. The Mi Home app is never in the data path.
Why is there always a delay between motion triggers on this sensor?
That’s the 60-second hardware lockout described above. It’s fixed at the sensor level and isn’t something Z2M or Home Assistant can override.
What’s the difference between RTCGQ01LM and GZCGQ01LM?
The RTCGQ01LM is a motion sensor. The GZCGQ01LM is an unrelated light/illuminance sensor with a similar-looking model code. They are not interchangeable.
What battery does the RTCGQ01LM use?
A CR2450 coin cell, not the CR2032 used in most Aqara-branded sensors.
Does the RTCGQ01LM work with ZHA as well as Zigbee2MQTT?
Yes. ZHA supports it through a device handler (quirk) that creates both a motion and an occupancy binary sensor. Be aware of a long-standing, recurring report where the occupancy entity behaves inconsistently on Aqara/Xiaomi PIR sensors under ZHA while the raw motion event keeps working. I run Zigbee2MQTT rather than ZHA, so I can’t vouch for the exact quirk behavior release-to-release — if you’re deciding between the two stacks, our ZHA vs Zigbee2MQTT comparison covers the trade-offs.
The lockout behavior on this sensor isn’t documented anywhere near the Z2M device page as clearly as it should be, so if you’ve got one of these paired and your automations feel a beat behind, that’s the first thing to check before you start swapping hardware.