Jump to content

INSTEON Water Leak Sensor, low battery on ISY99?


tome

Recommended Posts

Does the INSTEON Water Leak Sensor (2852-222) send a low battery signal to the ISY99 when it is time to change the battery? On the description it claims to send a daily heartbeat, does the ISY99 report if that is missed as well?

Thanks,

Tom

Link to comment
Hi Tom,

 

ISY does not listen for daily hearbeats.

 

With kind regards,

Michel

 

 

Are there plans to add that? Seems like a critical feature for something like a water detector (to know it is still working). Do you know if it reports low battery?

 

I am considering this device or a Waterbug type device connected to either an IOLinc/ISY or my Ecobee thermostat which has some limited home automation functionality. I want it to be reliable and as maintenance free as possible.

 

Thanks,

Tom

Link to comment
Tom,

 

ISY does hear the hearbeat but does not actively listen or do anything with them. Low battery should work.

 

With kind regards,

Michel

 

Can a program be written on the ISY to do something with it, if it hears them?

Tom

Link to comment

Hi Tom,

 

Not at the moment. The reasons are:

1. I have one of those here and I've yet to receive a 100% accurate heartbeat every 24 hours (ever)

2. Heartbeat need to become another property such as on level/ramp rate

3. We have to alter ISY processing to do things based on broadcasts and not multicasts

 

So, obviously we can add support for these features but it will not be something quick since it requires major regression testing (see #3).

 

With kind regards,

Michel

Link to comment
  • 3 weeks later...

I too just added six of these sensors to ISY this weekend. They all added flawlessly.

 

Happy to hear if I can help test or watch for Heartbeat (Group 4) signals anyway here.

 

Here are a few notes I had on the sensors.

There is a jumper (jp1) installed in the ON position on the board, wonder what that is about?

 

After prior issues with the i/o linc water sensor kits I wanted to the wet/dry contacts.

 

After adding all of the sensors I tried putting them in a dish with 1/4 of room temp tap water (softened). 4 of the 6 responded instantly as expected with on/off as dipped/dried. 1 of them seemed turned on the led for 2 seconds (or very fast blinked) when dipped/dried the first two times. On third+ tries it behaved as expected.

 

1 of the units failed to respond to dipping in the water. After 3 tries manual push of the set button triggered brief blink of the led and expected status change. Tried re-dipping in water after this and again no response. Opened the case and made slight adjustment the + battery terminal that was rather loose. Also inspected the case for water (none). Re-installed case, re-dipped and received expected on signal. Tested a few cycles of wet/dry and all worked fast. Rather surprised that batt re-seat or cover re-seat "fixed" it but seems to.

Link to comment

How about add group 4 as another node "Heartbeat" and use the following program

 

If
       (
            Control 'Leak Sensor-Heartbeat' is not switched On
        And Control 'Leak Sensor-Heartbeat' is not switched Off
       )
   Or Time is Last Run Time for 'Leak Sensor Monitor' + 36 hours 

Then
       Send Notification to 'Me' content 'Leak Sensor Error'

Else
  - No Actions - (To add one, press 'Action')

Link to comment

Hi az1324,

 

The main issue is that heartbeat is a broadcast and not multicast (to a group) so a) we have not yet seen this message and B) we have to be cognizant of all 99s out there. Adding another node is certainly doable but might cause the code size to exceed that of 99.

 

So, for now, if anyone can keep the event viewer on for more than 24 hours and monitor messages from leak sensors, it would be fantastic to see how many actually get this message.

 

With kind regards,

Michel

Link to comment

When wet, it will send the group 2 on message every 15 seconds. I don't know if this continues forever as I didn't leave it running for very long.

 

When going from wet to dry, it will send the group 1 on message once.

 

When pushing the set button, it will send the group 1 or 2 message depending on state and then 15 seconds later will send the group 4 message.

I will let you know what the behavior is when it is undisturbed for 24hrs+, but I expect the group 4 message will come in.

 

I don't see why specifying that a leak sensor has a group 4 node would change the codebase. The way I'm doing these tests is just adding the leak sensor as a remotelinc 2 4 scene and it works fine to trigger my program below:

 

If
       Time is Last Run Time for 'Leak Sensor Monitor' + 36 hours 
    Or (
            Control 'Leak Sensor - D' is not switched On
        And Control 'Leak Sensor - D' is not switched Off
       )

