INSTEON Water Leak Sensor, low battery on ISY99?

[az1324]

Excellent work. Unfortunately it is not documented in the dev notes.

[LeeG]

Although I don't subscribe because of the NDA, enough of these situations where the doc is either missing or wrong makes me wonder how useful a subscription really is.

 

In the past a Controller Set button link stored the Responder cat/subcat values in the On Level and Ramp Rate fields. Never heard of a case where this information was used in the past. Perhaps the 03 is taken as a PLM responder and generates the Group Cleanup Direct. Pure speculation.

[az1324]

Interesting, but not sure why it would use that info as a filter since aren't all Insteon devices capable of group cleanup behavior? If you get bored, see what values work and which don't.

[LeeG]

I'm not that bored.

[junkycosmos]

Nice work All !

my .002

>I prefer the Heartbeat as a separate node. Easier for us programming rookies to keep things straight

 

>don't mind having to remove and re-add back

 

Few questions; more thoughts than needing replies.

>what new devices may come next with heartbeat group? Doing separate node now might set good path for next devices.

 

>does any of the above heart beat / node testing need to be done with low batt? Of course the idea is no heartbeat once unit or batt is dead. However recall issues with low batt signal variance from 2420Ms. Personally I cannot think of any scenario here however I know some of these wireless devices have been a tad inconsistent with low batts.

 

Thanks

J

[LeeG]

>does any of the above heart beat / node testing need to be done with low batt?

 

A Program would be triggered when the Low Batt turns On if something like an email notify was to be done. The heartbeat requires a Program with a Wait of 24-?? hours with an email notify if the Wait completes. Not sure how accurate the heartbeat relative to actual 24 hours which is why perhaps a 36 hour Wait would work better.

[az1324]

Mine is set to 25 hours. No alerts.

[RichTJ99]

So is the heartbeat alert now working in a newer firmware, or is this something that needs to be done manually?

[Michel Kohanim]

Hi RichTJ99,

 

Yes, but you will have to remove your Leak Sensor and then add it back in so that you get a heartbeat node.

 

With kind regards,

Michel

[DigitalAnvil]

Hi RichTJ99,

 

Yes, but you will have to remove your Leak Sensor and then add it back in so that you get a heartbeat node.

 

With kind regards,

Michel

 

with the official firmware or the beta?

[LeeG]

The 4.0.1 Beta has support for the Heartbeat node.

[mattc]

Lee/Michel,

 

I realize this thread is old, but I was writing a post on the leak sensor for my blog (http://homeautomationguru.com/), and went down the rabbit hole on what the "heartbeat" node actually meant. This thread came the closest to explaining what it was and the thought process that went into the implementation, but I wanted to make sure my understanding is correct. As of the 4.0.1 release, the "heartbeat" signal is a "node" in the ISY, but it will NEVER be OFF, right? All that really happens is the device sends an ON signal every 24 hours that an end user can programmatically detect and alert on if another one doesn't come in within the next 24 hours (using the "wait" command in a custom program)?

 

As a programming end user, in a perfect world I'd write a program that alerts me when WET changes to ON (indicating a leak) and when HEARTBEAT changes to OFF (indicating that it's been more than 24 hours since the last heartbeat signal was received and the device is no longer "online"). The current implementation is very similar, but I can't check for OFF on the heartbeat - I have to "start the clock" myself, right?

 

Here's the raw text from my blog post draft going out next week - I'm not asking for any proofreading or anything, but I'm interested in fact-checking before it's officially published:

When added the to the ISY-994i, 3 distinct nodes show up: “Dryâ€, “Wetâ€, and “Heartbeatâ€. The first two are pretty much redundant – when the state of “Dry†is “Onâ€, the state of “Wet†is off – and vice-versa. So any program you could write (such as “send me a text message when a leak is detectedâ€) would work with either of them.

 

The “Heartbeat†node is a bit more complicated – as the much-smarter-than-me folks on the Universal Devices Forums have extensively discussed during the implementation phase. The problem (as I perceive it) is that in the past, wireless Insteon devices such as the motion detector or smoke detector bridge sent a signal for “low battery†when the device’s battery was low. This is great because you as an end user can write a program to alert you via email or text message when the battery for these devices gets low. But, what if for some reason one of the following conditions occur:

