thanks bobbles. I uninstalled that but no go yet. I'm going the disable path but hate to disable all TP-Link devices and Xiaomi devices. It's getting tougher to narrow down.
If you have disabled Chromecast, make sure you either disable the rules that are using the Chromecast device or select a different device in those rules.
I deleted anything chromecast related and echo speak as well. I do have a C5 I have not hooked yet. I guess I may go the 2 hub route. Still using the old C4 which worked great for the year until recently. The only worry I have now is if it is TP-Link integration. It's 3rd party but man I spent a lot on H300s and hate to turn them all off 
Don't forget:
After you shutdown your hub, wait 10 minutes before turning it on again!
Hi everyone! Sorry that I've not been around much. Life has been.... busy.
I would never consider the reported percentage to be "accurate". It's just a direct conversion from the most recent voltage reading message divided by the difference between the "assumed" minimum / maximum possible voltages of the battery.
The issue with this method of calculating percentage, as I've mentioned in past, is that it's too simplistic, and doesn't actually tell you what the remaining battery capacity is. A much better way calculate battery capacity is to know its maximum mAh (milliAmp hours), current mAh, and the mAh at which the battery will stop providing enough power for the device to work correctly (i.e., the minimum mAh).
Unfortunately Xiaomi / Aqara devices don't let you know the current mAh value of their battery. So the rough percentage estimate is all that can be used here. Where it becomes less accurate is if the min / max values aren't accurate. So for example, if the max Voltage value is too low, a percentage of 100% will be seen until the reported battery voltage goes below that max value. I suspect that's what is happening in your case. Which is actually a good thing because the voltage level is going down really slowly, and the battery/batteries is/are lasting a long time.
There is no button 2 for double-click. With the latest version of my Aqara button driver, you will get button 1 doubleTapped when you double-click the WXKG12LM button.
Please see this post.
You can use button 1 doubleTapped for your double-click automation.
As suggested by others, this is an issue with the hub code execution being slowed down, likely from a driver / app that is causing an I/O bottleneck. It is definitely not caused by any Xiaomi / Aqara drivers, because they are for ZigBee devices, which make a negligible impact on the hub's I/O performance.
If you are seeing timing issues with such simple drivers as the Xiaomi / Aqara ones, then you are going to have all kinds of timing issues with all drivers / apps. The Xiaomi / Aqara drivers use the same Groovy language methods for taking actions based on timing that Hubitat's built-in drivers and apps use.
Really the best approach is to hunt down the reason for the I/O bottleneck and eliminate it. Restarting the hub daily or editing the drivers' programming logic to try to circumvent the issue is just a road to continued frustration.
1 Like
I noticed recently (maybe the last few months) the temp sensors would throw a weird humidity value every now and then. It was throwing off my master bathroom fan automation and I finally got annoyed enough to look into it.
Every 4 or so reports it would report a value of 654.4 (and its always the same). Below is the relevant log from one of those reports so you can see the raw values etc its getting. FF9C is the strange value that is reporting. I've confirmed this on a few sensors so not sure if its from a hub change recently (I'm running the beta firmware).
Master Bathroom Sensor: Creating event [name:humidity, value:654.4, unit:%, descriptionText:Humidity is 654.4%]
Master Bathroom Sensor: Humidity is 654.4%
Master Bathroom Sensor: Raw reported humidity = 654.36%
Master Bathroom Sensor: Message payload: FF9C
Master Bathroom Sensor: Parsing message: read attr - raw: 1D970104050A0000219CFF, dni: 1D97, endpoint: 01, cluster: 0405, size: 0A, attrId: 0000, encoding: 21, command: 0A, value: 9CFF
Have you seen this?
Completely agree. I am down the path of sorting it out. I think I may have found the issue being a bad ZWave device blasting the hub but still investigating.... (It was a Coolcam ZWave light switch which went bad). Not sure if that's the answer yet. Splitting to two hubs as well so I can better analyze future slow down issues as well. (Hubconnect) so it's taking me some time. Also moving all RM from 3 to 4 is taking time as well.
I too have been noticing over the past few months that my xiaomi buttons is not registering button presses properly and seeing them as holds. I'll start checking other devices to see if they're causing I/O slowdown.
Just noticed the following error messages on a couple of devices:
- Original xiaomi round button on latest driver 0.8.5:
[error] java.lang.NullPointerException: Cannot invoke method getAt() on null object on line 73 (parse)
and
2} Aqara temperature and humidity sensor (square version) on 0.8.2:
[error] java.lang.NullPointerException: null (parse)
I have no idea what the issues might be unfortunately.
Hi I am a new Hubitat owner.
I have many of Aqara Smart Wireless Curtain Motor (B1) ZNCLDJ12LM any way driver is available for these ?
I have never seen any out-of-bounds humidity values reported from any of the Xiaomi or Aqara Temperature-Humidity sensors.
It's concerning that you're seeing that value as often as you are. The raw read attribute message is correct correctly formatted for a humidity value report, but the last two bytes - the message payload with the humidity value itself - make no sense.
What are the surrounding reported values like? High or low?
These errors are from non-useful messages that the drivers weren't written to ignore. I need to add code to skip them which would get rid of the annoyance of the errors. However, those errors won't stop the driver from working as expected otherwise.
I don't personally own any Aqara Curtain Motors, so I would have no way to test a driver. It's possible to port the SmartThings device handlers, though. It would require some end-user testing to get it working.
Hi,
I have the Xiaomi original motion sensor but it only detects motion once per minute. I can set it to become inactive after x seconds, but it only detects motion again after 60 seconds and it only become active again after that time.
Is this the normal behavior? or is there any way to change this?
Thanks for that (and also for the time you've put into the drivers! 
)
On a new note I know you've mentioned somewhere that we have no control over the reporting frequency for the aqara temp/humidity sensors but it's the only xiaomi device that seems to burn through batteries (1-2 months max, whereas my other sensors are still running 1 year on). Would the original xiaomi ones be a better bet? I really don't need to know the temps every other minute 
Yes.
Yes to that too.
There is a mod out there in one of the threads that will allow the sensor to be ready to report motion every 5 seconds instead of the default 60 seconds.
Have a search you may find it or can someone else point us in the right direction?
Here it is.
1 Like
It is the normal behavior, and can't be changed programmatically. However...
It can be changed with a fairly simple hardware modification, if you're not afraid to open up the motion sensor:
And here are some additional notes by Hubitat user @SmartHomePrimer:
Hmm, I have bunches of both the Xiaomi and Aqara-branded Temp-Humidity Sensors and all of their batteries have lasted well over a year, with the one exception being an Aqara sensor I've mounted just outside my front door. I am not surprised by the shortened battery life on that one because of the colder temperatures.
Either way, the Xiaomi-branded sensor reports based on temperature / humidity changes, the same as with the Aqara one, so you wouldn't see much difference in the frequency of reporting. I honestly don't have enough data with battery life to know which of the two lasts longer given the same battery brand / age.
1 Like
Thank you for your answers, seems like a simple hack and I'm going to try it.
I will let you know how it went
1 Like
No worries thanks. I've only got the one aqara sensor but have a couple of the originals on the way to compare.
I have 65 Aqara Temp/Humidity/Press sensors running for about six months now, the only ones where the batteries show a significant voltage drop are outside in the cold. The indoor sensors have an initial voltage drop during first week or two then stabilize.
1 Like
Holy mackerel! That's a lot!!
I notice this with both temperature and humidity on one of my sensors as well, but it's one that I've kept outdoors (covered, but outdoors) and just figured the weather finally got to it. It did it even when I took it inside for a while (wasn't sure if sub-0-degrees C temperatures were special; I know they've been problematic before). None of my other sensors--all of which have remained indoors the whole time they've been in use--have been doing this.
I'm not sure exactly how these two anecdotes would connect unless perhaps the bathroom has excessive humidity on occasion or it's very near a water source (I wouldn't doubt that there's been condensation on or at least near my outdoor sensor at some point). I told myself that at this price, I don't care too much...but I am trying to figure out how to get the several-hundred-degrees-below-zero readings out of my Home Assistant history graphs. 
1 Like
