Insteon Heart Beat Monitor?

[Grover]

Hello,

Does this plugin monitor heartbeats from Insteon Leak sensors?

[SteveMSJ]

Hello,

Does this plugin monitor heartbeats from Insteon Leak sensors?

I can't say categorically that it does because I don't have any Insteon devices never mind a Leak sensor. However, based on feedback from other Insteon users' experience, I would say it should but i depends on how the device is represented in HS.

There is more than one Insteon pi so the device setup may be different for each. My understanding is that for each Insteon physical device you should get a grouped set of devices. For a battery device these should include a Parent and a Battery Level child. There may also be a Low Battery Warning and a Heartbeat as well as obviously the actual sensor child. As long as the devices are grouped and there is a Parent and a Battery child then SDJ-Health should be able to monitor it successfully.

It won't pick up Insteon devices automatically, unlike Z-Wave, you will need to go to the SDJ-Health>Config page and select the devices you want monitoring. The MonitorHeartbeat method won't work as that is for ZWave devices. Use the MonitorActivity method. Your Insteon battery devices should be in the dropdown list of Devices that Require Activity Monitoring. Select the devices from the list and you should find that at the next refresh period monitoring devices are created.

If the devices aren't grouped or there isn't any kind of Battery child then it can also be done but it is slightly more fiddly. Let me know how your device is represented in HS and I will let you know.

The ActivityMonitoring method works by checking all the child devices of physical device at preset intervals to see that some activity has occurred since the previous check. You should have a Heartbeat child which is being regularly updated so as long as the Heartbeat interval is shorter than you set the Monitoring Period it should work fine.

It will also keep track of the battery levels but my understanding is that Insteon devices don't use a 100% down to 0% range like Z-Wave devices. You can set a factor in SDJ-Health to adjust the range, e.g. a factor of 10 will adjust a 0-10 range to 0-100.

I hope that helps.
Steve

[Grover]

For the Leak Sensors, there are only 2 items:

Sensor = wet|dry
Heartbeat = pulse every 23 hours by default

There is not actual battery level here. And for the insteon devices, they seem to report full/good/low/replace as distinct values, not as a % of the battery life.

So, I have written m own routine to do the heartbeat checks at this point. Your plugin looks very nice. I wish there was something like it that also did insteon.

[SteveMSJ]

For the Leak Sensors, there are only 2 items:

Sensor = wet|dry
Heartbeat = pulse every 23 hours by default

There is not actual battery level here. And for the insteon devices, they seem to report full/good/low/replace as distinct values, not as a % of the battery life.

So, I have written m own routine to do the heartbeat checks at this point. Your plugin looks very nice. I wish there was something like it that also did insteon.

Even without a battery child you can still use it within the pi if you really want to. If you go to the Advance tab of the Heartbeat child and in the text box for the Device Type (string) add the word Battery to whatever is there, the pi should then pick up the device as the Battery Child and add it to the list of devices that can be monitored by Activity Monitoring. The battery level reported will be whatever value the Heartbeat child displays so is irrelevant. Turn off Battery Level and Battery Discharge alerts for this device, or globally, as only Missed Wakeup alerts and Battery Life alerts are relevant.

However, there is probably not much point in monitoring the devices this way unless you have other types of battery devices also being monitored. The main advantage is to centralise your alerting and reporting for all battery devices but if it is only these leak sensors it probably doesn't justify the overheads of a pi. However, its free so it's up to you.

Steve

P.S. Editing the Device Type (string) shouldn't effect the operation of the Insteon pi but just in case, make a note of what it was before you altered it so you can change it back.

[mrceolla]

Instead of altering a Device Type string which could potentially lead to problems, would it be possible to simply manually add this device via your plugin, leaving default settings like that unchanged?

I too have a number of battery operated Insteon devices, including 4 leak sensors and 4 or more motion sensors. I have my own little script to report on these but your solution seems neater so I've been doing some research.

One of my older Insteon door sensors has no heartbeat or battery level so I need to monitor the last change time of the sensor itself. Does your plugin support something like that?

I'm sure I'll find this answer in here somewhere as soon as I send this, but another question on my mind is, are all thresholds configurable on a per device basis?

Thanks!

[SteveMSJ]

Instead of altering a Device Type string which could potentially lead to problems, would it be possible to simply manually add this device via your plugin, leaving default settings like that unchanged?

I too have a number of battery operated Insteon devices, including 4 leak sensors and 4 or more motion sensors. I have my own little script to report on these but your solution seems neater so I've been doing some research.

One of my older Insteon door sensors has no heartbeat or battery level so I need to monitor the last change time of the sensor itself. Does your plugin support something like that?

I'm sure I'll find this answer in here somewhere as soon as I send this, but another question on my mind is, are all thresholds configurable on a per device basis?

Thanks!

It's possible but I don't want to do half measures. At the moment that is a kludge to fool the pi into thinking the heartbeat device is a battery device. Whilst it works reasonably I wouldn't want to build that level of functionality into the pi. What is really required is to properly support the various types of Insteon battery devices.

As I don't have any Insteon devices that isn't an easy task. I would need help from someone who has the various devices types, who can feed me information and test out the pi. If you are interested in doing that then send me a pm.

Thanks,

Steve

[SteveMSJ]

