Xiaomi / Aqara ZigBee device drivers (possibly may no longer be maintained)

Keith, my Aqara drivers are mostly based on your DTHs, and I managed to get them working with full functionality, even though in some cases I don't like the solutions I had to use.

They're available here, check them out, maybe you'll find something useful...

And for anyone who has issues: feel free to use my drivers as long as @veeceeoh provides a full solution (I don't recommend using my drivers in the long term, as I can't promise they'll be as well-maintained as @veeceeoh's stuff are)

1 Like

Thank you for all of your time and hard work that you have put in to maintain these drivers.

I just wanted to thank @veeceeoh as well for the time and effort. I gave my wife a pink Mi Cube for her area and it skyrocketed my WAF. She shows everyone. It's always the little things. Couldn't have done it without your work and of course @bspranger. Thanks fellas.


Is there some sort of trick with these that I'm missing? I installed the driver and then paired two Aqara motion sensors. I had no problem pairing them, but they only show batteryLastReplaced in the status section, and aren't detecting motion. I repaired the zigbee on one, and it connected right away, but still looks the same on the device page.

Not sure what firmware you are on, but if you've updated to the latest firmware in the last week, there is an issue with Xiaomi sensors. Just read up a few posts. It should be rectified in the coming days. Or you could downgrade to an older firmware.

[UPDATE] All Xiaomi & Aqara Hubitat Device Drivers

Compatibility fix for Hubitat Hub firmware 2.0.5 or newer

Only two changes have been made to the below linked drivers:

  • All functionality is restored when the driver is used with Hubitat firmware 2.0.5 or newer
  • For users with a hub running firmware 2.0.4 or earlier, a preference setting has been added, allowing the user to disable the compatibility fix (see screenshot below)

Links to my updated Xiaomi & Aqara Device Drivers:

  • Aqara Button (WXKG11LM / WXKG12LM) v0.6.5
  • Aqara Leak Sensor (SJCGQ11LM) v0.8
  • Aqara Motion Sensor (RTCGQ11LM) v0.7.2
  • Aqara Vibration Sensor (DJT11LM) v0.7.3b
  • Aqara Wireless Smart Light Switch - 1 button (WXKG03LM) / 2 button (WXKG02LM) v0.7.5b
  • Xiaomi/Aqara Door-Window Sensor (MCCGQ01LM / MCCGQ11LM) v0.7.2
  • Xiaomi/Aqara Temperature Humidity Sensor (RTCGQ01LM / WSDCGQ11LM) v0.8.1
  • Xiaomi Button (WXKG01LM) v0.8.5
  • Xiaomi Mi Cube Controller (MFKZQ01LM) v0.2.1b
  • Xiaomi MiJia Honeywell Smoke Detector (JTYJ-GD-01LM/BW) v0.5.1
  • Xiaomi Motion Sensor (RTCGQ01LM) v0.7.1

Links to updated Xiaomi & Aqara Device Drivers by @guyeeba:

  • Aqara Wired Wall Switch (no neutral) - 1 button (QBKG04LM) / 2 button (QBKG03LM) driver
  • Aqara Wired Wall Switch (with neutral) - 1 button (QBKG11LM) / 2 button (QBKG12LM) driver
  • Aqara Wireless Smart Light Switch - 1 button (WXKG03LM) / 2 button (WXKG02LM) driver
  • Xiaomi/Aqara Door-Window Sensor (MCCGQ01LM / MCCGQ11LM) driver

Many thanks to @mike.maxwell for the suggested code to make the drivers compatible.

At this point, I plan to return to updating and improving each of the drivers on an individual basis (which is a lot more sane given my limited time resources!)

Detailed Notes

  • All this update does is accommodate a change in the way certain kinds of "raw" ZigBee message data is passed on to device handlers. Specifically, the order of bytes of payload data with little-endian data types is reversed, to avoid issues with variable length payload data.
    Most ZigBee device drivers aren't affected because they make use of "helpers" that parse the data and "un-reverse" the byte order of payload data where needed. But many Xiaomi / Aqara devices send messages with data in a non-standard format, so use of the "helpers" doesn't make much sense or simply isn't possible.
    The fix in my updated drivers un-reverses the byte order of payload data where needed, and otherwise all other aspects of the code remains unchanged. I plan to look at switching to the use of helper methods where applicable, on a case by case basis.

  • If debug message logging is enabled, a log message is displayed whenever it has been determined that the byte order of payload data needs to be "un-reversed".

  • IMPORTANT: If you are using any firmware version prior to 2.0.5 with these updated device drivers, then make sure to turn on the preference setting to DISABLE the 2.0.5 firmware compatibility fix for every Xiaomi / Aqara device:


