Any good guides on the use of "control" vs "status" in progr

[ellesshoo]

The logic used for programs is very different than what I'm used to and one of the things I don't quite understand is how these two conditions differ in order to implement each in the appropriate situation. Can someone try to explain this to me or point me somewhere that this has already been explained?

[LeeG]

The UDI Wiki has some good information on Status versus Control.

 

To summarize, If Control is looking at specific commands the device is sending to the ISY/PLM. The Program is triggered (runs) whenever the command being checked for is received by the ISY/PLM.

 

If Status is looking at the state of the device the ISY tracks for each node. The Program is triggered (runs) whenever the device/node Status/state changes.

 

In both cases when the If checks evaluate to True the Then clause is executed. When the If checks evaluate to False the Else clause executes.

[ellesshoo]

The UDI Wiki has some good information on Status versus Control.

 

To summarize, If Control is looking at specific commands the device is sending to the ISY/PLM. The Program is triggered (runs) whenever the command being checked for is received by the ISY/PLM.

 

If Status is looking at the state of the device the ISY tracks for each node. The Program is triggered (runs) whenever the device/node Status/state changes.

 

In both cases when the If checks evaluate to True the Then clause is executed. When the If checks evaluate to False the Else clause executes.

So a program like:

 

If: status - light x - is On

Then: set variable A = 1

Else: set light Z Off

 

Would run Else at all times when light x is off or only AFTER light x were turned on, thus satisfying the IF of the program, and then the else runs when light x turns off sort of like "exiting" the program? Also, how would using Control change the behavior?

[LeeG]

The Status of light X has to change for the Program to be triggered. The Status could change from On to Off, from Off to On, from Off to 50% On if a dimmer, from 50% On to 80% On, and so on. Light X could change Status as a result of pressing the light X paddle (assuming it has a paddle). It could change Status by being controlled by another device. Whenever the ISY detects a change in Status the Program is triggered.

 

When the Program is triggered the If clause executes, checking the Status against how the If is coded. The Then clause runs only when the Status changes to On. Any other change in Status, such as to Off, to 50% On Level, causes the Else clause to run.

 

An If Control 'light X' is switched On triggers the Program only when light X is turned On by its paddle/button. This is the only time light X sends an On command. If light X is turned On by another device the Program is not triggered because the device was not turned On by its paddle/button press.

 

Once triggered the Then clause runs as that is the only If result possible in this simple example. The Program only triggers with an On command and the If is checking for On.

 

If clauses can be complex, with combinations of If Control Anded/Ored with combinations of If Status. Also tests of Variable values can be done and testing ELK conditions.

[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 taken. 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)

- - Status: Triggers with a change in status. 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.

 

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.