Xathros

Try this: If Control 'Garage-Furnace Room / Furnace Room-Opened' is switched On And Control 'Garage-Furnace Room / Furnace Room-Opened' is not switched Off Then Set 'Garage-Furnace Room / Furnace Room Lights' On Else Wait 15 minutes Set 'Garage-Furnace Room / Furnace Room Lights' Off When using Control you need to specify each control signal that you want to trigger on. If you used Status instead, a one liner would have worked. -Xathros

I think, in general, the rule is: add a delay between any Insteon trigger and subsequent programmed Insteon action especially (but not limited to) when the triggering device is an RF device. -Xathros

Looks to me like comm failure plain and simple. Try unplugging the loads and run a few scene tests. Then reconnect and repeat. Any difference? If so, you may need to place filters on the loads. -Xathros

A router that supports VPN and is configured to do accept VPN connections, a VPN configuration on your mobile device to connect to your router's VPN server and usually a DDNS service so that you can find your router's VPN server from outside when you have a dynamic IP from your ISP. -Xathros

You don't need the connect features if you can port forward the https port through your router or use vpn as you stated. No scam at all here and the Dev of Mobilinc is very upfront about not requiring a connect subscription. -Xathros Sent from my iPhone using Tapatalk

Set it to non toggle then set it back. Also check the on level in the scene when the button is selected. -Xathros Sent from my iPhone using Tapatalk

Was your relay On at the time by any chance? -Xathros

In your situation, I see no need to use a scene. Just add the IOLinc sensor in place of your tilt sensors. Wire the switch so that the IOLinc sensor is On when the door is Open. -Xathros

No, for the IOLinc. -Xathros Sent from my iPhone using Tapatalk

You could create a new "AlmostEverything" scene and include everything except the IOLink then edit the 3am query to use your new scene instead. -Xathros

Kush- Is your IOLinc and mag switch set up to have the sensor On when the door is closed? If so, this could be an issue where the Query returned the correct state for the sensor but the ISY instead heard the return of the Relay state (Off) and mistook it to be the state of the sensor. I know this has been discussed on these forums a few times before. LeeG can likely explain the reasoning better than I but I believe it comes down to timing of the status messages mixed with duplicate messages from the IOLinc being received at the PLM. The PLM Queries both the sensor and the relay in separate messages and can mistake a duplicate response from the first query as a response to the second. -Xathros

The best solution is to replace the magnetic switch as mentioned previously, then uncheck Trigger Reverse in the IOLinc options dialog. If you don't want to replace the switch, then I believe there was a program based solution offered previously as well for reversing the KPL Button state on any IOLinc status change. -Xathros

sandpiper- This is NOT normal by any means. If you have a good backup, you should be able to recover all of the links both in the devices and the PLM. Do you have any motion sensors or door sensors that could be creating traffic during the Show PLM links or restore PLM processes? If so, this traffic could very well be interrupting these critical processes. II have found it best to ensure no traffic happens during these processes. Hope this helps. -Xathros

The status check in your program is the problem. It forces a reevaluation when the light turns on and cancels the wait. This will do: If Time is sunset Then Set light on Wait 4 Hours Set light off Else -Xathros Sent from my iPhone using Tapatalk

Glad it's working for you. -Xathros Sent from my iPhone using Tapatalk

I think you also need to set the button to non toggle on mode as well. -Xathros Sent from my iPhone using Tapatalk

The IOLinc options have an option for how long the relay stays energized in momentary mode. Make your program delay 1 or more seconds longer than the selected momentary delay. -Xathros Sent from my iPhone using Tapatalk

Both are normal. The door status depends on the type of reed switch used on the door (Normally open vs normally closed). The relay, assuming you are set using one of the momentary modes is normal as well. The relay turns on then off again after the delay you specified in the IOLinc options dialog. It simply does not send a status update to the ISY after turning off. You can test this: Open or close the door then issue a query against the relay, it will update to show off. Again, this is normal given that the relay portion of the IOLinc is a responder only device, it does not issue status messages and the ISY simply tracks the status based on what it last told the relay to do. Hope this helps. -Xathros

Item #1 is the smart move. I moved my garage doors off to an ethernet controlled relay (DIN Relay) that I can control from the ISY or directly if needed. This eliminated my garage doors from being affected by an all on. Since you have an Elk, I would recommend moving control of the garage off to the Elk. Thats where it should be to begin with. As for the whole house fan, I would consider a ZWave option for that or a load controller relay tied to the Elk. Either way, you can maintain ISY control and eliminate the threat of an All On hitting those devices. -Xathros

It's actually not the ISY randomly sending an All On to a scene. It appers to be a collision/corruption of an insteon message that looks to all of the responders like an AllOn message. See this thread for more: http://forum.universal-devices.com/topic/10516-random-all-on-event/ -Xathros

Pick your top level scene that has all of your devices in it. Turn it on. Additionally, there is an All On and All Off button on the main scene at the bottom of the console. -Xathros

I do. -Xathros Sent from my iPhone using Tapatalk

I have both and am quite happy with both solutions. If the wireless remote if the preferred solution, simply make sure you have sufficient RF coverage from access points or dual band devices in the area in which you plan to use the remote. The battery in the RL2 is a rechargeable. The RL2 can be charged from any MicroUSB charger and runs for months on a charge for me. -Xathros

I would suggest the following change to the example program: If ( Control 'Door 1 Sen (2C.73.62)' is Switched Off Or Control 'Door 2 Sen (32.8E.CE)' is Switched Off Or X10 'A12/On (3)' is Received ) And $i_Alarms_On is not 3 Then Wait 3 seconds Run Program 'Alarm Audible' (Else Path) Disable Program 'Garage M1 Motion' Disable Program 'Garage M2 Motion' Disable Program 'LT Bldg M1 Motion' Disable Program 'Front Driveway Sensor' $i_Alarms_On = 3 $s_Alarms_On = 3 Send Notification to 'Donald' content 'Alarm Disarmed' Set 'X10 Devices / A12 Disarmed' On Set 'X10 Devices / A11 Silence Delayed' Off Set 'X10 Devices / A10 Arm' Off Else - No Actions - (To add one, press 'Action') This way it's not based on status but rather door events. This doesn't solve the unknown state after a power cycle but should not be confused by it either. -Xathros

Not sure. I have never tested this myself. Another user on this forum was unable to make a dualbrite unit work this way but I have no way to know if your sensor units are the same kind/brand etc. -Xathros EDIT: See: http://forum.universal-devices.com/topic/13863-in-linelinc-briefly-turns-on-then-off/?p=114887 That was using an InLineLinc but it mentions the sensor model.