Thanks for all that you do for us with xiaomi.

Silly question, updating drivers in HE, is it as simple as pasting the new code over the old code and saving?

Yes, or copy the link, go to the driver, click import, paste the link, import, save. It's default is for 2.0.5, so I did this first then updated the hub from 2.0.4 to 2.0.5.


Thanks, the import feature is nice.


The import works, just make sure when importing the link goes to the raw code, the links in this thread are all directly to the raw code so no problems, but just saying in case you try with other community's drivers.


Thank you; very nice touch adding the compatibility select switch to allow use with 2.04 f/w. I always prefer changing just one thing at a time.

1 Like

[UPDATE] v0.7b of Aqara Wireless Smart Light Switch Device Driver

The new beta device driver code can be grabbed from here.

EDIT: Some errors were discovered, and I have re-released the updated driver. Please see this post for details.

Hi @veeceeoh and thanks for you great work on the drivers.
Just an observation.
I notice that the date/time stamps are not being displayed in 'English' for the want of a better word.


Yes, originally I removed the "human readable" date/time stamps when I ported the ST device handlers to Hubitat device drivers because there was no mobile app for Hubitat. I left the Unix/Epoch-based date/time stamps for people using WebCoRE on their Hubitat, though. That string of numbers is simply the number of milliseconds since Epoch time (00:00:00 Thursday January 1 1970) for when that event took place.

Since then, the Dashboard feature was added, and people who love to see exactly when something has happened on every device starting asking for a custom date/time attribute to be put back in the driver.

However, other people, who hate having their events list cluttered or feel that it may be slowing down things, have asked for a way to disable the custom date/time attribute events altogether.

So, I am going through each of the drivers and adding these features. The one from your screenshot for the Motion Sensor has not yet been updated. I hope to get to it soon.

Thank you for your patience.

This was discussed earlier (around post #293). On the sendEvent( lines you can replace "value: now()" with "value: new Date().toLocaleString()" to get readable dates.

1 Like

I had to change this line:
if (!oldFirmware & valueHex != null & encoding > 0x18 & encoding < 0x3e) {

to this:
if (!oldFirmware && valueHex != null && encoding > 0x18 && encoding < 0x3e) {

Groovy uses a double ampersand '&&' for the 'AND' operation.

I have not seen any errors with that change. Is there any reason this will be a problem? (I am NOT a Groovy expert).

Thanks. Great work!

[UPDATE] This change is NOT necessary! I used the original code by @veeceeoh and it works great. The error I saw must have been caused by some fat-fingering of my own.

Why did you have to change that line? Was something not working?

Not from what I have read. Although & is a bitwise operator, when evaluating boolean expressions, both & and && act as logical AND operations as they do in Java:

Using && is a little more efficient because if any expression is false then evaluation of all the expressions stops there, and false is returned. In this case, the code is only executed once when a message is passed from the hub's parser, so efficiency isn't really a big concern.

What I am concerned about is that something isn't working despite all of my testing. Are you seeing errors?

As I said, I am not a groovy expert. I had used a pre-release version from your github that had '&' and I did get an error on that line. I honestly did not run the released version before I made the change to '&&'. I will run it as you had it when i get home and report back.

Ahhh, I think that would explain it. I made a copy-paste error that propagated into an earlier update of the code on GitHub which was subsequently fixed, all before I made the announcement last night.

I guess I didn't anticipate people watching over the GitHub repository for any updates.... :rofl:

Looks like I jumped the gun on my stalking. :eyes: I changed the code back to single ampersands"&" and I do not see any errors. Your code looks great. I'll update my post above to make sure no one thinks that change is necessary.

Thank you!

1 Like

Download the Hubitat app