Then
       Send Notification to 'Me' content 'Program Details'

Else
  - No Actions - (To add one, press 'Action')

 

Obviously group 1 (A) doesn't turn off when group 2 (B) turns on or vice versa but I don't think that is important since they will still trigger programs. I'll just keep running it as a remotelinc 2 until it is fully supported.

 

This is how I did notifications:

 

Leak Sensor Wet

If
       Control 'Leak Sensor - B' is switched On
    Or Control 'Leak Sensor - D' is switched Off

Then
       Send Notification to 'Me' content 'Program Details'
       Disable Program 'Leak Sensor Wet'

Else
  - No Actions - (To add one, press 'Action')


 

If
       Time is Last Run Time for 'Leak Sensor Wet' + 15 minutes

Then
       Enable Program 'Leak Sensor Wet'

Else
  - No Actions - (To add one, press 'Action')


Link to comment

Hello az1324,

 

Thanks so very much for the feedback. Please note that based on the developers doc:

cmd = INSTEON command
param = param 1

  if (cmd == LIGHT_ON_INSTEON_COMMAND)
  {
   if (param == 0x01 || param == 0x04)
   {
            //Dry
     set DRY node ON
            set WET node OFF
   }
   else if (param == 0x02)
   {
     //Wet
            set WET node ON
            set WET node OFF
   }
  }
  else if (param == LIGHT_OFF_INSTEON_COMMAND)
  {
   if (param == 0x04)
   {
     //Wet
            set WET node ON
            set DRY node OFF
   }
  }

 

So, in essence, what you are doing is using raw data whereas ISY tries to figure out what they mean. This might be OK for you as I am sure you are pretty well versed in all things INSTEON but adding multiple nodes to a simple device makes it quite difficult for us to support (all different permutations). Furthermore, as you can see above, this code is NOT common. As such, adding nodes will indeed impact the code base.

 

In all cases, I am very eager to see whether or not you get 4 group commands every 24 hours.

 

With kind regards,

Link to comment

If what you posted is the way it is currently processed then it should already support the heartbeat as it would either cause a DRY ON or WET ON event. Then simply ensuring one of those occurs every 24h would be fine for heartbeat detection and no additional nodes would be required. However I did not see any group 4 events in the event viewer when pushing the set button until I changed the device to remotelinc so maybe the group 4 link is not written?

Link to comment

Ok heartbeat came in at pretty much exactly 24hrs since the last heartbeat. This is even though there were other group 1&2 messages more recently than that. So spacing is 24hrs from last group 4 message.

 

Why have you never seen them? You didn't write the group 4 link. :wink: If the leak sensor has no group 4 links in its database it is not going to send any group 4 messages. Which is fine since why would it waste its battery sending if nobody is listening?

 

So a simple fix for you.

Link to comment

az1324, is this a fix that UDI has to make (writing the group 4 messages) or something I can address as a user? I've been an INSTEON user for years but I don't even know what "group 4 messages" are! I am about to install a leak sensor to forestall a repeat of our $10,000 repair bill for a sewer backup and I need to be sure I can track when its out of power. Dumb that Smarthome didn't provide a low battery event from the device, but sounds like this heartbeat process will work if ISY supports.

Link to comment

The choice of no low battery notification is Smartlabs choice and they never comment on their choices.

Like a big secret. Even the Developers Group members rarely get any data on their choices. Sometimes if we are lucky they give us a set Developers Notes for the device in question. The leak sensor has no low battery notification as of the publication of the notes we got.

Also they specify it has a Lithium Battery and it should last ten years. :?:

 

From the Heartbeat findings. Seem it doesn't match the Developers Notes either. :roll:

Link to comment
RichTJ99

 

SmartLabs is estimating 10 year battery life. Not sure how useful a low batt indication after 10 years would be. Any bets on whether that Leak Sensor will be functional 10 years from now.

 

Yes low battery would probably not be that useful, but would not have taken much effort to do it anyway. The heartbeat is more useful in that RF signal path changes over time are also a problem and regular monitored communication helps prevent a situation where the sensor needs to notify of a leak and the RF signal can't get through. Using the heartbeat as the dead battery notification, worst case the sensor battery is dead for 24hours before you know about it.

