Another ALL ON Event

[Algorithm]

Hi Al,

 

Sorry and, yes, correct:

88576 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:36 PM Program Log

88577 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:36 PM Program Log

 

As you can see, they were activated by a program. So, there must be a program that controls them.

 

With kind regards,

Michel

 

Hi Michel,

 

This is the only program containing that scene:

4Lvl Stairway Motion Laundry Check - [ID 0253][Parent 013C]

If
        (
             Control '4Lvl / 4d Stairway Motion-Sensor' is switched On
          Or Status  '4Lvl / 4d Stairs Light - Top' is not Off
          Or Status  '4Lvl / 4d Stairs Light - Bottom' is not Off
        )
    And Status  '3Lvl / 3d Laundry Light' is not Off
    And Status  '4Lvl / 4d Rec Room Track Lights' is Off
 
Then
        Set Scene '4Lvl / 4s Rec Room Track Lights' On
 
Else
   - No Actions - (To add one, press 'Action')
 
When motion is sensed, or stair lights are on, if the laundry room light is on,
and the 4th level rec room track lights are not on, then turn them on,
since the 4th level rec room track lights are used for doing laundry.

The motion sensor is linked to the stairway lights (top and bottom) in a scene, so motion turns those switches/light on.

 

But, one of the conditions is that the Rec Room Track Lights must be Off, so once the program turns the scene on, it should not turn it on again.  What else might account for those extra lines in the log -- and, do those extra lines actually have anything to do with the ALL ON event?

 

Al

[stusviews]

An identified possible cause of the AL ON phenomenon is when a trigger device is also a responder in which case a 2 second delay is recommended. That would be true in your case if any of the devices in the If statement is also in the triggered scene.

[Algorithm]

An identified possible cause of the AL ON phenomenon is when a trigger device is also a responder in which case a 2 second delay is recommended. That would be true in your case if any of the devices in the If statement is also in the triggered scene.

Hi Stu, correct.  But alas, none of those are in the scene.

[Michel Kohanim]

Hi Al,

 

For some reason, the following was issued twice:

Set Scene '4Lvl / 4s Rec Room Track Lights' On

 

Looking at the program, can you think of any possible cases where this program would run twice immediately one after the other ?

 

With kind regards,

Michel

[Algorithm]

Hi Al,

 

For some reason, the following was issued twice:

Set Scene '4Lvl / 4s Rec Room Track Lights' On

 

Looking at the program, can you think of any possible cases where this program would run twice immediately one after the other ?

 

With kind regards,

Michel

 

Ha ha ... that's my question to you!

 

Hypothesis:

1.  Sensor senses motion, turns on stairway light top and bottom (lines 88572,88573)

2.  ISY receives ON from sensor, program runs THEN, turns on rec room lights (88574, 88575)

3.  ISY updates stairs top status, causes program to evaluate again (88576)

4.  ISY updates stairs bottom status, causes program to evaluate again (88577)

 

Problem:

After step 2, rec room lights are on (one of the conditions), therefore steps 3 and 4 should run ELSE rather than THEN.

 

Thoughts?

 

Al

[Michel Kohanim]

Hi Al,

 

I didn't have (and still don't have) enough information and thus the reason for asking you.

 

1. We know that the Stairs Light caused the program to run:

88572 4Lvl / 4d Stairs Light - Top Status 90% Tue 2016/04/05 05:41:35 PM System Log

88573 4Lvl / 4d Stairs Light - Bottom Status 90% Tue 2016/04/05 05:41:35 PM System Log

88574 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:35 PM Program Log

88575 4Lvl / 4d Rec Room Track Lights Status 90% Tue 2016/04/05 05:41:35 PM System Log

2. I do not see any entry for Laundry Light. So, please go back in the log and find the first occurrence right before 05:41:35 and let me know the status

3. I am not sure whether or not you intended this, but since you do not have 'And Control '4Lvl / 4d Stairway Motion-Sensor' is not switched Off', in essence the first statement will always be true after the first motion is sensed AND any of those lights are not off. Of course, the program will be evaluated every time the motion is sensed but after the first motion, any change to non-off in those lights causes the first part to become true

 

With kind regards,

Michel

[larryllix]

Ha ha ... that's my question to you!

 

Hypothesis:

1.  Sensor senses motion, turns on stairway light top and bottom (lines 88572,88573)

