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

markus · October 29, 2020, 1:03am

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

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

My Generic Zigbee Drivers, see this thread .
My Sonoff Zigbee Sensor Drivers, see this thread .
My Tasmota WiFi Device drivers, see this thread.

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.

AQARA WALL SWITCHES

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 .

Installation

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

Alexd51 · October 29, 2020, 2:03am

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.

BrunoVoeten · October 29, 2020, 9:11pm

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

BPTWorld · October 30, 2020, 1:02pm

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.

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

Thanks

markus · October 30, 2020, 1:07pm

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

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

ogiewon · October 30, 2020, 1:31pm

@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…

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")
}

markus · October 30, 2020, 1:38pm

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.

hoveeman · October 30, 2020, 3:22pm

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?

bBrian · October 30, 2020, 7:02pm

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.

bBrian · October 30, 2020, 7:33pm

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.

hoveeman · October 30, 2020, 8:27pm

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.

bBrian · October 30, 2020, 9:03pm

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.

BPTWorld · October 31, 2020, 12:41am

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

bobbles · October 31, 2020, 8:34pm

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.
Thanks.

markus · November 1, 2020, 2:59am

@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.

bBrian · November 1, 2020, 1:55pm

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

bBrian · November 1, 2020, 6:00pm

@markus
Missed close event

Logs

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.

hoveeman · November 1, 2020, 11:58pm

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.

aaiyar · November 2, 2020, 12:46am

@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.

markus · November 2, 2020, 12:53am

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

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