ISY shows incorrect device status

[Techman]

I'm currently using a 99i with 3.2.6

 

All devices and scenes are working as they should with no error messages in the logs.

 

However I have two scenes, one with a TL and two KPL's and the other with two SL's, the scenes come on at dusk and turn off about 11 pm. The ISY shows the correct device/scene status when the scenes are on but after they turn off the ISY still shows them as on.

 

If I toggle the scenes manually from the ISY or at the devices the correct status is always displayed.

 

Any idea why the ISY isn't updating?

[oberkc]

It is my understanding that device status can get out of sync for a variety of reasons. I would expect a program that commands a scene on and off would result, however, in a correct status indication.

 

I can only theorize as to some problems that may apply to you....

 

a) are all scenes and links created with the ISY? Are there some that were created manually?

are you using any X-10 commands?

c) are you using a program and scene command to turn your lights off at 1100?

 

Perhaps others can help more.

[LeeG]

Are you saying the devices actually turned Off but they still show On in the Admin Console OR at 11 PM the devices did not actually turn Off.

 

Suggest posting the Program as it is more likely the Scene Off did not get executed rather than the device Status did not get updated.

[Techman]

All the scenes were created in the ISY

No X10 commands are being used

The scenes correctly turn off lights as they're supposed to, but the ISY doesn't show them as off

 

One of the scenes is dimmed at 9 pm using a program, the other scene is just turned on then off.

 

Out of all my scenes these are the only two scenes which always show up in the ISY as still on even though they physically turned off.

[LeeG]

That is a very strange problem. When one of the Responder devices is selected in the My Lighting tree, does the Scene show up in the Membership list on the right side of the right pane?

[Techman]

The scenes show up correctly on the right pane, all the device relationships are listed as they should be.

 

All the devices were purchased within the last 3 months so the hardware/firmware is current

 

I wonder if it could be an issue in he PLM.

 

I'm fairly new with Insteon devices having switched over a few months ago after about 35 years with BSR/X10 so troubleshooting is still somewhat of a challenge for me.

[Michel Kohanim]

Hi Techman,

 

Is this also an issue when you turn off the scene from the Admin Console (not through programs)? If not, then, what you must do is to look at Tools | Log, find instance where the program turned the scene Off, and then follow through ... it's also possible that they turned off and something else turned them on (but they didn't turn on for a variety of reasons).

 

With kind regards,

Michel

[Techman]

Hi Michel

 

The ISY correctly displays if I turn the scene on/off from the admin console.

 

I'll go through the log to see what I can find. If I'm stumped I'll post the log.

 

thank you

[Techman]

Hi Michel

 

I just checked my logs and for one of the scenes, East yard, which has 2-KLP and 1-TL

The log shows the scene turning on and the 2 KPL turning on but only the scene turning off. All 3 devices are in the scene as controllers. The leds on the KPL turn off when the scene turns off. There were no other entries in the log other than those below. Any thoughts?

--------------------------------------------------------------------------------------------------

Scene:East Yard Floodlight On 255 Thu 2012/10/04 07:01:34 PM Program Log

 

Hallway Keypad / Hallway Keypad B Status 100% Thu 2012/10/04 07:01:34 PM System Log

 

Bedroom Keypad North / Bedroom Keypad North C Status 100% Thu 2012/10/04 07:01:34 PM System Log

 

East Yard Floodlight Status 65% Thu 2012/10/04 07:01:34 PM System Log

 

Scene:East Yard Floodlight Off 0 Thu 2012/10/04 11:30:01 PM Program Log

-----------------------------------------------------------------------------------------------------

[Michel Kohanim]

Hi Techman,

 

Are there no entries whatsoever after this:

Scene:East Yard Floodlight Off 0 Thu 2012/10/04 11:30:01 PM Program Log

 

Nothing else at all? How about for the previous runs of the same program? If there's nothing else, it seems that the PLM is not responding at all to this command. That's the only explanation that I can think of right now especially since you can turn them on/off from Admin Console.

 

With kind regards,

Michel

[Techman]

Hi Michel

 

There were no other entries that pertained to this device for this one period. I copied only the lines in the log for this device and pasted them in the last post.

 

I've run several scene tests, link tests, etc and they all look normal. The device responds correctly from all the KLP's and from the admin console.

 

This morning I noticed that the device didn't turn off yet the KPL's were off and the log showed the device as off.

I've checked for noise on the line using an X10 tester. I saw no noise and a strong Insteion signal.

 

Should I try a PLM restore? Are there any diagnostics for the PLM that I overlooked?

[LeeG]

An individual device intermittently not responding to a Scene Off where other devices have reacted to the Scene Off will not be resolved with a Restore Modem (PLM). The link records in the PLM are used for a Scene Test but not a Program or Admin Console initiated Scene On/Off. If the device was missing a link it would be a solid failure. The ISY marks the device status based on the assumption the device has responded to the Scene command.

 

Indications are a powerline signal level problem, either being attenuated by something or some form of interference or a phase coupling problem.

[Techman]

Hi LeeG

 

The device was not responding to a scene off commnand sent by the PLM. If I do a manual on/off either from ther KPL or the ISY it works perfectly. The device sits in a two gang box with a device that has no issues so I don't think it's a signal / line noise issue.

 

