Reliable water leak sensors

These are Samsung Smartthings STS-WTR-250 which look almost identical with the Centralite sensors, which i have 1 as well and that one looks to be not affected.
This is what it looks like.


huh, unfortunately I only have the original centralite units.

hmm.. so no thoughts on what i may try? Aside from replacing them - which i think i may just do and replace them with Third Reality sensors. I do like these as they report temp. Also, interestingly, these were rock solid on Wink.

Any of those "Lights" that are repeating on your network map bulbs by chance, or are they all plugin outlets?

I prefer the ecolink zwave plus. Nice battery that lasts well over 2 yrs. Never had one drop off. I j
Have about 12 between 2 houses.

1 Like

Reporting issues with that device go way back.

Continuing the discussion from SmartThings Water Leak Sensor:

I'm sure you know this, but it's worth asking. When you join the device, you are holding down the pairing button while you install the battery, correct? I also find it's helpful to keep the battery out for a minute before you hold the pairing button and reinstall the battery.

NOTE: I have only one of the Centralite versions that was produced for Lowes Iris (3315-L), but it's probably the same device with different firmware.

  • endpointId: 01
  • application:
  • firmwareMT: 104E-002A-18005310
  • manufacturer: CentraLite
  • model: 3315-L
  • softwareBuild: 18005310

No, none are bulbs, They're all plug-in Sylvania RGBW flex strips.

1 Like

Yep, i read that thread. It looks like mainly people had issue with joining them to HE, which looked to be channel related. Mine join just fine and are staying connect, with reporting temp and battery, just not wet. The one centralite sensor i have doesnt have the issue, only these samsung ones,

I could send one to you

Most of my old SmartThings water sensors from 2018 are still working (1 still on a battery died)
I have also added quite afew more Aeotec GP-AEOWLSUS Water Leak Sensors.
Most of the SmartThings and Aeotec (might still be 1-2) have all been modified.
I removed the batteries and cut the end off old usb cables and soldered the positive and negitive to the battery connections (of course you void your warrenty).
I hate dealing with batteries
Haven't had any issues pairing these for many years but my zigbee mesh is extremely good.

I also a have 2 hardwired Fibaro leak sensors still working from 2018 but I would recomend the modified Aeotec over them.

aprox 20 in total

1 Like

Thanks for the reply. Are your Samsung sensors same as the ones I posted above, or the other kind. As I recall there was two different types.

yes these ones
Still working fine.

1 Like

Hmm… Would you mind checking your properties page and comparing to my screenshots that I posted above and tell me if anything looks different please?
I don’t get why mine are having this issue… every single one of them.

My firmware is a little older but everything else looks the same.
Just tested the water detection and it works fine.
Only tested one of the old SmartThings water sensors but I am sure the rest will be the same.
As I said it has been modified with a usb cable for power but that shouldn't matter.
This one is on my C7 hub on zigbee channel 20.
One of your other zigbee devices could be causing interference possibly.
I would try zigbee channel 20 first.

1 Like

Thank you!
Yes already on ch20, so that isn’t it. Interference… possible, but I just don’t get why all 5 of them would be connected and report on battery and temp, but not on the state change. Maybe, my mesh is still two week from them, though him I don’t think so, plus one off them is probably bout 15ft away from the actual hub, not even using a repeater.

Have you tried waking them up while hitting “configure” on the device’s page? I’ve had devices not configure properly, and just report battery and temp. Hitting configure again fixed them.

1 Like

Once I was having issues on my zigbee network it was a faulty wall switch.
The only way I found it was to physical power down (trip breaker, unplug, remove batteries) of all my zigbee devices except the one having issues.
Then test the last one to make sure it was working (you may have to pair it to the hub again).
Once I confirmed it was working.
Then go and power on one device at a time testing that device you were having issues with to make sure it is still working.
Until I found the device causing the problems.

The faulty light switch in my case worked fine but messed up my other devices.

1 Like

Oh man… you’re a genius. That exactly what was needed and now they’re all fine. I can’t believe I didn’t do that, if anything just to try. So looks like just specifically, with this model sensor, configure is needed to get the pairing fully completed. Haha.
Thank you!!!

1 Like

Wow, that sounds daunting.. well thankfully the solution here was much easier haha. See above.

1 Like

For what it's worth, before concluding how your sensors are connected you need to consider the scenarios that the Zigbee Graph app draws which are impossible in a stable Zigbee mesh. The most obvious are the cases where it's showing simultaneous connections to more than one router. From the pic you posted above, I've highlighted in red those that are ambiguous:

At most all you can conclude is that one of those sensor-to-router connections may have existed previously, but no saying which one (if any) still exists at the current time.... the multipl-pass process of the Grahp app tends to conflate current links with ones that no longer exist (as well as inventing some that never existed, due to the way it infers mesh connections).

If this were a Z-Wave mesh, where both sensors and mains powered repeaters can track multiple in-range neighbors (discovering them at join time or when requested to do so during Z-Wave repair) this topology could make sense but as depicted, end device-to-multiple-router connections can't happen in Zigbee. A Zigbee end device keeps a persistent link to only one parent router (and checks in with it periodically),. That single parent performs all routing tasks for it and maintains a set of send/receive buffers on its behalf until one of two things happesn... it determines it has lost connectivity to that parent, or is commanded to leave the mesh for some other reason.

4 Likes