What actions change control & status, and scenes affect?

[ellesshoo]

I thought I was finally over the "hump" in fully understanding this but it turns out that's not the case. I think my issue is understanding how various actions trigger or don't trigger control and status. These are my questions:

 

1) Which of the following will trigger an "if switched" condition to trigger?

a) physically pressing a switchlinc or load button on a KPL?

physically pressing a non-load button on a KPL?

c) a program turning the light on or off

d) a program turning a scene on which the light is a member of

e) a linked sensor or KPL button turning the light on via a scene which both are members of

 

2) Which of the above scenarios will trigger an "if status" condition to evaluate?

 

3) How is fade up/fade down interpreted? If one program fades down a light will another program with "if status not on" trigger during the fade? Does the status get set to "on" or "off" after the fade is complete?

 

 

4) If a scene containing both switches of a 3-way circuit is turned on by a program do both switch nodes also get set to on?

 

5) If a switch in the above scene is physically switched off does the scene and both switches get set to off?

 

6) If a program "then" causes it's own "if" to be "false" does it complete the "then" followed by the "else" or does it terminate the "then" and immediately run the "else"?

 

I'm sorry to ask some questions which I'm sure are answered in various places but I can't seem to figure out some of these as I've specifically worded it or some of the things I've read were from much earlier firmware revisions that I'm not sure whether they are accurate currently. I'm sure I'll have a couple of follow-up questions so I would definitely appreciate sticking with me in this thread for a little bit. Thanks!

[apostolakisl]

This post of mine regarding a different but similar question should help.

 

Two concepts:

 

1) Triggers

2) True vs False after the trigger

 

1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers.

- - Control: Triggers whenever the action listed is physically taken on that switch. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger). (Note: with motion detectors, the act of "physically pushing" is actually the act of presenting motion to it.

- - Status: Triggers with a change in status regardless of what caused the change. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger.

- - State variables: Trigger on any change in the variable's value.

- - From:To times: Both the from and the to time itself is a trigger.

- - An outside program or manual "run if" is a trigger

 

2) Once a trigger event occurs, then EVERY line is evaluated.

- - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not".

- - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true.

- - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered.

- - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise. (NOTE: if the to time is before the from time, the program will not be a trigger. Like if you say sunrise to 7am, and sunrise at that time of year is after 7am, then neither the from nor to are triggers, and if something else triggers it, it will be false)

 

Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on.

 

Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true

Multiple lines connected by "AND" statements will be false unless all lines are true.

Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

[ellesshoo]

This post of mine regarding a different but similar question should help.

 

Two concepts:

 

1) Triggers

2) True vs False after the trigger

 

1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers.

- - Control: Triggers whenever the action listed is physically taken on that switch. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger). (Note: with motion detectors, the act of "physically pushing" is actually the act of presenting motion to it.

- - Status: Triggers with a change in status regardless of what caused the change. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger.

- - State variables: Trigger on any change in the variable's value.

- - From:To times: Both the from and the to time itself is a trigger.

- - An outside program or manual "run if" is a trigger

 

2) Once a trigger event occurs, then EVERY line is evaluated.

- - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not".

- - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true.

- - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered.

- - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise.

 

If this is true. Why does the code in the UDI Wiki Bathroom Light Motion Sensor example contain this?

 

If
       Control 'Main Bath Motion.1-Sensor' is switched On
   And Control 'Main Bath Motion.1-Sensor' is not switched Off

Then
       Set 'Main Bath Lights' On

Else
       Set 'Main Bath Lights' Off

 

Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on.

 

Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true

Multiple lines connected by "AND" statements will be false unless all lines are true.

Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

 

Also, if a program makes a scene or node "fade up" does that make the scene/node "on" after the fade is complete?

[ellesshoo]

This post of mine regarding a different but similar question should help.

 

Two concepts:

 

1) Triggers

2) True vs False after the trigger

 

1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers.

- - Control: Triggers whenever the action listed is physically taken on that switch. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger). (Note: with motion detectors, the act of "physically pushing" is actually the act of presenting motion to it.

- - Status: Triggers with a change in status regardless of what caused the change. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger.

- - State variables: Trigger on any change in the variable's value.

- - From:To times: Both the from and the to time itself is a trigger.

- - An outside program or manual "run if" is a trigger

 

2) Once a trigger event occurs, then EVERY line is evaluated.

- - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not".

- - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true.

- - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered.

- - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise. (NOTE: if the to time is before the from time, the program will not be a trigger. Like if you say sunrise to 7am, and sunrise at that time of year is after 7am, then neither the from nor to are triggers, and if something else triggers it, it will be false)

 

Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on.

 

Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true

Multiple lines connected by "AND" statements will be false unless all lines are true.

Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

 

Also, am I understanding correctly that if I were to hit the first floor switch for a stair case light that's in a 3-way circuit that a "control 2nd floor stair-case light switched on" would not trigger even though the switches are linked in a scene (both as controllers)? Would the status of the 2nd floor switch even change in this scenario?

