ISY99i IR PRO shows device status; different actual status

[propman07]

Hello-

 

I've got a problem that I'm having trouble figuring out how to troubleshoot. I've got a program that runs at sunrise and sunset to control my outdoor lighting. It has been working well for some time now, but recently, I've noticed the following.

 

When the program runs, the ISY99i IR/PRO send the commands to turn off (for example) the outside lights. When I check the ISY, it shows that all of the outdoor lights are off. If I look at the actual switches, one of them (the same one) is sometimes still on. This also occurs when the lighting program runs to turn on the outside lights. I have added a timer in the program (to try to fix this issue) that sends the same commands a few minutes later. Unfortunately, I still am having issues with the one troublesome switch.

 

Here is the program that I'm using to control the outdoor lights.

 

 
If
       From    Sunset 
       To      Sunrise -  5 minutes (next day)

Then
       Set Scene 'Scenes / Outside Lighting' On
       Wait  5 minutes 
       Set Scene 'Scenes / Outside Lighting' On
       Send Notification to 'David' content 'Lights On'

Else
       Set Scene 'Scenes / Outside Lighting' Off
       Wait  5 minutes 
       Set Scene 'Scenes / Outside Lighting' Off
       Send Notification to 'David' content 'Lights Off'

 

Here is the switch I'm having trouble with...

 

2476S SwitchLinc Relay - Remote Control On/Off Switch v.3A

 

It is in a scene with the other outdoor lights.

 

Thanks.

[LeeG]

The ISY marks all the Scene devices Off. There is no device response to the Scene On or Scene Off.

 

There is a comm problem of some type with that particular device. Could be distance to the device, interference from the type of loads that are controlled by that Scene, phase coupling, etc.

 

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Turn that device On and Off a few times and watch the Hops Left=x count. Does it change over time? If the device works individually with at least a consistent Hops Left=1 or greater count, turn On the other devices controlled by the Scene and see if the problem device Hops Left=x count changes.

[WayneW]

IMHO, this is one of the weaknesses of Insteon scenes (the lack of a device error).

 

My workaround was for add extra lines in the program to manually set critical items to the desired state. If the devices fails to respond to a direct command, then the ISY knows. Then I notify myself for logging & investigation.

 

If

Status 'LL 1' is not Responding

Or Status 'LL 2' is not Responding

Or Status 'LL 3' is not Responding

etc...

Then

Send Notification to 'email & cell' content 'Device XX is not responding'

Else

- No Actions - (To add one, press 'Action')

 

My notification:

${sys.node.#.name} is not responding at ${sys.time12}.

Address ${sys.node.#.addr}. Status ${sys.node.#.ST}.

[propman07]

LeeG

Thanks for the reply. I'll take a stab at what you suggested.

 

WayneW

Thanks for your reply. The problem is in my situation is that the isy thinks the switch is on. It actually is not and the only way I know that is by looking at the LED on the switch.

[WayneW]

WayneW

Thanks for your reply. The problem is in my situation is that the isy thinks the switch is on. It actually is not and the only way I know that is by looking at the LED on the switch.

The ISY assumes that the switch is on because the ISY turned the scene on. I suspect that you could add a query of the switch with some retry logic in your program, but I would be afraid of an infinite loop. What if the switch failed to respond at all?

 

If you did a manual query of the switch, the ISY would get properly updated with the switch status. But that requires you to see that the light is in the wrong state before you intervene.

 

There is a fundamental difference between turning a scene on and turning a device on in that when a specific device is turned on, there is a method to make sure that the switch actually receives and responds. A scene is blind faith. Like the difference between TCP & UDP, if you are into networking.

 

Also to clarify, Lee is perfectly correct. His post gets more to the "real" solution, whereas my method simply documents that something has gone wrong. IMHO, the best way to know that something is broken is to have it logged. Once you have a log, you can start to figure out a pattern or frequency. And determine how many resources should be devoted to fix the issue. Once a month issues are very hard to test & fix & confirm the fix. Daily issues are easier.

 

To clarify, my first quote is a error handling separate program, not an addition to your program.

 

Your program would become something like:

Then

Set Scene 'Scenes / Outside Lighting' On

Set 'Front Porch Switch' On

Wait 5 minutes

Set Scene 'Scenes / Outside Lighting' On

Send Notification to 'David' content 'Lights On'

[propman07]

WayneW-

 

Thanks....when you made the statement that scenes and lighting commands are different, the bell went off in my head. I plan to modify my program exactly as you have described. This should catch the switch that I am having issues with.

 

Thanks for the explanation on scenes and individual control commands. That helped a lot.

 

David