Anomaly on all on and all off

[Thom]

In the administrative console, when I do All On followed by All Off directed at My Lighting, two devices initially show a status of off, and then after a couple of seconds later show a status of on.

 

For these two devices, the log shows

the status of on after the web initiated fast on

then a status of off after the web initiated fast off and

then the status of on for each of the two devices for no apparent reason.

Before the final On status events, there are only the predicted status events for all the devices. There are no scheduler events.

 

When I communicated with you via email, you suggested:

"there MUST be a program that turns on/off a "scene" that those

two devices belong to ... a trigger based on some other device"

 

The two devices are in two scenes. The first scene contains only those two devices. Both are controllers, they replace two 3-way switches. Neither the devices nor the scene are in ANY programs at all.

 

The second scene contains these two devices and several other devices. The two devices are only responders for this scene. This scene is not in ANY program. Other devices in this scene are in other scenes that have time scheduled programs only. No triggers other than time.

 

The only programs in my ISY that are based on device triggers are for bathroom and closet lights to turn them off after 15 minutes. None of those devices is in either of the two scenes that contain the two devices that report the erroneous On status.

 

Neither of the two scenes containing the two devices nor the two devices has ever been in a program.

 

I am finding the analysis of a program causing the On status events difficult to understand. If there is such a program, how did it accomplish this feat without a report in the log? If this is a program doing the deed, how might I find it?

[Michel Kohanim]

Thom,

 

Thank you for posting your issues in our forum and I do hope they will benefit everyone.

 

My assumptions (which may be wrong) that you have a program turning these devices on/off is based on the following:

ISY updates the status of devices on the Admin Console if and only if:

 

1. You physically turned on/off a device, PLM sensed it --> ISY sensed it, updated the status, checked to see whether or not this is a controller for a scene, and predicted the status of all the devices in that scene

 

2. You turned on/off a device through ISY (either web or program), in which case, ISY waits for response back from the device and if one received, updates the status of that device ONLY. If not, you get device comm errors.

 

3. You turned on/off a scene (including All on/All off) through ISY (either web or program), in which case ISY waits for a confirmation from the PLM (that it has send out the command) and then predicts the status of the devices in that scene

 

Unless there's a bug that we cannot reproduce here (but will continue trying), it seems that somehow ISY believes that the status of those devices have changed and, as I mentioned before, there are only 3 cases which this takes place.

 

With kind regards,

Michel

 

In the administrative console, when I do All On followed by All Off directed at My Lighting, two devices initially show a status of off, and then after a couple of seconds later show a status of on.

 

For these two devices, the log shows

the status of on after the web initiated fast on

then a status of off after the web initiated fast off and

then the status of on for each of the two devices for no apparent reason.

Before the final On status events, there are only the predicted status events for all the devices. There are no scheduler events.

 

When I communicated with you via email, you suggested:

"there MUST be a program that turns on/off a "scene" that those

two devices belong to ... a trigger based on some other device"

 

The two devices are in two scenes. The first scene contains only those two devices. Both are controllers, they replace two 3-way switches. Neither the devices nor the scene are in ANY programs at all.

 

The second scene contains these two devices and several other devices. The two devices are only responders for this scene. This scene is not in ANY program. Other devices in this scene are in other scenes that have time scheduled programs only. No triggers other than time.

 

The only programs in my ISY that are based on device triggers are for bathroom and closet lights to turn them off after 15 minutes. None of those devices is in either of the two scenes that contain the two devices that report the erroneous On status.

 

Neither of the two scenes containing the two devices nor the two devices has ever been in a program.

 

I am finding the analysis of a program causing the On status events difficult to understand. If there is such a program, how did it accomplish this feat without a report in the log? If this is a program doing the deed, how might I find it?

[Thom]

Michel, one more thing about the two devices that show status ON after the all off. They are not actually on. It is only the status indication that has changed, and a log entry has been written. I believe that this is conclusive proof that it is not a program that is doing this. A program would actually turn the devices on.

 

I assure you that I did not physically turn the two devices on. And, if I had done that, they would be on. I did not turn on the scene that contains these two devices.

 

So I think we can eliminate all 3 ways you mention. And by the way, all three of those ways would have actually turned the devices on. But they were really off. Only the status reported on.

 

Given the specific repeatable nature of this problem, it does not surprise me that you cannot repeat it. Something is broken here. I would like to determine if it is the ISY or the PLM.

 

I am interested in this problem because there are so many flakey things going on on my system, I really want to attack and correct repeatable problems.

 

To that end, I did a hard reset on the PLM and then restored it. The problem persists.

[Michel Kohanim]

Thom,

 

Thank you for the update. It would be very hard to argue with your logic, but please keep in mind that 2 out of the 3 ways above have the word "predict" in them. i.e. ISY predicts what the outcome should be and thus your issue falls within them.

 

Here's how All On/Off works from Insteon perspective: each device turns on to the on level/ramp rate for the FIRST ever entry for the controller in that devices database. So, since those devices do NOT actually turn on, this leads me to believe that one of the two following things are the cause:

1. ISY is predicting incorrectly ... but if your devices are in ANY scene, then that would be quite unlikely

2. Your devices do not have a SLAVE link for the PLM for the initial scene and/or any other scene

3. You have random communication issues between your PLM and those devices.

 

If query works for those devices 99% of the time and/or if you can turn on/off those devices through a scene 99% of the time, then the problem has to be either 1 or 2. To isolate:

1. Do a restore device on one of your devices. If that fixes the problem, then we know that we had a missing link

2. If not, try airgap on your device

 

I have started a root cause analysis to see if we can repeat this problem.

 

With kind regards,

Michel

 

 

 

those devices are missing the SLAVE link for the PLM. What I suggest is:

1. Try restoring one of the devices, if it works, then we have found the problem

2. If it doesn't, take the device

 

Michel, one more thing about the two devices that show status ON after the all off. They are not actually on. It is only the status indication that has changed, and a log entry has been written. I believe that this is conclusive proof that it is not a program that is doing this. A program would actually turn the devices on.

 

I assure you that I did not physically turn the two devices on. And, if I had done that, they would be on. I did not turn on the scene that contains these two devices.

 

So I think we can eliminate all 3 ways you mention. And by the way, all three of those ways would have actually turned the devices on. But they were really off. Only the status reported on.

 

Given the specific repeatable nature of this problem, it does not surprise me that you cannot repeat it. Something is broken here. I would like to determine if it is the ISY or the PLM.

 

I am interested in this problem because there are so many flakey things going on on my system, I really want to attack and correct repeatable problems.

 

To that end, I did a hard reset on the PLM and then restored it. The problem persists.