I tested it again and it didn’t reset. I ended up taking the backing plate off so the button was exposed to reset it. That ended up working.
Glad that worked, but kind of a bummer you had to do that. Ironically, I
just replaced one of mine with the Lowes Iris Leak Detector. It’s Zigbee
and identical to the ST branded version, but it joined a Thing. That was
easily fixed by changing the DH in the IDE to SmartSense Moisture Sensor.
I like the smaller compact design compared to the Everspring (it still has
it’s pros too).
One thing I noticed when testing was that the LED was not turning on when it got wet. It beeped (not super loudly), but that was it.
@tosa I have 4 of these running your code and they never seem to report battery. They all read 100% and one has been in use for a year plus. Tested and it still working but there is no way it’s still at 100%. Thoughts?
I can’t speak for @tosa, but I bet these devices don’t report actually battery levels so they can preserve as much battery as possible. According to the device’s documentation:
The Water Leak Detector is powered by 3x AA 1.5V alkaline batteries. When battery level drops to an
unacceptable level, the Detector will flash a red LED once every 30 seconds and report low battery
status to the Iris™ Smart Hub. Iris™ will notify you of the low battery status. When this occurs, the
batteries should be replaced as soon as possible.
Based on that description, ST will probably always show 100% until the battery drops to that level, and then there could be some type of notification. ST’s default device handler does have the check for low battery, as does the DH posted above.
It’s been a long time since I’ve looked at this since my SmartThings has been boxed up due to a move. But I’ve got it set back up, and here’s what I remember about this device… @johnconstantelo is right about the device conserving battery power and about it alerting on low battery level. However, the device can also respond to battery status query during its wake up notification. The goal of my handler was to be able to modify this wake up interval (e.g. set it to wake up even less often to conserve even more battery) and to report battery status during wake up notification. At the time I wrote it, I had tested both the Utilitech and Everspring versions of the device with various levels of depleted batteries. Both reported battery level, and both would update their wake up interval according to settings. However, some time after that, a hub firmware update seemed to break the wake up notification and response. And SmartThings said it was my code even though it had been working before the hub update. Alas, it was then that I boxed it up and never did figure it out.
But like I said, I’ve recently set it back up, so perhaps I should look at this again! The time to respond to the device’s wake up notification is short, so back then I didn’t know if v1 hub latency was an issue – keep in mind back then it was not a v1 hub, just the hub because there was no v2 yet. I still only have the v1 hub, but presumably it now has newer firmware that perhaps behaves differently?
The one time the device does stay awake for an appreciable amount of time (min instead of msec) is right after power up. As an experiment, you might try pulling the batteries for a few seconds, then popping them back in to see if then the device reports a different (more depleted) battery level.
I’m having the same issue where it is showing wet - days after a test. It is clearly dry. I’ve taken the back off but I see no change. I can see the sensor is communicating in the logging. Any tips on what you did with the button to reset it?
See this thread, there are a few batches of defective electronics the cause the sensor to get “stuck”.
So, I finally got back to this device. One thing that’s always bugged me is not knowing if the device is “still out there”, short of going around and manually tripping the sensor (which I still do from time to time). Anyway, I made a couple quick mods to:
report to the activity feed changes to the Wake Up Interval (i.e. when the device actually picks up and sets a User change to the Wake Up Interval in the device settings).
Added an option to report to the activity feed each time the device Wakes Up. This is my way of being able to monitor that the device is “still out there” by just checking recent activity. I have made it an option in the device’s settings because if I don’t, then somebody will ask to be able to turn it off.
Added an option to always report the battery status, even if no change since the last report – for the “hey, is this thing really reporting battery level?” people. Should be the case that a change in battery level will still get reported to activity feed regardless of this setting (along with the typical low battery alarms). But with this option on, each time battery level is reported, it will go to the feed, even if it hasn’t changed since last report. So far my experience has been that batteries last a loooong time.
I’ve also taken a stab at this GitHub thing and have moved this device type to:
I’ve tested this on both Utilitech and Everspring branded sensors, and it seems to work ok. But since I do this only very part time, let me know if you find any problems with this handler.
Thanks for this. I’ve installed for my six Utilitechs and all seems good. What are the github repo parameters for (if and when) updates?
The batteries do last a long time. I’m over 2 years on a set. I’m using a different DTH but it still shows 100%, not sure I believe it.
Have you seen anything other than 100% battery?
I was just wondering the same thing. I think these devices report either the battery is good, or a low level; but not actual. I thought I remember reading that somewhere a while back, but it’s worth a try to see if this DTH does capture actual.
I’m trying @tosa’s DTH right now with both options enabled. I also tweaked it to use multiAttributeTile features and to put a “\n” in front of the word battery to get it on a second line. Right now it still says 100% (it’s been in use for at least 2 years).
Here are results for me. I set the wakeup to 2 minutes to see what happens. You can see the battery % bounce between 90 and 100:
When I was first working with this DTH, I ‘borrowed’ a number of batteries from my kids’ toys that were in various states of depletion. Definitely reported the different battery levels. But I think it was in 10% steps, and it was something like anything below 20% instead triggered the low battery alarm.
@johnconstantelo, for my mobile app of choice, the word “Battery” is on the second line just by word wrap happenstance. So I never looked at it beyond that. Good to know that maybe not everything word wraps the same and could benefit from a line feed.
Also curious about your change to the multiattribute tile given this is such a simple device. Did you add item(s) to display? Just a layout preference?
I’m running Android on a Note 5, so perhaps the screen width was just wide enough not to force the word wrap. I’m so use to adding that now. See the image below.
I didn’t add anything, just a layout preference for me:
I needed to add code to DTH to make compatible with ActionTiles:
> capability "Sensor" > capability "Actuator"
Thanks for the work on this!
Thanks so much, this couldn’t have come at a better time as I found my sensor was dead as a door nail from batteries earlier this week. It is only 3 months old or so and I didn’t anticipate the batteries would be dead but I checked them and they were completely depleted. I don’t know how long they were dead or how long it was offline since there was no log history in ST.
Hopefully this will help alleviate that happening again