Trying to revive Aqara leak sensors

All,

I have 6 non-working Aqara sensors. Last reporting time for these bad ones:
7/13/19
8/26/19
1/18/20
7/10/18
6/24/19
3/5/19

They worked for many months or even a year without issues. I can’t think of anything that changes around the times that they stopped responding.

And 5 others are humming along without issues.

I am using this outdated version of bspranger’s Aqara Leak Sensor DH:

To my knowledge, I do not have any Zigbee repeaters (only bulbs).

With the exception of the 1/18/20 sensor, the bad sensors are the furthest from my hub.

The 1/18/20 sensor is THE CLOSEST to my hub.

My ST v2 hub looks to be set on ZigBee channel 20. My 2.4 GHz WiFi was set to channel 7, but I just read about ZigBee/WiFi coexistence and changed it to channel 1. The hub is about 8 feet from the router, and I am planning on moving it.

Questions:

  1. With the non-reporting closest 1/18/20 sensor in mind, is this symptomatic of a home that needs repeaters?

  2. If so, Would it solving this be most cost efficient if I invested in something like a Digi XCTU device?

  3. (Also if so) I have read that only certain repeaters work well for these Xiaomi devices. Does anyone have any good/cheap recommendations? Somewhere I read unconfirmed good things about Tradfri.

  4. Once the potential coverage issue is solved, how do I “wake up” the bad sensors? Do I perform the pairing process again, and if so, will they retain the network IDs that they had previously?

  5. What about Xiaomi firmware updates?

  6. Should I cut my losses and order another half dozen sensors?

Edit: Forgot to say THANKS!

How are you defining the ‘last reporting time’? What is the status of the sensors in the IDE (account.smartthings.com)?

There is a bit of a non-sequitur there. Many Zigbee bulbs are repeaters.

If you just go through the pairing process without trying to delete anything before hand, you should be fine.

As already mentioned, most zigbee bulbs are repeaters. There are a couple of exceptions like Sengled, but not many.

Possibly, but hard to say. The more repeaters the better, but they need to be compatible with your devices. Could also be bulbs that are incompatible repeaters, or low batteries if you’ve had them a while (the batteries last a long time but the battery reporting on these things is terrible IME).

The Tradfri plugs, repeaters, and bulbs are all confirmed to work very well as repeaters for Xiaomi/Aqara devices, and they’re generally the most cost effective option.

Yes, you can start the pairing process over again, and as long as you don’t delete the device first it should retain the zigbee ID so that you don’t need to re-build any automations using them. IME they will sometimes pop up as a device during the re-pairing (with whatever name you previously assigned them), and sometimes nothing will appear to happen but they’ll reconnect. My point is that once you’ve gone through the re-pairing process don’t start over if nothing pops up. Wait a few min and log into the IDE and check the device status there and it will often be functioning properly again.

I got tired of mine randomly dropping off. Tossed them in the trash and picked up SmartThings branded ones. Wasn’t worth the instability of their custom zigbee on a device that needs to be reliable.

They will drop off randomly if they pick up a repeater that can not handle a sleepy Zigbee device. ST has made allowances for these but other manufactureres haven’t as it’s non-standard.
SImply re-pair the device close to the hub, log into the IDE and inspect the device. Confirm it says the Next Hop is Home Hub and it should be ok. If it is anything else then it will likely fall off as the repeater will not handle the sleepy device.
I have 2 light swiches that turned out to be not Z-Wave and they cause me the only grief. If my sensores drop off and I check the DE they will be the next hop so I re-pair.

Woa! Somehow I missed the reply notifications. I am very interested in your help. Thanks for being patient with the replies.

Here is an example of what I see in the IDE:

Current States	
battery: 100 %
water: dry
checkInterval: 7320
lastCheckin: 2019 Jul 13 Sat 5:46:21 AM
lastCheckinDate: 1562996781000

Status	OFFLINE

Last Updated	2020-02-24 6:40 AM EST

List Events (All)
No events found matching this criteria

My bulbs appear as SYLVANIA Smart 10-Year A19, and after I read this, I kind of wrote them off as not being useful:

For what it is worth, I just checked every ZigBee device in the IDE and each had “Next Hop” listed as “Home Hub (0000)”.

Does that mean what I think it means? I do not have any functioning repeaters? With regards to the Osram firmware issue that JDRoberts mentioned, if there is a firmware fix, while troubleshooting I realized that I have firmware updates disabled. Is that something that folks recommend to turn on? I am generally skeptical about updates when things are working, but in this case …

Finally, with regards to re-pairing, thank you for the explanation MinerJason:

I followed the instructions that worked for me originally (first-time setup):

But I was not sure if any interaction with the app or IDE is necessary. When I followed ArstenA’s process (just the button presses, skipping any IDE work), I monitored the device status after several attempts and it still reads “OFFLINE.”

Thanks for the help! I think I have a handle on notifications this time. I look forward to the replies.

In the absence of documentation, I haven’t tested Health Check thoroughly enough to determine exactly what it is monitoring to decide if something is online or offline, and for that reason I don’t read anything into the device being marked as OFFLINE. I can think of a reason why that might happen but I am not that sure about it, and similarly I wouldn’t necessarily expect it to show ONLINE immediately. That might just be an error of omission in the device handler.

I’m more bothered by the lastCheckin as the handler populates those whenever it is passed anything from the device. That’s assuming the devices are definitely still using that device handler.

