Ideal behavior for a device heartbeat?

[mwester]

Assume I'm implementing the heartbeat feature for a device to be managed by an ISY.  How exactly should that heartbeat function?

 

1) I'm leaning toward a fixed heartbeat time period.  The argument against a user-adjustable period is that it renders sharing of programs to monitor the heartbeat more difficult, invites confusion when different instances of the device in question end up with different heartbeat times, and it adds yet another step when performing a complete reset of a device (one has to update the heartbeat).  Feel free to try to convince me why you need it to be adjustable.

 

2) Right now, I've implemented the heartbeat as a periodic sending of the DON command (i.e. the device was just switched on).  The device will ALWAYS respond OFF when queried, and will never send the DOF command.

 

  2a) Is this consistent with other devices that have heartbeats?

 

  2b) Would it be better to send a DON, wait a few seconds, then send a DOF instead?

 

  2c) Would it be better to implement something completely other than an On or Off?

         2c1) perhaps an actual HEARTBEAT command?

         2c2) perhaps an actual HEARTBEAT command with an incrementing value?

 

Feedback requested.

[Teken]

Not really sure what your after but no two devices send their heartbeat at the same time interval.

 

So don't know what you mean by fixed vs variable?!?

 

 

=========================

 

The highest calling in life is to serve ones country faithfully - Teach others what can be. Do what is right and not what is popular.

[mwester]

What I mean by fixed is that I determine when I build the device what the heartbeat interval is - and you can't change it, no way, no how.

Variable is if you, as a user, have a control or setting to change the interval at which the heartbeat is sent - so if you want a heartbeat once per 24 hours, you can set that, or if you want it once every 8 seconds, you can set it to that...

 

I'm going to take your question as a vote for "fixed".  

[Teken]

I had assumed you were talking about a Insteon product, no?

 

If this is for some 3rd party device than yes a fixed heart beat would be the preferred method.

 

Makes audit / tracking predictable for long term trouble shooting.

 

 

=========================

 

The highest calling in life is to serve ones country faithfully - Teach others what can be. Do what is right and not what is popular.

[LeeG]

Here is an example of a functional Heartbeat Program.  Different device types and different device firmware in same device type have different characteristics.  This Program does nothing to alert me until a Heartbeat is missed.   Works on Leak Sensor, Hidden Door Sensor, Open Close  Sensor.    There are much more complex Programs but this one is simple and functional. 

 

HeartBeat - [iD 0044][Parent 0001]

 

If

        Control 'Leak Sensor-Dry / Leak Sensor-Heartbeat' is switched On

     Or Control 'Leak Sensor-Dry / Leak Sensor-Heartbeat' is switched Off

 

Then

        Wait  25 hours 

        do something to alert about missing Heartbeat

Else

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

[larryllix]

I think the heartbeat period needs to be set by the urgency of a failure.

 

Leak detectors are typically 24 hours and IMHO that is too long for a device with that importance. My best gues for a leak detector woud be more like a few hours but that would shorten battery life for battery devices, also. The chance of an actual leak should be low so risk of a non-detected failure is low.

 

Thermostats should have shorter times for heartbeat detection as some heating algorithms could run amuck before failure detection remedies need to be taken.

 

IOW. Heartbeat time period should be based on the risk involved and the urgency of detection. Since these will vary from user to user and application to application, IMHO a variable period should be available.

 

Better yet, perhaps selections of two, short and long periods, so that users can decide, but only within the confines of the designer who has thought out the device more thoroughly than an inexperienced user.

eg. Some new ISY user sets a leak to a 7 day heartbeat period to save battery life and has a leak on the second day or ISY has power failures each week and increases the risk of detection failure past the usefulness of the Leak Detector.

 

As far a signal style an alternating beacon polarity show some intelligence from the sending end. It could potentially increase noise rejection looking for a predicted polarity True/False. Other than that most ISY detection programs couldn't care less.

 

I am reminded of some electrical metering pulses where signal polarity is actually three state to eliminate intermittent electrical signals form causing random pulses. The exact same concept may not apply but a random confused Insteon (or other style) signal could be eliminated from faking the receiving logic.

 

A last point is retransmitted heartbeats that change polarity are easier to bridge between mediums. eg: Ethernet to RS485 to Insteon to copper contact. ie: how do you convert on-on-on-on to contact closures?

 

The ramping value heartbeat sound interesting and may present some other uses, such as "alive time".

Edited June 15, 2016 by larryllix

[G W]

What I mean by fixed is that I determine when I build the device what the heartbeat interval is - and you can't change it, no way, no how.

Variable is if you, as a user, have a control or setting to change the interval at which the heartbeat is sent - so if you want a heartbeat once per 24 hours, you can set that, or if you want it once every 8 seconds, you can set it to that...

 

