Reliable water leak sensors

No, but I'll reset one of them and try that for you.

1 Like

Can you get me a complete fingerprint for the device you have?

2 Likes

I get the feeling I'm talking to myself LOL...

Makes no sense. I joined one of them as a new device, and it picked up the manufacturer specific Leaksmart driver that you wrote. Tested and sure enough it would not report WET. But I pressed Configure and tested again, now reports WET.

Reset the device and rejoined in place and it again correctly reported WET.
Removed the device and joined again and without needing to press Configure, it correctly reports WET. :person_shrugging:

I know I pressed Configure the other day when trying to get this working. Cannot explain the reason it's now working fine. Hub version hasn't changed and I did try a reboot the other day, so there's no outside change I can point to. :face_with_diagonal_mouth:

Here's the fingerprint output.

1 Like

@mike.maxwell - I found the issue. Description text logging has to be kept enabled. I typically turn this off for my devices and I found that it will not report WET if this is disabled. Once enabled it will correctly report WET every time.

1 Like

What driver?, never mind I see the issue, I'll get it fixed so text logging doesn't need to be enabled

5 Likes

It is definitely possible that my mesh is still not good, though i think it improved a lot with me adding additional repeaters (Sylvania Plug-in outlets),
Here's the breakdown of my zigbee mesh:
total 43 devices (12 are repeaters), which are:

  • 4 NYCE door hinge contact sensors (planning to replace those with zwave contact sensors, as rest of my security sensors are zwave.

  • 9 Sylvania/Osram Flex RGBW lights - these are latest revisions that from what i read do not cause mesh issue (Repeaters)

  • 3 Sylvania Smart+ plug-in outlets (Repeaters)

  • 1 Third Reality Toggle Switch actuator

26 Water leak sensors, which are:

  • 9 Leaksmarts V1 (all running latest firmware)
  • 6 Third Reality Leak sensors with siren 3RWS18BZ
  • 5 Samsung Smartthings STS-WTR-250 sensors (these are older smatthings sensor)
  • 1 Centralite 3-series sensor
  • 4 Tuya generic sensors with remote lead

I will be repairing each sensor close to the hub tonight, to see if this improves things. And yes i have the same issue with some of my Leaksmarts as well, they report battery and temp, but not state change. But as i've mentioned, the same problem is with the other sensors as well...

I've moved all my Leaksmarts to the customer driver per the other thread. I think my Leaksmarts are not much more stable, as they no longer drop from mesh like crazy, but some, id say half, still have the issue with reporting on sate change from dry to wet

just to be sure when we're talking about custom driver, we're talking about the driver by ericvitale, correct?

I wonder if that is also a problem with other sensors

This is driver specific. The built-in Leaksmart Zigbee Moisture Sensor driver has the issue. None of the other sensors I have joined to Hubitat, using Generic Zigbee Moisture Sensor and Generic Zigbee Moisture Sensor (no temp) have this problem.

If you’re still experiencing devices dropping, you likely need more repeaters, or you need to experiment with relocating your existing repeaters.

As a result of having Electric heat and multiple Sinope Zigbee thermostats, I have good repeaters in every room of my house.

1 Like

Yeah that makes sense. I do think my mesh is much better now, as i have much less drops, since i've added additional repeaters. Much bigger issue now is with sensors not reporting wet/dry state change.

Descriptive logging 'off' (as @SmartHomePrimer discovered) exposes the problem with wet/dry state change reporting using HE's built-in Leaksmart driver... Turning descriptive logging 'on' fixed the issue with the built-in Leaksmart driver for me as well (generic moisture sensor driver cannot be used with Leaksmarts as it only reports battery and temp).

If some of your Leaksmarts weren't reporting wet/dry change with the custom driver (which never had this issue) its likely there's something (other than a driver) causing a problem.

One thing to keep in mind is that if the hub doesn't process the state change event (say, it's being rebooted or is shut down when an initial dry-wet event happens, or its Zigbee is down), once things are up and running the device will still appear 'dry' to HE until another dry-to-wet event happens, even if it's still in a puddle of water with its alarm sounding. Even a subsequent 'Refresh' from the device details page will not make it show its current wet/dry state.
This would appear to be fixable with a driver change, AFAIK; is that correct @mike.maxwell?

The generic contact sensor driver has the same issue with open/closed status; I use a hacked driver for contact sensors that does sync the device's actual status on command but haven't figured out how to modify the modified ST community Leaksmart driver to do the same.

This capability would be useful as part of a 'sync up' routine to be run at hub restart time just to make sure the hub is seeing the actual current state of sensors when it regains the capacity to begin monitoring them once again... though the probability of missing an event is small, scheduled reboots aren't uncommon.

2 Likes

platform 2.3.8 will have a fix for the reporting as well as adding an attribute fetch for wet/dry status to the refresh command for the leaksmart driver.

3 Likes

@mike.maxwell for the built in leaksmart driver, or for custom driver by ericvitale?

^this
Hubitat doesn't make changes to community drivers.

1 Like

Thats what i thought, but just wanted to doublecheck. So would you say once 2.3.8 is out it would be better to switch back to the Hubitat driver?

I can't say anything, but I would appreciate if someone could test out the Hubitat driver as I didn't actually have a device to test the changes with.

1 Like

Im sure we can help with that! I certainly will be willing.

1 Like

Ok Folks, here's an update. By this point i did the following.

  1. Added 4 more repeaters (2 more Sylvania plug-ins and 2 in-wall outlets).
  2. After adding 4 more repeaters and making sure all other repeaters are functioning, i've reset and re-paired every battery zigbee device, at their intended destinations (all re-paired fine, except one leaksmart that looks like maybe failing)
  3. Shutdown the hub (c8) for 30 minutes.
  4. After restart waited for 24 hours for the mesh to stabilized.
  5. Retested all sensors for wet/dry state change.

Here's what the mesh looks like now. Does it look heathy? (to me it looks messy haha), but joking aside, looking at the mesh, for the most part it does look like most of the battery device are now hanging off a right repeater, for the exception of the few. One question is why a lot of them still have a tentative (gray line) line back to the hub?

Now, more on item #5.

  • All Third Reality sensors, Tuya sensors and one Centralite sensor have reported wet/dry state change as expected - so good news there.

  • Out of 9 Leaksmarts, 7 have reported the wet condition, and two have not. I will re-pair those again and we will see

  • Here's looks to be where the big problem is, None of the 5 Samsung Smartthings STS-WTR-250 sensors are reporting the wet state change when tested. However all 5 are online and reporting the the battery/temp, as well as responding to a refresh command.

Any thoughts @mike.maxwell ?
Here are the properties for one of them. All are setup the same, using the same driver.