I know you're saying that humidity is the only thing worse than temperature. In my experience, Indoor lux is also horrible to calibrate. I can have two identical lux sensors (Fibaros as it turns out) sitting next to each other. One of them is reading ~100, the other is reading ~700 ......
That's a whole-house humidifier unit, right? Did it come with its own hygrometer / humidity sensor(s)?
What's the furnace brand? What kind of sensor does it have? Does the furnace's documentation claim that it's presenting RH or Specific Humidity (or something else)?
You mean you thought the furnace was reporting RH too low, and as a result your humidifier was adding too much moisture to the air?
Acoustic guitars, right? I don't play acoustic guitar, but I understand buzzing frets / bridges means the RH is probably way too low, so Xiaomi/Aqara and Zooz sensors are reporting RH too high.
A quick search produces recommendations of an RH from 45-55% as being ideal for acoustic guitars.
Have you tried using another type/brand of digital hygrometer in the place where you store your guitars? So far, it looks like you're comparing just 3 data points (the three brands of humidity sensors).
Okay, but this is based on one set of readings, and as I understand it since Specific Humidity is in part calculated from Relative Humidity, and RH is calculated in part based on the temperature, both of them will change as the temperature changes. So more sets of readings as data points would be needed to correctly establish correlation.
I imagine this would be pretty tricky to do without a tightly controlled environment, so perhaps it's better to contact The Smartest House to confirm that their Zooz sensor is definitely reporting RH and not Specific Humidity. If they responded that it indeed is, then your furnace's sensor would be the outlier and what would be needed is to increase the target RH in your custom automation application.
Yes, the sensor reports relative humidity.
--- 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
All is good!!
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
To be clear, there's only one contributor, and we all owe Keith (@veeceeoh) our gratitude.
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:
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,
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
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
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
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.