[Release] Xiaomi / Aqara / Opple Drivers with Presence!

NOTE: Although Xiaomi / Aqara devices are used by many users with great success, Xiaomi / Aqara Zigbee devices are NOT officially supported on HE.

Why new drivers?

Xiaomi / Aqara drivers was something I wanted to write my own version of. Since @veeceeoh isn’t here to support his I thought I’d release mine. I have published drivers for most types of Zigbee devices from Xiaomi / Aqara, if any are missing it’s probably because I don’t have the specific device. With this said, a big thank you goes to @veeceeoh for his drivers which were where it all began for me :slight_smile:

What’s different?

Many things, these are a COMPLETE rewrite, they don’t share any code with the old drivers. They have been tested by a few people and been found to make the devices more stable and responsive. Yes you read that right, if you want to know more about how that is done, look at the code.
For those that monitor Last Activity to see if the devices are online, that will not work as expected with these drivers, check the Presence attribute instead.

Supported Devices

  • Xiaomi / Aqara / Opple Button/Switch/Remote (works with models WXKG01LM, WXKG11LM (2015 & 2018), WXKG12LM, WXKG02LM (2016 & 2018), WXKG03LM (2016 & 2018), WXCJKG11LM, WXCJKG12LM & WXCJKG13LM) - Import URL
  • Xiaomi / Aqara Contact Sensor (works with model MCCGQ01LM & MCCGQ11LM) - Import URL
  • Xiaomi / Aqara Motion Sensor (works with model RTCGQ01LM & RTCGQ11LM) - Import URL
  • Xiaomi / Aqara Temperature & Humidity Sensor (works with model WSDCGQ01LM, WSDCGQ11LM & Keen RS-THP-MP-1.0) - Import URL
  • Xiaomi Mijia Smart Light Sensor - Zigbee 3.0 (works with model GZCGQ01LM) - Import URL
  • Aqara Water Leak Sensor (works with model SJCGQ11LM) - Import URL
  • Aqara Smart Curtain Motor (works with models ZNCLDJ11LM & ZNCLDJ12LM) - Import URL
  • Xiaomi / Aqara Smart Plug/Wall Outlet (works with models ZNCZ02LM & QBCZ11LM) - Import URL
  • Aqara Vibration Sensor (works with model DJT11LM) Import URL
  • Aqara Cube (works with model MFKZQ01LM) - Import URL
  • Xiaomi Smoke Detector (works with model JTYJ-GD01LM/BW) - Import URL

My other drivers

Which driver should I use?

All drivers are as combined as they can be, the list above should make it clear which driver go with which model.


An initial driver for the Aqara Wall Switches has been published. The full support is just for the new D1 series (tested with QBKG24LM), as well as the old no-neutral switches QBKG03LM and QBKG04LM. Others may work, please report your progress. If I can get the logs (NOT with debug turned on) from all other Aqara wall switches, it is now easy to add full support for them all. PM me the logs from when you turn on, off and double click all buttons on the device, don’t send them as a screenshot, I need them as text since I will need to extract data from them. Test disconnecting the buttons from the relays with the commands in my driver, if it work/doesn’t work for your model, please report it.

Available here . Also available using HPM.

Beta Versions

The Beta versions with the latest (and usually just as stable) features and enhancements can be found here .


Use the Hubitat Package Manager or install manually using the Import URLs above. When changing from another driver to mine, run Initialize.


Have to thank you guys for this. Biught sone motion sensor without knowing tgey wouldn’t work natively with HE and this saved my bacon.


Those drivers are amazing, I use them since a couple months on my HE, they have worked fine. I cannot thanks Markus enough, he’s my hero.
I hope the drivers will keep working on HE. Another solution could be a new OLL hub :wink:


As you know I wrote a very popular app ‘Device Watchdog’ (HE). This app relies on the ‘Last Activity’ to make sure things are up and running. This change basically kills all Xiaomi device support for users of your drivers (me included) in DW. :frowning_face:

Please reconsider updating the ‘Last Activity’ within your drivers.



I know, this is an issue, the problem is that there is no way of controlling when Last Activity is updated. Updating Current State (which the presence functionality requires) does so automatically.

If you could allow a check against the Current State lastCheckin as and alternative to Last Activity that could be solved since this represents basically the same thing as Last Activity (in other drivers) but with some enhancements like Recovery etc.

I’d be happy to work with you in making sure this works reliably :slight_smile:

Another alternative could be to just look for the presence attribute, if set to “present” the device is there, “not present” it is not.

1 Like

@markus, so I took a quick look at your code for a motion sensor after seeing @BPTWorld’s question…

I am curious why you’re not allowing the Hubitat Event system to determine if the state of the attributes have changed, but rather forcing it to either False or True…?

Wouldn’t simply removing the “isStateChange:” parameter in all of the calls below resolve the issue so that The Device Watchdog App would continue to work properly? Am I missing something? To be honest, I have not tried to follow all of the logic in your code, but a quick search of this one driver made me curious… :thinking:

