Yes, the sensor reports relative humidity.
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!
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!!
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.
More photos Also offset function in the driver seems to work well so the calibration should be easy. Many thanks again
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:
- Generic ZigBee Motion/Humidity Sensor (a built-in driver)
- SmartThings Humidity Sensor (a built-in driver)
- Konke ZigBee Temp-Humidity Sensor
Is the last 3 items suppose to be reading in a proper time format?
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
Hi Bogdan, did you manage to get it working? Is it stable? I was thinking of buying the same ones
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.
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.
As @markus indicated that is an Epoch timestamp. You can convert it to a human readable timestamp using a converter like this one:
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
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
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
Thanks mate the repair resolved the issue, I was missing the prefsSetCount value altogether but I have it now.