2.  ISY receives ON from sensor, program runs THEN, turns on rec room lights (88574, 88575)

3.  ISY updates stairs top status, causes program to evaluate again (88576)

4.  ISY updates stairs bottom status, causes program to evaluate again (88577)

 

Problem:

After step 2, rec room lights are on (one of the conditions), therefore steps 3 and 4 should run ELSE rather than THEN.

 

Thoughts?

 

Al

Yes, you definitely have an echo situation in your program.

 

 

Any time I see conditions based on the status of a device being controlled by the same program it makes me squirm..

 

Usually this isn't a problem with a 'switched' trigger as an ANDed trigger since 'switched' triggers can never be true, as a condition, and cause an echo trigger.

 

In your program, you have your trigger ORed with other statuses, which can be true, eliminating the "usually" scenario, above, so your program, with the right statuses not off,  will always run twice in succession as fast as ISY can go and put them out. Ouch!

 

 

This sounds like a set up to test for ALL ON problems, based on what UDI has been telling people.

      "How to create Insteon signals in rapid succession 101"

 

 

EDIT: Corrected below. I was insane at the time I made these comments.

[Algorithm]

Hi Al,

 

I didn't have (and still don't have) enough information and thus the reason for asking you.

 

1. We know that the Stairs Light caused the program to run:

88572 4Lvl / 4d Stairs Light - Top Status 90% Tue 2016/04/05 05:41:35 PM System Log

88573 4Lvl / 4d Stairs Light - Bottom Status 90% Tue 2016/04/05 05:41:35 PM System Log

88574 Scene:4Lvl / 4s Rec Room Track Lights On Tue 2016/04/05 05:41:35 PM Program Log

88575 4Lvl / 4d Rec Room Track Lights Status 90% Tue 2016/04/05 05:41:35 PM System Log

2. I do not see any entry for Laundry Light. So, please go back in the log and find the first occurrence right before 05:41:35 and let me know the status

3. I am not sure whether or not you intended this, but since you do not have 'And Control '4Lvl / 4d Stairway Motion-Sensor' is not switched Off', in essence the first statement will always be true after the first motion is sensed AND any of those lights are not off. Of course, the program will be evaluated every time the motion is sensed but after the first motion, any change to non-off in those lights causes the first part to become true

 

With kind regards,

Michel

 

Hi Michel,

 

Sorry, I didn't specify:  prior to the motion being sensed, the laundry light was ON, the rec room lights were OFF, and the stair light (both switches, top and bottom) were OFF.

 

The sensor is in a scene with the stair light (top and bottom), and set to send ON only, and thus no checks for sensor switched OFF.  Pretty standard.

 

So, the sensor saw motion, and turned the stair light (top and bottom switches) ON.  ISY saw the motion ON, and updated the status of both switches to ON (88572, 88573).  All as expected.

 

Since the laundry light was ON, and the rec room lights were OFF, the program ran THEN, and turned ON the rec room lights, also as expected (88574, 88575).  From this point on, any re-evaluation should result in FALSE, since the rec room lights are now ON.

 

But, since this is the only enabled program controlling that scene, do we assume that this program must have run THEN again, to account for lines 88576, 88577?  If so, what was the trigger?  Was it ISY updating the status of each switch from OFF to ON?  Or, was it multiple transmissions from the motion sensor?  (The motion sensor is NOT at this time indicating low battery.)

 

Additional datum:  looking back through the log, I do see the two additional program-generated scene ON lines whenever this exact situation occurred.  However, none of the prior ones ever resulted in an ALL ON event.

 

Al

[Algorithm]

Yes, you definitely have an echo situation in your program.

 

 

Any time I see conditions based on the status of a device being controlled by the same program it makes me squirm..

 

Usually this isn't a problem with a 'switched' trigger as an ANDed trigger since 'switched' triggers can never be true, as a condition, and cause an echo trigger.

 

In your program, you have your trigger ORed with other statuses, which can be true, eliminating the "usually" scenario, above, so your program, with the right statuses not off,  will always run twice in succession as fast as ISY can go and put them out. Ouch!

 

 

This sounds like a set up to test for ALL ON problems, based on what UDI has been telling people.

      "How to create Insteon signals in rapid succession 101"

 

Hi Larry,

 

Sorry, I don't quite follow.  Could you explain how the program will always run twice in succession?

 

Al

[larryllix]

Hi Larry,

 

