[OBSOLETE] Xiaomi Sensors and Button (beta)

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).

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

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.

1 Like