Aqara water sensor suddenly reports water for no reason #905

mdescher · 2018-10-26T09:56:32Z

I added an Aqara water sensor some time ago. Not visible in the Phoscon app but in the API. It reported "water" : false as expected for a few days. Suddenly it switched to "water" : true although it never got wet. I played around with it and put it into water, dried it, etc. but nothing changed. I eventually removed it from deCONZ, added it again and somehow managed to made it work again. It reported "water" : false when dry and "water" : true when wet. Then I put it in its place again and after a few days it switched to "water" : true again and still keeps reporting this although it never got wet. Does this sound like a problem with the sensor? Does anybody else see such a behaviour?

ebaauw · 2018-10-26T10:04:54Z

Did you check the sensor's battery? I haven't experienced this with my leak sensor, but my IKEA Trådfri motion sensor started reporting motion falsely, when the batteries began to run dry.

mdescher · 2018-10-26T10:47:33Z

Good point, I will try a new one later when I am at home.

timbru31 · 2018-11-05T18:51:50Z

I’ve had some false alarms, too. I’ve checked the battery, too, but it was full.
So far (2 weeks?) I had no false alarms.

martikainen87 · 2018-12-17T14:52:28Z

I also have a sensor that's showing water: true constantly, have tried to replace the battery but no change.
Pushing the sensor updates the rest api but it still think it's wet.

JBS5 · 2018-12-18T19:13:22Z

Got the same problem with the leak sensor.

maffee · 2019-01-16T13:03:26Z

Same problem here. Could this have anything to do with it?

Koenkk/zigbee2mqtt#448

manup · 2019-01-16T13:24:41Z

Good catch, yes seems that the hourly report can't be trusted for the water leak status, so we should rely on the IAS report only.

I'll change this for the next version 2.05.56.

maffee · 2019-01-16T13:30:19Z

Great, thanks!

The special report value seems to cause false positives. Issue #905

ebaauw · 2019-01-16T19:35:39Z

I installed one of these last April - I haven't seen any false positives during these 9 months. I do receive the special reports.

Not happy with this change - I check state.lastupdated (manually) to verify that the sensor is still connected.

Can we please double-check if this is related to a certain firmware version of the sensor. Or at least continue to update state.lastupdated on receiving the report?

manup · 2019-01-16T20:00:00Z

Not happy with this change - I check state.lastupdated (manually) to verify that the sensor is still connected.

Sorry I thought the IAS reports are also sent periodically? I haven't checked this though.

Can we please double-check if this is related to a certain firmware version of the sensor. Or at least continue to update state.lastupdated on receiving the report?

Sure state.lastupdated can be refreshed safely.

My sensor didn't have false reports either, it has version 20170721.

wvuyk · 2019-01-16T20:12:01Z

No false positives here either, also version 20170721

ebaauw · 2019-01-16T20:18:38Z

Sorry I thought the IAS reports are also sent periodically?

Nope, only Xiaomi special reports in the log.

Mine reports swversion 3000-0001 - I probably paired it before swversion would show the date. Will fetch the sensor and squeeze it to read the attributes this weekend.

manup · 2019-01-16T21:44:18Z

Mine reports swversion 3000-0001

Normally even when the former version 3000-XXXX is known the datecode should be queried after the special report.

Does the sensor still work with a recent timestamp?

Update state.lastupdated timestamp. #905

ebaauw · 2019-01-16T22:19:06Z

Normally even when the former version 3000-XXXX is known the datecode should be queried after the special report.