Sorry, I don't quite follow.  Could you explain how the program will always run twice in succession?

 

Al

My apologies for that. I have stated incorrectly here.

 

I misread your program and confused the device in the "If" section. I believe I was confusing your stairs lights with the scene controlled devices and you used OR logic there causing a restrike. (in my mind)

 

 

Here is the usual check line some people like to use

If

      Originator is switched On

AND

      Status of Lamp is Off    <-------------

 

Then

     Set Lamp On

     Wait x seconds

     Never gets executed

Else

    ---

 

In this usual case when the lamp gets turned on, the condition line "Status of Lamp is Off" become false and runs the Else clause, as soon as the Wait is encountered, not the True clause again..

[Algorithm]

Hi Larry, no problem!  I rather thought that might be the type of situation you were envisioning, but couldn't see it in the program above   .

 

Al

[Michel Kohanim]

Hi Al,

 

 

Based on the given evidence, it's either a bug or some other program is turning that scene on multiple times.

 

With kind regards,

Michel

[Algorithm]

Hi Al,

 

 

Based on the given evidence, it's either a bug or some other program is turning that scene on multiple times.

 

With kind regards,

Michel

 

Hi Michel,

 

Okay, I did another search, with same results.  There is no other enabled program that contains that scene.  So do we conclude that it must be this program which is causing the multiple scene on commands?  Is there any way that ISY's processing could logically account for that?  Otherwise, perhaps it is a bug.

 

But... this doesn't seem to be related to the ALL ON event.  Would you concur?

 

Al

[LeeG]

Being Disabled does not eliminate a Program.  Many users, including my own environment, have disabled Programs performing tasks.   Being Disabled simply means a Program is not triggered by it's If clause.   Other Programs may execute both Then and Else clauses in a Disabled Program.

[Algorithm]

Being Disabled does not eliminate a Program.  Many users, including my own environment, have disabled Programs performing tasks.   Being Disabled simply means a Program is not triggered by it's If clause.   Other Programs may execute both Then and Else clauses in a Disabled Program.

 

Understood.  This particular disabled program is called only from a program triggered by a KPL button (its purpose is only to activate the scene when the button is pressed); it is not related to the events above.

[Jimbo.Automates]

I would say this does have something to do with your all on. All of mine have been caused by a motion sensor controlling a scene that has a KPL button as a member, and a program that modifies a scene that also includes the same KPL.

 

Sent from my Nexus 6P using Tapatalk

[larryllix]

I think LeeG's comment needs more explanation.

 

You stated "Okay, I did another search, with same results.  There is no other enabled program that contains that scene."

 

LeeG stated "  Other Programs may execute both Then and Else clauses in a Disabled Program."

 

Your statement may implies there may be more programs with line containing the scene in question.

[Algorithm]

I would say this does have something to do with your all on. All of mine have been caused by a motion sensor controlling a scene that has a KPL button as a member, and a program that modifies a scene that also includes the same KPL.

 

Sent from my Nexus 6P using Tapatalk

 

Hi Jim,

 

You are correct that the motion sensor may have been involved in this ALL ON event.  But what I was referring to, was the two extra scene on commands shown in the log, which we have been trying to determine the root cause of.  It is those which perhaps are not related to the ALL ON event.

 

Al

[Algorithm]

I think LeeG's comment needs more explanation.

 

You stated "Okay, I did another search, with same results.  There is no other enabled program that contains that scene."

 

LeeG stated "  Other Programs may execute both Then and Else clauses in a Disabled Program."

 

Your statement may implies there may be more programs with line containing the scene in question.

 

Hi Larry,

 

You are correct that my statement, which you quoted, does allow for more than one disabled program (though only the one enabled program) containing that scene.  I know it is hard to keep track of these things, but I indicated in post #198 of this thread that there was only one disabled program with that scene.  Since I was aware of having previously posted that fact, I was perhaps not as clear as I should have been in the post you referred to.  Sorry   .

 

Al

[Michel Kohanim]

LeeG, excellent point!

 

Hi Al,

 

Thank you. It might be a bug and we are trying to reproduce alas without success. Looking at the code, it pretty much looks like an impossibility (but maybe we have seen the code too much that we are numb to it).

 

We shall continue looking. In the meantime, can you please search any programs that call the disabled program?

 

With kind regards,

Michel

[larryllix]

Hi Larry,

 

