2843-222 Open Close Sensor Heartbeat

[Ed Sybesma]

I have an Insteon 2843-222 Open Close Sensor installed under Polisy.  In the Main device listing tab of the Administrative Console, it shows up as 2 devices, 1 for the sensor itself and the second one for the heartbeat.  The sensor is working properly, so I know that it should have a heartbeat and I also receive a heartbeat signal approximately daily.  Nevertheless, the Device listing for the heartbeat in Administrative Console frequently changes back and forth between ON and OFF.  I do not have any programming commands which attempt to alter the setting for or query the heartbeat device.  In fact, I don’t think either are possible for this device.  What could cause this Device heartbeat item to switch OFF?

[Techman]

The heartbeat signal status alternates between ON and OFF, this is normal. The following program can be used to send a notification if there's no heartbeat signal

 

IF

    Control Heartbeat is not switched ON

or

    Control Heartbeat is not switched OFF

THEN

    wait 26 hours

    Send Heartbeat fail notification

ELSE

 

[Ed Sybesma]

6 minutes ago, Techman said:

The heartbeat signal status alternates between ON and OFF, this is normal. The following program can be used to send a notification if there's no heartbeat signal

 

IF

    Control Heartbeat is not switched ON

or

    Control Heartbeat is not switched OFF

THEN

    wait 26 hours

    Send Heartbeat fail notification

ELSE

 

Thank you for that information.  Are you saying that the heartbeat signal status switches between ON and OFF due to something in Polisy or due to the Insteon module?  It is my understanding that Polisy/ISY do not query this particular wireless Insteon module and that the only heartbeat activity in the module is to send out a signal approximately one time per day to indicate that the heartbeat is still working.  I have a program which notifies me when that signal is reached and indeed it does tell me of that once a day.  I actually have two of these Insteon modules working and the status shown under Polisy does not change back and forth for the other one.

[Techman]

The on/off signal is sent by the sensor and usually alternates between ON and OFF, the ISY/Polisy only displays the status sent by the device.

The heartbeat signal cannot be queried. It's sent out about every 24 hours but can vary by an hour, which is why I gave the program 26 hours to listen for the heartbeat signal. That way you won't get a false alert if the signal is delayed.

Not sure why you're not seeing a change on the second device, maybe try deleting and reinstalling the sensor will fix it, or you can try doing a factory reset on the device then a restore device from the Polisy

 

 

Edited July 26, 2022 by Techman

[MrBill]

16 hours ago, Ed Sybesma said:

Thank you for that information.  Are you saying that the heartbeat signal status switches between ON and OFF due to something in Polisy or due to the Insteon module?  It is my understanding that Polisy/ISY do not query this particular wireless Insteon module and that the only heartbeat activity in the module is to send out a signal approximately one time per day to indicate that the heartbeat is still working.  I have a program which notifies me when that signal is reached and indeed it does tell me of that once a day.  I actually have two of these Insteon modules working and the status shown under Polisy does not change back and forth for the other one.

Most Insteon devices send DON for heartbeat (and don't alternate DON, DOFF, DON..) but it's been said that some do, and I've never paid much attention to which do.  The generally accepted, most basic, heartbeat monitoring program is close to what @Techman typed above.  (in actually "is NOT switched" isn't an option.)

IF
           Control Heartbeat is switched ON
    OR  Control Heartbeat is switched OFF
THEN
    wait 26 hours
    Send Heartbeat fail notification
ELSE
    [nothing]

The basic theory behind the program is that when the heartbeat is received, it starts the THEN block of the program which is a wait statement.. if the 'wait' expires a fail notification fires.  However because ISY programs are event driven the heartbeat will be received again in less than 26 hours-- when this NEXT heartbeat arrives the wait in progress immediately stops and a new 26 hour wait begins counting down.  So as you can see, the fail  notification is only reached when a new heartbeat doesn't arrive in time. 

But we can always build a better mousetrap..

One of the problems with the above is that if for some reason the notification isn't received, or is ignored there's no nag.  Another is that it's a fact sometime heartbeats are missed, missing one today doesn't matter if we know it's a reasonably fresh battery it's likely just a fluke.  Also the sensors stop sending hearbeat before they are completely out of battery... meaning they actually work for a period of time after the heartbeat quits. In conclusion, failed heartbeat is not an emergency need to replace the battery, it means 'replace battery soon' as in the next days--- not it must be done now.

