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

Thanks Kenneth. Another good idea. I would need to prevent too many notifications. There’s 10 humidity sensors. I bet that could be fixed too, maybe with Webcore.

I’m hoping the Bspranger DTH works, but my humidity sensors main device display doesn’t show in STSC. It’s always “checking status.” The detailed humidity sensor tiles work in STSC, and everything works in ST Classic. Does anyone know if there’s a fix for the STSC problem?

I’m waiting to invest much effort into 3rd party apps, Webcore, or other Groovy smartapps. I don’t know how much of the old IDE will survive the transition to Samsung Connect (STSC).

I’ll probably start by changing the main device display to show humidity instead of temperature, and put the guitar humidity sensors in a room. That will work pretty well, and I can do it without using software or features not supported in STSC.

When SmartThings officially supports devices with custom device handlers in the new mobile app, then hopefully it can be fixed. Right now, however, there are no official fixes, and quite a lot of different devices using custom device handlers don’t work 100% in the new app (or STSC as you’re calling it.)

All of my Xiaomi original and Aqara versions of the temp sensor has stopped reporting temperature.
All other paramters report fine.

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:22: debug Temp Vaskerom: Parse returned [name:pressure, value:988.5, unit:mbar, isStateChange:true, descriptionText:Temp Vaskerom Pressure is 988.5 mbar]

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:22: debug Temp Vaskerom: Parsing description: read attr - raw: 8A8E0104031C000029DC03140028FF1000299D26, dni: 8A8E, endpoint: 01, cluster: 0403, size: 28, attrId: 0000, result: success, encoding: 29, value: 269D290010FF28001403DC

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:21: debug Temp Vaskerom: Parse returned [name:humidity, value:66, unit:%]

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:21: debug Temp Vaskerom: Parsing description: humidity: 66

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:21: error java.lang.NumberFormatException: For input string: "21.0 C" @line 201 (parseTemperature)

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:49:21: debug Temp Vaskerom: Parsing description: temperature: 21.0 C

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:52: debug Temp Vaskerom: Parse returned [name:pressure, value:988.5, unit:mbar, isStateChange:true, descriptionText:Temp Vaskerom Pressure is 988.5 mbar]

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:52: debug Temp Vaskerom: Parsing description: read attr - raw: 8A8E0104031C000029DC03140028FF1000299D26, dni: 8A8E, endpoint: 01, cluster: 0403, size: 28, attrId: 0000, result: success, encoding: 29, value: 269D290010FF28001403DC

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:52: debug Temp Vaskerom: Parsing description: read attr - raw: 8A8E0104031C000029DC03140028FF1000299D26, dni: 8A8E, endpoint: 01, cluster: 0403, size: 28, attrId: 0000, result: success, encoding: 29, value: 269D290010FF28001403DC

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:51: debug Temp Vaskerom: Parse returned [name:humidity, value:74, unit:%]

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:51: debug Temp Vaskerom: Parsing description: humidity: 74

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:51: debug Temp Vaskerom: Parsing description: humidity: 74

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:51: error java.lang.NumberFormatException: For input string: "21.0 C" @line 201 (parseTemperature)