You are correct that my statement, which you quoted, does allow for more than one disabled program (though only the one enabled program) containing that scene.  I know it is hard to keep track of these things, but I indicated in post #198 of this thread that there was only one disabled program with that scene.  Since I was aware of having previously posted that fact, I was perhaps not as clear as I should have been in the post you referred to.  Sorry   .

 

Al

I may have missed the mark as well as the point I was  trying to make, also.

 

 

LeeG stated "Other Programs may execute both Then and Else clauses in a Disabled Program."

 

IOW: With a  program, "being disabled" is not relevant factor in  the search for cause results. All occurrences of the scene usage need to be examined,  as well as all occurrences of programs that call those programs, even if disabled.

 

Also, Michel seems convinced you have another source of activating this scene, and since you have a better "test bench", to find the "ALL ON" ghost, you are exciting the crowd 

[Algorithm]

Hi Al,

 

Thank you. It might be a bug and we are trying to reproduce alas without success. Looking at the code, it pretty much looks like an impossibility (but maybe we have seen the code too much that we are numb to it).

 

We shall continue looking. In the meantime, can you please search any programs that call the disabled program?

 

With kind regards,

Michel

 

Hi Michel,

 

Already posted in #215 (also in #198):  the disabled program is called only from programs triggered by a KPL button press (I just searched again to confirm); i.e. it will run only when a physical action is taken.  I honestly believe this disabled program is a red herring*[1].

 

But, still curious as to your thoughts on the hypothesis in post #205.  Is it possible (whether a bug or not), that ISY's updating of the status of the two switches could each cause a separate re-evaluation, before ISY had updated the status of the rec room lights to ON, and therefore these separate evaluations would run THEN instead of ELSE?

 

Al

 

[1] Does anyone else like those kippered fish snacks (herring in a can)?  My favorites are the ones smothered in tomato sauce -- which is not to say that I like red herrings   !

[Algorithm]

Also, Michel seems convinced you have another source of activating this scene, and since you have a better "test bench", to find the "ALL ON" ghost, you are exciting the crowd 

 

Sorry to disappoint   !

 

To summarize:

 

My first ALL ON event (mentioned in post #190) seems to have had nothing to do with any battery-operated devices (motion sensors, etc.).

 

My second ALL ON event (the one under discussion) did seem to occur at the time of a motion sensor activation, which is nothing new to readers here.  But because a scene was programmatically turned on two additional times, much of the discussion has been as to what may have caused those additional activations.  It is not clear whether those activations played any part in the ALL ON event.

 

The only thing that was new (at least to me; I hadn't seen it mentioned before) was the reason that I posted (post #194) about my second ALL ON event in the first place:  lights that had been on at a lower percentage prior to the event, were now on at 100% after the event.  I wondered whether this might shed some additional light on these ALL ON events; i.e. are devices seeing a direct-on-to-100% command, or a fast-on command, or something else?

 

Al

[LeeG]

Unfortunately going to 100% is not new information.    Going back to an old RemoteLinc device, there is an All On button that turns On all the devices linked as Responders to any of the 6 RemoteLinc individual Scene buttons.   There is a unique Insteon Group Broadcast message that causes all the RemoteLinc responders to turn On in response to All On button.   No other Insteon device that I know of has an All On button.

 

However,  because of an overlap of Insteon traffic (assumption), the PLM can produce an All On Group Broadcast message.  Since all devices added to the ISY have a PLM responder link record,  all devices react to the special PLM Group Broadcast All On message.  Some devices may miss the message because of comm issues.  

 

This is all old/known information.

[Algorithm]

Unfortunately going to 100% is not new information.    Going back to an old RemoteLinc device, there is an All On button that turns On all the devices linked as Responders to any of the 6 RemoteLinc individual Scene buttons.   There is a unique Insteon Group Broadcast message that causes all the RemoteLinc responders to turn On in response to All On button.   No other Insteon device that I know of has an All On button.

 

However,  because of an overlap of Insteon traffic (assumption), the PLM can produce an All On Group Broadcast message.  Since all devices added to the ISY have a PLM responder link record,  all devices react to the special PLM Group Broadcast All On message.  Some devices may miss the message because of comm issues.  

 

This is all old/known information.

 

Hi Lee,

 

Thanks so much for the update!  Sorry the feedback wasn't helpful.  Like all of us, I'm anxious to see this problem resolved.

 

Al