I create 3 integer variables for each sensor, Missed Heartbeats, battery days, and transmission count.

Then this is the program:

hb.WhiteRefrigLeak Copy - [ID 00FB][Parent 0072]

If
        'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Heartbeat' is switched On
     Or 'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Heartbeat' is switched Off
 
Then
        Wait  25 hours
        $iDoor.WhtRefrigLeak.HBmissed += 1
        $iDoor.WhtRefrigLeak.HBmissed Init To $iDoor.WhtRefrigLeak.HBmissed
        Wait  2 seconds
        Resource 'NotificationNS.DoorTrouble.BarnOHD'
        Run Program 'hb.WhiteRefrigLeak Copy' (Then Path)
 
Else
   - No Actions - (To add one, press 'Action')
 

The key differences are: incrementing the HBmissed variable for the sensor if it was missed, I use a different message to send notifications, and then the last line re-runs the THEN portion of that program... that is if the heartbeat was missed we will for sure repeat the notification again tomorrow if it is again missed.   (the original program relies on a heartbeat to be received again before it's re triggered.)

It should be noted that this program should also be configured [Run at Startup], mines not because I have a separate program that starts heartbeat, so that I can used it at Daylight Saving Time switches in the spring and fall (the time change will interrupt any waits running at the time change).

Like wise there is a program that counts all tranmissions for a device.  Since this is a leak sensor thread this seems insignificant... the only signals a leak sensor normally sends is heartbeat.  However I use the same base program for all insteon battery devices, and 15,000 open and closed or motion detects does make a difference.  so to count transmissions:

White Refrig Leak - [ID 007E][Parent 0033]

If
        'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Wet' is switched On
     Or 'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Wet' is switched Off
     Or 'Door Switches / White Refrig Leak - Dry' is switched On
     Or 'Door Switches / White Refrig Leak - Dry' is switched Off
     Or 'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Heartbeat' is switched On
     Or 'Door Switches / White Refrig Leak - Dry / White Refrig Leak - Heartbeat' is switched Off
 
Then
        $iDoor.UpperSlider.TransCount += 1
        $iDoor.UpperSlider.TransCount Init To $iDoor.UpperSlider.TransCount
 
Else
   - No Actions - (To add one, press 'Action')
 

That counts any transmission received... again this makes more sense for door sensors or motion detectors.

and finally the last value... Battery Days

AddAge - [ID 003D][Parent 0034]

If
        Time is 12:12:12AM
 
Then
           [..redacted about 100 lines to make the forum post shorter..]
        $iDoor.RachioButtonUpper.BatteryDays Init To $iDoor.RachioButtonUpper.BatteryDays
        $iDoor.UpperSlider.BatteryDays += 1
        $iDoor.UpperSlider.BatteryDays Init To $iDoor.UpperSlider.BatteryDays
        $iDoor.WhtRefrigLeak.BatteryDays += 1
        $iDoor.WhtRefrigLeak.BatteryDays Init To $iDoor.WhtRefrigLeak.BatteryDays
 
Else
   - No Actions - (To add one, press 'Action')
 

At 12:12:12 every morning there is a program that adds 1 to the age of every battery in my system.

and finally the failed notification includes all the data:

<b>White Refrig Leak Sensor Trouble</b>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Missed Heartbeat Count: ${var.1.103}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Battery Days: ${var.1.7}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Transmission Count: ${var.1.77}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;${sys.date} ${sys.time12}

Here's what the notification received looks like:  (but the notification is for a different battery sensor)

So as you can see in the past 162 days this sensor has missed it's heartbeat 15 times.  (6 months = 180 days)

I don't worry about a sensor until it's missed multiple days in a row, and even then if the counts are low sometimes i just pull the battery and wait 30 seconds and re-install it and heartbeats continue.  When the counts are high then I change the battery.

One more program:  to reset all the counters i used a program that's manually run from my Home Assistant dashboard.

LowerSlider.reset - [ID 01AB][Parent 01B5]

If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')
 
Then
        Resource 'NotificationNS.DoorTrouble._resetCountersBegin'
        Wait  1 second
        Resource 'NotificationNS.DoorTrouble.LowerSlider'
        Wait  2 seconds
        $iDoor.LowerSlider.HBmissed  = 0
        $iDoor.LowerSlider.HBmissed Init To $iDoor.LowerSlider.HBmissed
        $iDoor.LowerSlider.BatteryDays  = 1
        $iDoor.LowerSlider.BatteryDays Init To $iDoor.LowerSlider.BatteryDays
        $iDoor.LowerSlider.TransCount  = 1
        $iDoor.LowerSlider.TransCount Init To $iDoor.LowerSlider.TransCount
        Wait  2 seconds
        Resource 'NotificationNS.DoorTrouble.LowerSlider'
        Wait  1 second
        Resource 'NotificationNS.DoorTrouble._resetCountersComplete'
        Run Program 'hb.LowerSlider' (Then Path)
 
Else
        Resource 'NotificationNS.DoorTrouble.LowerSlider'
 

I also have an Excel spreadsheet to make creating many notification bodies much simpler, keeps track of all the variables and concatenation a string that can simply be pasted into the admin console.  (if anyone's interested in the spreadsheet PM me)

 

 

 

[Techman]

My heartbeat program is set to run at startup. If the program doesn't receive an ON or OFF the THEN clause timer starts and will ultimately send the failure notification.  

The program needs to have the THEN clause manually executed when you first create it.  I have a lot of battery-operated devices and have never had the program let me down or not received a heartbeat signal as long as the battery voltage was sufficient.

[Ed Sybesma]

I have been using the programming logic supplied by Techman for several years with my Leak sensors.  This sensor happens to be an open/close door/window sensor.  I can see that I may use the logic from MrBill in the future, and either of these can be used as workarounds for what I am seeking to do right now.  However, I have a more basic question:  What event or other circumstance causes the ISY/Polisy Status to change from ON to OFF in the display for the module in the Main tab of the Administrative Console?  Partial screenshot as follows:

 

[Techman]

The device sends either an ON or OFF heartbeat signal, the ISY or the Polisy just displays what it receives from the device.

[Ed Sybesma]

Thank you.  I had been under the impression that the heartbeat only sent an ON signal and not could not send an OFF signal if the battery was dead.  I now understand, however, from the earlier e-mails that it does send OFF signals before the battery dies.

[MrBill]

1 hour ago, Ed Sybesma said:

Thank you.  I had been under the impression that the heartbeat only sent an ON signal and not could not send an OFF signal if the battery was dead.  I now understand, however, from the earlier e-mails that it does send OFF signals before the battery dies.

It doesn't actually send an OFF signal.  It only sends ON and will always show ON in the admin console.  It's the LACK of an ON signal that tells us the battery may be low.  which is why we WAIT 24 or 26 hours to notify after not receiving.

Most all Insteon devices send DON only has hearbeat.  Some device firmware historically however did alternate on, off, on, off... which is why we write the programs as ON or OFF, we don't need to know which way the device sends it either on, on, on, etc or on, off, on , off....   all more modern insteon devices tho only send DON or On, as the heartbeat and never send DOFF or Off.   Definition of more modern:  perhaps at least the last 6 or 7 years at least... i don't know when devices last had firmware that sent on, off, on, off as hearbeat.

[Ed Sybesma]

29 minutes ago, MrBill said:

It doesn't actually send an OFF signal.  It only sends ON and will always show ON in the admin console.  It's the LACK of an ON signal that tells us the battery may be low.  which is why we WAIT 24 or 26 hours to notify after not receiving.

Back to where we started from then.  That's what I originally thought.  So is there something wrong with my ISY/Polisy?  Because on one of the modules (but not the other), the heartbeat status keeps switching back and forth between ON and OFF.

[MrBill]

16 hours ago, Ed Sybesma said:

Because on one of the modules (but not the other), the heartbeat status keeps switching back and forth between ON and OFF.

older modules DO alternate.  I've repeated this twice above.

16 hours ago, MrBill said:

Most all Insteon devices send DON only has heartbeat.  Some device firmware historically however did alternate on, off, on, off... which is why we write the programs as ON or OFF, we don't need to know which way the device sends it either on, on, on, etc or on, off, on , off....   all more modern insteon devices tho only send DON or On, as the heartbeat and never send DOFF or Off.   Definition of more modern:  perhaps at least the last 6 or 7 years at least... i don't know when devices last had firmware that sent on, off, on, off as hearbeat.

 

[larryllix]

 

..to elaborate,

that is why we advise to use 'control switched' construct as 'status' would not function for a non-alternating status.

Sent from my SM-G781W using Tapatalk

[Ed Sybesma]

Got it.  Thanks much.