smokegrub Posted January 9, 2018 Posted January 9, 2018 Insteon devices powered by batteries represent a serious problem when you lose connnection to them, and they are located at a distant location. Moreover, they are a real pain even when nearby and you have to remove them from door jambs etc. to restore communications. I understand the primary reason for that is they are battery operated and energy savings is essential. But, is there a way they could be developed that would permit contacting them? For example, programming them with a brief daily (or other) interval where they would come on or a few seconds allowing a user the opportunity to intervene during that interval and perform a restore. If this were possible it would make these devices immensely more user friendly.
mwester Posted January 9, 2018 Posted January 9, 2018 If you are wondering if its possible for a new Insteon device to be designed so that it doesn't need to be manually awakened, the answer is "Yes" -- newer Z-Wave devices do this with a feature called "beaming" (a very poor name, as it implies the wrong thing, but be that as it may). However devices need to be designed to work with this sort of technology, both the sending (powered) device and the sleeping (battery) device. For current Insteon products, there is a way to run a program when the device triggers, and force any updates to be applied. I'm not sure, however, that this technique will work for the heartbeat, or if it requires the actual triggering of the device (which would be a lot harder to do for a leak sensor than a door sensor, for example). And, of course, this will only work if the device is still linked correctly to the PLM -- so things like PLM replacements will never work with this. I've used this technique with an Insteon motion sensor, so my experience is limited -- perhaps someone knows if this works with the heartbeat from devices like leak sensors, etc.
oberkc Posted January 9, 2018 Posted January 9, 2018 I recall also that, when triggered, insteon (battery) devices have a window of opportunity through which they can be programmed. I thought ISY would take advantage of this window, but am not confident of this. I would also suggest that this is a good reason to use programs (rather than scenes) to trigger events from battery devices. One can easily change programs without needing to update link records in those battery devices. None of my battery devices are scene controllers. I also am not overly concerned with the delay associated with programs. 1
lilyoyo1 Posted January 9, 2018 Posted January 9, 2018 Insteon devices can be reprogrammed when awaked. Just write a program that runs once triggered and the ISY will trigger as you go.
stusviews Posted January 10, 2018 Posted January 10, 2018 Here's a typical program: EX Side Door Sensor [Not Enabled] <--saves battery life, enabled as needed If Control 'EX / Devices / EX Side Door-Sensor' is switched On Then Set 'EX / Devices / EX Side Door-Sensor' Write Device Updates Else - No Actions - (To add one, press 'Action')
lilyoyo1 Posted January 10, 2018 Posted January 10, 2018 In addition to what Stusviews wrote, I would add a disable program to the then clause so that it automatically disables itself after the update 1
stusviews Posted January 10, 2018 Posted January 10, 2018 In addition to what Stusviews wrote, I would add a disable program to the then clause so that it automatically disables itself after the update Like this: EX Side Door Sensor [Not Enabled] If Control 'EX / Devices / EX Side Door-Sensor' is switched On Then Set 'EX / Devices / EX Side Door-Sensor' Write Device Updates Wait 4 minutes Disable Program 'EX Side Door Sensor' Else - No Actions - (To add one, press 'Action') Consider it done--because it is. Thanks. 1
lilyoyo1 Posted January 10, 2018 Posted January 10, 2018 Exactly how I would've written it. Great minds think alike.
smokegrub Posted January 10, 2018 Author Posted January 10, 2018 I have written this program and awaiting it running. Thanks. This will be a very valuable tool.
rccoleman Posted January 11, 2018 Posted January 11, 2018 (edited) I have a similar program and have found that it’s a little flakey in terms of whether it triggers and succeeds. To eliminate the uncertainty, I carry a laptop around with me to watch the writes happen and make sure they go through. Sometimes I have to walk through the same area a few times, and I’ve found that adding a short delay (like 2s) before writing updates tends to help. Edited January 11, 2018 by rccoleman
Recommended Posts