Aqara Water Sensor SJCGQ11LM reports Unknown (issue mentioned in 17145) #18243
Comments
apadua
changed the title
|
Same thing happened to me since last week... |
|
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%. |
|
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. |
|
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 |
|
Got the same problem as you guys |
|
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. |
|
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 |
|
Still an issue |
|
I have the same issue. could we report "false" when current status is "N/A"? |
|
Ran into this as well. |
|
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 |
|
@Koenkk do you have an example of an automation to do trigger them? |
|
@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. |
|
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:
I consider this sensor as Bool, not bool?, meaning that it has 2 states: Dry(false)/Wet(true), not null/false/true. Thanks |
|
So... there is a binary_sensor for leakage in Home Assistant, like mine:
I have no problem with automations, because it triggers an alarm and notification when my What is your problem with automations? I would love to see "Clear" instead of There is also a "Trigger count", does anyone of you know what it does? |
|
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 |
|
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days |
|
Is this not still an issue?
|
As per discussion in Koenkk/zigbee2mqtt#18243, null values are expected for some properties. As this behavior is somehow suprising, add a note in the docs about that.
As per discussion in Koenkk/zigbee2mqtt#18243, null values are expected for some properties. As this behavior is somehow surprising, add a note in the docs about that.
|
I also faced this issue after migrating from deconz, which was instead reporting either true or false with this sensor. We can check if sensor is alive through the other attributes (e.g. device_temperature). |
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:
Clicking on Button:
Z2M GUI:
Device that has seen water:
Regular Update:
Clicking on Button:
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
The text was updated successfully, but these errors were encountered: