Eisy programs will turn some insteon switches on but not off

[lionheartkc]

I just moved to the eISY from a ISY 944. I have programs set to turn on and off Christmas lights using Insteon plug-in switches... several indoor and 2 outdoor. They worked nearly flawlessly on the 944. On the eISY, however, everyday at sunset, without fail, all of the lights turn on, but everyday at midnight, the indoor lights turn off but the outdoor lights stay on.

I even have programs set to run 10 minutes later to check if they are off and, if not, turn them off. Those also always fail to turn them off.

If, however I go to the mobile interface and manually tell them to turn off, they do, every time.

I'm at a loss as to why they come on programmatically but will only shut off manually.

Does anyone have any ideas for fixing this issue?

Thanks. 

Edited December 20, 2023 by lionheartkc

[paulbates]

The. I ink for the device direct is different than the links for the scene. I would right click on one of the devices and pick "Restore device" and then retest the scene. This may not be it, but important to eliminate and doesn't take long to do.

Edited December 20, 2023 by paulbates

[Goose66]

Are you turning them on or off individually in your scheduled programs or through scenes?

[lionheartkc]

1 hour ago, Goose66 said:

Are you turning them on or off individually in your scheduled programs or through scenes?

The initial program uses scenes. The test 10 minutes later is individual.

[Goose66]

Here is my anecdotal Insteon experience from the last 12 years: If I have individual commands in a program, I can just enter them sequentially in the Then or Else branch and it seems to work. If I have multiple scenes, however, I will generally put a wait between them of 2 or 3 seconds. I think this is because the sequence that Insteon uses for scenes (send scene command broadcast, then follow up individually with each device) takes multiple zero-crossing cycles to perform.

Also, for my Holiday Lights programs and my daily/nightly lighting programs, I execute an On on the scene, wait a minute, then execute the On on the scene again. This frequently cleans up stragglers that may be multiple hops down the communication path that never receive the initial signal because of the noise that is generated from turning on all these LED power converters at one time. 

Edited December 20, 2023 by Goose66

[lionheartkc]

4 hours ago, Goose66 said:

Here is my anecdotal Insteon experience from the last 12 years: If I have individual commands in a program, I can just enter them sequentially in the Then or Else branch and it seems to work. If I have multiple scenes, however, I will generally put a wait between them of 2 or 3 seconds. I think this is because the sequence that Insteon uses for scenes (send scene command broadcast, then follow up individually with each device) takes multiple zero-crossing cycles to perform.

Also, for my Holiday Lights programs and my daily/nightly lighting programs, I execute an On on the scene, wait a minute, then execute the On on the scene again. This frequently cleans up stragglers that may be multiple hops down the communication path that never receive the initial signal because of the noise that is generated from turning on all these LED power converters at one time. 

Thank you. I'm trying a new program now that turns off the scene, then waits, turns off one switch, waits, and turns off the second switch. Fingers crossed that will do the trick.

[lionheartkc]

7 hours ago, paulbates said:

The. I ink for the device direct is different than the links for the scene. I would right click on one of the devices and pick "Restore device" and then retest the scene. This may not be it, but important to eliminate and doesn't take long to do.

Thank you. I just restored both to see if that helps.

[lionheartkc]

Just as an update, I've tried everything mentioned above and none of it has made a difference. The programs are still failing to turn off the lights, while manual control is working perfectly.

I have to say that this is particularly frustrating considering the only variable that has changed in the whole system is moving from my old ISY 994 to the eISY. It all worked before that change.

Edited December 21, 2023 by lionheartkc

[paulbates]

Just to clarify a few things

• You did "Restore Device" for both, and that ran successfully? A lot gets communicated from the PLM to the devices for that to complete, which suggests the PLM can talk to the devices
• The eisy PLM is plugged into the same outlet as the ISY?

One more thing, easy to try through I'm not sure it works with scenes. I used it at my last house that had problem areas and it helped... adjust the individual device retries:

• Right click on the device
• Pick advanced / PLM Communications
• Bump the Retries up to 2 or 3 and retest

[paulbates]

One more idea.. the common element of the problem is the program - you're sure every thing is good in the program? .. maybe open and resave it

Edited December 21, 2023 by paulbates

[Techman]

@lionheartkc

Try removing power from the eisy for about 15 seconds then let it boot up.

If that doesn't work then it's possible that one of your loads on your modules is creating noise on the powerline which is interfering with the off command.

Are all the modules involved all dual band?

You can try disconnecting the modules, one at a time, to see if it may be causing issues.

 

[lionheartkc]

1 hour ago, paulbates said:

Just to clarify a few things

