I have had an Aquara Temp/Humidity/Pressure sensor on my Hub from early July this year (so about 6 weeks.
It is sitting on my desk so its about 10 feet from my hub. Looking though the logs I see long periods between updating, but my conditions are not changing much. However the sensor had been working consistently since installation.
The only other Zigbee devices are a Pearl thermostat and an early "homemade" board from iharyadi.
Below is a sample of the data I grabbed from the events screen. The last column is the time between Events entries. This data shows ~5 hours up to 21 hours between readings. I've seen as low as 2 hours.
I have yet to do any simulated changes, probably temperate would be the easiest to see what delta's are required to trigger a reading.
I've not been able to find any detailed information on this sensor. If somebody can point me to a website with more info I would appreciate it.
I'm using @veeceeoh 's driver V0.8.2 with the only modification I made was to change kPa to hPa.
Right at the top there, it updated the humidity in just 13 minutes. I use one of these in my bathroom for the exhaust fan and I can tell you that in Winter when the windows are closed, the fan will turn on within a minute
I understand what you are saying. I believe more change = sooner reporting. My instance was / is terribly constant. But it shows what the reply frequency could be if there is little / no change in the environment.
I saw 21 hours before a report in one case. I wonder if I can keep one constant enough to see if there will be a report if there was NO change. Perhaps 24 hours? Or maybe with a battery initiated report.
I got off track a little with my response. My original thought when starting my post was that I had at least one solid sensor that did not drop out in the 6 weeks I had it.
I don't see where you are referring to. Note the column is hh:mm:ss
I haven't looked at the data enough to determine if the battery report includes the envoronmental readings or not. The top line in the attachment suggests the battery report does not include the other sensors, but I'm not willing to say that at this time.
Nah, nothing to worry about. After the most recent release of that driver I realized a number of Xiaomi/Aqara devices send a certain type of message, once during pairing, that the driver doesn't "expect".
Since the driver code is only executed when 1) a message is received from the device, 2) a driver command is used, or 3) the driver requests to run some part of its own code in future on a scheduled basis, this error doesn't "hurt" anything.
Because the message serves no useful purpose, I just need to add code which ignores it so no error is generated. I am currently (slowly) working on updates across all the drivers and that fix will be included.
Yes, in fact all ZigBee devices should be paired in situ. But don't just take my word on it.
Here's a post in another thread just today about this from Hubitat's head honcho:
Everything you have described is perfectly normal behavior for Aqara Temperature Humidity sensors, based on my experience.
You haven't found it because it doesn't exist. These are inexpensive Chinese market sensor devices, not scientific instruments. Here is the best documentation I have found, located in the GitHub repository of the parent company Lumi United Technology's:
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.
Note: when they say "temperature changes over 0.5 degrees" they are talking about changes in degrees Celcius.
Despite what Lumi states above, the reports are not as consistent as expected. I have seen the sensor wait to report on temperature changes in excess of +/- 5° C. Also, temperature changes seem to have priority over humidity changes. So the sensor seems to sometimes wait for a +/- 5°C temperature change before sending a report, even though humidity has changed more than +/-6%.
Also, for those people like yourself who are trying to work with the reported values in a detailed way to generate graphs or look trends, etc., it's important to understand how the driver generates events.
The sensor only sends reports for all readings (temperature and humidity for the Xiaomi model, and temp, humidity, and pressure for the Aqara model). It does not send individual readings. If you don't see readings arriving in groups in the logs, that means there is very likely some issue with the ZigBee mesh connection (i.e., dropped messages).
However, events for then Hubitat Hub are only generated when there is a change. If for example a new temperature reading is the same value as the previous one, no event is generated. This is by design, to avoid spurious redundant repeated values from cluttering the device's events list. It is of course in direct conflict with some people's desire to plot a graph over a specific interval of time, but then the sensor by design doesn't work that way. It reports based one changes, not time intervals - with the exception of the "heartbeat" reports (which I call "check-in" messages).
I will be adding functionality to the next update of the driver to include the temperature, humidity, and atmospheric readings that are sent with each check-in message (occurring approximately every 50-60 minutes). I am thinking about forcing those to generate events regardless of whether the values have changed or not, because I can see that being useful to people who would like to track the values over time for various purposes.
Outside of the sensor reading reports, if you are concerned about whether the devices are remaining connected to the hub, the absolute consistent method for doing this is to look at events for the custom attribute lastCheckin. This feature is not on by default (to keep the events list "cleaner") and needs to be turned on in the preferences for each device:
Thank you for the information. Really I've been quite happy with this sensor. My post was really for those folks asking if they were staying connected......then I got carried away
I figured the only way to tell if they were staying connected was to look at the events log. Being such a large amount of data I couldn't tell by inspection how the sensor was reporting..... the rest is history.
I thank you for sharing your driver. Works fine have no issues at all. Kudos.
Yes the SyIvania plug is on my hot water recirculation pump.
Make sure it is still the non A version I have not test the A version.
I have not had any Xiaomi issues for a very long time.
Xiaomi & Aqara Devices - Pairing & Keeping them connected
Also, I am reworking the opening post to include a very visible disclaimer about Xiaomi / Aqara devices not being fully supported by Hubitat, more information on pairing them in general, and a list of possible solutions / workarounds avoid pairing difficulties and dropped connections.
Not sure exactly what you mean, but I have already added a Best Practices When Pairing section. Everything in that section will help to result in much better success in keeping Xiaomi / Aqara devices connected. Maybe I should just say that under a Best Practices to Avoid Dropped Connections heading?
Hi all...
I know you guys have missing me for a while... not!
Due to health reasons i have been absent but this also gave me the lucky/unlucky opportunity to observe a strange behaviour with my setup.
First my Setup
Xiaomi Sensors connected directly to HUB. No other devices on this network.
Background:
A few months back Xiaomi devices start dropping not showing up on hub (hub dos not record any events, including battery pings) this was noticed as rules stop triggering.
As i was in no condition to go take the sensors from their locations and repair i just left them there.
Now the funny part:
After a few days a few sensors started showing up again, but others were still in silence.... i admit i thought it was that battery on those sensors.
However 2 months late my hub completely hung. As i was using the hub to send the hue lights control i restarted the HUB.
2 days later ALL the XIAOMI devices come online (well except 1 humidity sensor, that one is the battery) this after 2 months of inactivity and no repairing.
My conclusion the Xiaomi devices do not loose the information of the host even after days of no response/connection from the hub.
This was interesting... just reporting it
Now time to update the hub as I'm still a few versions behind.
I can confirm this behaivior also! My first HE deployment has 15 Aqara temperature sensors. Three days ago we had a 26 hour power failure. All 15 were not reporting for nearly 24 hours after the power returned. After that, they have slowly begun to show up and at this point 14 out of 15 have returned to reporting status:slightly_smiling_face:. The last one may still return hopefully. i am also using the IKEA signal repeaters recommended by may here. Very good information. I also have one Aqara wall plug router inserted into my system as my thoughts were maybe having one Aqara router would somehow inject a friendly signal to the network.
Wanted to post something similar to the last few posts. I use the Device Monitor app to tell me when my Xiaomi devices drop from the hub. Today all 10+ of my devices stopped communicating with the hub. After rebooting the hub a few hours later (12 hours after last checkin), all of my devices successfully reconnected to the hub. Any idea what's going on? Is there a way to trigger a hub reboot, don't think I saw an option to do this using Rule Manager?
Not sure if a reboot itself would help.
I believe this has more to do how the zigbee stack is built to monitor zigbee traffic to ensure multi brand compatibility and hubitat probably has almost very little to nothing they can do, if I'm correct.
Nevertheless it raised a question to me that us two-fold, if neither the devices or the zigbee stack looses (apparently) the network information, than what triggers the hub to stop receiving the information in such way that not even the battery pings check in is received or what happens on the Xiaomi/Aqara devices that stops sending information to the habitat hub.
Would be interesting for those with xbee to check if when the hub stops receiving and processing events ("Drop") if the Xiaomi devices are still trying to reach the zigbee controller every hour. If this happens than is the router is not acknowledging the network information being fired by the xiaomi devices.
What channel seems to work for people ? Looks like I need to try 13 according to this thread.
I spent yesterday resetting my zb settings on HE. Had all my nue dimmers removed (for other reasons ) and set everything up again with repeaters first following the ZigBee tips from HE.
Brand-new batteries for the xiaomis and still they are sleepy. And half disconnect.
I am on channel 20.
Perhaps it's my swannone outlets (ZigBee 1.2) that are bad repeaters for these sensors.
right - i can't get those in australia yet which is frustrating. it's either those repeaters i get or hopefully the Aqara T1 motion sensors get released this month still
. The last one may still return hopefully. i am also using the IKEA signal repeaters recommended by may here. Very good information. I also have one Aqara wall plug router inserted into my system as my thoughts were maybe having one Aqara router would somehow inject a friendly signal to the network.
