Aqara Water Sensor SJCGQ11LM reports Unknown (issue mentioned in 17145)

[apadua]

What happened?

The listed Aqara water leak sensor (SJCGQ11LM) shows water_leak state as Unknown until it is triggered by water for the first time. After that, they show as Clear when dry.

Although i have no way of testing, it seems like the same thing is happening to the battery_low attribute.

Device that has never seen Water:

Regular Update:

Debug 2023-07-07 12:00:50Received Zigbee message from 'Master Bathroom: Water Leak Sensor', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3195,"10":2538,"100":0,"3":30,"4":17320,"5":29,"6":[0,1],"8":518}}' from endpoint 1 with groupID 0
Info 2023-07-07 12:00:50MQTT publish: topic 'zigbee2mqtt/Master Bathroom: Water Leak Sensor', payload '{"battery":100,"battery_low":null,"device_temperature":30,"last_seen":"2023-07-07T12:00:50-04:00","linkquality":76,"power_outage_count":28,"voltage":3195,"water_leak":null}'

Clicking on Button:

Debug 2023-07-07 12:51:02Received Zigbee message from 'Master Bathroom: Water Leak Sensor', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3195,"10":2538,"100":0,"3":30,"4":17320,"5":29,"6":[0,0],"8":518},"modelId":"lumi.sensor_wleak.aq1"}' from endpoint 1 with groupID 0
Info 2023-07-07 12:51:02MQTT publish: topic 'zigbee2mqtt/Master Bathroom: Water Leak Sensor', payload '{"battery":100,"battery_low":null,"device_temperature":30,"last_seen":"2023-07-07T12:51:03-04:00","linkquality":69,"power_outage_count":28,"voltage":3195,"water_leak":null}'

Z2M GUI:

Device that has seen water:

Regular Update:

Debug 2023-07-07 11:46:45Received Zigbee message from 'Laundry Room: Downstairs AC Water Leak Sensor', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3035,"10":49409,"100":0,"3":29,"4":17320,"5":21,"6":[0,1],"8":518}}' from endpoint 1 with groupID 0
Info 2023-07-07 11:46:45MQTT publish: topic 'zigbee2mqtt/Laundry Room: Downstairs AC Water Leak Sensor', payload '{"battery":100,"battery_low":false,"device_temperature":29,"last_seen":"2023-07-07T11:46:45-04:00","linkquality":109,"power_outage_count":20,"tamper":false,"voltage":3035,"water_leak":false}'

Clicking on Button:

Debug 2023-07-07 12:40:09Received Zigbee message from 'Laundry Room: Downstairs AC Water Leak Sensor', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3035,"10":49409,"100":0,"3":29,"4":17320,"5":21,"6":[0,0],"8":518},"modelId":"lumi.sensor_wleak.aq1"}' from endpoint 1 with groupID 0
Info 2023-07-07 12:40:09MQTT publish: topic 'zigbee2mqtt/Laundry Room: Downstairs AC Water Leak Sensor', payload '{"battery":100,"battery_low":false,"device_temperature":29,"last_seen":"2023-07-07T12:40:09-04:00","linkquality":116,"power_outage_count":20,"tamper":false,"voltage":3035,"water_leak":false}'

Z2M GUI:

Parsing for attribute 100 is linked here and, although there is an "else" for this model, it should only apply when the Model ID is present. This is documented in the code notes and can the logic there be confirmed by the included log messages.

What did you expect to happen?

New Aqara Leak Sensors would always expose Wet or Dry according to the zigbee message received.

How to reproduce it (minimal and precise)

Add a new device to the zigbee network. See it as null. Wait as long as you want (in my case, months). Throw it in water. See it as Wet. Remove it from Water. See it as Dry.

Zigbee2MQTT version

1.32.0 commit: unknown

Adapter firmware version

20230507

Adapter

Sonoff Zigbee 3.0 USB Dongle Plus

Debug log

 /share head log.txt 