I’m not that concerned by all the Zigbee devices showing your hub as the next hop, as long as it is actually up to date information. What would be interesting to know is if they show ‘meshinfo’ in the Data in the IDE as that has a timestamp on it

I don’t think you fully understood that post you’re referencing. The Sylvania/Osram Lightify bulbs are worse than not useful, they’re problematic repeaters. For one, they’re not compatible with Xiaomi/Aqara sensors, which could be why your leak sensors went offline. And even for devices they are compatible with they can drop messages and cause issues when used on a busy zigbee network, particularly the older models. The newer models supposedly have improved buffer size and don’t have that issue as much, but even if yours are the newer ones they’re not compatible with your leak sensors and will cause them to drop off the network.

No, it just means that nothing is currently routing through a repeater.

And FWIW from my experience when a Xiaomi/Aqara sensor that connects to an incompatible repeater and gets dropped off the network because of it, the next hop will update to “unknown device” with a random zigbee ID. Makes tracking down the incompatible device tricky, since you need to see it listed as next hop before the issues arise. Since your sensors dropped off the network prior to the next hop feature being added to the IDE, I’m not sure that any next hop info currently listed for them would be useful.

That’s the correct process but you need to put the hub in pairing mode first, which does require interaction with the app. I suggest using the classic app to put the hub in pairing mode as the new app doesn’t seem to work as reliably for this function.

Also, since it appears these sensors have been offline for ~9 months it might not hurt to throw some new batteries in them before trying to re-pair them.

Whoops. I did not understand. That is a shame … I have 2x old bulbs:

And 6 new bulbs + one under-cabinet light that may not behave any different:

I just revived 3x on the first try! It seems so obvious now that this is a required step – thank you for pointing this out! Let’s see how long they stay online now …

Interestingly, these 3x leak sensors now show Next Hop as some of my newer 6x Osram bulbs. Here is the Data from the IDE for these:

  • application: 04
  • endpointId: 01
  • manufacturer: LUMI
  • meshInfo: {“route”: [{“type”: “UNKNOWN”, “deviceId”: “2A3A”}, {“type”: “UNKNOWN_ROUTE”}], “metrics”: {“totalTransmittedMessages”: 0, “transmitFailures”: 0, “duplicateMessages”: 0, “lastLQI”: 0, “lastRSSI”: 0, “lastResetTime”: “2020-03-03T21:26:21.000Z”}, “updatedTime”: “2020-03-06T15:27:09.000Z”}
  • model: lumi.sensor_wleak.aq1
  • zigbeeNodeType: SLEEPY_END_DEVICE

And for comparison, Data from another that has remained online (and shows Next Hob as the ST Hub):

  • application: 04
  • endpointId: 01
  • manufacturer: LUMI
  • meshInfo: {“route”: [], “metrics”: {“totalTransmittedMessages”: 0, “transmitFailures”: 0, “duplicateMessages”: 0, “lastLQI”: 255, “lastRSSI”: -59, “lastResetTime”: “2020-03-03T21:26:21.000Z”}, “updatedTime”: “2020-03-06T15:27:09.000Z”}
  • model: lumi.sensor_wleak.aq1

Is the lastRSSI value of zero on the “revived” sensor above indicative of the recent pair, “excellent reception” (unlikely :grinning:), or the Osram bulbs dropping messages?

Or is the presence of meshinfo in itself a good sign?

Thanks!

Let us know how it goes, but my guess is that the ones routing through your Sylvania lights will drop off within a few days. The Xiaomi/Aqara sensors simply aren’t compatible with the vast majority of zigbee repeaters.

Back from trying to revive the others.

All but one behaved well and paired easily.

One was stubborn. I replaced its battery and tried (opened classic App, tried for 5 minutes and force closed it) about 5 times.

I got frustrated and held the leak sensor button for a longer period (about 45 seconds) and tried again. It worked!

But interesting, the sensor has a new Device Network Id and the tiles for the device are blank in the app. Are this symptoms indicative of any known issues?

Thanks again.

2 weeks later, the sensors are all still reporting. Unsure if I am out of the woods fingers crossed

Thanks again everyone

Does anyone know the most up to date device handler for Aqara leak sensors in March 2020? Mine keep disconnecting periodically and need to be reconnected.

In my experience, an updated device handler isn’t needed to fix disconnects. I am using this version from 2018:

But I believe this is the newest:

That is linked from this thread:

Good luck.

P.S. my sensors are still connected! Thanks again for everyone’s help.

Have the exact same problem. I have a v2 hub and been using Smarthings Classic app untill a few months ago. I’ve had a couple of Aqara leak detectors, temperature sensors and smoke detectors connected for two years without any issues what so ever. Rock solid. Then I migrate to the new app, and they start dropping one by one with about a week apart. Only thing that has changed was the migration of the app. I do not have any Zigbee repeaters in the system, and the range is not a problem.

Try to reconnect the devices, and they work for a short time before they drop again. After the migration, Smartthings has pretty much become useless, so I think I’ll give up and and find another solution. Keeping my Aqara devices though…they are absolutely great!

My aqara leak sensor dropped off when migrating to new ST app as well. However, after a couple tries to reconnect it has stayed online for over a week now. Initially it would stay connected for less than a day and go offline so I moved it closer to my v2 hub to connect on 3rd try and kept it there for a day before moving back into garage where water heater is located. Not sure moving it closer to hub had anything to help but that was only thing different between the first 2 times it went offline post app migration.