Long delay when turning on switch through a simple program

[greazer]

I have a simple program:

 

If

     Switch1 is fast switched on

Then

     Turn on Switch 2

 

 

It works, but there is a 4 to 5 second CONSISTENT delay that occurs after the fast switch of Switch 1 occurs before Switch2 is turned on. Why????

 

I see my program fire very quickly in the ISY admin console, it's just that the Then portion seems to take 4 to 5 seconds. I figured there was just some delay in ISY being able to access Switch2. Unfortunately that doesn't seem to hold water because if I turn Switch2 on and off directly via the ISY admin console, it responds very quickly (within a second of toggling). So, I'm totally confused as to where the delay is coming from.

 

Can anybody help me understand what might be happening and whether there's a way around it?

[MWareman]

4-5 a seconds seems a long time I agree. 1-2 is more usual in my setup when triggering a program to perform an action.

 

One thing to try. Put 'Switch 2' in a scene and have the program turn the scene on. Scenes don't ACK requests unlike direct device control. This may make things faster. Down side is if you have a less than reliable Insteon network it may get missed, but it's worth a try.

 

Main possibility is you Insteon network may just be very busy. Maybe the request out to the light is queued, causing it to get delayed. Have you assessed how busy the communication is? (The log will help here...). Maybe you have a loop somewhere...

[asbril]

I no longer use Insteon and have about 40 Zwave devices in my home. Possibly your issue is that many Zwave devices do not report their status. In that case your program does not know that device 1 is ON or OFF.  I created a QUERY program whereby relevant devices are being queried (polled) every few seconds and this does the job for me.

Ideally my query program would repeat every second, but I don't know yet whether that could have any negative impact on my ISY network performance. That is why I have designed different Query programs, one running every 4 seconds for devices that I use all day long and one running every 4 seconds from sunset to sunrise for devices that I only use at night. I also run another Query program every 30 minutes for most other devices, so that I have a reasonable view on my Mobilinc  of what is On or Off when I am not at home.

[greazer]

Thanks guys. I'll play around with scenes (which I haven't done much of yet) and see if that helps. As for creating a program to poll devices, I'm not sure why that would help, but I'm willing to try.

[PurdueGuy]

If you are turning the switch "fast on" then Switch1 is an Insteon switch right?   Is Switch2 Insteon as well?

 

If you run the program from the Admin Console (right click and choose "Run Then" how long does it take?)

 

Is "Wait while busy reading" checked under Configuration -> System -> System?

[larryllix]

I have a simple program:

 

If

     Switch1 is fast switched on

Then

     Turn on Switch 2

 

 

It works, but there is a 4 to 5 second CONSISTENT delay that occurs after the fast switch of Switch 1 occurs before Switch2 is turned on. Why????

 

I see my program fire very quickly in the ISY admin console, it's just that the Then portion seems to take 4 to 5 seconds. I figured there was just some delay in ISY being able to access Switch2. Unfortunately that doesn't seem to hold water because if I turn Switch2 on and off directly via the ISY admin console, it responds very quickly (within a second of toggling). So, I'm totally confused as to where the delay is coming from.

 

Can anybody help me understand what might be happening and whether there's a way around it?

It's possible, if you didn't factory reset your SwitchLinc before linking to ISY,  switch1 is full of links to devices you don't have.

 

When this happens switch1 is retrying and retrying to get an ACK response from device(s) that will never respond, and the ISY drivers are waiting for the air to clear, before they can add their two cents worth on the Insteon network.

[paulbates]

Thanks guys. I'll play around with scenes (which I haven't done much of yet) and see if that helps. As for creating a program to poll devices, I'm not sure why that would help, but I'm willing to try.

 

It sounds like noise problems. Insteon devices will try several times to turn a device on and that can create a delay.

 

I would suggest using the admin console to turn on the 'LED on TX' option on a swtichlinc that you can see, possibly the one in question.... that will make that switches LED a traffic indicator. Repeat the the action that runs the program. If the the LED flashes through out the 4 - 5 second delay, that means the the switch is retrying communications and it would mean following the procedure for diagnosing noise... run logs, look for noise producing devices.

 

Also, is there another program that is triggered by this action or on this device at the same time, it could be collisions from that program issuing direct insteon commands

 

Paul