[23:42:32] INFO: Preparing to start...
[23:42:33] INFO: Socat not enabled
[23:42:33] INFO: Zigbee Herdsman debug logging enabled
[23:42:34] INFO: Starting Zigbee2MQTT...
Zigbee2MQTT:debug 2023-07-07 23:42:37: Loaded state from file /config/zigbee2mqtt/state.json
Zigbee2MQTT:info  2023-07-07 23:42:37: Logging to console and directory: '/config/zigbee2mqtt/log/2023-07-07.23-42-37' filename: log.txt
Zigbee2MQTT:debug 2023-07-07 23:42:37: Removing old log directory '/config/zigbee2mqtt/log/2023-06-07.18-27-03'
Zigbee2MQTT:info  2023-07-07 23:42:38: Starting Zigbee2MQTT version 1.32.0 (commit #unknown)
Zigbee2MQTT:info  2023-07-07 23:42:38: Starting zigbee-herdsman (0.16.0)
Zigbee2MQTT:debug 2023-07-07 23:42:38: Using zigbee-herdsman with settings: '{"adapter":{"concurrent":null,"delay":null,"disableLED":false},"backupPath":"/config/zigbee2mqtt/coordinator_backup.json","databaseBackupPath":"/config/zigbee2mqtt/database.db.backup","databasePath":"/config/zigbee2mqtt/database.db","network":{"channelList":[25],"extendedPanID":[221,221,221,221,221,221,221,221],"networkKey":"HIDDEN","panID":6754},"serialPort":{"path":"/dev/ttyUSB0"}}'

cat log.txt | grep "2023-07-08 00:17:37: MQTT publish: topic 'zigbee2mqtt/Master Bathroom: Water Leak Sensor'" -B 30
2023-07-08T04:17:36.728Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":179}
2023-07-08T04:17:36.729Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-07-08T04:17:36.729Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0x70ac08fffeebde9d:49409/1 (0,0,1)
2023-07-08T04:17:36.730Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":49409,"destendpoint":1,"srcendpoint":1,"clusterid":2820,"transid":180,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[24,101,11,10,0]}}
2023-07-08T04:17:36.730Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,1,193,1,1,4,11,180,0,30,5,24,101,11,10,0,54]
2023-07-08T04:17:36.768Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100,254,3,68,128,0,1,180,114]
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100,254,3,68,128,0,1,180,114]
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,180,114]
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,180] - 114
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":180}
2023-07-08T04:17:36.769Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-07-08T04:17:37.423Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,5,69,196,101,168,1,234,9,171]
2023-07-08T04:17:37.423Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,5,69,196,101,168,1,234,9,171]
2023-07-08T04:17:37.423Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 5 - 2 - 5 - 196 - [101,168,1,234,9] - 171
2023-07-08T04:17:37.423Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- ZDO - srcRtgInd - {"dstaddr":43109,"relaycount":1,"relaylist":[2538]}
2023-07-08T04:17:37.423Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2023-07-08T04:17:37.448Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,62,68,129,0,0,0,0,101,168,1,1,0,61,0,82,166,234,0,0,42,28,95,17,50,10,1,255,66,34,1,33,123,12,3,40,32,4,33,168,67,5,33,29,0,6,36,1,0,0,0,0,8,33,6,2,10,33,234,9,100,16,0,234]
2023-07-08T04:17:37.448Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,62,68,129,0,0,0,0,101,168,1,1,0,61,0,82,166,234,0,0,42,28,95,17,50,10,1,255,66,34,1,33,123,12,3,40,32,4,33,168,67,5,33,29,0,6,36,1,0,0,0,0,8,33,6,2,10,33,234,9,100,16,0,234]
2023-07-08T04:17:37.449Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [9,28,45]
2023-07-08T04:17:37.449Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,62,68,129,0,0,0,0,101,168,1,1,0,61,0,82,166,234,0,0,42,28,95,17,50,10,1,255,66,34,1,33,123,12,3,40,32,4,33,168,67,5,33,29,0,6,36,1,0,0,0,0,8,33,6,2,10,33,234,9,100,16,0,234,9,28,45]
2023-07-08T04:17:37.450Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 62 - 2 - 4 - 129 - [0,0,0,0,101,168,1,1,0,61,0,82,166,234,0,0,42,28,95,17,50,10,1,255,66,34,1,33,123,12,3,40,32,4,33,168,67,5,33,29,0,6,36,1,0,0,0,0,8,33,6,2,10,33,234,9,100,16,0,234,9,28] - 45
2023-07-08T04:17:37.450Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":0,"srcaddr":43109,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":61,"securityuse":0,"timestamp":15378002,"transseqnumber":0,"len":42,"data":{"type":"Buffer","data":[28,95,17,50,10,1,255,66,34,1,33,123,12,3,40,32,4,33,168,67,5,33,29,0,6,36,1,0,0,0,0,8,33,6,2,10,33,234,9,100,16,0]}}
2023-07-08T04:17:37.451Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0},"transactionSequenceNumber":50,"manufacturerCode":4447,"commandIdentifier":10},"Payload":[{"attrId":65281,"dataType":66,"attrData":{"1":3195,"3":32,"4":17320,"5":29,"6":[0,1],"8":518,"10":2538,"100":0}}],"Command":{"ID":10,"name":"report","parameters":[{"name":"attrId","type":33},{"name":"dataType","type":32},{"name":"attrData","type":1000}]}},"address":43109,"endpoint":1,"linkquality":61,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
Zigbee2MQTT:debug 2023-07-08 00:17:37: Received Zigbee message from 'Master Bathroom: Water Leak Sensor', type 'attributeReport', cluster 'genBasic', data '{"65281":{"1":3195,"10":2538,"100":0,"3":32,"4":17320,"5":29,"6":[0,1],"8":518}}' from endpoint 1 with groupID 0
Zigbee2MQTT:debug 2023-07-08 00:17:37: SJCGQ11LM: unknown key 6 with value 0,1
Zigbee2MQTT:debug 2023-07-08 00:17:37: SJCGQ11LM: Processed data into payload {"voltage":3195,"battery":100,"device_temperature":32,"power_outage_count":28}
2023-07-08T04:17:37.455Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:debug 2023-07-08 00:17:37: SJCGQ11LM: Processed data into payload {"voltage":3195,"battery":100,"device_temperature":32,"power_outage_count":28}
Zigbee2MQTT:info  2023-07-08 00:17:37: MQTT publish: topic 'zigbee2mqtt/Master Bathroom: Water Leak Sensor', payload '{"battery":100,"battery_low":null,"device_temperature":32,"last_seen":"2023-07-08T00:17:37-04:00","linkquality":61,"power_outage_count":28,"voltage":3195,"water_leak":null}'