void sendMotionEvent() {
    logging("sendMotionEvent()", 1)
    Integer resetTime = resetTimeSetting != null ? resetTimeSetting : 61
    runIn(resetTime, "resetMotionEvent")
    sendEvent(name:"motion", value: "active", isStateChange: false, descriptionText: "Motion Active")

void resetMotionEvent() {
    logging("resetMotionEvent()", 1)
    sendEvent(name:"motion", value: "inactive", isStateChange: false, descriptionText: "Motion Inactive")

void resetToActive() {
    logging("resetToActive()", 1)
    sendEvent(name:"motion", value: "active", isStateChange: true, descriptionText: "Motion was Reset to Active")

void resetToInactive() {
    logging("resetToInactive()", 1)
    sendEvent(name:"motion", value: "inactive", isStateChange: true, descriptionText: "Motion was Reset to Inactive")

The two sendEvent calls with isStateChange set to True are triggered solely by commands and are meant to fire an event every time pressed. This is not part of normal device operations.

Whenever it is possible (and doesn’t make more sense with the opposite) I do use “isStateChange: false” (baring some mistake somewhere, but that should have been found by now). The big issue with using Last Activity inside my drivers occur when the attributes notPresentCounter and presence are updated as part of the device NOT being present. Every time that occurs and there is a change in Last Activity.

I’m having an issue with my contact sensors not receiving a closed event reliably. I have sensors on my freezer, fridge, and a couple doors. I will open the Fridge, and it will receive the open event, and I will close it a few seconds later and it will still show it as open. I will have to open the door again and then close it again and it will then receive the closed event. This is happening on all of my xiaomi contact sensors.

You can see on the events for my Refrigerator Door that it received open, but not closed. On picture 2 there is a red line. That is when I realized that the door sensor was still listed as open. So I opened the door and closed it again to the get the closed status.

I would say that this has been happening for the past 4 months or so.

I also tried to re-pair the xiaomi sensor to the hub yesterday, but it is still happening today.

I’m using the latest drivers, installed through Hubitat Package Manager.

Any suggestions?

For monitoring if Xiaomi devices are online / present, DW is so close to working using the special tracking ability. The issue is the “Trigger Value for attribute” does not distinguish between ‘present’ an ‘not present’

This shows what is reported when the attribute value is ‘present’. If the attribute value is ‘not present’ then nothing is reported.
Perhaps I am misunderstanding how to use Special tracking.


First I assume you have taken steps to verify the sensor is connected to the hub. It is really curious that you are having troubles with fridge / freezer doors. I have the same issue. It’s the issue I have had the longest. I have tried everything I can think of. I have an Ikea repeater with line of sight to the sensor and maybe 15 feet away. I’ve tried different placements. Having the magnet the moving part and the non moving part. I have read that contact sensors do not like it if the magnet slides in from the side. Instead they need to come together perpendicularly. Still not reliable.
I wonder if the metal of the door is some how causing the problem. Out of curiosity is the door also metal? I wonder how many other people are experiencing the same problem.

Good call out, and yes I have. I can always just open and close the door again and it fixes it. I believe it always receives the open event.

They are opening/closing the same way they would on door/door frame.

The chest freezer one is about the same scenario as yours where the repeater is about 15 feet away. I will try moving the repeater so it is about 2 feet away from the contact closure and see what happens.

I don’t believe I had this issue until switching to these drivers. I could be wrong… but I may switch back to the original ones from veeceeoh on the fridge and see if it always receives the event.

Two fridges, 6 sensors. I took the one that gave me the most trouble and moved it to a door leading to the garage and it has been working perfectly. This why I’m perplexed as to why it doesn’t work on the fridge.

Using this with Device Watchdog’s ‘Special Tracking’ option will give us what we need. Thanks


Hi @markus
I’m using these drivers on HE at the moment and I’ve noticed that with the latest release, as mentioned above, they no longer work with @BPTWorld’s Device Watchdog app.
It has been said that using ‘Special Tracking’ in DW will be OK as a work round.
Unfortunately for me this is not giving the information that I need.
Just a couple of questions for you.
Is there a specific reason why you had to do this?
Would it be possible to reverse/make some changes to your drivers so this functionality works again with Bryan’s code.

@hoveeman I think the below would apply to your situation as well. Even though you have it happen to all of your sensors. Have you tried changing batteries?

That is truly odd, exactly which model is it and which year was it purchased? I’m trying to track down if maybe there are two different packets being sent and my driver listens for one and @veeceoh for another. Then it just so happens that the one I’m listening for is not reaching the driver under bad sending conditions. This is very far fetched, but could be worth looking for.

What is it that is missing for you when doing it that way?

Yes, it’s the Presence and Recovery feature. What is it that has changed for you in this? I have not made any specific changes to this part of the code for this release.

You can disable the Presence and recovery feature in Settings, though I wouldn’t really recommend that.

I ordered 20/05/2020. I turned debugging back on and will watch out for anything interesting.
Almost forgot, the model is MCCGQ01LM.

Missed close event


Other than the close event missing close event nothing looks out of place.

Opened and closed the door twice.

And the logs

I gave up on this months ago because I couldn’t prove/disprove it wasn’t a signal problem. Let me know if you see anything. Meanwhile I have the code reactivated and will watch what is going on. Can it be an issue is the open/close events are only a few seconds apart.

1 Like

Thanks @markus for the reply! Yep, I have. New batteries.

I moved the refrigerator over to the veeceoh driver after my post and I haven’t had any missed messages all weekend on the refrigerator. Every open and close has been coming through.

I’ll have to track down when I bought them, but it was probably 2 years ago.

I’d be happy to do any testing for you. Really appreciate our hard work on these.

1 Like

@markus fwiw, I have the exact same observation. Curiously, also with a contact sensor that is on my fridge door.

And similar to @hoveeman, there are no missing events with the older (Keith G’s) driver.

That’s good enough, then I know what to expect in signaling. :slight_smile:

There must be two different events, I’ll look into it, this is very odd indeed.