Sunrise to Sunset - Not always working

[Jberglie]

Hi all, 

I have a very simply program -- I want to turn a number of devices on at Sunset, and off at Sunrise. 

I have the program attached in the image.  

I set a variable to 1 for use in other programs, then set each unit I want to on.  

Initially this is all I had, but I noticed some devices would not always turn on (or off for the sunrise program) so I decided to adjust my program and wait 10 minutes, then repeat the same set of instructions.  

That helped --  but still, it doesnt seem to be the best solution as regularly, there are some devices that will not turn on or off.  

There does not seem to be a pattern to which devices will turn on or off the most reliably.   I'm guessing it is a ISY connection issue maybe?  

 

So I'm trying to think of another work-around - anyone have any ideas? 

Thanks so much! 

[Bumbershoot]

I'd insert a 2 second wait between turning each device on.  This ensures that there won't be any communication collisions and the ISY rapidly tries to turn on multiple devices.  I do this every evening as I turn down the sentinel LEDs for a bunch SwitchLinc Dimmers, and the reverse in the morning.  I never seem to have trouble with them.  Or, you could just put all these devices into a scene, and turn the scene on.

[Jberglie]

Ahhh ok -- Thank you so much!  - Do you think it's better to do it as a scene vs a program?  

[Bumbershoot]

I guess that depends.  Scenes are awfully useful, and fast.  On the other hand, ISY programs consume no links in your PLM.  If you're pushing the limits on your PLM, then use a program.  I use scenes when I want things to happen immediately.  When I don't care so much, I use a program.

[Jberglie]

Thanks so much for your help!   

[larryllix]

ISY has the speed and can handle commands back to back without bogging down.

However the Insteon comm channel cannot handle constant commands. I had some problems with this too. If you have a bad unit that doesn't ACK right away or noise the next command can clobber the protocol sometimes. This gets bad if a unit is unplugged and ISY seems to send it anyway. I found putting bad units at the end of the list worked but in the middle of all the units it clobbered the next three units in the program list. Bumbleshoot's 2 second delays makes it more bulletproof, if you can stand the looks of the delays.

If one particular unit fails a lot, look back at what the  previous units are in the list and insert delays between or move the suspect to the bottom.

[Jberglie]

9 hours ago, larryllix said:

ISY has the speed and can handle commands back to back without bogging down.

However the Insteon comm channel cannot handle constant commands. I had some problems with this too. If you have a bad unit that doesn't ACK right away or noise the next command can clobber the protocol sometimes. This gets bad if a unit is unplugged and ISY seems to send it anyway. I found putting bad units at the end of the list worked but in the middle of all the units it clobbered the next three units in the program list. Bumbleshoot's 2 second delays makes it more bulletproof, if you can stand the looks of the delays.

If one particular unit fails a lot, look back at what the  previous units are in the list and insert delays between or move the suspect to the bottom.

Thanks Larry - I went the route of putting them all in a scene, and as of this morning, it seems to all be fine.  I'll continue monitoring this and see if we have any more issues.  Thanks!