[TEF2one]

Same thing happened to me since last week... So following you comment I just dipped it in water and then the values updated correctly.

[apadua]

It won't last. Another week or a server reboot or two and it will be back to unknown.

It's scary to have 8 and see a few dry and a few unknown.

You want to be sure that your water automations are 100%.

[ThrashinVictim]

I was having this problem but after a reboot of HA (after upgrade etc.) I get water_leak and battery_settings listed as N/A and never goes back to any other state unless I unpair and re-pair them.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[Ky0sHiR00]

Got the same problem as you guys

[apadua]

We can always build a N/A into the policy, but that's horrible since you won't know if the Water sensor is actually alive or not. And it's a water leak sensor, so it's pretty important.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[knudsvik]

Still an issue

[hlyi]

I have the same issue. could we report "false" when current status is "N/A"?

[djuntgen]

Ran into this as well.

[Koenkk]

This is expected behaviour, you need to trigger the sensor once for z2m to know the state. Assuming the state is dry when pairing is incorrect

[johntdyer]

@Koenkk do you have an example of an automation to do trigger them?

[apadua]

@johntdyer i think he means you need to have it get wet once before z2m knows the state. The problem with that is that z2m forgets the state - so it's harder to make an automation that detects when the device is gone vs when the device is dry for prolonged periods.

The issue i had was that the device got into the weird state some Aqara devices get wehre they're there but really aren't. And i didn't know i had lost leak detection.

I guess the solution then is to find out a way to tell the device is healthy - then assume N/A is dry until it isn't.

[vitalybibikov]

Thanks for support of such a good component as zigbee2mqtt.

I am making transition from ZHA to zigbee2mqtt and noticed difference in how the latter behaves.

For me it is a problem as well, as I am using this sensor in external integration (voice assistant) which I cannot affect

How it triggers right now:

1) Aqara Leak sensor status is unknown (when sensor is new or mqtt was reloaded) 2) Aqara status changes to Wet (external voice assistant does not care as it is not considering unknown -> wet as a state change so nothing happens, notification is not being triggered) 3) Aqara status changes to Dry 4) Aqara status changes to Wet (external voice assistant notifies me about dry-> wet state change) 5) Go to 1 after restart

I consider this sensor as Bool, not bool?, meaning that it has 2 states: Dry(false)/Wet(true), not null/false/true.

Thanks

[cadavre]

So... there is a binary_sensor for leakage in Home Assistant, like mine: binary_sensor.ground_boiler_leakage_sensor_water_leak.

• As long as no water is detected it is in state unknown.
• When water is detected it turns on.
• After water is no longer detected it turns off.

I have no problem with automations, because it triggers an alarm and notification when my binary_sensor turns on, no matter the previous value.

What is your problem with automations? I would love to see "Clear" instead of unknown as well, but it doesn't break any automation rules.

---

There is also a "Trigger count", does anyone of you know what it does?

[shake0606]

For my part, I had the same problem, I couldn't get it recognized by ZigBee2mqtt, so I thought there was an issue, something wasn't right. The humidity sensor wasn't working (showed N/A). So, I opened it up, removed the two screws, and then used a small flat screwdriver along the edges in the gap to uncap it. I noticed it was a bit oxidized on the motherboard. So, I took out the batteries and unclipped it from its holder, then I rinsed it under water and scrubbed it with a toothbrush. After that, I dried it and reassembled everything, and like magic, it worked perfectly. The only minor downside is that I slightly damaged the protective cover when uncapping it

pour ma part j'avais le même problème impossible de le faire reconnaître par ZigBeetomqtt donc je me suis dit il y a un problème c'est pas normal le capteur d'humidité ne fonctionne pas N/A donc je l'ai ouvert j'ai enlevé les deux vis et ensuite sur les rebords j'ai passé un petit tournevis plat dans la fente pour le décapsuler et j'ai remarqué qu'il était un peu oxydé au niveau de sa carte mère donc j'ai enlevé les piles et ensuite je les déclipsé de son support et je l'ai passé sous l'eau et frotter avec une brosse à dents je l'ai ensuite séché et remonter tout ça et puis comme par magie tout fonctionne parfaitement le seul inconvénient minime c'est que j'ai un petit peu abîmé le cache de protection lorsque décapsuler