[347a77e2-a1aa-4514-ad64-0d5745ebcac9](https://graph-eu01-euwest1.api.smartthings.com/ide/logs#347a77e2-a1aa-4514-ad64-0d5745ebcac9) 19:48:51: debug Temp Vaskerom: Parsing description: temperature: 21.0 C
error java.lang.NumberFormatException: For input string: "21.0 C" @line 201 (parseTemperature)

Something must have changed in the way the hub parses ZigBee temperature report messages.

However, I see what needs to be changed to fix this. After I get home to test the fix, then I can post the updated code.

Thanks for reporting it!

Thank you!

I’m on the hub beta 0.25.X by the way. Not sure if this only affects this firmware

I think yes, because of this in 0.25.x beta release notes:

  • Changes to the way Zigbee messages are sent to the DTH (should have no impact but be on the lookout for issues)

The way the temperature reports are handled in the two device handlers is not ideal. Now that I understand DTHs a lot better, it’s a pretty easy fix. I just want to test it first.

1 Like

Just as an FYI this was an unintentional regression. I will aim to resolve this in the next few days, and it will certainly be handled before we go to wide release.


Based on my testing, if I change the code to use SmartThings recommended method to parse temperature reports, then the ability to report values with 0.1 precision will be lost. Only rounded integer values will be given in temperature reports.

So I am asking about this on the Hub Firmware 25.x Beta thread.


My Door/Window sensors and Temperature/Humidity sensors are working really well with no disconnection for about two months now! For some reason though, the Water Leak sensor would often drop out and show up as Unavailable in SmartThings. This becomes essentially unusable when I added two more Water sensors (for a total of three). None (including the one that was previously able to stay for several days or weeks) can stay for more than a few hours. The Recently tab in SmartThings app shows no events except for the initial battery runtime event when I added them. The web events list a ping event immediately before the state change to offline. Any ideas why or anyone having similar problems with the Water Leak sensors?

EDIT: It looks like that disabling the Ping() function from device handler may eliminate the symptom but then what about actual disconnection of these critical sensors? checkIntervalEvent() seems to suggest that the sensor should wake up at least once every hour to respond to ping.

The ping() function isn’t even used in any of the Xiaomi / Aqara device handlers, so that’s not the issue. As for checkIntervalEvent(), that is only used for the Device Health feature is turned on, and it tells the hub to decide a sensor has gone offline when it hasn’t checked in for more than 3 hours.

There are a couple of reasons why your Water Leak sensors may be dropping off the network:

  1. Weak ZigBee signal.
    If the sensors are distant from the hub, or there are materials in the walls or objects between the hub and the sensors which reduce signal strength, then they may lose the connection.
  2. Incompatible ZigBee repeaters.
    The best way to increase the “strength” or “health” of a ZigBee network is to add devices that act as repeaters. Generally these are ZigBee devices that are mains-powered (but often not including ZigBee bulbs). Strategically placed, the increase the range of the network by allowing end devices to connect to a repeater with better signal strnegth instead of to the hub directly.
    However, in the case of Xiaomi / Aqara devices, many ZigBee repeaters won’t work well with them, because Xiaomi / Aqara devices check-in rather infrequently (every 50-60 minutes depending on the model), and so the repeaters drop them.

In both of these cases, the normal routine would be for the hub or repeater to send a “leave and rejoin” request when then device finally comes around attempting to check in. Unfortunately, Xiaomi / Aqara devices work in a non-standard way, and they do not comply with the rejoin part of the request and never come back online.

So the goal is to try to make sure they never get kicked off the mesh network in the first place.

How many ZigBee devices do you have, and do you think you have any ZigBee repeater-capable devices (such as ZigBee plug switches or outlets)?

Thanks for the detailed answer. The only repeater-capable devices I have are smart plugs, and I was indeed suspecting the two issues you indicated. What I did to try to rule them out was: when they dropped off the network, I moved the three water sensors to the same room as the hub with straight line of sight, disconnected the only smart plug in the room, reconnected the sensors and kept them in that room. They would still drop out after a few hours. Let me try disconnecting all smart plugs in my house and test again. Suppose this fixes the problem, will the sensors switch to a repeater once they are moved to a new position? They should still be able to receive signals from the hub, although weaker.

If the signal from the repeater is stronger than the signal from the hub, they’ll likely switch to the repeater eventually.

You mentioned no activity after pairing other than one initial battery event, which makes me suspect they never got fully/correctly paired in the first place. Typically Xiaomi/Aqara sensors are very active for the hour or two following pairing while they’re in “test mode”, and send data every 3-5 min during that time. I would try re-pairing them while they’re close to the hub, and leaving them close to the hub until the test mode ends. After they’ve paired properly, and test mode has ended, then try moving them to the final location and see what happens.

Which brand/model of smart plugs?

Since there’s no way without special hardware - specifically an XBee (see this thread for some great and helpful information) - then there’s no way to confirm whether an end device is connecting through a repeater or directly to the hub.

I’m afraid they can do that, because the way ZigBee mesh networking is designed, end devices are free to choose their route via which they connect to the network based on best signal strength, and that can route can change even after they have been paired.

So, even if you were able to pair the leak sensors directly to the hub, after moving them to their desired locations and reconnecting your smart plugs, the leak sensors could “decide” to try connecting through a smart plug instead of directly to the hub.

This only applies to the Xiaomi and Aqara motion sensors. Other Xiaomi/Aqara devices do not have a test mode. With the leak sensor, the only activity you would see besides the battery reports is “dry” or “leak detected”. Outside of that, the sensor goes into “sleep” mode.

Also worth noting, during pairing the initial battery report is missed, so the first battery report that results in a battery percentage event happens on the device’s first check-in (about 50-60 minutes after pairing, depending on the model).

The plugs I have are Securifi Peanut Plug.

Would getting an Aqara-branded repeater (e.g., smart switch) help or is there basically no good solution for these sensors if they are to be placed closer to a repeater than the hub? I seem to recall reading somewhere ZigBee devices tend to stick to the old link unless the signal becomes really low. I’m keeping my hopes up that this won’t be the case since my other Aqara Temperature or Door sensors are working so reliably.

I think I did this correctly, but just to confirm: I pressed the button on the sensor for about 5 seconds until the blue lights flashed, then I released it, and the blue lights quickly blinked for 3 times. I would press the button once (which would trigger 3 blinks) every half a minute until the SmartThings app found the sensor. After I saved the found sensor and went back to the Things page, that sensor would come back online with the Dry status.

I tried a Peanut Plug, and it now lives in a drawer because it did not like Xiaomi / Aqara devices at all. Not only did Xiaomi / Aqara devices get dropped off the network when connected or paired through the Peanut Plug, also some messages weren’t passed on to the hub.

I did all of my tests while using a XBee to look at the Zigbee mesh network map.

An Aqara smart plug should work, but I have never tried one so I can’t confirm that. Besides an XBee (which also works really well as a repeater in addition to its diagnostic capabilities), the only other repeater that is reliably “friendly” with Aqara / Xiaomi devices is the IKEA Tradfri smart plug. They are inexpensive if you are local to an IKEA location, but they don’t have a physical on/off switch, are kind of big, and I’m not sure if the power specs match that of the Peanut Plug.

That’s right, and the quick flashes of the LED indicate successful pairing on the sensor’s side. However, I’d actually recommend continuing to short press the reset button (i.e., the top of the leak sensor) every 1-2 seconds until the sensor shows up in the SmartThings mobile app.

If the sensor shows up with the correct device handler selected (and not displayed as a “thing”) and if you look at the device details page (IDE → My Devices → click the name of the leak sensor in the Display Name column) and don’t see blank information fields in the Data and Raw description areas, then that means it was properly paired. As long as it was paired directly to the hub, or through a compatible repeater, of course.

Thanks for the really good information. I wish I had found this before, and you probably mentioned it to other people, but they were likely buried too deep in the discussions. Is there a wiki type site with collections of such common wisdom?

Then the sensors have been correctly paired. And now that I’ve disconnected all the Securifi Smart Plugs, they are staying fine on the network. I’ll try adding back the plugs one by one, and see if the sensors will stay connected directly to the hub or switch to one of them. If they do switch, I can identify which one is the culprit.

Is this specific to messages from Xiaomi Aqara sensors or are Securifi Plugs just a poor choice as ZigBee repeaters in general?

A great idea. I’m about to enter a s**tstorm of needed updates to SmartThings device handlers and device drives for Hubitat due to upcoming firmware upgrades, but after that I’ll see what I can do.

It’s specific to messages from Xiaomi / Aqara sensors as far as I know. I haven’t read anything about Peanut Plugs not working well as repeaters for other brands of ZigBee devices.

That said, remember that the Peanut Plug was originally intended to be used with Securifi’s own Almond hub(s).

My door sensor was working well until ab8ut a week ago. Now it is unavailable. Battery seems good- LED blibka when I press the button. How do I re-add it to smartthings?


Nevermind. I got it. I just followed same steps as before. I had to keep hitting the button every few seconds until the ST detected it.

@veeceeoh did you get on the hub beta to test the necessary changes to the button dth?