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

Found the bug changed

for (i = 0; i < (MsgLength-3); i++)

to

for (int i = 0; i < (MsgLength-3); i++)

Nice find! There were actually 6 DHs that I made that mistake on. I have updated them. Thanks for letting me know. This is what happens when you copy and paste and only have 3 minutes to do it.

Wasn’t able to pair the aqara motion sensor using your method, but it seems to be working with your device handler and catchall method… Hope it stays paired

I have been monitoring a few of these threads for a while now hoping someone will have a solution would find a solution to the disconnecting sensor problem. As far as I can tell, a method still has not been found.

I have three xiaomi aqara window/door sensors (the squarish ones with the button). I can get them all to connect but they consistently disconnect after a hour or two. The only other devices I have on my hub are a number sengled element bulbs and four hue white bulbs that are direct connected to the hub as well. As far as I am aware, none of those act as repeaters so my aquara sensors should be direct connecting to the hub.

The only twist I can think of to my setup is that I use the SmartThings Link as my hub (which is the dongle that plugs into an Nvidia Shield TV). I have had no issues with my devices using the Link but I did see mention somewhere that the Link might not be on the same firmware version as an actual v2 hub.

I am hoping someone can shed some light on a reliable solution. I’d like to add some more xiaomi devices but I don’t want to commit to a purchase before I get these connection issues sorted.

I was using a SmartThings Link until about a month ago, and gave up on it. It just wouldn’t work with Xiaomi devices. ST support told me that the Link is different hardware than in the v2 hub, and is on a different development path. Who knows what other “unsupported” devices that work fine on the v2 hub won’t work with the SmartThings Link. I wasn’t going to wait to find out, and bought a v2 hub.

With my v2 hub, all my Xiaomi door / window sensors (both “original” and Aqara,) Aqara water sensor, and Xiaomi cube all paired correctly (using the Add a Thing… method, not the catchall method). None of them have lost a connection with the hub.

1 Like

I’m in a similar boat.

I bought a Connect Home thinking I can kill 2 birds with 1 stone… But I’m just having a heck of a time getting those Aqara sensors to stay online. Firmware is not the same as the hub V2. Not even sure if the hardware smartthings hardware is the same as V2 either. I’ve pretty much given up and about to by the Smartthings Hub V2 from the Smartthings shop.

Promo goin on now Hub V2, 2x Sengled A19 bulbs, and a motion sensor for $99… Not too bad a deal. Only catch is that I live in Canada. Shipping is 15 extra, + duties and taxes when it crosses the border.

I notice the revised DH code to immediately retrieve battery voltage on reset button press isn’t working as expected.

Using the most up-to-date DH code on a newly paired sensor, before the first check in pressing the reset button doesn’t update battery voltage or percentage displayed in the battery tile.

Example of code from the Aqara door / window sensor DH:

Code (click the triangle to reveal)
// Parse raw data on reset button press to retrieve reported battery voltage
private Map parseReadAttr(String description) {
    def buttonRaw = (description - "read attr - raw:")
    Map resultMap = [:]

    def cluster = description.split(",").find {it.split(":")[0].trim() == "cluster"}?.split(":")[1].trim()
    def attrId = description.split(",").find {it.split(":")[0].trim() == "attrId"}?.split(":")[1].trim()
    def value = description.split(",").find {it.split(":")[0].trim() == "value"}?.split(":")[1].trim()
    def model = value.split("01FF")[0]
    def data = value.split("01FF")[1]
    //log.debug "cluster: ${cluster}, attrId: ${attrId}, value: ${value}, model:${model}, data:${data}"
    
    if (data[4..7] == "0121") {
    	def MaxBatteryVoltage = (Integer.parseInt((data[10..11] + data[8..9]),16))/1000
        state.maxBatteryVoltage = MaxBatteryVoltage
    }

    if (cluster == "0000" && attrId == "0005")  {
        resultMap.name = 'Model'
        resultMap.value = ""
        resultMap.descriptionText = "device model"
        // Parsing the model
        for (int i = 0; i < model.length(); i+=2) 
        {
            def str = model.substring(i, i+2);
            def NextChar = (char)Integer.parseInt(str, 16);
            resultMap.value = resultMap.value + NextChar
        }
        return resultMap
    }
    
    return [:]    
}

