[Release] Xiaomi / Aqara ZigBee device drivers

Yes, the sensor reports relative humidity.

2 Likes

UPDATE
--- FIXED ---

I'm sure my problem is simple, however I have a QBKG12LM and one side of the switch works perfectly with a generic, but not the second.

if i install the driver

I can see status and changes, but cannot activate a buttons, the driver sees it as a button, not a switch and when pressed, it returns an error;

java.lang.IllegalArgumentException: Command 'push' is not supported by device. on line 5346 (appButtonHandler)

this is where i am stuck! :grin:


So i found after a lot of searching that I had to install the Child Device

https://github.com/guyeeba/Hubitat/blob/master/Drivers/Generic%20Child%20Switch.groovy

All is good!! :ghost::ghost:

Hi
First time on this forum. Hence sorry for any errors in advance.
Many thank to veeceeoh and rest of the contributors for developing the Hubitat driver for WSDCCQ11LM Xiaomi temperature humidity sensor. I've tested last night with a a similar new sensor fitted with an LCD screen which I believe is non-branded version of the Blitzoolf BW-IS4 LCD Screen Smart Home Temperature Humidity sensor. Almost looking like the Xiaomi bluetooth units but being Zigbee. All went well with the above mentioned driver and the only parameter that I cannot get is the battery but nevertheless the unit is displaying this on the screen. I'll try now to attach some photos as well.

2020-02-13%20IMG_8625

More photos2020-02-13%20IMG_8623-1 2020-02-13%20IMG_8622 Also offset function in the driver seems to work well so the calibration should be easy. Many thanks again

2 Likes

While my driver for the Xiaomi / Aqara Temp-Humidity sensors is based on standard ZigBee messages for temperature and humidity reports, the battery level messages are completely non-standard. My guess is that this device you've got probably sends standard ZigBee battery level messages.

I'd actually recommend to try changing the device driver to another ZigBee-based driver that handles Temperature & Humidity reports.

Other ZigBee Temp-Humidity drivers to try:

1 Like

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

It also gives 2 instances in the event logs

I got the aqara temperature/humidity sensor

Pairing was very easy (paired after 2 or 3 retries) and it's been working flawlessly in the last 5 days
Thanks to the contributors

1 Like

To be clear, there's only one contributor, and we all owe Keith (@veeceeoh) our gratitude.

7 Likes

Hi Bogdan, did you manage to get it working? Is it stable? I was thinking of buying the same ones :slight_smile:

Hi @veeceeoh I have noticed that one of my Xiaomi contact sensors is reporting it's info message logging but I have confirmed it's disabled. I have tried to enabled and then disable yet it still says its enabled in the logs.

image
image

I actually have another contact sensor and it's working fine with the exact same driver. Any ideas? Should I maybe remove completely and re-add it?

@jchurch does you contact sensor report corect time? Or a string of numbers like my screen shot above?

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.

3 Likes

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

3 Likes

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

3 Likes

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.

Great! Sure, I'll wait, thanks :slight_smile:

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.

2 Likes

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