Link to comment
RichTJ99

 

SmartLabs is estimating 10 year battery life. Not sure how useful a low batt indication after 10 years would be. Any bets on whether that Leak Sensor will be functional 10 years from now.

 

Perhaps I am being naive but I would say it had better be functional 10 years from now! I have a Waterbug monitor tied to my security system for a critical sump pump and it has worked flawlessly since 1999 (knock on wood). I don't anticipate it failing either. I don't mind changing a battery every 10 years (more or less) but I would fully expect the thing to work! But that's just me I guess... :)

 

I guess heartbeat is better than a sharp stick in the eye, and as was pointed out, worse case is 24 hours of dead battery. Of course, Murphy's law will dictate that that failure will occur during the 500 year flood :shock:

 

Tom

Link to comment

Hi az1324,

 

What you are suggesting does not jive with what we have developed to. Again, this is NOT a group 4 command and it should not be. This is a parameter = 4 in a broadcast (not group) message. The reason they used broadcast was because they wanted to save a link. So, the question is whether or not we should code to what you have found or what the developers guide suggests.

 

Do you see any broadcasts with param=4 at the same time as the group 4 command?

 

With kind regards,

Michel

Link to comment

Thu 01/31/2013 01:51:54 AM : [iNST-SRX    ] 02 50 21.22.23 00.00.02 C7 11 02    LTONRR (02)

Thu 01/31/2013 01:51:54 AM : [std-Group   ] 21.22.23-->Group=2, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:51:54 AM : [  21 22 23 2]      DON   2

Thu 01/31/2013 01:51:54 AM : [  21 22 23 2]       ST 255

Thu 01/31/2013 01:51:55 AM : [iNST-SRX    ] 02 50 21.22.23 00.00.02 C7 11 02    LTONRR (02)

Thu 01/31/2013 01:51:55 AM : [std-Group   ] 21.22.23-->Group=2, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:51:55 AM : [iNST-DUP    ] Previous message ignored.

Thu 01/31/2013 01:51:56 AM : [iNST-SRX    ] 02 50 21.22.23 11.00.02 C3 06 00           (00)

Thu 01/31/2013 01:51:56 AM : [std-Group   ] 21.22.23-->11.00.02, Max Hops=3, Hops Left=0

Thu 01/31/2013 01:51:57 AM : [iNST-SRX    ] 02 50 21.22.23 11.00.02 C7 06 00           (00)

Thu 01/31/2013 01:51:57 AM : [std-Group   ] 21.22.23-->11.00.02, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:51:57 AM : [iNST-DUP    ] Previous message ignored.

Thu 01/31/2013 01:52:10 AM : [iNST-SRX    ] 02 50 21.22.23 00.00.04 C7 11 04    LTONRR (04)

Thu 01/31/2013 01:52:10 AM : [std-Group   ] 21.22.23-->Group=4, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:52:10 AM : [  21 22 23 4]      DON   4

Thu 01/31/2013 01:52:11 AM : [iNST-SRX    ] 02 50 21.22.23 00.00.04 C3 11 04    LTONRR (04)

Thu 01/31/2013 01:52:11 AM : [std-Group   ] 21.22.23-->Group=4, Max Hops=3, Hops Left=0

Thu 01/31/2013 01:52:11 AM : [iNST-DUP    ] Previous message ignored.

Thu 01/31/2013 01:52:11 AM : [iNST-SRX    ] 02 50 21.22.23 11.00.04 C7 06 00           (00)

Thu 01/31/2013 01:52:11 AM : [std-Group   ] 21.22.23-->11.00.04, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:52:12 AM : [iNST-SRX    ] 02 50 21.22.23 11.00.04 C7 06 00           (00)

Thu 01/31/2013 01:52:12 AM : [std-Group   ] 21.22.23-->11.00.04, Max Hops=3, Hops Left=1

Thu 01/31/2013 01:52:12 AM : [iNST-DUP    ] Previous message ignored.

 

The dev doc must have a typo (x3) since if you note it specifies ALL the messages are broadcast when in fact they are ALL group broadcast (flag is set). But then there are no cleanup messages so they are kind of a hybrid I guess. :? Plus it makes sense to only send the heartbeat messages if someone has subscribed to them. As far as saving a link, don't know what to tell you.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...