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

Yes, as mentioned, lastCheckin, lastClosed, and lastOpened are all expressed in the Unix-standard Epoch date/time format.

I included those for webCoRE users originally when v0.7 of the driver was released:

You will see two events because there is contact - open or close event that is used to record the state of the sensor for hub automations, and then there is the second event for the custom attribute lastClosed or lastOpen.

Since the Epoch date/time stamp is simply the number of milliseconds since 00:00:00 UTC on 1 January 1970, those values can. also be used in Rule Machine to compare the previous and current value and take action accordingly. Of course, the contact - open / close events themselves have a date/time stamp so that could be used as well.

I plan to release an update to this driver which includes custom attribute events for both Epoch and human-readable date/time stamps that are by default disabled and can be optionally enabled if the user wishes to use them.

The driver also decides whether info message logging is enabled based on the value of the state variable prefsSetCount. This state variable is used to allow info messages to display while the device is being paired, and then when it changes to a value of 1, the message display stops until the user enables it in preferences.

It's possible that something got out of sequence and prefsSetCount is not set to 1. You can check on the device's details page in the hub UI here:

If you see a value other than 1 then like something happened out-of-sequence during pairing. You could try doing a re-join, which means you go through the pairing process, but without first removing the device from the hub's device list. That should hopefully get prefsSetCount to click up to a value of 1, but if not, then remove the device and pair it as new to fix it.

The next update of the contact sensor driver will no longer use prefsSetCount, and instead show log messages for the first 2 hours after pairing, and after that the user would need to enable log message display in the preferences.


Thanks @veeceeoh
I hadnt noticed the timestamp before, it was only because i thought i was having issues with my contact sensor not reporting that i saw it. But i could see in the events page what was happening.

If the main page could show proper format, would be easier to see whats happening at quick glance. Either way, logs report correct time - so no big drama..

Appreciate the work - Cheers

1 Like

Thanks mate the repair resolved the issue, I was missing the prefsSetCount value altogether but I have it now.

1 Like

Hi All,

thanks @veeceeoh & @guyeeba for your hard work on this.

I have quite a few of QBKG03LM, QBKG04LM devies and they're working 100% with no drops!

I recently bought a couple of the WXKG11LM buttons recently and they have been quite reliable in the sense that they drop from my zigbee network quiteoften.
I can't tell you how long before they drop off, but re-discovering them without removing them from my device list, connection only last for a short of time (like less than a couple hours).
If I remove the devices completely and run discovery, then it seems to last much longer.

I used the driver --> image

and the device seems to be assigned with aqara driver

Any idea what I can do about this.

Oh yeah - I forgot to mention that I have 4 ikea zigbee outlets around the house to ensure that I have a healthy zigbee mesh, but that doesn't seems to be doing the trick for these buttons.

Any suggestions? Thanks


I have this happen to me to. The hack I've done is to pair it to a second hub, then re-pair it to the original hub, from which it dropped. It will then stay on the zigbee mesh much longer. (But, as you've identified, not for too long).

I have red that the IKEA Signal Repeater does work better with some of the Xiaomi devices, than the IKEA Outlets. But not sure why.
Let me see if I find the link to the post where I red this...
EDIT: It sais:
Zigbee repeaters reported to work with Xiaomi devices

From this post:

1 Like

Thanks @mike - so have a second hubitat hub? and you can link the 2 hubs together? :upside_down_face:? wow, i didn't know you can do such things with hubitat hubs. by now you can guess that I'm a newbie :crazy_face:

Thanks @RogerThat, I'm based in UK this is our version which I guess should perform the same way

Do I have to import a specific driver and discover it?
I guess I need to because hubitat hub needs to know of it's existence in order to link its zigbee mesh even though it won't be use to control anything...well you can't really...

so once it's discovered, it will just be there sitting pretty? correct?

There 's a built-in driver for the Tradfri USB repeater. So just pair away .....

1 Like

