Here's my take on drivers for a select few battery powered Xiaomi Aqara devices. There are a number of other excellent drivers out there with more complete support of the range, but these are for the devices I own and now use every day.
There's a little backstory below, but due to the faff I've had with Xiaomi products I will only post drivers here that work together and will only comment on things I have actually tested and experienced myself, however limited that may be.
Straight from the BirdsLikeWires GitHub if you like to do things manually.
- Xiaomi Aqara Temperature and Humidity Sensor WSDCGQ11LM - Import URL: RAW
- Xiaomi Aqara Wireless Mini Switch WXKG11LM - Import URL: RAW
- Xiaomi Aqara Wireless Mini Switch WXKG12LM - Import URL: RAW
- Xiaomi Aqara Wireless Remote Switch WXKG06LM / WXKG07LM - Import URL: RAW
- Xiaomi Mijia Smart Light Sensor GZCGQ01LM - Import URL: RAW
Otherwise, search on Hubitat Package Manager for "xiaomi", "aqara" or "mijia" and you should see Xiaomi Aqara and Mijia Drivers from BirdsLikeWires.
I didn't think I would ever write anything for these devices due to my inability to have them stay on my Hubitat mesh, but when I discovered the limitations of interfacing with them on their own hubs I had to give it another shot. I'm now extremely happy with them despite the four years (yeah, I know) it has taken to get here.
I've encountered so many issues getting them to work reliably that keeping them on their own separate network and making them available using Hub Mesh is the only method I can recommend. My setup is very simple:
- Hubitat C-7 on Zigbee Channel 23
- IKEA Trådfri Signal Repeater E1746
Then I add no other devices apart from those which I've written drivers for, or that have sat on the mesh for a week with the generic system "Device" driver in debug mode so I can scowl at them. If a driver appears above then I've had success keeping the devices happy together.
I found and reliably repeated that the some of Xiaomi's own wired Smart Wall Switches (namely models QBKG22LM and QBKG25LM) will cause mesh instability. Battery devices will become unreliable and then drop completely within a few hours, so you will never find drivers for those here. Instead I use very reliable Samotech modules fitted behind the Wireless Remote Switches.
In theory the Zigbee channel shouldn't matter, but channel 23 was the best I had available, away from my wifi and with a little space between other Zigbee frequencies in use.
The drivers do nothing special to try and keep devices alive and connected. The mesh is either good or it's not and devices should check in every 50-60 minutes with battery readings. These reporting intervals are a firmware default and cannot be changed.
Some of the devices send a unique transmission (sometimes with battery data) on a short press of the reset button. Where this could be useful it is mapped to a button press and referred to here as the "reset button" feature, to give an extra means of control for "free".
Provides temperature, relative humidity, calculated absolute humidity, pressure, pressure direction (rising or falling), reset button, device presence and battery reporting. Tapping reset is mapped as button one.
Supports push, double push, triple push, quadruple push, quintuple push, reset button, device presence and battery reporting. Tapping reset is the same transmission as the quintuple push, so is also reported as button five.
Supports push, double push, hold, release, reset button, acceleration (shake), level (calculated from duration held), device presence and battery reporting. Tapping reset is again reported as button five, while acceleration (shake) is reported as button six.
Supports push, double push, hold, long hold, device presence and battery reporting. Left key is button one, right key is button two, both keys together make button three, with each button supporting all four modes of press:
- Double Press
- Hold (2 seconds)
- Long Hold (5 seconds, reported as a "released" event)
If you hold a button for more than 10 seconds the device will reset, so don't do that.
The "long hold" feature makes use of a message received from the device if a button is still being held down three seconds after the "held" transmission has been sent. A "hold" is reported after two seconds, therefore this "long hold" message is triggered after five seconds.
Given that there is no genuine "released" message supported by the device it would seem the best way to capture this functionality is to consider it an "autorelease" of the button. Therefore a long hold is reported as the held button being released.
We're basically getting a fourth type of press for free!
Supports illuminance, illuminance direction (brightening, darkening), device presence and battery reporting. Tapping reset is mapped as button one.