• You did "Restore Device" for both, and that ran successfully? A lot gets communicated from the PLM to the devices for that to complete, which suggests the PLM can talk to the devices
• The eisy PLM is plugged into the same outlet as the ISY?

One more thing, easy to try through I'm not sure it works with scenes. I used it at my last house that had problem areas and it helped... adjust the individual device retries:

• Right click on the device
• Pick advanced / PLM Communications
• Bump the Retries up to 2 or 3 and retest

Yes. Restore Device ran for both with no issues. I can also sit here and turn the devices on and off in the interface all day long and it works perfectly, so it's not a communication issue. 

The PLM and ISY are plugged into outlets that are around 4' apart.

I know it's not the program for a couple of reasons. First, it turns the indoor lights off. Second, it's the same program that worked fine before I switched the controller. That being said, I've messed with it a lot to try to make it work.

I just tried setting the retries. One of the devices throws a "request failed" error when I select a number of retries from the dropdown, but then appears to work when I hit done. I'll note that I tried the Advanced PLM settings on other switches, both plug and wired, just to see, and every single one throws that "request failed" error.

The other outdoor switch said that it doesn't support PLM settings, so it's a little long in the tooth.

Edited December 21, 2023 by lionheartkc

[lionheartkc]

15 minutes ago, Techman said:

@lionheartkc

Try removing power from the eisy for about 15 seconds then let it boot up.

If that doesn't work then it's possible that one of your loads on your modules is creating noise on the powerline which is interfering with the off command.

Are all the modules involved all dual band?

You can try disconnecting the modules, one at a time, to see if it may be causing issues.

 

I thought about line noise, maybe even from the LEDs plugged into the switches, which would explain on working and off not working, but I can't explain why manual switching works from the interface if that is the issue.

[IndyMike]

There are a few misconceptions regarding the protocol and how the ISY handles scenes -

1) Scenes - ISY scenes do not interrogate members to determine if they have responded correctly.   As a result, there are no PLM retries used.  The ISY assumes that the scene executed properly.  The scenes are a single command and are very fast.  Since there is no additional communication between the PLM and responders, scene commands in programs normally do not require delays.

2) Device direct commands (admin console) - Device cleanup commands are used to determine if the device has responded properly.  If it does not, the PLM will re-try the command xx times.  PLM retries are invisible to the ISY.

3) Device direct commands (programs) - Similar to commands executed from the admin console, cleanup commands are issued.  The difference here is that the PLM can be overloaded if commands are "chained" and it will abandon cleanup attempts.  This is where you need to insert delay between commands to give the PLM time to issue cleanup messages and retries.

4) Device cleanup retries (advanced menu for the devices) - This is for adjusting the #of retries that devices use to communicate with the PLM (not PLM to device).  It will have no effect on scenes initiated by the ISY.  It is only available on newer devices.

https://wiki.universal-devices.com/index.php?title=ISY994i:INSTEON_Device

5) ISY Retries - ISY retries are used when querying a device.  To my surprise, they do not appear to be used for device direct commands (anymore??). Retries default to 2 and can be changed by using Telnet to connect to the ISY Shell.  Use "CR" max command retries.  I do not advise adjusting beyond 2 as this significantly bogs down the ISY.

https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide#CR_-_Max_Device_Command_Retries

Edited December 22, 2023 by IndyMike
typo

[apostolakisl]

The problem is not with links.  ISY programs turn off the lights using the PLM and your mobile device turns off the lights using the same PLM.  Since your mobile device works, it can't be bad links.  So restoring the device won't have any affect.  Same thing with bad comm.  If your mobile device works, then the comm is fine since it is following the same path from the PLM to the device.  That pretty much just leaves the program.

Try deleting the program completely and create a brand new program.  Perhaps something got scrambled when you did the backup of your old ISY and restored it to your new one.

Edited December 22, 2023 by apostolakisl

[IndyMike]

Just noticed that your problem lights were outside - i.e. on GFI outlets.  GFI's can sometimes degrade powerline communication.  What model Insteon devices are you using outside - are they dual band? Can you temporarily bypass the GFI for testing purposes?

To @apostolakisl's point above.  Much of this revolves around your programs.  Please post them.

[lionheartkc]

7 hours ago, apostolakisl said:

The problem is not with links.  ISY programs turn off the lights using the PLM and your mobile device turns off the lights using the same PLM.  Since your mobile device works, it can't be bad links.  So restoring the device won't have any affect.  Same thing with bad comm.  If your mobile device works, then the comm is fine since it is following the same path from the PLM to the device.  That pretty much just leaves the program.

Try deleting the program completely and create a brand new program.  Perhaps something got scrambled when you did the backup of your old ISY and restored it to your new one.

