False "wet" reports attributed to Dome Leak Sensor

🛎️ Get Help
1

I removed one of my Dome Leak Sensors from ST and added it to my HE, and HE will occasionally report that this sensor is wet (triggering some RM rules), even though the sensor itself is not giving its sound/LED alarm. This never happened in ST.

If I test the sensor with actual water, it always correctly gives its sound/LED alarm and reports "wet" to HE, then "dry" when I remove it from the water. But at random intervals of hours or days, HE will just report that the sensor has become "wet", even though the sensor itself is clearly not wet and not giving its sound/LED alarm as if it were wet. I can hit "refresh" in HE and press the sensor's button to flash the LED and wake up the device, and the battery level may update, but HE will not update the status to "dry". Similarly, I can take out the battery on the sensor and put it back in, but no "dry" in HE. Only way that I have found to get HE to recognize that the sensor is dry is to set the sensor in water (so it actually does alarm) and then remove it (so it stops alarming).

Has anyone else had anything like this happen? Any solution discovered? Could this be an issue with Z-wave interference, as I have a separate ST Z-wave network still running in the same house?

I will probably try removing, resetting, and re-adding the sensor when I have time, but, no, I haven't tried that yet.

1 Like
2

I’m having the same problem with the lowes Utillitech water sensor.
An aeotec motion sensor is stuck on as well. Re-pairing it fixes it for about a week then they revert.

3

Can't say for sure if it's related, but my ST moisture sensor is also stuck on "wet". I didn't have time to troubleshoot this morning but I checked the sensor and it was dry at the time. Also none of my light automation (turn blue) seemed to trigger either.

1 Like
4

I have also noticed in my logs that other Z-Wave device drivers are reporting strange unhandled commands, such as:

[warn] Downstairs Bathroom Fan received unhandled command: ThermostatHeatingModeReport(mode:255)

The above device is a GE/Jasco Z-Wave Plus Toggle-Style Switch using the Botched1 driver, but the way I understand the above, parse() on this device driver is being called for some Z-Wave event corresponding to a thermostat mode report.

I’m not clear whether this issue is unique to my setup or whether somehow certain Z-Wave events (such as an alarm report that could be falsely interpreted by a water sensor’s driver as “wet”) received by the HE Z-Wave radio are being sent to incorrect HE devices and their drivers to be parsed and handled.

5

Did anyone get resolution to this? I’m considering buying dome leak sensors for their extension cable ability