What's really strange is that when I changed the scene off time from 11:30 to 11:35 the program and scene worked as they should. When I changed it back to 11:30 it quit working There are no other programs scheduled for that time slot so I don't think there was a communication conflict.

 

I think there's a corrupted byte of data either sitting in the PLM or ISY. I just deleted the program, the scene and the device from the ISY and will start fresh to see what happens. I'll keep you updated.

[LeeG]

If the time factor is consistent, not just a coincidence, there is a device or appliance that is On at 11:30 and not On at 11:35. It is not a conflict of traffic at 11:30.

 

The Scene On consists of two bytes of functional information from the ISY to the PLM, the Scene number and the command code. These values must be correct for other responders of the Scene to react. The Scene On is a single message on the powerline. It contains no responder Insteon addresses and it is not ACKed or retried. Nothing about a Scene On message itself is time significant.

 

It has to be something like a noisy CFL, LED or florescent device or some other appliance that is generating interference at 11:30 that is not On at 11:35.

 

Individual device On/Off commands are ACKed and retried several times. Unless a really bad communication problem a device On/off will generally work because of the ACKs and retries.

 

Look for something that is powered at 11:30 and not powered at 11:35. Link data is not time sensitive.

[Techman]

The only activity I had running at 11:30 pm was dimming the leds on two KPLs, which I had earlier overlooked. There is no other device, program or appliance running at that time or close to it.

 

Yesterday I deleted the device in question from the ISY, deleted the program, and deleted the scene then recreated them, so far the scene now seems to be working correctly and the ISY is showing the correct status. One of the KPLs that was dimmed was a member of the scene. At this point I'm not sure if the issue was with the KPL. I'll keep an eye on it for a few more days to see if it remains consistent.

 

My 8 button dimming (2486D) KPL's are h/w ver 5.9 with firmware ver .40. I believe there's a later version of the KPL that's now available but I'm not sure what the changes are, or what the issue was with the previous version.

[Xathros]

Hi Techman-

 

Anytime I have multiple events the should occur at a specific time, I try to stagger them in 5 to 10 second increments to prevent collisions on the powerline. I have six or seven programs that run between 23:59:00 and 23:59:45. I was having reliability issues with some of these programs when four of them all were scheduled for 23:59:00. Since staggering them and adding some additional programs, I haven't had a single failure. The length of time to allow between programs depends on the number of Insteon actions the earlier program needs to run through before you run the next program.

 

-Xathros

[oberkc]

I have six or seven programs that run between 23:59:00 and 23:59:45.

 

I wonder if, instead of staggering them, with each program having their own slightly different time conditions, whether it would be as good or better to employ a tactic such as:

 

if

time is 23:59

then

run program 1 (then path)

run program 2 (then path)

...

run program x (then path)

[ISYhbsh01]

I think that when you do that it will start to run one program right after the other with program 2 not waiting for program 1 to complete first, and so on with all the programs thus defeating the purpose. What you can do is to put in a wait in between each program on the list.

 

Sent from my SPH-D710 using Tapatalk 2

[oberkc]

I think that when you do that it will start to run one program right after the other with program 2 not waiting for program 1 to complete first, and so on with all the programs thus defeating the purpose

 

You may be right. Have you tried this and, thus, speak from experience or, like me, just wondering aloud?

 

If I get ambitions, I may create a couple of test programs to find out.

[LeeG]

Program execution is in parallel, not serial. Program A invoking Program B does not wait for B to complete before Program A continues. It is documented either in the User Guide or the Wiki.

[ISYhbsh01]

You may be right. Have you tried this and, thus, speak from experience or, like me, just wondering aloud?

No I haven’t tried it myself, but I have read many times on this forum about cases where the goal was the opposite, that the 2nd or later action in the “then†statement should NOT be dependent on the successful completion of the prior action in the “then†statement. The advice given as I recall has been to make a separate program for the 2nd action and call this program from the main program & then the 2nd program will execute regardless of what happens with the first action. This made me come to the above conclusion, but if I am wrong I would love someone to correct me.

 

I didn’t do a search now but I recall seeing this mentioned in the forums many times, especially in cases where a wait or repeat command was involved.

[Xathros]

Oberkc, hbsh01-

 

I had tried something similar quite a while back and discovered the parallel execution issue. One Idea I had was to just call the next program from the end of the previous one but I reuse some of the individual programs (run then or else) during the day or on demand and don't necessarily want the remainder in the chain to run as well. I could build a master with waits but thats yet another program when what I've got works.

 

Anyway, my point to the OP was that I ran into traffic collisions and that they should be avoided if at all possible.

 

Thanks for the suggestions though. Always nice to see different approaches to the same problem.

 

-Xathros

[Michel Kohanim]

Hi guys,

 

Please note the following:

Program A invoking Program B does not wait for B to complete before Program A continues

Yes, this is true.

 

Program execution is in parallel, not serial

This is mostly true, every program essentially runs in an individual thread, but, a single ISY thread simulates this. Therefore, at any one time, there is only one program actually executing commands.

 

With kind regards,

Michel

[Techman]

Looks like my issue was resolved by by changing the program run times in the ISY so that they're not executing at the same time. I had two programs running at the same time, one was setting the led level on several keypads and the other was turning off a scene.) Troubleshooting was difficult as the outcome of the programs running at the same time didn't always produce the exact same issue(s).

 

Thanks again for all your input.