If I’m understanding this changed code correctly, a press of the reset button will read the current battery voltage and assign that value to the state of the variable maxBatteryVoltage, which is later used in the getBatteryResult function in calculating the maxVolts variable used for determining the top of the voltage range that is used to show battery percentage. But pressing the reset button results in data that includes the current raw voltage value, not the maximum possible voltage.

To immediately update the battery voltage on reset button press, the getBatteryResult result needs to be called. But in order to do that, you need to map the resultMap of getBatteryResult function, and there’s already another conditional using resultMap to retrieve the device model.

I don’t see why the device model text is needed, since it’s already defined in the DH’s fingerprint line. If you remove the code that parses the device model, then the reset battery parse code can be changed back to:

if (data[4..7] == "0121") {
        	resultMap = getBatteryResult(Integer.parseInt((data[10..11] + data[8..9]),16))
        }

and the return [:] is also no longer needed.

I hope this makes sense.

I have been experimenting and trying to parse as much of the message as possible.

I am not totally convinced that the message provides the actual voltage versus the maximum voltage. Perhaps you can also experiment?

ok so it’s been paired and untouched for almost 12hrs

i’ve noticed that my motion detection delay intervals are far beyond the 1 minute that other people are getting (it’s been at least 20 minutes since it last detected motion…)

is the IDE is reporting this “checkInterval: 7320”

Edit: removed the sensor from my devices and re-paired it hoping to use the catchall method, but to my surprise it was instantly added to my devices… Working as expected so far… Will have to wait until it gets out of test mode

1496598051135126050
I have the Aqara Temperature Humidity Sensor and together with the device type handler is has been was working for about a month. Now for the life of me I can’t get it to work more than once.

As in I can get it to finally be added as new after many presses on the tiny button that makes the blue light flash.
It’ll finally see it and update its status once, then stops updating completely (seriously after one time…)

Any help?

UPDATE: Placing it atop my HUB fixes this but that’s ridiculous really, since it was working perfectly fine. It could be that there’s an interference but I am without a doubt nobody in my vicinity has any Zigbee devices.

UPDATE #2: Now my door sensor (also a Aqara) has stopped working, obviously I can’t place that atop my HUB. It was working well for about 2 weeks.

One of my original buttons and original door contact just started doing this



I have the same problem with the latest code, all my contact sensors are reporting negative battery percentage of around -360%

I have done numerous tests and I am 100% convinced that the actual voltage is given when the reset button is pressed (at any time after proper pairing.) Here are the tests I did:

Pair a device (Aqara door/window sensor, Aqara leak sensor, Xioami Cube), then press the reset button to read the battery voltage, and then waited for the first check-in (50 or 60 minutes) for the battery voltage to be read again. The raw voltage value from the reset button was the same as the voltage reported from the check-in. Every of my devices have slightly different voltage values (i.e…, 3.055 versus 2.990), so this shows that the voltage read when the reset button is pressed is not a standard maximum voltage, but rather the actual current voltage.

I also tried pairing the devices, waiting for the battery voltage to be read during the first check-in, then then after that pressing the reset button to read the voltage again. Same as the above test, the raw voltage value read from the reset button press was the same as the value given from the first check-in.

I also tried switching batteries, and saw that the voltage read from reset button press changed specific to that battery and was again the same as the value read during check-in.

All of this is consistent with reports by other non-SmartThings users (that I have posted about elsewhere) that have worked on integrating Xiaomi sensors with other HA systems.

So, I have zero reason to believe that the raw voltage value given when the reset button is pressed is a maximum voltage. It is quite clearly the actual current voltage.

For anyone having trouble with pairing their Xiaomi device, there are English-language manuals for some of them accessible on the FCC ID Search Database website. They are listed under FCC ID applications for Lumi United Technology Co., Ltd, here.