Pretty much, but it comes with a USB-A port, so you can use it as a (non-controllable) USB charger/power adapter if you want to. It doesn't have to do nothing. :slight_smile: (My guess is that Ikea did this so you have an easily-accessible USB port to charge the battery pack in their Zigbee blinds, which is their intended use for this repeater, and they recommend having these somewhat close to the blinds.)

As mentioned above, there is a dedicated driver for this device. But there's no need to be too concerned about that--repeating is handled by the device itself, not the driver, so it will fulfill that function regardless. You may still want it for the extra features it provides on the Hubitat side,

1 Like

Are there any featurers, except the repeater side of it, that we get from it when connected to HE?

The "extra features" I meant are just two commands in the driver that let you see (log) devices routing through it and the Zigbee link quality, two things that may be useful for troubleshooting but most of which is also accessible elsewhere if needed (and are not generally needed to begin with). There are no features that Hubitat adds to the device itself.

These two commands, with these drivers, also work with other devices like CC2530 and CC2531 and some Xbees, all mine work, @veeceeoh didn’t get replies from his. There is a thread about those drivers and these commands:

Ah, ok, I see.
I like that too, but I really wonder what these devices are though?

2020-02-26 07:14:59.221 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.217 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.213 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.198 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.194 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.191 inforoute info- Destination:This Hub, Next Hop:This Hub, Status:Inactive

dev:3552020-02-26 07:14:59.187 traceroute info- Destination:GELDOPTO Kitchen Led, Next Hop:GELDOPTO Kitchen Led, Status:Active

dev:3552020-02-26 07:14:59.182 traceroute info- Destination:Iris 3326-L Motion Living Room, Next Hop:IKEA Outlet Living Room Window

I suspect that the lines that just say Destination:This Hub, Next Hop:This Hub, Status:Inactive, can be the Xiaomi devices.

I have also seen more strange stuff happening with HE after adding two of the IKEA repeaters. I had to reboot this morning, since nothing worked, but I could log in and do a normal reboot. But dashboards did react, but nothing followed the button actions. I think I will try to take them off the network again, to se if they are the reason for hickups I have seen after adding them. Very strange.
Have anyone else felt the same?
They where added together with an IKEA Tradfri LED (250 lm) bulb, so it might be that bulb that made things go wacky... Never before had any issues, so a bit baffeled what has happened latelly. Did the update to 2.9.114 though, so not so easy to put the finger on what is the cause now... Hmmm....

I'd start with removing the bulb


I use 3 Aqara Temp & Humidity sensors in my setup & they have been working perfectly for my needs (thanks for the drivers!); I find that the air pressure sensors in them are quite accurate, once adjusted for elevation. 2 days ago (after the most recent HE update)I did a soft reset and started over from scratch after having some issues with a few automations. Upon reinstalling, I no longer have options in the Temp & Humidity Device section for either calibrating the pressure sensor, or setting the pressure sensor to inHG, options that were there prior to the reinstall. The options are still there for calibrating temp & humidity.

The device driver is the same version, 1.01. Did something in the most recent HE update break those settings, or did I overlook something & do something differently?

Thanks, Greg

I got the zigbee Blitzwolf temperature/humidity sensor and I can confirm that it also works with the Aqara Temperature sensor driver

If you use the Konke temperature sensor driver the battery level should also report correctly when adjusted for the aaa voltage ranges.

1 Like

is there a way to get those blitzwolfs to show Fahrenheit by chance?

I believe they are restricted to Celsius because they were not designed with the US market in mind.


1 Like

@veeceeoh Please list the hubitat driver for "Xiaomi Smart Plug" (model lumi.plug) as available in beta in your main list.
This is a fork from the original SmartThings driver from bspranger, edited for Hubitat with the hex order updated for correct power consumption reporting. Temperature reporting only in Celcius but not yet reliable.


I been testing this driver for the last 4 month in five different Xiaomi and Aqara Smart Plugs and it is working reliable without any errors reported in the Logs.


Download the Hubitat app