It makes sense, and nothing wrong with wanting to do things right!

The way this thing works, it will never be off (unless the ‘dry’ address actually works, however Eloy’s testing seemed somewhat inconsistent), so I don’t know if there is any downside to being ‘out of sync’ as the MH object will have to always be ON. 

What about a ‘complex object’? For example the ANALOG_SENSOR item has a few components inside it. It listens for xap temperature values, and this can be queried through $object->temperature. The actual state is user defined.

As this water sensor still isn’t that straightforward (it seems non-deterministic what ON messages are sent to group 1 and then to group 2), An object that is set to wet or dry (that can be set by manual methods — to allow web control or script control) that is also set by insteon ON messages. Since mine has a reliable heartbeat, having a $object->heartbeat method would be good to test each New_minute to see if the battery is dead.

This approach might be regressive based on messages on the list over the past few months about having more simple objects rather than fewer complex ones...

That said, in absence of anything else, this is probably the type of usercode I’d sketch up - a generic item set to wet or dry that changes based on group 1 messages from a water sensor as a triggerlinc. I’d also set up a 25 hour timer based on heartbeat messages. This would work for my use, but I’m wondering if something more robust might be useful as these leak sensors are cheap and I think quite useful.

Any other ideas or suggestions from those that have these sensors?

On Jan 27, 2014, at 5:36 PM, Kevin Robert Keegan <> wrote:

Would it make sense to create a derived object for the water leak from triggerlinc that allows a regular set command? Or is triggerlinc even the best fit object?  If there was an object, it would be nice to include heartbeat warnings, as it looks like those get consistently send 23 hours and 50 minutes.

Creating a WaterSensor object wouldn't be an issue, it probably would not be derived from the triggerlinc, but that isn't a big deal.

I am still a little uncomfortable with the idea of using the set function to reset MH's status while not altering the device.  It would really be an outlier in that we would be encouraging the status between MH and the device to become out-of-sync.  This is partially why I advocated for the tracking object, as the abstracted layer recognizes the distinction between what we represent in MH and what is in fact reality.  The motion sensors have long been able to send only ON commands, granted this is an optional setting, but when in this mode, MH respects their reported state.

Maybe I am trying to be too formalistic.