"All on" glitch

[Brian H]

Some of the early 2412S PLMs . Where made from reworked 2414S PLCs and had their Serial Daughter Board in them. I have a few with the RTC Clock chip and battery backup in them. Along with the mostly unused large 24LC256 EEPROMs, used for both link database and downloaded program storage.

[maxnorth]

Following up on the garage door security/safety issue, what's the recommendation for a solution more secure than the IOLinc? I have an Elk as well that could be used.  Could someone post details of their solution?

[mwester]

If you have an elk, there's probably an elk-based solution for you...

 

but, I don't have an elk, so I opted to go the z-wave route. I use the Linear GD00Z zwave garage door opener. It's a secure device, has the alert-before-operating feature, and if your door currently works with the IOLinc's relay you just connect the two wires you currently have on the IOLinc to the Linear device and you're done with the wiring! (The door open/close sensor is a wireless tilt sensor, and just attaches to the top door panel with tape or screws, real easy.)

[MWareman]

I have an Elk as well that could be used. Could someone post details of their solution?

From memory...

 

For the Elk, I wired the mag sensor to an alarm zone - configured as an 'Entry 2' zone (I think... in my case). I have a longer entry time associated with this (when I arrive home and open the door, a longer entry delay starts. When you open the door to the house, the entry delay sharply shortens). With the Elk module on ISY, I trigger the garage light from the door being opened, and turn it off 2 mins after the door is closed.

 

To control, I have an output wired to a remote button (I have a Chamberlain MyQ enabled door and then smart button - I cannot wire directly to the GDO). Basically, you wire the output in the same way the IOLinc was wired to the GDO.

 

I configured a rule on the Elk - when output 65 turns on, turn on output 3, wait 1 second, turn off output three, turn off output 65.

 

On ISY, all I need to do is turn on Elk output 3 to open or close the door.

[DennisC]

I configured a rule on the Elk - when output 65 turns on, turn on output 3, wait 1 second, turn off output three, turn off output 65.

On ISY, all I need to do is turn on Elk output 3 to open or close the door.

I'm doing this also. Works well and no chance of a stray Insteon signal opening up the garage door.

 

Dennis

[maxnorth]

Note sure what I'm missing here.  I can certainly control the garage door from my Elk, but if any Insteon devices are linked to a program that would trigger an Elk output for the garage door (as they are), then why shouldn't I worry that an "All On" event would trigger that device and program and open my door through the Elk?

 

Example: I have a KPL button that currently opens my garage door.  Do I have to give that up to be more secure?

[stusviews]

Note sure what I'm missing here.  I can certainly control the garage door from my Elk, but if any Insteon devices are linked to a program that would trigger an Elk output for the garage door (as they are), then why shouldn't I worry that an "All On" event would trigger that device and program and open my door through the Elk?

 

Example: I have a KPL button that currently opens my garage door.  Do I have to give that up to be more secure?

 

The All ON seems to affect devices, not scenes, so you should be OK.

[larryllix]

Note sure what I'm missing here.  I can certainly control the garage door from my Elk, but if any Insteon devices are linked to a program that would trigger an Elk output for the garage door (as they are), then why shouldn't I worry that an "All On" event would trigger that device and program and open my door through the Elk?

 

Example: I have a KPL button that currently opens my garage door.  Do I have to give that up to be more secure?

ISY has never been aware that an All On has happened. This should mean that ISY doesn't issue the problem. The feeling is that Insteon signal get confused somewhere and get interpreted as this All On signal in the RF, PLM, or PLM interface to ISY.

 

ISY to Elk, ISY and Elk  communications have proven very reliable.

[maxnorth]

Ok, let me try to recap:

 

1. All-On events don't seem to "involve" the ISY, meaning that programs and scenes are not triggered by an All On event.

2. All-On events seem to be confined to Insteon devices, and may involve the PLM in sending an All-On signal to all devices. (I have replaced my failing PLM and have not yet had any more All-On events).

3. Therefore, an Insteon action triggered (exclusively) by a scene or program should not be triggered by an All-On event.

4. To insulate a garage door from All-On risk, remove the IO Linc as a garage door controller.  If there is no Insteon device to trigger the door, it should be safe.

5. Instead, use an output on the Elk board (output 3 directly or any other output triggering an external Elk 912 relay board), to open or close the door. This would be wired to the same device as was the IO Linc (in my case, a wireless remote door opener).

6.  Use any sensor, including an IO Linc-connected sensor, to sense whether the door is open or closed. (The ISY can be used to sense the door state, just not to control it).

7. The Elk output can be triggered by any ISY scene or program, without any risk of getting triggered by an All-On event.

 

Please let me know if there are any corrections/revisions to this.

[MWareman]

Ok, let me try to recap:

 

1. All-On events don't seem to "involve" the ISY, meaning that programs and scenes are not triggered by an All On event.

2. All-On events seem to be confined to Insteon devices, and may involve the PLM in sending an All-On signal to all devices. (I have replaced my failing PLM and have not yet had any more All-On events).

3. Therefore, an Insteon action triggered (exclusively) by a scene or program should not be triggered by an All-On event.

4. To insulate a garage door from All-On risk, remove the IO Linc as a garage door controller. If there is no Insteon device to trigger the door, it should be safe.

5. Instead, use an output on the Elk board (output 3 directly or any other output triggering an external Elk 912 relay board), to open or close the door. This would be wired to the same device as was the IO Linc (in my case, a wireless remote door opener).

6. Use any sensor, including an IO Linc-connected sensor, to sense whether the door is open or closed. (The ISY can be used to sense the door state, just not to control it).

7. The Elk output can be triggered by any ISY scene or program, without any risk of getting triggered by an All-On event.

 

Please let me know if there are any corrections/revisions to this.

On 2, many do not seem to be 'initiated' by the PLM, but the collision occurs and the devices themselves see a corrupted packet that they interpret as an 'ALL-ON'. The PLM has no knowledge this occurred, even though a signal it sent was the cause. This may be why the ISY never sees it.

 

Given that the ISY is never aware of this (according to overwelming evidence), programs will not trigger. This is good.

 

Finally, if you are going to hook control up to the Elk, why wouldn't you hook the sensor up to Elk as well on a zone (point 6) - and benefit from the garage door triggering the Entry 2 entry delay (which can be longer that your front door entry delay). That way, anyone using the hook 'trick' (or other forced entry) to open your garage door by releasing the emergency lever will still trigger the alarm? In my case, my night arm scenes will trigger immediately, no entry delay at all.