Not sure if anybody using the original Xiaomi buttons but was wondering if anybody else recently found the single click is not working well? Sometimes it works after a hub reset but most of the time it now considers it a button hold instead of a button push. Increasing/decreasing hold timer didn't do much.
Changed battery, that didn't do much.
Could it be too many zigbee devices or something overloading the hub that can cause this?
Not had any issues with mine thus far...
Sorry, I have 2 and I'm not seeing this. My hold is blank so the default 1 second. Had it been working correctly for a while? Seems to be a button issue. I don't think it would be anything to do with number of devices or the hub. It sound like the button is just sending the wrong signal for whatever reason. Is it possibly sticking? Just spit-balling here.
I have 5 or 6. I think it's a hub issue because the hub seems sliggish when this happens. I assume I need to research how to improve performance on hub when by ways of removing things or devices. Not sure how to debug that with the logs yet to see what's hogging the hub utilization
Ok, I kind of found how to reproduce and avoid the issue of the xiaomi button. If I click the button too fast then the countdown times out to the "held" state. If I click and hold a couple of seconds then it works as a single click.
So I guess if HE slows down a bit on executing the event handler than this situation will happen due to two events happening on top of each other. Not sure how to fix in code.
Here is how I observed it with the log file in view:
When I pushed the button, these messages came up on the log:
dev:5162019-11-24 04:11:13.959 pm debug Living Room Couch Button: Button press detected, starting heldState countdown of 10 second(s)
dev:5162019-11-24 04:11:13.462 pm debug Living Room Couch Button: Setting buttonPressedEpoch and buttonPressedTime to current date/time
dev:5162019-11-24 04:11:13.284 pm debug Living Room Couch Button: Message payload: 00
dev:5162019-11-24 04:11:13.282 pm debug Living Room Couch Button: Parsing message: read attr - raw: 02C20100060800001000, dni: 02C2, endpoint: 01, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00
After I get the debug message of the "Button press detected, starting heldState countdown of 10 second(s)" , I release the button and it works as a single click. Unfortunately that message takes 1-2 seconds so I need to hold the button a bit. If I release before these messages the second "release" event begins and screws the whole thing up (I can see the message mixed in order for press and release). That means it will end up timing out and creating the "held" event.
So I guess two things come out of this, the driver cannot handle multiple events, and my hub must have slowed executing the event handler for the driver 
I can try to hack the driver to work with some boolean magic but if anybody else has a suggestion, greatly appreciated 
(Also I need to figure out what is slowing down the HE which appears to be a huge undertaking from all the other messages).
Just set up a rule to automatically reboot your hub every night.
I guess that works for some but for me even after a proper hub reset it still has this issue still digging and reading the many others with this issue. disabling tons of custom stuff and can't seem to pin point it yet.
Chromecast (beta) caused an issue for me and I disabled it.
Just throwing it out there in case you are using it.
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?
