[OBSOLETE] Xiaomi Sensors and Button (beta)

[veeceeoh (Keith G)]

@Victor_Karlsson

Hello! Just got my smartthingshub and trying to add som sensors to it, got some motionssensors and temprature sensors and leaksensor added succesfully, im trying to add xiaomi original button but it wont pair like the others in the app but i can see them working in the eventlist.

@MinerJason

You could try the catchall pairing method, which is detailed nicely in Post 165 of this thread. It works great for pairing, though some here feel that it results in less stable performance, and devices dropping off easier. I’ve a few xiaomi devices I paired with the catchall method over a year ago that have never dropped off though.

The main disadvantage to using the “catchall” method is that in most cases, the device’s ZigBee ID is unknown to the SmartThings hub, and so the hub has no way to identify the device when it needs to be rejoined after dropping off the ZigBee mesh network.

A ZigBee ID is a unique 16-digit hexadecimal identifying string that is very similar to the MAC address used for IEEE 802 networks (i.e., Ethernet, WiFi, & Bluetooth). When a ZigBee device is paired with a hub, the device is supposed to send its ZigBee ID to the hub, and also the hub assigns a 4-digit hexadecimal Device Network ID (DNI) to the device (which functions similar to a IP address on a Ethernet / WiFi network).

If a device drops it’s connection with the hub for some reason, the DNI is unassigned, but if the device subsequently attempts to connect, the hub can use the device’s ZigBee ID to match to the device’s entry in the hubs device list, and assign it a new DNI.

Without any ZigBee ID, the hub has no way to match a disconnected device to its entry in the hubs device list. So both automatic rejoin and manual rejoin will fail. By manual rejoin, I mean when the user puts the hub and device in pairing mode in an attempt to rejoin it. Without the ZigBee ID information, the hub will decide it’s a “new” device, and the user has to set it and any of its automations up from scratch.

You can see whether a device’s ZigBee ID is known to the hub by logging into the SmartThings Groovy IDE and viewing the Device List Page:

As long as your device maintains it’s connection with the hub, not having the ZigBee ID isn’t a problem. So that’s why the “catchall” method works for many users. For others, due to interference or weak signal strength, they have issues that seem to indicate a lack of stability. Really it’s just that the hub can’t rejoin the sensor to the network.

In my testing, I have noticed that in rare cases, a Xiaomi / Aqara device will supply its ZigBee ID to the SmartThings hub after being paired using the “catchall” method. Also, it’s quite common for the ZigBee ID to show up in the Hub Events list (IDE > My Hubs > List Events) at the time when attempting to pair the device. It would be a 16-digit hexadecimal string beginning with 00158D (which indicates the manufacturer). Simply copy that entire 16-digit string, and then paste it into the hub’s device details for that device (IDE > My Devices > click Edit > paste string into “Zigbee Id” text field > click Update).

@britannijaf9

Guys is there a different device handler for long press of the xiaomi button from just the standard press, if so can you point me in the direction of the long press option.

@MinerJason

The a4refillpad button DTH in the first post of this thread has an emulated hold function. The hold function isn’t super reliable just due to the fact that it’s emulated and the nature of potential delays in the cloud processing, and you need to have the timing right to get it to work, but it’s the only DTH I’m aware of with that capability.

Actually there is a complete newer and updated set of DTHs for Xiaomi / Aqara devices, with links and discussion here:

[OBSOLETE] Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)

Here is the official LATEST Xiaomi Zigbee Sensor Device Handlers. These are developed originally from @a4refillpad The device handlers are located in GitHub here: or can be brought in via the GitHub integration by using these settings: Owner: bspranger Name: Xiaomi Branch: master These sensors are very sensitive. Drop offs are usually a result of the Xiaomi sensor trying to repeat through a zigbee router. They do not handle it well. Therefore when pairing you need to make sure all other zigbee routing devices are off and that the device is pairing directly to the hub. Also interference on the 2.4 frequency band can be an issue. I had to move my wifi channels so they did not interfere with my zigbee. There are many devices on the 2.4 range (baby monitors, cordless phones, bluetoot…

All of these updated Xiaomi / Aqara DTHs correctly parse battery voltage data, and many improvements have been made both in functionality and features.

The updated Xiaomi “Original” Button DTH, which can be grabbed from here, uses the same method as a4refillpad’s DTH to emulate a button hold function, but with some changes in the code to improve reliability and accuracy. @MinerJason is 100% correct in saying that it can’t be fully reliable due to delays in SmartThing’s cloud execution of the DTH code, however.

Personally, I own both a SmartThings hub and a Hubitat Elevation hub, which executes all code locally, and having ported over all of the SmartThings DTHs to Hubitat can confirm that local execution makes a massive difference in reliability of the emulated button hold feature.

Honestly, if you are looking for the ability to do “long press” or button hold, I would choose another button besides the original round Xiaomi Button. I’d recommend an Aqara Button, but there are now three different revisions, and the only one guaranteed to provide hardware-based button hold that works on the SmartThings platform (using the updated DTH I mention above) is the Aqara Button model WXKG12LM.