I have a WXKG11LM in my garage and when it works, it works good.
But often if stop communicating. I have an IKEA outlet as extender and I have read that Aquara can have problem with extenders so I will replace the button for a ST button to see if that works better.
Before making the switch, is there anything I can do to get the Aquara button to preform more stable?
If you're already running my drivers you are doing all you can in software while still keeping the device on HE directly. Any other fixes are mesh related, to know what to advice there, much more information would be needed about your mesh, like what all your repeating devices are and how many endpoint devices you have. If you have an Xbee and can give a map of your whole mesh that would also help. For mesh issues, please re-post in another thread.
So far so good with the ST button. But the Aqara worked fine as long as it was working. Need a week before I can see if the ST works better with the IKEA wall plug as extender.
I will use my Aqara button in a position where it “talks” to my HE directly.
@markus, I know greglsh ended up not needing this, but I think it might be helpful for a use case I have - unless someone knows of a different way to achieve what I am after. I would like a simple way to see on a tile what time a contact last changed - and ideally, its state.
Using the Attribute Template, if I select lastClosed as the Attribute, it shows the epoch string, not the readable time. Is there a way to achieve what I am after? I could use TileMaster to combine the 2 if needed, but at the end of the day, if I could just see the last closed in the time format, that is all I would need.
Just activate the setting "Log Open/Close Time" in preferences.
The epoch in the screenshot is about 1 month old, so that must be from the driver by @veeceeoh, right?
Not seeing that option - I am sure this is your driver (I took off the @veeceeoh ones ages ago and use
No, I am using your driver via Package Manager and it is showing as up to date??
EDIT:
Ah, yes, it has not yet made it to the non-Beta release of the driver, forgot about that. I might push it into release this weekend, otherwise it is available here as Beta.
Ah ha. I've gone ahead and updated the driver.
Yep, that seems to have done the trick. Thank you very much for your help (and the driver) 
Actually, I might have spoken too soon. It looks like it is showing the date/time for lastOpened, but still the epoch for lastClosed. Note: I did remove and re add the lastClosed tile.
Opening and closing the contact seems to make it update
Yes, it needs an event. The Epoch was from a previous driver, not mine.
To ALL here, I want to let you know how many people have struggled to get these drivers in place. Many have done great work, but this latest set from Markus, are nothing short of incredible. I recall a long time ago people argued that the performance of Xiaomi devices couldn't be affected by the driver, "the devices don't follow the standard", etc.
I'm not sure what black magic, if any, was included, but I can tell you 100%, my xiaomi devices have never worked better than with Markus's drivers.. So much so I'm actually re-deploying my Xiaomi devices, where prior they were in the junk pile.
Just yesterday I found an aqara flood sensor had fallen off about 6-7 days ago, due to a dead battery.(it had a "non-present" count of over 70-another amazing Markus driver feature) With previous drivers, this was the death blow, oh but not this time. I changed the battery hit initialize, and like magic the device came online, without having to re-pair, as I was always forced to do.
A shout out to @Somel, who argued extensively that drivers could make a difference with Xiaomi devices, based on my experience he has a valid point and these drivers make that point.
Here's my story for you and @markus.
~10 days ago, I was in bed recovering from surgery, when I noticed that none of my morning automations had run. I discovered that overnight one of my cats had pulled the power cord out of my Xiaomi Hubitat. When I plugged it back in, every Xiaomi sensor was disconnected - and I was in too much discomfort to go to each one and re-pair it (there's over 40). So I just let it be.
Later that afternoon, I noticed that Xiaomi-sensor dependent automations were working again. Every single sensor had re-paired by itself over a 2 to 3 hour period.
That would have never happened before @markus' drivers.
I currently have my Xiaomi devices connected to a MI Home hub and then to HE using docker on an RPi using the Mi Connect app. This is working well with no issues BUT it has introduced another step in the chain for my automations which must extend the execution time albeit minimal.
I may just slowly put my Xiaomi/Aqara devices directly on my HE hub and see how things go.
Hhhmmmmm...........
@markus I have to agree that these drivers are making the Xiaomi devices really viable to be used as the main devices in my HA setup. Just a huge shout-out to markus for the time he puts in to this platform.
Thank you
Well that stinks. I hope all is well, and recovery is speedy my friend
Wish you a speedy recovery!
It makes me very happy to hear that the drivers are making a difference! My philosophy when making drivers is to emulate the original environment as much as possible. In the case of these drivers I did so as far as what can be done from inside a driver, but I also added some more aggressive methods to help in keeping devices on the mesh 
This doesn't help against all types of reasons for falling off, but many of them. For the remainder I still need to do more research.
The reliability of these sensors with your drivers (and compatible repeaters) is about the same as I have with any other zigbee end-device that is on the Hubitat compatibility list. I would say that is a huge achievement.
Download the Hubitat app