I'm sure I'll find this answer in here somewhere as soon as I send this, but another question on my mind is, are all thresholds configurable on a per device basis?

Yes, all the alerts and other parameters can be set globally and overridden for individual devices where desired.

Steve

[mrceolla]

Hi Steve,

Thanks for the replies. Is your goal only to monitor batteries? I was hoping this could replace the scripts I use to monitor not only batteries, but other sensors as well. I monitor sensors to make sure they are reporting as often as they should, battery operated or not. With the name "Health" I would think you could build all sorts of monitoring under that umbrella. But I understand if you wish to concentrate only on battery devices. However, if you are open to expanding the pi to support that kind of monitoring, let me know and I'll pm you with more details and we can discuss testing.

Thanks!

[SteveMSJ]

Hi Steve,

Thanks for the replies. Is your goal only to monitor batteries? I was hoping this could replace the scripts I use to monitor not only batteries, but other sensors as well. I monitor sensors to make sure they are reporting as often as they should, battery operated or not. With the name "Health" I would think you could build all sorts of monitoring under that umbrella. But I understand if you wish to concentrate only on battery devices. However, if you are open to expanding the pi to support that kind of monitoring, let me know and I'll pm you with more details and we can discuss testing.

Thanks!

Hi mrceolla,

It's an interesting idea and I'm not adverse to extending the scope of the plug-in if it proves useful. It would need some careful thought as to the best way to implement it within the framework of the existing plug-in without compromising the battery reporting. If I did incorporate other devices I think I would separate the reporting into groups so that battery devices remain in their own group as they are a specific case and where I see the most use for this type of utility. As you point out I did call it SDJ-Health rather than SDJ-Battery

What sort of issues do you have that require monitoring and what sort of devices? Is it a problem with a particular technology like Insteon? I am mainly ZWave, with a few old X10, and I find that once stuff is working I don't normally have any problems (touch wood).

Steve

[mrceolla]

Thank you for your reply and sorry for my delay.

I don't really have any issues, so to speak, I just want to make sure things are operating as they should be. Battery operated or not. Even with a full battery, a device could malfunction in some other way. I use some scripts and events to do this now. I have one script to detect low batteries, and the other to detect "stale sensors". Both scripts have an option to only report recently offending devices, or to report all. The report all script runs once daily as a reminder, the other every 15 min. for more immediate notification.

I have another event or two to report if any of my temperature sensors go out of range due to either malfunction, fire, furnace failing, etc., so some sort of range monitoring would be cool too.

I also have some events to report if a door gets opened while the lock is still reporting that it's locked, cuz that shouldn't be possible. I realize this is an edge case, but it has alerted me to the fact that my SmartStick or Z-wave plugin had crashed. My open/close sensor was Insteon, so that reported to HS, but the Unlock event on the lock never made it to HS.

I too use Z-wave, but only have 4x HSM-200, 1x HS-MS100+, 1x thermostat, and 2x door locks. Only the door locks and MS100+ have a battery as far as my z-wave devices go. My thermostat does have a battery device, but the thermostat itself is hardwired to power.

Yes, things shouldn't go wrong, and they rarely do, but it's peace of mind knowing I have something monitoring to make sure.

Does that give you a better idea of what I'm after?

It'd be nice to be able to add a device, and then select what types of things to monitor on that device: battery, last change, within range, etc. Maybe allow your users to manually select the sub device tied to battery monitoring, or which sub device to monitor for last change, etc., so you don't have to guess, rely on default device information, or have users edit it and potentially break something else. Just some thoughts. I may be speaking out of place though as I haven't used your plugin yet.

Let me know what you think. Have a great day!

[mrceolla]

I just added a Z-wave enabled First Alert Smoke/Fire & Carbon Monoxide detector. I think it is a good example of where additional types of monitoring would be useful, even though it has a battery. As you can see, it apparently has a heartbeat and therefore should ping HS on occasion. It would be nice to monitor and make sure these heartbeats are being received at the proper frequency. Improper frequency could indicate malfunction or spotty communication.

[SteveMSJ]

I just added a Z-wave enabled First Alert Smoke/Fire & Carbon Monoxide detector. I think it is a good example of where additional types of monitoring would be useful, even though it has a battery. As you can see, it apparently has a heartbeat and therefore should ping HS on occasion. It would be nice to monitor and make sure these heartbeats are being received at the proper frequency. Improper frequency could indicate malfunction or spotty communication.

Hi mrceolla,

The pi does have a method to automatically monitor those type of devices using the Heartbeat. It is monitoring method No 2 in the guide.
If you check the option 'MonitorHeartbeats' on the SDJ-Health Config page then the pi will listen for those heartbeats. They are treated effectively like wake-ups in monitoring method 1 so will set the period based on subsequent heartbeats so the pi can alert you of missed heartbeats.

Once the option is selected it should pick the devices up automatically and create a monitoring child when the first heartbeat is received. You don't need to specifically select the devices to be monitored. If you have already selected them to be polled or monitored by activity checking then the monitoring children already created should convert to Heartbeat monitoring the first time a heartbeat is detected as there is a hierarchy to the monitoring methods. If they don't convert you might have to delete the monitoring child previously created for polling or activity.

I'm still digesting you earlier post, I'm not ignoring it

Steve