I'm going to take your question as a vote for "fixed".

Is this a battery powered device? If so the battery needs to last 6 months.

 

Sent from my SM-G930T using Tapatalk

[Teken]

@Larry,

 

With out more information from the OP as to how he intends to use the *Heart Beat* in his specific application. I would have gathered its intent would be to keep him aware the device was *Alive / In Range*.

 

As all other Insteon devices already provide immediate feedback whether it be leak, motion, open / closed. For me if this was not a Insteon product but some kind of 3rd party product that you wanted to monitor for what ever reason the over all scope needs to be defined.

[mwester]

With out more information from the OP as to how he intends to use the *Heart Beat* in his specific application....

 

 There's the problem - I can't know that.  The application is to add a "heart beat" to Polyglot, so that one can be assured that the connection between the Polyglot node server and the ISY is functional -- I have no idea what specific sensors or devices might be handled by that specific instance of the Polyglot service so I don't know how critical it might be.

 

Thanks for the comments on battery life - for some reason I'd never connected the loooong 24-hr heartbeat interval with battery life, but it's obvious now!  Since this wouldn't be battery powered, that would imply a much shorter heartbeat.  How often is too often, though?

 

(Note: this is ONLY between Polyglot and the ISY -- this won't add a heartbeat to sensors served by Polyglot if the end device doesn't have a heartbeat to begin with!  So this is just to ensure that your Raspberry Pi, for example, hasn't crashed overnight...)

[larryllix]

In the case if just between polyglot and ISY I am back to a selection of say two or three different speeds of heartbeat with an expanded exponential clicks.

 

Say 15 seconds for OCD uses, 60 seconds, and 300 seconds.

 

Personally I would use the 15 seconds and allow a few to slide before reporting. IOW I may discount some ISY logic triggers on one miss but not nuisance report until 10 heartbeats missed.

Edited June 15, 2016 by larryllix

[G W]

I agree with Larry on this. No battery, no worries. Send the heartbeat and it can be used or ignored.

 

Sent from my SM-G930T using Tapatalk

[jgcharlotte]

 

Here is an example of a functional Heartbeat Program.  Different device types and different device firmware in same device type have different characteristics.  This Program does nothing to alert me until a Heartbeat is missed.   Works on Leak Sensor, Hidden Door Sensor, Open Close  Sensor.    There are much more complex Programs but this one is simple and functional. 

 

HeartBeat - [iD 0044][Parent 0001]

 

If

        Control 'Leak Sensor-Dry / Leak Sensor-Heartbeat' is switched On

     Or Control 'Leak Sensor-Dry / Leak Sensor-Heartbeat' is switched Off

 

Then

        Wait  25 hours 

        do something to alert about missing Heartbeat

Else

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

 

This is exactly what I'm using, seems like it should work fine, I'm wondering why a lot of folks are using the variable version, where when there is a leak a variable goes to '2' and takes action.  Am I missing something?

[larryllix]

This is exactly what I'm using, seems like it should work fine, I'm wondering why a lot of folks are using the variable version, where when there is a leak a variable goes to '2' and takes action. Am I missing something?

Maybe you have the wrong thread for this question. This thread was discussing heartbeat functions/frequency for polyglot devices.

 

You question appears to be about Leak sensor codes used in the reporting/trigger variable and related to different topic. Out of context I can make no sense out of it.

 

BTW: Using a variable for notification stimuli, gives better control over constant reporting of the same thing, as well as limiting the time of reporting before declaring normal again.

Edited September 25, 2016 by larryllix

[paulbates]

This is exactly what I'm using, seems like it should work fine, I'm wondering why a lot of folks are using the variable version, where when there is a leak a variable goes to '2' and takes action.  Am I missing something?

 

Its a matter of preference and how elaborate you want your programs to function. I do it the same way you do.  

 

I imagine the programs with variables help those that have a lot of sensors and want a systematic approach to 'corral-ing" them

 

Paul

Edited September 25, 2016 by paulbates

[jgcharlotte]

Its a matter of preference and how elaborate you want your programs to function. I do it the same way you do.  

 

I imagine the programs with variables help those that have a lot of sensors and want a systematic approach to 'corral-ing" them

 

Paul

 

This is true, for that reason and others I am a big fan of use of flags in programs, but I like simplicity, too.

One thing. . . . if I set a variable and use it as a flag that one of the sensors has gone offline, that flag will stay set and I can check it periodically.  If it just sends one text message, I may miss it.

[larryllix]

Nothing like being on the other side of the world and a sensor decides to go crazy.

 

Now you get a text message, and an email, every three seconds, for the next 14 days.