As long as all zigbee repeating devices are compatible, the Xiaomi devices will be reliable. The HE hub itself is fine with Xiaomi devices.
Thanks!
Sounds good!
I discovered that reliability for a big part comes from a strong mesh. The Trådfri devices have been very solid and ST has been quite reliable.
I remember the first Xiaomi devices not sticking because of the 50/60 minute check-ins, which eventually was solved, and then ST re-introduced the issue with a firmware update (following Zigbee specs).
100 eh? 
I have two of them. They gave me a hard time, but within 3-4 attempts, I was able to get them to pair. But 100, well that is something.
Try removing the battery for 10 seconds. Reinsert then hold the pairing button for 10 seconds. Release, and wait for 10 before attempting the pairing again as described above.
If you have no compatible Xiaomi repeaters, such as the TRÅDFRI outlet or TRÅDFRI repeater, then you will have to be near the hub and the final installation distance will be limited to between 20-30 feet.
You should add compatible repeaters if you don’t have them already. It will keep the Xiaomi devices stable on HE. Otherwise they will drop off from time to time. This is not what you want from a leak sensor obviously.
Welcome to the Hubitat Community. Some say they have good luck with Xiaomi bulbs as repeaters, but in general this is not a good idea. Zigbee bulbs that repeate tend to do so nicely for other bulbs of the same or similar compatibly, but for devices, they tend to drop packets so frequently that the mesh becomes unstable and devices drop off, especially the not fully compliant Xiaomi.
However, I’ll echo @aaiyar in stating the TRÅDFRI outlets and repeater, both Zigbee 3.0 and compatible with Xiaomi (confirmed by many with a Network map via Xbee, myself included). I have zero drops with two TRÅDFRI outlets and a dedicated TRÅDFRI repeater in a 1200 sq ft home. One repeater per floor.
Many of us (me too) have all Zigbee lightbulbs on a Hue bridge so the bulbs have their own Zigbee network and cannot interfere with the non-bulb devices. Or we have Sengled bulbs on the main hub, as they are the only Zigbee bulbs that don’t try to repeat the signal, and so are fine to have paired together on the same hub with other devices.
Others have the bulbs on a separate HE hub and use the HE Link to Hub app, or one of the community integrations to link the two hubs. Great discount on the HE hub. Ends today though, so if you decide to go that route, order before the day is out.
Thanks!
I have been using the bulbs in nu setup for awhile without any hiccups or dropped messages.
Keeps fingers crossed
[BETA] v0.1b of Xiaomi MiJia Honeywell Gas Detector device driver for Hubitat
This driver has since been updated; please see this post for the latest version.
4 Likes
[UPDATE] v0.6.1 of Xiaomi MiJia Honeywell Smoke Detector device driver for Hubitat
So while working on the new Xiaomi Gas Detector driver, I noticed a typo I made in the Xiaomi Smoke Detector driver code which will prevent the sensitivity level change feature from working. That has been fixed.
Also, I have learned that there is a way to ask the device what its currently set sensitivity level is. This can be accomplished in this driver with a new Check Sensitivity Level command, found in the Hubitat hub's web UI device details page for a paired smoke detector. Press that command button in the web UI and the smoke detector should return a message with data representing the currently set sensitivity level. For now, this data will only show up as a debug log message (your driver will need debug messages enabled).
If anyone with a Xiaomi Smoke Detector could please report back with debug log output that occurs immediately after using the Check Sensitivity Level command (if it is actually working), then I can use that data to add code to parse the response message and produce a plain English info log message (and perhaps a state variable that can be viewed on the device details page.)
The updated Xiaomi Smoke Detector driver code can be grabbed from here.
Detailed List of Changes
- Fixed a typo that prevented sensitivity level change command from working
- Added
Check Sensitivity Levelcommand (untested) which should result in a message from the sensor (received as a debug log message) with data representing its currently set sensitivity level. - Improvements to description / explanation text in the header section of the code
1 Like
Thanks, @guyeeba! This four lines of log output tell me three things I need to fix in the driver! 
So, sensitivity level "67174400" corresponds to "high". What catchall message do you get if you Check Sensitivity Level after setting the level to medium or low?
Medium:
Low:
Strange...
But this one is even stranger: One more Check Sensitivity Level press causes this:
Hmm, well I think the Zigbee write attribute command that sets the sensitivity level might not be working.
sensitivity -> [0x04010000:"High"],[0x04020000:"Medium"],[0x04030000:"Low"]
zigbee.writeAttribute(0x0500, 0xFFF1, DataType.UINT32, Integer.parseInt(sensitivity), [mfgCode: "0x115F"])
Is the payload definitely supposed to be UINT32?
Hmmm... I can't find my packet captures, most probably I deleted them... But at the time of writing the driver I double-checked, and HE sent the same command (besides the obvious differences: addresses, counters, checksum...) that the Aqara hub sent. I make mistakes, though... 
But I think the command is right.
For the sake of completeness, the very same Aqara hub sends a non-working command (disconnecting switch from button) to a kind of wired switch, so IMHO it IS possible that I just copied 3 mumbojumbo packets... Honestly, I have no idea how to reliably test the sensitivity of a smoke sensor.
That's what the zigbee.readAttribute is supposed to help with!
I'm just confused about the catchall response being different lengths every other time, alternating between ending in 01 01 or 04 01 00 after the 115F manufacturer code.
I suspect the second to last value tells us the current sensitivity level, but need more evidence...
We're talking about Aqara devices... and their manufacturer-specific attributes. All we can do is guessing...
But both the hub and the app had several updates since then, so maybe tomorrow I'll rejoin the sensor to the Aqara hub, and sniff the communication again...
1 Like
With the xiaomi button and aqara one, do they only have the ability for a single button press, no a double press or hold ?
Anyone getting errors with the xiaomi devices in the logs. I'm getting them for temperature and contact sensors.
I was getting optimistic reading "official", lol. My contact sensors have been alright so far, but I'm always uneasy with the unofficial-ness. And my tradfi has been flaking out on me. Here's to hoping they actually come out soon and are still reasonably priced... I need a few more motion sensors, lol.
Xiaomi "original" Button
model WXKG01LM
Functionality Chart
| Action | Hub Event | Notes |
|---|---|---|
| Single press | button 1 pushed |
|
| Hold | button 1 held |
Event comes after button is released ~ |
| Double-click | button 2 pushed |
|
| Triple-click | button 3 pushed |
|
| Quadruple-click | button 4 pushed |
|
| Shizzle-click | button 5 pushed |
5 or more multi-click |
~ Note: The default minimum time required to hold the button for the held event is 1 second, and this can be changed in the preference section of the device's details page in the Hubitat Web UI |
Aqara Button
models WXKG11LM (original / new revisions) and WXKG12LM
Functionality Comparison Chart
Action|...11LM (orig)|...11LM (new)|...12LM
---|---|---|---|---
Single press | button 1 pushed | button 1 pushed| button 1 pushed
Hold | | button 1 held | button 1 held
Double-click | button 2 pushed | button 1 doubleTapped| button 1 doubleTapped
Triple-click | button 3 pushed | |
Quadruple-click | button 4 pushed | |
Shake | | | button 2 pushed
Release |button 0 pushed | button 1 released | button 1 released
Notes on hold & release for Aqara Buttons:
-
Model WXKG11LM (original revision):
The driver includes an automatically delayedbutton 0 pushedevent that by default occurs 2 seconds after a single press. The length of the delay can be changed in the preference section of the device's details page in the Hubitat Web UI. -
Models WXKG11LM (new revision) / WXKG12LM:
These two models send a "held" message when the button has been held for 400 milliseconds. This timing is hardware-based and cannot be changed, but the button can be held as long as liked. With both models a "released" message is only sent when the button is actually released.
1 Like
I may be able to help, but I really need to know what errors you're seeing.
Could you please post the log message text or a screenshot of the errors with some of the other messages both preceding and following them? Having debug log message output enabled would be best, thanks.
The Tradfri Outlet or bulbs? What kind of issues?
I have come to dislike very much the tradfri plugs. The bulbs are okay(a19 white). Signal is poor on all tradfri devices including the new USB repeater. I'm taking my plugs back to ikea, they have a 1 year return policy. Everytime my tradfri plugs flake out I lose my hampton bay fan controller and some xiaomi devices. I now have 5 xbees to support my Xiaomi devices
