Can someone tell me what governs the polling time for the Temperature/Humidity sensors? 2 days ago I started using one to run a dehumidifier and most of the time it seems that it won't transmit until there's a large difference from the previous value. Sometimes HE won't hear from it for hours even though the humidity has gone up over 5% (if I moisten my hand and cover it, it immediately sends a signal, so it hasn't dropped off.). Then today it wont shut up and transmits for every .3% change, every few mins or so. I have 2 others in different parts of the house and it seems they talk every 5-10 minutes as well, but sometimes hours would go by without a peep.
It is not really polling if I am not mistaken.
In Zigbee, there is a command called "configure reporting". This command should control when (or how much of a change) a device should report its attribute. A Zigbee device should proactively send the attribute (temp or humidity) based on the configuration parameter.
@veeceeoh or other member here may be able to tell you in more detail whether an Aqara Temperature sensor will comply with this command.
Can confirm it paired with generic ZigBee outlet also. No temp sensor obviously.
Will check in in next 24 hours to confirm if they stay online.
Again happy to test a dedicated driver. Tnx G
I have one of the temp/humidity sensors, and mine has very intermittent reporting also. I tried to use it for a bath fan sensor, and it was too slow to be of use. Sometimes it will go days without reporting even though I know the bathroom humidity has risen and fallen significantly.
I have plenty of Zigbee repeaters nearby, so I don't think that is the issue. I don't think this is a driver or Hubitat issue, I think the devices are just not all that well built or at least not consistently built.
Great! I'm hammering out a new beta of the Gas Detector driver, and then I can put together a Smart Plug driver for you to try. It will take some days, as I'm pretty busy, it being summer and all here north...
The official word from Lumi on the reporting of the Aqara Temperature / Humidity sensor at least is:
When the temperature and humidity sensor detects temperature changes over 0.5 degrees or more than 6% humidity change, a report will be sent. The atmospheric pressure value will be sent along with the temperature or humidity report. The Temperature and humidity sensor also reports the current temperature, humidity, and atmospheric pressure values during each heartbeat.
The only thing I could improve in my drivers is to parse those temperature, humidity, and atmospheric pressure values sent "during each heartbeat", which is what I call the "check-in", that occurs every 50-60 minutes. Otherwise I have zero control over controlling how often both the Xiaomi and Aqara sensor models report, because it's "locked" in their hardware, as it were.
Since these are "sleepy" ZigBee end devices, in my experience they also seem to employ some "tricks" to save on power usage, meaning they don't seem to report as often as would be implied by Lumi's statement above. For example, it appears they may skip reporting if the check-in time interval is coming soon, because that includes a full set of report values. Also, I have read that temperature reports may take priority as part of the power-saving scheme, such that sometimes a change in humidity isn't reported until there is at least a 0.5° C change in temperature. Only Lumi/Aqara's hardware engineers of the sensor would know...
Another very important point to remember is that the driver is set up not to generate events with redundant repeat values. So for example if the most recent temperature event was 25.4° C and a message is received from the sensor reporting 25.4° C again, no new event is generated because there has been no change in temperature since the last report. This is normal accepted behavior on the SmartThings platform device handlers, and Hubitat follows suit on that.
In addition to it being normal behavior on the platform, quite a few Hubitat users have a strong opinion on keeping the number of events devices produce at a minimum by not generating repeat value events (for things such as battery level, temperature, etc.), but if enough people are interested, I could see about adding a preference to toggle that behavior. However, I'm not sure that will help you with your particular use case / needs.
I really wish there was a PCB "hack" to get temperature / humidity reporting every X minutes like there is for the Aqara Motion Sensor.
Hi. I'm using Aquara sensors for a month, and one of them to control bathroom fan. Reaction for fast increased humidity is about couple of second. This is very nice. But last updates doing something wrong with communication with them. After last update (184.108.40.206) all Aquara sensors stop reporting humidity (!), but temp and pressure ok. I try everything: removing, adding again, reseting and no result. Then I'm get back to 220.127.116.11 and everything working again. Strange.
Do yours stay connected? I have 5 of these and I have ikea plugs acting at repeaters. All my xiaomi motions and temp sensors have been rock solid since adding the ikea plugs. My leak sensors are another story, they never stay on and very difficult to pair or rejoin when the battery dies.
[BETA] v0.4b of of Xiaomi MiJia Honeywell Gas Detector device driver for Hubitat
This driver has since been updated; please see this post for the latest version.
v0.4b Detailed Change List
- Fixed source of
Cannot get property 'descriptionText'errors
- Fixed ZigBee command used to query detector's current sensitivity level
- Fixed ZigBee command used to set sensitivity level
- Fixed method used to set sensitivity level
- Changed handling of catchall messages to ignore every-minute "heartbeat" messages
- Changed log messaging to state sensitivity level in plain English ("low", "medium", "high")
resetToCleardriver command to
ResetHubToClearfor clarity that it will not clear the detector's audible alarm
importUrlfor automated import of updated code from GitHub
- Added check of sensitivity level when detector is paired
- Added state variable to display currently set sensitivity level as "low", "medium", or "high"
- Added info log message to include a "check-in report" of additional data from 5 minute interval checkin messages:
- Internal temperature (unconfirmed)
- RSSI dB value
- Gas density value (unit & scale unknown)
Still To Do
- Add handling to parse check sensitivity level response and level change acknowledgement messages
- Convert sensitivity level state variable into custom attribute used to create device events (if there is enough interest by users)
- Convert Gas density value into custom attribute used to create device events (if there is enough interest by users)
- Convert RSSI dB value into custom attribute used to create device events (if there is enough interest by users)
- Add custom
gasleakattribute used to create device events "detected","clear","tested" (if there is enough interest by users)
I might be able to get some testing done this afternoon, if not then tomorrow. Thanks for all the hard work on this.
You are talking about the latest hot fix from two hours ago? I haven't updated to that yet, so I cannot say if it's an actual issue.
Did you try blowing on any of your Aqara sensors with your warm breath? That should get humidity reports. I would recommend enabling debug log message output first, then try the breath test, and look at your logs to see if there are humidity messages being received or not.
I just updated to the latest 18.104.22.168 and breathed on my sensor and it picked up humidity just fine!
@skowron0451 I'm on the latest firmware and all of mine are reporting as expected. I did the breath test on one.
Yes I'm talking about last hot fix. The "warm breath" test, didn't get any reaction and there was no event in event monitor. Temperature and pressure was reported corectly. Now I have report about every 30 min, all three parameters (and occasionally battery report). I try after feew days to install again this hotfix.
If you have debug log messages enabled - Did you see anything in the logs for humidity reports?
Since two other people are saying that humidity reporting is working fine with hub firmware 22.214.171.124, I expect your issue is not directly related to the hot fix. Also, the hot fix release notes don't mention any ZigBee changes.
You have right - this is not an update issue. Today again humidity is stop reporting. But this is not the same sensor, which yesterday was problematic. I have two and this is the second one. Yesterday I exchange them. Now one sensor reports temperature, humidity and responding for warm breatch test. And second sensor which reports only tempetature and very occasionaly (when I heat few degrees them with hair dryer) humidity. Not responding for warm breatch test. This can be software issue ? Or something wrong with hardware (sensor) ? Problematic sensor is working in bathroom, condensation ?
I have logs from my Aquara sensors after "warm breath". Can you do analysys please ? "Roof" is working ok, but "bathroom" logs only temp and pressure.
Little update. After reconnecting procedure OR restarting HUB there are 2-4 humidity transmissions and stops responding again. This means hardware supposed be ok.
I see drivers for Xiaomi sensors,
i found two different sensor online Xiaomi Aqara Motion Sensor and Xiaomi Mijia human body sensor.
which one is reliable with Hubitat.
i looked for drivers code i dint find for Xiaomi Mijia human body sensor, or is it same driver for both?
My Xiaomi/Aqara Temp/humidity sensors are draining a lot of battery. The are new and I bougth them last saturday, the lost 15-23% in a few days.
My HE is also new and I am new... so a newbie question, should this happen?