Well, deCONZ tries that (assuming it doesn't try to ACK the special report), but fails with 0xD0 on the confirm:

Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:004 APS-DATA.indication srcAddr: 0x00158d000233f290, srcEp: 0x01 dstAddrMode: 2, profile: 0x0104, cluster: 0x0000, lqi: 255, rssi: -52
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:004 #011asdu: 1c5f11ff0a01ff42220121b30b03280d0421a84305210d0006240100000000082104020a21f873641000
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 no button map for: lumi.sensor_wleak.aq1 ep: 0x01 cl: 0x0000 cmd: 0x0A pl[0]: 001
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 ZCL attribute report 0x00158D000233F290 for cluster 0x0000, ep 0x01
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 0x00158D000233F290 extract Xiaomi special attribute 0xFF01
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01101 battery 2995 (0x0BB3)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01103 temperature 13 °C
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01104 unknown 17320 (0x43A8)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01105 RSSI dB (?) 13 (0x000D)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01106 LQI (?) 4294967296 (0x0100000000)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01108 unknown 516 (0x0204)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #0110a unknown 29688 (0x73F8)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:005 #01164 on/off 0
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:012 discard sensor config push for config/temperature (already pushed)
Jan 16 22:43:24 pi2 deCONZ[12654]: 22:43:22:016 APS-DATA.request id: 158, addrmode: 0x03, addr: 0x00158d000233f290, profile: 0x0104, cluster: 0x0000, ep: 0x01 -> 0x01 queue: 1 len: 5 tx.options 0x00
...
Jan 16 22:43:32 pi2 deCONZ[12654]: 22:43:32:157 0x00158D000233F290 error APSDE-DATA.confirm: 0xD0 on task
Jan 16 22:43:32 pi2 deCONZ[12654]: 22:43:32:157 APS-DATA.confirm id: 158, status: 0xD0

Checked the old log, the 0xD0 is there every time.

Does the sensor still work with a recent timestamp?

Yes,

{
  "config": {
    "battery": 98,
    "on": true,
    "reachable": true,
    "temperature": 1300
  },
  "ep": 1,
  "etag": "a51ac85379e2362ec9ecf26eecf6e7a7",
  "manufacturername": "LUMI",
  "modelid": "lumi.sensor_wleak.aq1",
  "name": "Boiler Leak",
  "state": {
    "lastupdated": "2019-01-16T21:43:22",
    "lowbattery": false,
    "tampered": false,
    "water": false
  },
  "swversion": "3000-0001",
  "type": "ZHAWater",
  "uniqueid": "00:15:8d:00:02:33:f2:90-01-0500"
}

dxxxm · 2019-01-17T12:02:16Z

I can confirm "false" water alarm. Happened in the past 12 months a couple of times.
current deconz 2.05.55
e.g. now:

{
  "config": {
    "battery": 95,
    "on": true,
    "reachable": true,
    "temperature": 2100
  },
  "ep": 1,
  "etag": "a02b2bfc34ef5bfe50d41e362dcc9f48",
  "manufacturername": "LUMI",
  "modelid": "lumi.sensor_wleak.aq1",
  "name": "Water Sensor",
  "state": {
    "lastupdated": "2019-01-16T11:24:55",
    "lowbattery": false,
    "tampered": false,
    "water": true
  },
  "swversion": "20170721",
  "type": "ZHAWater",
  "uniqueid": "00:15:8d:00:02:11:b4:59-01-0500"

ebaauw · 2019-01-17T12:02:41Z

After manually reading the Basic cluster attributes, while squeezing the sensor, swversion has changed to 20170721. I even managed to read the power descriptor. While messing with the sensor, tested it as well. It reports leak/no more leak just as it's supposed to.

mdescher · 2019-01-17T12:15:03Z

I did not try the new versions yet, but the constant false alarms (they always occurred a week or two after a reset) made me remove the sensor from my network since those false alarms rendered it useless. Will try with the latest version soon.

maffee · 2019-01-17T12:20:12Z

Is there a way to update it without the Xiaomi Gateway? I assume that is the intended way.

dxxxm · 2019-01-17T12:22:00Z

To winnow down false alarms I have put to ea Xiaomi a Heiman water leak sensor. The later less sleek but never reported a false alarm.

VVW44 · 2019-01-19T13:27:32Z

I have the same false water alarm with two of my water leak sensor Xiaomi "swversion": "20170721 also. That seems to have happened after a long time after add the new sensor, several weeks.

ebaauw · 2019-01-19T13:53:29Z

@dxxxm @VVW44 @mdescher @maffee @martikainen87 could you please check the Model Identifier, Date Code, and SW Build ID of your sensor (see my screenshot above)? You'll have to briefly squeeze the sensor every other second while reading the attributes from the deCONZ GUI. It might take several attempts. If you run headless, please check the /sensors resource, that should report the Model Identifier under modelid and the Date Code (or SW Build ID) under swversion.

martikainen87 · 2019-01-19T14:05:27Z

Sorry @ebaauw, I removed my sensor from deconz and haven't been able to add it back again =/ Had some issues before with the same sensor and now I've mostly given up :P Cant even reset it by holding the button for "unlimited" time.

ebaauw · 2019-01-19T14:17:32Z

It should blink when holding the button for 5 to 10 seconds, see #263. Did you double-check the battery?

mdescher · 2019-01-19T14:22:25Z

@ebaauw

Model Identifier: lumi.sensor_wleak.aq1
Date Code: 20170721

For "SW Build ID" nothing shows up, I tried squeezing every other second and clicking read again and again for several minutes.

manup · 2019-01-19T20:50:56Z

Currently testing some general IAS Zone improvements, turns out also the Xiaomi water sensor can be configured just fine. By writing the IAZ CIE address and sending the enroll response.

Reading the attributes back it looks properly.

I'll keep the sniffer running, and hope for some periodically IAS reports.

dxxxm · 2019-01-20T19:24:22Z

@ebaauw

here you go

  "manufacturername": "LUMI",
  "modelid": "lumi.sensor_wleak.aq1",
  "swversion": "20170721",
  "type": "ZHAWater",

ebaauw · 2019-01-20T19:31:20Z

Thanks, guys. Unfortunately, it doesn't look like versions reporting false positives vs versions that don't.

manup · 2019-01-20T20:20:03Z

To the ones with false positives, please check if the issue remains with latest version:

https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/V2_05_57

dxxxm · 2019-01-21T14:45:07Z

Well, neither a spontaneous self-healing nor worsening ...
Got water sensors on two different locations. Ea site had one "aq1" reporting a false "wet" state. (same swversion, modelid)
Both sites upgraded to 2.05.57 this morning.
After the upgrade situation unchanged, both "aq1" kling on to {"water" : true}.
The local one changed its mind after a deliberate "wetting/drying"-cycle. Done the "brain wash" multiple times in the past. Doesn't last long. (> many days)
As of writing the one on the remote place is still on { "water": true}.
Please s. below. All of the three water sensors located in one spot. (Scoring)
In fact I suspect flakey hardware. Had other lumi.aq1 ones dying slowly after initially working ok-ish. e.g. becoming increasingly unresponsive, blue led constantly on etc
And it's not the battery. Multiple times replaced to boil down on issue. Not the reason.

"16": {
    "config": {
      "battery": 100,
      "on": true,
      "reachable": true,
      "temperature": 1800
    },
    "ep": 1,
    "etag": "77748a46f344d8f272b9776e46ff444a",
    "manufacturername": "LUMI",
    "modelid": "lumi.sensor_wleak.aq1",
    "name": "lumi.sensor_wleak.aq1_16",
    "state": {
      "lastupdated": "2019-01-21T13:57:28",
      "lowbattery": false,
      "tampered": false,
      "water": false
    },
    "swversion": "20170721",
    "type": "ZHAWater",
    "uniqueid": "00:15:8d:00:02:33:4f:83-01-0500"
  },
  "17": {
    "config": {
      "battery": 100,
      "on": true,
      "reachable": true,
      "temperature": 1900
    },
    "ep": 1,
    "etag": "a85ab6eb72a81114dbfd1502c4c8ad57",
    "manufacturername": "LUMI",
    "modelid": "lumi.sensor_wleak.aq1",
    "name": "lumi.sensor_wleak.aq1_17",
    "state": {
      "lastupdated": "2019-01-21T14:19:23",
      "lowbattery": false,
      "tampered": false,
      "water": true
    },
    "swversion": "20170721",
    "type": "ZHAWater",
    "uniqueid": "00:15:8d:00:02:13:8f:22-01-0500"
  },
{
  "config": {
    "battery": 14,
    "on": true,
    "reachable": true
  },
  "ep": 1,
  "etag": "dda709f57bebc95777c9337a0df57760",
  "manufacturername": "Heiman",
  "modelid": "WATER_TPV14",
  "name": "WATER_TPV14",
  "state": {
    "lastupdated": "2019-01-17T23:12:01",
    "lowbattery": true,
    "tampered": false,
    "water": false
  },
  "swversion": "20160311",
  "type": "ZHAWater",
  "uniqueid": "00:50:43:c9:53:29:12:7f-01-0500"
}

Ltek · 2019-02-01T05:58:53Z

Guys, any verdict on these devices... still having false triggers? Worth getting or too much trouble?

mdescher · 2019-02-01T06:52:28Z

My sensor remains in "dry" state since the 2.5.57 update. For me the issue seems to be fixed.

maffee · 2019-02-01T07:10:16Z

Mine was "wet" at the time of the update and has stayed wet. I'm unable to 'reset' the state from HA so I will get the sensor, put it in water, dry it and see if that helps. It helped the last time. It's just that the sensor is in such a difficult place that I haven't had the energy to get out... :)

Will report back.

mdescher · 2019-02-01T07:19:21Z

That's what I did of course, mine did not reset to dry automatically by updating but I didn't expect that either.

manup · 2019-02-01T08:54:06Z

That's what I did of course, mine did not reset to dry automatically by updating but I didn't expect that either.

Likely this is needed since the sensor only sends proper changed value reports. The hourly reports which also contain a water value are not used anymore to update the value.

stale · 2019-06-01T09:18:35Z

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

manup added a commit that referenced this issue Jan 16, 2019

Xiaomi water leak sensor rely on IAS report for water level

3f60fd8

The special report value seems to cause false positives. Issue #905

manup added a commit that referenced this issue Jan 16, 2019

Xiaomi water leak sensor rely on IAS report for water level (2)

68deb91

Update state.lastupdated timestamp. #905

manup mentioned this issue Jan 16, 2019

aqara water leak sensor #822

Closed

stale bot added the stale label Jun 1, 2019

stale bot closed this as completed Jun 8, 2019

Aqara water sensor suddenly reports water for no reason #905

Aqara water sensor suddenly reports water for no reason #905

Comments

mdescher commented Oct 26, 2018

ebaauw commented Oct 26, 2018

mdescher commented Oct 26, 2018

timbru31 commented Nov 5, 2018

martikainen87 commented Dec 17, 2018

JBS5 commented Dec 18, 2018

maffee commented Jan 16, 2019

manup commented Jan 16, 2019

maffee commented Jan 16, 2019

ebaauw commented Jan 16, 2019

manup commented Jan 16, 2019

wvuyk commented Jan 16, 2019

ebaauw commented Jan 16, 2019

manup commented Jan 16, 2019

ebaauw commented Jan 16, 2019 • edited Loading

dxxxm commented Jan 17, 2019

ebaauw commented Jan 17, 2019

mdescher commented Jan 17, 2019

maffee commented Jan 17, 2019

dxxxm commented Jan 17, 2019

VVW44 commented Jan 19, 2019

ebaauw commented Jan 19, 2019

martikainen87 commented Jan 19, 2019

ebaauw commented Jan 19, 2019

mdescher commented Jan 19, 2019

manup commented Jan 19, 2019

dxxxm commented Jan 20, 2019

ebaauw commented Jan 20, 2019

manup commented Jan 20, 2019

dxxxm commented Jan 21, 2019

Ltek commented Feb 1, 2019

mdescher commented Feb 1, 2019

maffee commented Feb 1, 2019

mdescher commented Feb 1, 2019

manup commented Feb 1, 2019

stale bot commented Jun 1, 2019

ebaauw commented Jan 16, 2019 •

edited

Loading