Aqara Leak sensor has different state in New/Classic apps


Let me start by saying that I have not run the migration tool for the new App, but have had it running alongside the Classic one since it was available.

One reason that I have not fully cutover is that one of my dozen or so Aqara leak sensors shows up differently in each app.

The new app main screen shows that it is wet, but when you tap on it for more details, it has a cloud with a line through it, without any text.

None of the leak sensors have any “History” on the new app, and there is very little text, so it is difficult to tell exactly what is going on.

Perhaps the lack history is a function of the DTH or maybe it only shows information when it changes states.

The Classic app indicates that the same device has had events/check-ins in the last 30 minutes or so, with full battery life, but, complementing the new app, Simple Device Monitor shows it as N/A instead of wet or dry.

I cannot find an analogous view on the new app that indicates when it last received an Event or check in from a device.

Other leak sensors have regularly popped on and offline as these Aqara devices seem to (see Trying to revive Aqara leak sensors). But those sensors have never shown up the same way as this line sensor does in the new app (“wet” and cloud-with-line through it).

  1. Why is this sensor different than the rest? Is this one sensor defective?

  2. Why would the Classic app show that it checked in recently, but show it’s state as N/A in Simple Device Monitor?

  3. Is there anything incompatible with the new app in bspranger’s DTH?


It sounds a bit like the ‘water’ attribute still has a null value, rather than ‘wet’ or ‘dry’.

Although never publicised as such, it is good practice to initialise all the attributes to a valid value as otherwise the app throws a wobbly. That is something the ‘bspranger’ handlers don’t do as they haven’t really been updated since the community became aware of this.

The way the UI is defined in the Classic app, there is always a ‘default’ state displayed, even if it is wrong. The check-ins could well be the hourly battery reports.

Sure enough, after dunking it in water and drying it off, things are back to normal.


In case we are forced eventually, do you know if the migration tool process will break anything related to the bspranger DTH?

The underlying functionality is still the same, so nothing should break automation wise. If you are used to controlling the device via the Classic app you will see certain bits and bobs won’t be there, and as you have discovered the app does like attributes to have correct values so the app can throw a bit of a wobbler until valid data arrives.

1 Like