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

[markus]

@bdydrp

string of numbers

That is date and time represented as an Epoch, not a format favored by humans, but very easy to use when programming. This is by design in at least that driver.

[aaiyar]

@bdydrp

Or a string of numbers

As @markus indicated that is an Epoch timestamp. You can convert it to a human readable timestamp using a converter like this one:

Epoch Converter

[bdydrp]

Thanks @aaiyar & @markus
I had never noticed it before, so wasnt sure if it was bug or issue
Since thats how its suppose to be, ill move along..
Cheers

[bogdan.mail]

Hi spcat
The sensor is stable. No drops so far..Apart of not showing the battery display ( which is not critical since it indicated by display) all good and very happy because I can get the last update time stamp in the tile. I’ve attached a screenshot taken earlier before. I’ve tried other drivers as suggested by Keith ( thank you) but only the Xiomi Aquara was the closest to the mark.
If you are not in a big hurry I’ve already ordered a similar unit manufacturerd by Blitzwolf and a second one by Bakeey. Once, I’ll test them I’ll publish the findings.

[spcat]

Great! Sure, I'll wait, thanks

[veeceeoh]

@bdydrp

Is the last 3 items suppose to be reading in a proper time format?

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:

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

[UPDATE] All Xiaomi Device Drivers except Aqara Button Links to updated code “original” Button driver v0.8 “original” & Aqara Door/Window sensor driver v0.7 Aqara Smart Wall Switch model WXKG02LM driver v0.6 Aqara Leak sensor driver v0.7.1 “original” Motion Sensor driver v0.7 Aqara Motion Sensor driver v0.7 “original” & Aqara Temperature/Humidity sensor driver v0.7 Changes from previous versions All device drivers added (informational) info log message toggle preference setting, fo…

@bdydrp

It also gives 2 instances in the event logs

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.

---

---

@jchurch

have noticed that one of my Xiaomi contact sensors is reporting it's info message logging but I have confirmed it's disabled.

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.

[bdydrp]

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

[jchurch]

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

[j2hdwd]

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!
Awesome!

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

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

WXKG11LM

[mike]

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

@j2hdwd

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.

[RogerThat]

@j2hdwd

4 ikea zigbee outlets

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

• @iharyadi's Homemade Temperature, Humidity, Pressure, and Light Sensor
• IKEA
  • TRÅDFRI LED Bulbs (based on 1 user report)
  • TRÅDFRI Signal repeater (confirmed by multiple users)
  • TRÅDFRI Wireless control outlet (fully confirmed to work)

From this post:

Xiaomi & Aqara Devices - Pairing & Keeping them connected

NOTE: Although many users have had great success using them, Xiaomi / Aqara ZigBee devices are NOT officially supported or guaranteed to work on the Hubitat Elevation platform. Because of their small size, simple design, and relatively low price, the Chinese home automation (HA) market ZigBee mesh network-based devices from Xiaomi / Aqara have seen an increasing level of popularity in other countries, where users are attempting to integrate them with their HA hub platform of choice, instead of t…

[j2hdwd]

@mike

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

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

@RogerThat

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.

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?

[aaiyar]

@j2hdwd

Do I have to import a specific driver and discover it?

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

[bertabcd1234]

@j2hdwd

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

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. (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,

[RogerThat]

@bertabcd1234

You may still want it for the extra features it provides on the Hubitat side,

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

[bertabcd1234]

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.

[markus]

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:

IKEA drivers "Get Route Table" command - source code available?

Right, those are routers, so those commands should work on them.

[RogerThat]

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

dev:3552020-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....

[markus]

@RogerThat

They where added together with an IKEA Tradfri LED (250 lm) bulb

I'd start with removing the bulb

[ghgeiger]

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