Glad I shared it then!
It is the original model and yes, it did drop in connection at the time I took the screenshot but I got it connected back using the method we had talked about earlier.
Sadly, this is the only one among all my sensors, that keeps falling off, even though it sits closest to the hub! 
Another update for new devices I triedâŚ
This one was again with a4refillpadâs ST code.
Xiaomi Button (Original)
- Pairing succeeded on very first try
- Device hasnât fallen off after 2 hours.
- Pressing or holding of the button is not reported. Neither is the battery. Only the LastCheckin keeps getting updated.
So - if you have any other "original" Temp/Humidity sensors - have they reported a battery percentage at all?
I'd suggest looking through the Events list for each of them. Go to the Device List, select the device, and click Events at the top:
Any battery report will be in there, like this:
If there's no battery reports, and the sensors definitely have stayed connected for more than an hour at a time, then really the only way to troubleshoot this is for me to add a debug log output of the raw messages received from the sensor, and ask users to leave a browser window open with the Hubitat Logs, so we can capture what's going on.
One other thing - as I mentioned previously, with my "original" T/H sensors, when I reconnected them using the reset short-press method, the first thing they did was send a "status" report which gives the device driver the battery data so it can report battery percentage, so you should hopefully see the same. Have they done that for you?
I actually have one of these, and have been working on revised ST device handler code for it as part of the bspranger/Xiaomi repository.
The a4refillpad battery reporting method definitely doesn't work correctly, so that's no surprise here. Button press / release messages come across differently to the Hubitat (i.e., in raw data format), so that's why they aren't recognized.
I know what needs to be done, but the way the button capability is done with the Hubitat is different from SmartThings, so I need to mull over the best approach making the device driver work best for everybody.
One thing I don't like about the a4refillpad method is that it doesn't send the "held" state message until the button is released. So you have to practice and know how long to hold it for it to be considered "held", as opposed to having immediate feedback once you've held it long enough (e.g., After holding for 3 seconds, the lights go on, so I can release the button).
Add to this the fact that this button actually supports multi-click (2x, 3x, & 4x) in its hardware, but those messages were never available in SmartThings, because the ZigBee API "filters" out those messages. Either way, it does mean that the hardware itself has a slight lag on the response to a short single-press (which in the a4refillpad method would generate a "pressed" state message). So what happens is if you press and release the button quickly enough, the "pressed" state message can get skipped.
Since the Hubitat ZigBee API allows the device driver to receive all the different messages for multi-clicks, I will have to take a completely different approach to the logic of the code.
Long story short, I'd like to make sure the dropped connection issue is/can be resolved before starting that little project.
[RELEASE] v0.5 of unified Xiaomi Door/Window contact sensor Device Driver
Works with both the Xiaomi âoriginalâ and Aqara models
For convenience please copy the D/W sensor device driver code from this direct link.
This is a unified Hubitat Device Driver for both the Xiaomi âoriginalâ and Aqara Door/Window contact sensor models. Basic use is the same, with the only difference being the battery reporting, which is handled in the code.
Features:
- The Hubitat hub should correctly select this custom device driver for both contact sensor models when paired.
- The date/time of the most recent opening of the contact is stored as
lastopen(human readable) andlastOpenDate(java format). - The date/time of the most recent report of any kind is stored as
lastCheckin(human readable) andlastCheckinDate(java format). This may be useful in determining whether the sensor is still connected, since a status report including battery voltage is sent every 50-60 minutes. - Battery replacement date tracking, stored in
batteryLastReplacedstate - Commands / Preferences include:
⢠A Reset Battery Replaced Date command to track battery life
⢠Reset To Closed & Reset to Open commands to manually override an open / closed event
⢠Date / 24-hour clock settings for display oflastCheckin
⢠Min/Max voltage values used to calculate the battery percentage
Notes:
- This device driver is not final, and some features or preferences may be added / removed
- The Aqara Door/Window sensor is special in that you do not have to wait 50 minutes for the first battery report. After it is paired, just short-press the reset button, and the battery level will be reported. However, a couple times I did this, the sensor immediately dropped its connection (see the next note for details on how to reconnect).
- I have four of each kind of these sensors, and in most cases, they dropped their connection around an hour after pairing, either just before reporting battery level (for the âoriginalâ model) or just after (for the Aqara model.) A few times, they stopped reporting open/close events within a few minutes. To reconnect them without deleting them from the devices list, I have to put my Hubitat in âDiscover Devicesâ mode, and then start with a LONG-press of the reset button, watch for 3 quick LED flashes, and if not, keep short-pressing the reset button until the LED does flash 3 times. It wonât show up as a device to rename because itâs already in the device list.
1 Like
Sure enough, your assessment was spot on! 
I hadnât checked the battery reporting after the sensor was re-paired but when I did, the battery report was right there as you had predicted. Will watch if there are any other inconsistencies.
Thanks!
I didnât realize that this button supported multi-click too and that ST was the culprit there.
I am glad that you are considering these minor user experience related aspects around holding the button and getting immediate feedback.
Given the amount of thought and effort you are putting in and considering that the Xiaomi devices are working quite well with Hubitat now, you might have just made the prospect of buying these cheap sensors a lot more attractive! 
BTW, your newly release contact sensor handler also works perfectly! The lastopen timestamp is a nice and useful addition. Thanks again!
Only if the dropped connection issue can be resolved, of course. It would be really great, because these contact sensors are a no-brainer at $7-9 each.
Actually the lastOpen state was already in the bspranger/Xiaomi SmartThings device handlers, but thanks.
1 Like
A bit of an update on my findings with the "original" Door/Window contact sensors maintaining a connection.
One of mine stayed connected for over an hour, and dutifully reported open/close events, but I saw no battery reports. When I short-pressed its reset button (which is supposed to "check the network state" according to Xiaomi, as seen below), it immediately dropped its connection after sending a "status message".) Only after going through the reset button LONG-press steps I outlined above did the report with battery information arrive.
My guess is there's some kind of authentication or negotiation step that needs to happen, centering around the status message that contains the battery data. That information isn't given in the Hubitat logs or elsewhere, so I'd need to get a ZigBee sniffer device to see exactly what's happening.
I found this some time ago and haven't shared it here on the Hubitat forumes yet, but this is Xiaomi's explanation of the functions of the reset button and meaning of the LED flashes when the reset button is long-/short-pushed in different situations:
Nearly all Xiaomi sensors follow these same behaviors, or are very similar.
2 Likes
[RELEASE] v0.5 of Xiaomi Aqara Leak sensor Device Driver
For convenience please copy the device driver code from this direct link.
Features:
- The Hubitat hub should correctly select this custom device driver when paired.
- The date/time of the most recent detection of water is stored as
lastWet(human readable) andlastWetDate(java format). - The date/time of the most recent report of any kind is stored as
lastCheckin(human readable) andlastCheckinDate(java format). This may be useful in determining whether the sensor is still connected, since a status report including battery voltage is sent every 50-60 minutes. - Battery replacement date tracking, stored in
batteryLastReplacedstate - Commands / Preferences include:
⢠A Reset Battery Replaced Date command to track battery life
⢠Reset To Dry & Reset to Wet commands to manually override an wet / dry event
⢠Date / 24-hour clock settings for display oflastCheckin
⢠Min/Max voltage values used to calculate the battery percentage
Notes:
- This device driver is not final, and some features or preferences may be added / removed
- The Aqara Leak sensor is like the Aqara Door/Window sensor in that you do not have to wait 50 minutes for the first battery report. After it is paired, just short-press the top of the sensor, and the battery level will be reported.
Special Pairing Instructions
The Aqara Leak sensor is (supposedly) watertight, so there is no hole or reset button. The reset button is just underneath the center of the top shell of the sensor itself. When pairing, I recommend orientating the droplet icon upside-down to view the LED more easily, like this:
The pairing for the Leak sensor works a little differently from all the others:
- To put in pairing mode, hold down the center of the top of the sensor.
- Release when the LED flashes. After a pause, the LED will flash again.
- If you see 3 quick flashes continue with the next step. Otherwise, start over at step 1.
- Repeatedly short-press the top of the sensor to keep it awake during initialization.
- You can stop short-pressing when it appears on screen ready to rename.
3 Likes
[ANNOUNCEMENT] Progress towards resolving the dropped connection issue!
Earlier today, Hub update 698 was announced, which lists âUpgrades to Zigbee functionalityâ as one of the improvements.
I applied the update, deleted and re-paired over a dozen of my Xiaomi devices to see if they would maintain their connection to my Hubitat hub.
I am pleased to report that all of my Temp/Humidity sensors (both models) made it past the 60-minute mark and sent their âstatusâ reports that include the battery data for the device driver to generate a battery level event! Thatâs the longest Iâve seen them stay connected, and the first time Iâve seen a battery report without having to reconnect them.
Meanwhile, my âOriginalâ & Aqara Door/Window contact sensors, Aqara Leak sensor, Aqara Motion sensor, âOriginalâ button, and 2-panel wall-mount switch have remained connected for more than 60 minutes, still sending reports, but just not the âstatusâ report with the battery data, unfortunately. Iâm going to leave everything just as it is overnight and see if theyâre still connected and reporting.
Either way, this is great news and some real progress towards resolving the connectivity issues with the previous hub version. Hats off to the engineers!
UPDATE:
After the two hour mark from pairing, ALL of my Xioami devices were sending âstatus reportsâ which is evidenced by battery level events every 50 minutes for Aqara models and 60 minutes for the Xiaomi âoriginalâ models. Theyâve all been connected for 12 hours now, which is great!
7 Likes
[WORK IN PROGRESS] Xiaomi "Original" (round) Button - Seeking feedback
So I've done a bunch of testing with the Xiaomi round button, and Iâm hoping to get other userâs input on what theyâd like from the device driver before I sit down to complete it.
This is because the buttonâs hardware supports multi-clicks, and sends unique messages for double to quadruple-clicks.
Here's a handy chart (with some oversimplification of the messages received):
Observations during testing
- None of the multi-clicks return the "release (01)" message unless the button is held down on the last click
- If the button is multi-clicked too slowly then the "release (01)" message is not sent between clicks, only once, after the last click. For example, if I Quadruple-click slowly, I see four consecutive "press (00)" messages followed by a single "release (01)" message. This behavior is something that users will have to be aware of, and discover for themselves what the best speed is for multi-clicks to be properly registered.
Here's the catch, though: The button capability is handled differently on the Hubitat than in SmartThings, as explained in this forum thread. Capabilities are what shows up in apps (like Rule Machine) for a particular device that allows things to happen when the device's state changes in the capability.
For buttons, there are three options to work with:
- Capability
PushableButton, with the state namepushed, and a numerical state value for the button number - Capability
HoldableButton, with the state nameheld, and a numerical state value for the button number - Capability
DoubleTapableButton, with the namedoubleTapped, and a numerical state value for the button number
Although there isn't a named state released, the "release (01)" message from the button could still be used, for example, with a timer as a way to decide whether the button press should be considered pushed (a 'click' as called in my above table) or held, so that an app can take different actions based on either of those.
So, what I need to decide is how best to map the different behaviors from my chart above to the three available states (keeping in mind each button number value can correspond to a different action). Then I can finish work on the round Xiaomi "original" button device driver.
Any feedback or thoughts would be greatly appreciated.
Can you just set it up as a virtual 4 button-button? So button 1 = one click, button 2 = double click, button 3 - triple etc.
Then for the hold, set a variable for the clicks, then output the hold to that button equivalent? IE if you click 3 and hold the last, itâll count the 3 clicks, put to a variable, then read the (01) and output the hold3? Does that make sense?
1 Like
I like that idea as well.
Yes, that was my first thought. But then there's potential for user confusion.
There's no way to know if the button was held or just clicked until the "release (01)" message is received, and multi-clicks without hold never generate that "release (01)" message like the single click does.
This means a countdown timer (using runIn() in Groovy) is needed to decide whether the button was held or not. So when a "press(xx)" message is received, the countdown timer is started. Meanwhile, if a "release(01)" message is received, a button released flag is set. When the countdown timer is finished, it checks if the button released flag is set, and if it's not set, then the driver sets the "held" state for the button number that corresponds to the number of clicks.
This can be a user-set preference, of course, but what messes things up is if the button is clicked or multi-clicked several times before the countdown timer is finished. I can imagine people complaining and being confused about the strange behavior that would occur in this situation, and there wouldn't be any way to change it that I can think of.
So as long as people stick to clicking or holding the button within the countdown delay they have set, then it should (in theory) work properly. Call it a limitation of what would be a very multi-functional button driver, I guess.
The other option is to have a settings switch for complex and simple. The simple only allows hold on single click. The complex has the multiclick + hold for advanced users.
[BETA] v0.5b of Xiaomi âOriginalâ (round) Button Device Driver
For convenience please copy the beta round button driver code from this direct link.
So I realized that a "hold" feature is only possible for single press, because normal multi-clicks are not immediately followed by a "release" message from the button. That mean's there's no way for the code to know whether the button is being held on the last press of a multi-click.
Here's a chart of what happens with each kind button press:
EDIT: Multi-click over 4 --> pushed - button 5 (Added in v0.6b)
("click" means press & release quickly, same as computer mouse)
Other Features:
- The Hubitat hub should correctly select this custom device driver when pairing.
- The date/time of the most recent opening of the contact is stored as
lastopen(human readable) andlastOpenDate(java format). - Battery replacement date tracking, stored in
batteryLastReplacedstate - Commands / Preferences include:
⢠A preference to set how many seconds to wait until "held" event is sent
⢠A Reset Battery Replaced Date command to track battery life
⢠Date / 24-hour clock settings for display oflastCheckin
⢠Min/Max voltage values used to calculate the battery percentage
Notes / Limitations:
- This device driver is BETA, so some aspects of the driver may not work, and some features or preferences may be added / removed
- I am hoping people can test this device driver in use with Rule Machine and some switchable devices such as lights, to give feedback on the responsiveness and reliability of the driver in normal use conditions.
Possible enhancement
- Since the button generates a released message after a held button is released, if anyone believes it could be useful to link that to a Hubitat event, I could add that to the code. Options include linking the release to
doubleTapped-button 1, orpushed-button 5, as a couple of examples.
3 Likes
Thatâs good news, looking forward to trying this out later tonight! My button has remained connected; reporting hourly for several days now, even reconnecting after the hub had been power cycled for some equipment re-arranging.
I installed this and find it to be working great so far. Buttons register the expected click action reliably; great to see battery % and voltage appear in the log instead of hex numbers.
I set up a couple of buttons with a half dozen Simple Lighting rules to support a button mounted at each of the sliding doors at the ends of my deck; I set it up so that a single click toggles the nearest outside light, a double click turns off both near and far lights, and triple click turns on both lights. Easy to remember and convenient to use.
I verified that Rule Machine works for triggers; but its only toggle function âToggle Dimmerâ is not useful for me. This isnât a fault of the driver (âToggle Dimmerâ only turns on my GE Z-Wave dimmer but wonât turn it off; I suspect this is another Lutron-only supported feature).
Thank you for this. Its great to have support for a button that looks good on the wall and has great tactile feedback; multi-click support is a welcome bonus.
1 Like
Thank you for reporting back on how the driver's working for you. I will have a chance to do some investigating into using Rule Machine or another App to set up toggle actions for dimmers, since I have a few (including the GE Z-Wave Plus Dimmer) myself.
On a slightly-related note, I have just learned that there is now an "upgraded" model of the Aqara button, which has four functions: click, double-click, hold/release, and shake. The model number on the box and back of the button itself is WXKG12LM. It's so new that it will be difficult to ensure that is the model being shipped when buying from direct-from-China resellers like GearBest, etc. I am going to try to secure a couple because the messages they send are completely different and it will need a separate device driver.
