How do I kill alerts from a Water Sensor DTH?


#1

I’m trying to make use of a Samsung Water Sensor as a dry contact input. Easy enough.

I created a custom DTH based on the standard Water Sensor one, but I can’t figure out where the toast popups the SmartThings android App generates comes from to turn them off and/or customize them.

Also, no matter what I mangle, I don’t seem to be able to override the Wet/Dry statuses in the app.

I’m starting to conclude that some of this is being controlled by the Water Sensor capability, rather than the DTH itself.

Hints? I’d show my code… but thus far the only useful thing I’ve managed is to change the sensor ‘type’ :confused:


#2

OK I’ll bite. What DTH is your source? You say the ‘standard Water Sensor’ one, but which one is that? Is it smartsense-moisture-sensor.groovy for example?

The bottom line with the DTH is that messages from the device will arrive as arguments to the parse() method. The parse() method processes them, typically with some help, and the end result is usually a map that it uses as the argument to createEvent(). So if the water sensor is alerting you that water has been detected the parse method will end up returning createEvent( name: 'water', value: 'wet' ) (often with a descriptionText: 'message' as well). SmartThings will take that return value and use it to set the appropriate attributes and propagate change events to anything that is interested in them.

Custom capabilities haven’t been released yet, so if you want your DTH to be useful it has to work with a standard capability. So if you don’t want it to be a Water Sensor, which uses the attribute ‘water’ with values ‘wet’ and ‘dry’, you need it to be something else binary.

Here are some possibilities:

Water Sensor           water             wet           dry
Switch                 switch            on            off
Contact Sensor         contact           open          close
Motion Sensor          motion            active        inactive

Can you see where this is going? You replace the capability 'Water Sensor' with whatever capability you want to use e.g. capability 'Switch'. Then you track down where the moisture alarm is being processed and look for the map being generated. You change the name: 'water' to e.g. name: 'switch' and value: 'wet' to e.g. value: 'on' (likewise for 'dry', of course).

You will have a tiles() block that creates the custom UI for the Classic app. That will need adjusting too, but if you don’t use the Classic app just junk the entire tiles() block as you don’t need it.


#3

Success!

That’s exactly the DTH I was using as a baseline… and I fell for both traps of trying to mess with a custom capability, and custom tiles. :confounded:

Your hint on swapping the capability out and then mangling the value mapping did just the trick, so now I can move on to playing with my pistons.

For context (because obviously we all like geeking out over this stuff)… I’ve got an inductive relay sensing current draw on my sump pump, and the output of that relay is shorting the water sensor.
I’m hoping to log activations, and build some alerting around excessively long cycle times… if I get really froggy I might try to trigger an alert when I haven’t seen the pump fire when I’d expect it to based on rainfall data.

Yes, I could have just used a plug to get my power readings, but inductive was part of my design criteria so that it could never be turned off or fail in a way that would result in flooding.

Thanks!


#4

I applaud your optimism… Really I do.

I sincerely wish total success for this piston…
(and all others you create)

However…

I am aware of how easy it is to get complacent…
It’s too easy to think (hope) it is a “set it and forget it” situation.

I have not seen your piston, so this next bit is not directed at you, but more of a challenge to the community… I think we should try to enjoy the convenience of SmartHomes, but to not loose diligence on anything essential or crucial to our family. (locks, fire detectors, flood sensors etc)

Even with a 99% success rate, and an additional double check in place increasing the rate to 99.9%, (which is really phenomenal for this budding technology), that one time a year failure on certain devices can be very costly.


#5

I wholeheartedly agree, which is why I took care to not introduce any components into the critical path of the actual sump operation.

This is (indirectly) monitoring the current draw for statistics and such. Really just a digital version of “hey, I’ve heard it running a lot today” or “hrm, I haven’t heard it run lately”.

I’m 100% not a fan of using this sort of system as any kind of life/property safety tool. Even some of the burglar alarm things folks build make me nervous.