Direct links to the manuals: Aqara Leak Sensor, Aqara Door/Window Sensor, Aqara Temp/Humidity Sensor, Aqara Occupancy Sensor, Aqara Vibration Sensor

Of all of these, the most helpful is the manual for the Aqara Door/Window Sensor. Here is the section on how to use the button to reset / pair and what the LED flashes mean:


(NOTE: DWS = Door/Window Sensor)

Besides Aqara Door/Window sensors, I also have some Xiaomi “original” Door/Window Sensors, and one Aqara Leak Sensor, and the information above also applies to to those sensors as well, from my experience.

EDIT:

Some additional information based on my experience and research.

When you hold the reset button down, as soon as the LED flashes, the device has been completely reset and goes into pairing mode. 3 seconds is about right from everything I’ve seen, but really what you should do is hold the reset button in until the LED flashes and then stop pressing the reset button. This should all of course be done after you’ve selected “Add A Thing” in your SmartThings mobile app.

After that initial LED flash, there is a pause, and then you’ll either see the LED flash once (a long flash), or it will blink 3 times (short flashes).

If the LED flashes once, pairing was unsuccessful, and you should short-press the reset button to “wake up” the sensor to try pairing again. The LED will blink as you short-press the button, and after a pause it will either flash once (a long flash) or quickly blink 3 times. If it flashes only once, short-press the button again, and repeat until you see the LED quickly blink 3 times.

When the LED blinks 3 times, the pairing process has started, and you will see a “catchall” message appear in the hub event log in IDE (in My Hubs -> List Events, not in the Live Logging window).

Then, if you already have installed a correctly working Device Handler for the Xiaomi device in your IDE, a zbjoin message should appear in the hub event log shortly after the catchall message, and that’s when you’ll see the device show up in your SmartThings app, ready to be renamed.

However, because these are battery-powered “sleepy” ZigBee devices, the pairing process may not complete, so the best advice (based on a post by Ted Tolboom on this Athom home-automation thread) is to continue short-pressing the reset button every 5 seconds, even after you see the LED blink 3 times, until the pairing process is complete (and you see the device appear in your SmartThings mobile app.)

Following the procedures I’ve explained above, I have had 100% success in correctly pairing 4 Aqara Door/Window sensors, 4 “original” Xiaomi Door/Window sensors, and a Aqara leak sensor again and again in numerous tests. With my v2 hub, none of these sensors have dropped their connections.

3 Likes

It seems that the temperature offset function for the Aqara Temp/Humidity sensor is not working. When I enter any offset (positive, negative, single digit, with & without decimal) it gives me an error like this. It then refuses to update the temperature until I remove the setting.

error groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.math.BigDecimal#plus.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[class java.lang.Character]
[class java.lang.String]
[class java.lang.Number]
[class java.math.MathContext]

1 Like

All, I am very busy this week. I will try to get some time asap to resolve these issues.

@tmleafs are you willing to apply a fix to all the devices for the battery/button press reporting? I think we need to change the min max tracking because if you get a bad value you see the effects that @logopeda sees.

I think the min/max fix is simple:

Change
if (minBattery == 0 || rawVolts < minBattery)
to
if (minBattery == 0 || rawVolts < maxBattery)

That should let minBattery reset if the rawVolts is greater than minBattery, but less than maxBattery.

Nevermind. That won’t work. It won’t set the minBattery properly the first time, giving a wrong calculation (max will be set, but min will be 0, and the average will not be correct).

I think it will have to be changed to an array and average the rolling values to smooth the value fluctuations. Either that, or just ignore the fluctuations by removing the averaging. Or prevent out-of-range values from being set to min and max.

I happy to test any code

I was a little scared when I read this conversation, because I have a Smartthings Link too! :slight_smile: Today arrived my two Aqara motion sensors and one Temp Sensor. Just following your pairing steps and surprisingly all the devices are working! They didn’t report the battery status just yet (about 1 hr of pairing). Well… just have to wait I guess :wink: Thanks for all your great support guys!