* the battery goes POOF! and dies very quickly, preventing the device from sending a signal that it has a low battery in the first place

* the device goes out of range for some reason before the battery dies and it’s able to send the “low battery†signal

* power is lost to the dual-band device that’s receiving these RF signals for an extended period

* the battery is removed from the device

 

The above reasons are, I believe, why Insteon made this fundamental change from actively sending a "low battery" event to regularly to sending daily "heartbeat" events. Now, instead of the wireless device being responsible for notifying the central controller (ISY) when it’s about to go dead, the Insteon engineering team have shifted that burden to the central controller itself. In other words, I believe the Insteon engineers intended for the ISY “Heartbeat†node to go OFF if a “heartbeat†signal was not received within 24 hours, and stay ON the rest of the time. This would enable end users to write a program that said “if the heartbeat for the leak sensor goes OFF, send me a message to check on the device because the ISY hasn't heard from it in the past day for whatever reasonâ€.

 

Instead, it appears that the current implementation is to simply raise a "control" state for a "heartbeat" message that end users can detect and alert on in their programs using a "wait" statement. This approach makes sense because it would be a paradigm shift for the ISY to set the heartbeat flag to OFF after 24 hours without actually getting an OFF message on the Insteon network. But, this means it's the responsibility of the end user's program to confirm that a heartbeat is received every day rather than the ISY's...

[LeeG]

"the "heartbeat" signal is a "node" in the ISY, but it will NEVER be OFF, right?"

 

This is not correct. The Heartbeat node can be On or Off. The Heartbeat message contains an On or Off command based on the Wet/Dry state of the Leak Sensor.

 

This is my Heartbeat Program

If
       Control 'Leak Sensor-Heartbeat' is switched On
    Or Control 'Leak Sensor-Heartbeat' is switched Off

Then
       Wait  25 hours 
       Send X10 'A10/All Lights On (5)'

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

[mattc]

Thanks LeeG!

[RichTJ99]

Whats the best way to test out the program? Dump water on it, get the response & then dry it off?

[LeeG]

Tap the Leak Sensor Set button. The Leak Sensor will alternate between Wet message, Dry message, Wet message, etc for each Set button tap.

[ndfan77]

"the "heartbeat" signal is a "node" in the ISY, but it will NEVER be OFF, right?"

 

This is not correct. The Heartbeat node can be On or Off. The Heartbeat message contains an On or Off command based on the Wet/Dry state of the Leak Sensor.

 

This is my Heartbeat Program

If
       Control 'Leak Sensor-Heartbeat' is switched On
    Or Control 'Leak Sensor-Heartbeat' is switched Off

Then
       Wait  25 hours 
       Send X10 'A10/All Lights On (5)'

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

Wouldn't the net effect of that logic be to only send one notification (after the first 25 hour period expired without a heartbeat), but then nothing more after another 25 hours, etc. ? And, also, isn't it dependent on the heartbeat firing at least once to start the 25 hour wait?

 

I switched to a "two-part" approach. Instead of the two lines above in the "Then" section I'm simply resetting a watchdog variable ($Int_1), and then using another program (Leak Sensor HB Monitor) that has the Run at Startup flag set and runs continuously (incrementing the watchdog variable every hour; if it exceeds 26 send a notification, reset the variable, wait an hour, and start over; otherwise increment the variable, wait an hour, and start over):

 

Program: Leak Sensor Heartbeat

If
       Control 'Leak Sensor-Heartbeat' is switched On
    Or Control 'Leak Sensor-Heartbeat' is switched Off

Then
       $Int_1 = 0 

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

 

Program: Leak Sensor HB Monitor

If 
   $Int_1 > 26
Then
   $Int_1 = 0
   Send Notification to 'HeartbeatMissing'
   Wait 1 hour
   Run Program 'Leak Sensor HB Monitor' (If)
Else
   $Int_1 += 1
   Wait 1 hour
   Run Program 'Leak Sensor HB Monitor' (If)