Jump to content

A Question for you Technical Geniuses


smokegrub

Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment

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')

Link to comment

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.

Link to comment

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.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...