[Xathros]

Also, am I understanding correctly that if I were to hit the first floor switch for a stair case light that's in a 3-way circuit that a "control 2nd floor stair-case light switched on" would not trigger even though the switches are linked in a scene (both as controllers)? Would the status of the 2nd floor switch even change in this scenario?

 

3 triggers are possible in this scenario:

 

1) Control FirstFloorSwitch is Switched On

2) Status FirstFloorSwitch is xx (Assuming it was not on previously)

3) Status SecondFloorSwitch is xx (Assuming it was not on previously)

 

-Xathros

[oberkc]

Also, if a program makes a scene or node "fade up" does that make the scene/node "on" after the fade is complete?

 

Not necessarily. "ON" generally means 100%. Compare "ON" to "NOT OFF". Compare that still to other options, such as "NOT ON" and "OFF".

 

In general, "NOT OFF" means anything over zero. "NOT ON" means anything under 100 percent. "OFF" means zero. "ON" means full on, or 100%.

 

Also, am I understanding correctly that if I were to hit the first floor switch for a stair case light that's in a 3-way circuit that a "control 2nd floor stair-case light switched on" would not trigger even though the switches are linked in a scene (both as controllers)? Would the status of the 2nd floor switch even change in this scenario?

 

You understand correctly. A switch (or other insteon device) will trigger a program only when activated directly. When changing in response to a linked device (controller), an insteon device will NOT trigger a program. Despite this, I believe that if you look at the status of the linked (2nd floor switch, in your case), you WILL see an accurate status.

 

Still, I am uncertain if this rule is true only for "control" and may not apply to "status" (as suggested by Xathros). Perhaps a program would trigger if based on "status", even if the affected device changed status based on being a responder in a scene. This should be easily verified by a couple of experiments.

[LeeG]

ellesshoo

 

The "If Control 'xxxxx' is switched On" is looking at Insteon commands coming "from" device xxxxx and only looking at Insteon commands coming "from" device xxxxx. That means the paddle/button on xxxxx is pressed to generate an On command. A question related to any subject/scenario other than physical device xxxxx sending an On command, it does not trigger the Program. Does not matter whether xxxxx is turned On by a Program, turned On by a Scene, turned On by the phantom, if not turned On by the physical device itself so device xxxxx sends an On command the If Control does NOT trigger a Program. It is that simple for If Control.

 

“If Status ‘xxxxx’ is ???†triggers a Program any time ‘xxxxx’ changes Status. Does not matter why Status changes. Could be the device Status changed by pressing its button/paddle, its Status changed by a Program statement, changed by a Scene, changed by the phantom, so long as the device Status changes the Program is triggered. Once triggered the If clause is evaluated for True or False. When the If evaluates to True the Then clause runs, when it evaluates to False the Else clause runs. Does the scenario/question result in ‘xxxxx’ changing Status? If so the Program triggers, if not the Program does not trigger.

 

Every scenario, every question can be resolved by applying it to the above. It is fine to sanity check ones understanding of the above with individual questions.

 

I apologize if much/all of this has already been covered in the various posts thus far. Happy to add clarification or answer a specific question to sanity check the above.

[oberkc]

Could be the device Status changed by pressing its button/paddle, its Status changed by a Program statement, changed by a Scene, changed by the phantom, so long as the device Status changes the Program is triggered.

 

ellesshoo, my earlier post expressing uncertainty about whether programs based on "status" would be triggered by anything but a direct paddle press was, apparently well founded. Xathros was, indeed, correct. While I was pretty certain that program conditions based upon "control" would be triggered only by direct paddle/switch press, programs conditions based upon "status" will be triggered by change of status regardless of how/why achieved.

 

I apologize for my confusion.

[ellesshoo]

Could be the device Status changed by pressing its button/paddle, its Status changed by a Program statement, changed by a Scene, changed by the phantom, so long as the device Status changes the Program is triggered.

 

ellesshoo, my earlier post expressing uncertainty about whether programs based on "status" would be triggered by anything but a direct paddle press was, apparently well founded. Xathros was, indeed, correct. While I was pretty certain that program conditions based upon "control" would be triggered only by direct paddle/switch press, programs conditions based upon "status" will be triggered by change of status regardless of how/why achieved.

 

I apologize for my confusion.

 

 

Awesome, thank you to everyone that has helped. From reading all the responses and implementing these concepts when I got home from work, I think I finally bullet-proofed the programs that I've been working on. Prior to today I thought I had everything perfect but over the course of a couple of days of real world living I would find bugs in my code... even worse, my wife stumbled upon some bugs, nothing like the lights shutting off while she's taking a shower .

 

I still feel I have a lot to learn w/ regard to scenes/KPL stuff but for now things are good. If there's one lesson I've learned that I would pass along to anyone else that's new to the ISY is to take it slow, start simple and build complexity (if at all) slowly, don't attempt to have your house do every little thing for you from day one. I have a good handle on computer logic and that wasn't enough to hop right into ISY & Insteon... it's definitely a little different.