My next move was to just rebuild the programs from scratch, which I just did since when they didn't work last night, I just manually triggered the "then" and it worked. Fingers crossed that does the trick. 

13 hours ago, IndyMike said:

There are a few misconceptions regarding the protocol and how the ISY handles scenes -

1) Scenes - ISY scenes do not interrogate members to determine if they have responded correctly.   As a result, there are no PLM retries used.  The ISY assumes that the scene executed properly.  The scenes are a single command and are very fast.  Since there is no additional communication between the PLM and responders, scene commands in programs normally do not require delays.

2) Device direct commands (admin console) - Device cleanup commands are used to determine if the device has responded properly.  If it does not, the PLM will re-try the command xx times.  PLM retries are invisible to the ISY.

3) Device direct commands (programs) - Similar to commands executed from the admin console, cleanup commands are issued.  The difference here is that the PLM can be overloaded if commands are "chained" and it will abandon cleanup attempts.  This is where you need to insert delay between commands to give the PLM time to issue cleanup messages and retries.

4) Device cleanup retries (advanced menu for the devices) - This is for adjusting the #of retries that devices use to communicate with the PLM (not PLM to device).  It will have no effect on scenes initiated by the ISY.  It is only available on newer devices.

https://wiki.universal-devices.com/index.php?title=ISY994i:INSTEON_Device

5) ISY Retries - ISY retries are used when querying a device.  To my surprise, they do not appear to be used for device direct commands (anymore??). Retries default to 2 and can be changed by using Telnet to connect to the ISY Shell.  Use "CR" max command retries.  I do not advise adjusting beyond 2 as this significantly bogs down the ISY.

https://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide#CR_-_Max_Device_Command_Retries

Thank you. This is some very useful information.

[lionheartkc]

1 hour ago, IndyMike said:

Just noticed that your problem lights were outside - i.e. on GFI outlets.  GFI's can sometimes degrade powerline communication.  What model Insteon devices are you using outside - are they dual band? Can you temporarily bypass the GFI for testing purposes?

To @apostolakisl's point above.  Much of this revolves around your programs.  Please post them.

Here's the program to shut them off.

I added a notification, yesterday. It didn't work, so I know the program wasn't executing at all. Hopefully rebuilding it, today, will fix that.
 

[IndyMike]

21 minutes ago, lionheartkc said:

Here's the program to shut them off.

I added a notification, yesterday. It didn't work, so I know the program wasn't executing at all. Hopefully rebuilding it, today, will fix that.
 

Good idea adding the notification...

I'm assuming this is the "new" follow-up program that is talking directly to the devices - correct?

Are you still running your scene program and does it still fail to shut off the outdoor lights?

Are these lights on GFCI circuits (outside and garage)?

I am not familiar with the 'Holiday controller' date control.  Assuming the program triggers, the device direct communication should be the same as if you turned the devices off from the Admin console.  The PLM will issue device cleanup after each command and will retry communication 5x to devices that do not respond.

My only other comment would be to make sure you don't have any other programs running at the same time.  The Waits are effective at separating the PLM communication events WITHIN the program.  If you have multiple programs executing the ISY could insert communication from other programs within the waits.  This normally would be a huge concern, but if your PLM is performing retries to a problem device, it might abandon the cleanup in favor of the new command.

[lionheartkc]

13 minutes ago, IndyMike said:

Good idea adding the notification...

I'm assuming this is the "new" follow-up program that is talking directly to the devices - correct?

Are you still running your scene program and does it still fail to shut off the outdoor lights?

Are these lights on GFCI circuits (outside and garage)?

I am not familiar with the 'Holiday controller' date control.  Assuming the program triggers, the device direct communication should be the same as if you turned the devices off from the Admin console.  The PLM will issue device cleanup after each command and will retry communication 5x to devices that do not respond.

My only other comment would be to make sure you don't have any other programs running at the same time.  The Waits are effective at separating the PLM communication events WITHIN the program.  If you have multiple programs executing the ISY could insert communication from other programs within the waits.  This normally would be a huge concern, but if your PLM is performing retries to a problem device, it might abandon the cleanup in favor of the new command.

It is the new program, which is the same as the old program. 

I've not changed the time to test it, because I don't want to throw another variable in the mix, so we'll just have to wait until midnight to see if rebuilding it does the trick.

Yes, unfortunately, because they are outdoor lights, they are on GFCI circuits. Nothing can really be done about that. Still, I've been controlling this same setup with my ISY 994 for years with no issues. 

I have been very careful to time my programs so they don't fire on top of each other. 

I'll let everyone know if the rewrite did the trick.

[lionheartkc]

FINALLY! The program worked. Rebuilding it did the trick.