IF Statement clarification

[MarkJames]

Hi, all,

 

Before I get too far into my ISY programming I wanted to clarify something that was confusing with my last home automation controller (a JDS Stargate).

 

In the Stargate there was an IF statement and and IF (always) statement. The difference was with the IF statement

 

IF (condition is true)

...these statements would execute

...but only once

...and not again until the condition has changed to false first

 

this was useful for, say, a switch turning on. If you turned the switch ON, say a remote chime would ring. But now that it was on the chime would not continue to ring - however if you turned the swtich OFF and then ON again then the chime would ring again.

 

The second form - IF (always) meant that so long as the IF condition was true the statements would continue to execute.

 

In this format

 

IF (always) condition is true

...ring bell

...the bell would continue to ring until the condition was false

 

My first question is what is the ISY equivalent of these two functionalities.

 

Second - In reading the programming manual the ELSE statement is a bit confusing.

 

If time is 10pm AND button1 is on

... THEN

...... do this

... ELSE

...... do that

 

When and how many times will the else execute? Or will it only execute if it has managed to satisfy the IF at some point? Clearly the ELSE would just continue to run all the time that it's not 10 OR the button isn't on. That can't be what's intended?

 

So... my second question is basically when/how/how many times is the ELSE evaluated?

 

Third - what if there are NO conditions? The language allows these - when/how many times do the THEN statements execute?

 

Lastly.... Programs in a folder.....

Can one put a condition on a folder like say

Bed Folder (going to bed)

...if (bed mode button is pressed)

...THEN alllow programs in this folder to run

 

... prog1 in bed folder

... no ifs in this program

... then

... turn off all light

...

... progr2 in bed folder

... if temperature is below 65

... then turn on electric blanket

...

... prog3 in bed folder

... no conditions

... turn on security system

...

You get my gist - can there be a folder condition to cause a series of programs within the folder to run? Or is the folder condition merely to enable/disable the programs within the folder? (or is that reallly just the same thing?)

 

Thanks for the help... understanding this before getting too far will go a long ways towards getting it right the first time

 

Mark

[oberkc]

I am not sure I can respond to everything you ask, but I can try a couple of points:

 

My first question is what is the ISY equivalent of these two functionalities

 

I believe the answer lies in "control" versus "status". From a time standpoint, you can choose a specific time (when time = XX:XX) or range (from XX:XX to XX:XX). A control represents a one event (device sends an on signal). Status represent the fact that a device is on, for as long as it is on.

 

Knowing this, most commands that I can think of to perform in response to these conditions are one time commands (turn on, turn off, dim, bright). I am not sure how one would run a program indefinitely, based on the if statement.

 

So... my second question is basically when/how/how many times is the ELSE evaluated?

 

Else is never evaluated. Only the "if" statement is evaluated. The program statments will run one time when the "if"condition is true. However, if the "if" statement remains true, and somebody comes along and trys to create a condition contrary to the else statement, then the else statement will run again. For example, if the else statement tells switch A to turn on, and somebody comes along and turns it off later, then the program will immediately turn it back on. I hope I am making sense here.

 

Third - what if there are NO conditions? The language allows these - when/how many times do the THEN statements execute?

 

"Then" and "Else" conditions can be called from other programs. The syntax looks like:

 

Run Program "program name" (then path)

[Sub-Routine]

Hello Mark,

 

In ISY programming when any of the conditions change the program is evaluated. If the conditions are all true then the program is considered True and the Then Actions are executed, once. If one or more of the conditions are not met the program is considered False and the Actions in the Else section are executed, again, once.

 

If there are no Conditions the program will only execute when called from another program.

 

Folder conditions effectively enable/disable programs but do not automatically cause programs to run. Programs can use the condition of a folder though.

 

Hopefully this section of the Wiki can help: ISY-99i/ISY-26_INSTEON:How-To_Guide#Programs

 

Rand

[MarkJames]

Hello Mark,

 

In ISY programming when any of the conditions change the program is evaluated. If the conditions are all true then the program is considered True and the Then Actions are executed, once. If one or more of the conditions are not met the program is considered False and the Actions in the Else section are executed, again, once.

 

Ahhh.. OK... that makes sense then... I was trying to understand it in light of a program I saw where the IF was executing and when the condition was no longer true the ELSE executed. I didn't understand why that would happen as in general a program would evaluate the condition and then execute the THEN or the ELSE - not both but in ISY it seems that the THEN can be executed and if the condition changes the ELSE will execute as well. A bit confoozalating.

 

So... if I were to want an IF to continuously evaluate and continuously execute until the condition is FALSE then I could simply change part of the condition from within the THEN portion forcing the iSY to reevaluate the condition? Or is there a more direct approach?

 

And thanks for both the link and clearing up the folder issue.

[markens]

I was trying to understand it in light of a program I saw where the IF was executing and when the condition was no longer true the ELSE executed. I didn't understand why that would happen as in general a program would evaluate the condition and then execute the THEN or the ELSE - not both but in ISY it seems that the THEN can be executed and if the condition changes the ELSE will execute as well. A bit confoozalating.

Maybe this will help clarify: Rand said "when any of the conditions change the program is evaluated" -- which means that the IF clause containing those conditions will be evaluated, and either the THEN or ELSE is executed based on the result. The not-so-obvious side effect is that this evaluation happens even if the program is currently already running (either THEN or ELSE) when any of the IF conditions change state. So the observed behavior is that the program stops, reevaluates the IF, and then could run the ELSE instead as you have seen.

 

Note that the IF is not actually continuously evaluated (which implies continuous IF->THEN/ELSE->IF->THEN/ELSE->IF->etc execution). It is only evaluated when any of the conditions in it change state. For example: a switch status going from ON to OFF, a switch control event received (which is always a new event, regardless of current switch status), arriving at a specified time, etc. A subtle semantic distinction, but it will help understand the behavior.

 

So... if I were to want an IF to continuously evaluate and continuously execute until the condition is FALSE then I could simply change part of the condition from within the THEN portion forcing the iSY to reevaluate the condition? Or is there a more direct approach?

Look at it this way: The conditions in the IF will always be reevaluated when any one of them changes, and then the THEN or ELSE will run once until it's done. If the execution part is long lasting (with repeats or waits, for example, perhaps indefinitely), then it will be interrupted as described above when one of the conditions changes, forcing reevaluation and starting the process over again. It is perfectly acceptable for a program action to actually cause that to happen, which I think is what you are suggesting.

[TJF1960]

So... if I were to want an IF to continuously evaluate and continuously execute until the condition is FALSE then I could simply change part of the condition from within the THEN portion forcing the iSY to reevaluate the condition? Or is there a more direct approach?

If you want the program to continuously run until false you can add "Run If" in the "Then" section.

 

Prgm: Entry Lite Status

If
       Status  'Entry KPL 1 Lite' is On

Then
       Set 'Entry KPL 1 Lite' Off
       Run Program 'Entry Lite Status' (If)

Else
  - No Actions - (To add one, press 'Action')

This prgm example will keep trying to turn off the entry kpl 1 lite until the status of the lite changes to off.

 

Tim

[MarkJames]

Thanks, guys, I understand what you're saying.

 

I was worried to continuously re-run the program from within itself as I was afraid I might run into some stack overflow issues if the program continuously recursed. Sounds like that's not a problem.

 

Much thanks!

 

Mark

[Sub-Routine]

Personally, I would use a Repeat Every 1 second rather than Run Program.

 

It just seems more structured to me.

[MarkJames]

Personally, I would use a Repeat Every 1 second rather than Run Program.

 

It just seems more structured to me.

 

Yes - but repeating every second without nested if-then would be an endless loop. It would never reevaluate the IF condition

[markens]

Yes - but repeating every second without nested if-then would be an endless loop. It would never reevaluate the IF condition

But it will reevaluate the IF. Here are some principles, restated:

 

1. The conditions in an IF part of an enabled program are always evaluated when any of those conditions change (creating an event), regardless of whether the program is idle or executing THEN or ELSE parts.

 

2. If the program is running when this happens, then that instance of the program is immediately terminated before the conditions are reevaluated.

 

3. Whenever the IF conditions are evaluated, either the THEN or ELSE then executes based on the TRUE/FALSE result of the evaluation.

 

--Mark

[MarkJames]

2. If the program is running when this happens, then that instance of the program is immediately terminated before the conditions are reevaluated.

 

THAT is the part I was missing.

 

I assumed each instance was allowed to run to its conclusion.

 

OK... that opens up quite a bit of flexibility.

 

Thanks,

 

mark

[MarkJames]

Actually that just made me realize why something I was doing wasn't working.

 

I was using a photobeam connected to an iolinc to turn on a bunch of lights approaching my house. The code basically said

 

If photobeam status ON

set scene pathlights ON

wait 10 minutes

set scene pathlights OFF

 

This would turn them ON but never turn them off. I see now why - when the sensor beam broke it turned the sensor ON which turned the scene on - but when the beam restored the conditions changed and were reevaluated. That terminated the program so the wait 10 minutes was never completing. I guess the right way would be to put the WAIT and the scene off in the ELSE portion

 

Interesting... I'm gonna hafta be careful of this, I see.

 

Thanks for the time you spent explaining it - this will save much hairpulling.

[markens]

This would turn them ON but never turn them off. I see now why - when the sensor beam broke it turned the sensor ON which turned the scene on - but when the beam restored the conditions changed and were reevaluated. That terminated the program so the wait 10 minutes was never completing.

Yes, this almost certainly is what's happening. The Program Summary tab is useful to monitor. The Activity column shows if a program is executing or not, and you can easily see if a long wait has terminated prematurely. Tools->Diagnostics->EventViewer is also handy to monitor control and status events (see below).

 

I guess the right way would be to put the WAIT and the scene off in the ELSE portion

That would probably do what you want, depending on what other controls might be influencing things.

 

This is a good time to point out the difference between Control and Status events. So far, it seems you've been using Status. Control might be more what you're looking for.

 

The ISY maintains its idea of what the status of each device is. A Status condition monitors this latched status. A Status event happens only when the ISY's idea of that status changes, and is independent of what caused the status to change (switch event, ISY scene, etc).

 

A Control condition, on the other hand, looks for an event caused by a physical operation of a switch or sensor (ON/OFF/DIM/etc event) and is received (and evaluated) regardless of the current status of the device.

 

So, your example program will work as you expected if you change Status to Control:

 

If photobeam control ON

Then

set scene pathlights ON

wait 10 minutes

set scene pathlights OFF

 

This program does not check for photobeam control OFF (a different event than control ON). So when that happens (and its status also goes off), this program does not see an event and happily continues waiting until the 10 minutes is up. If it happens to turn back on during that time, then another event will be received: the wait will terminate, the condition will evaluate (true), and the THEN will start again, effectively resetting the timer to 10 minutes.

 

Note that, as written, there is no way that the IF of this program can ever evaluate to FALSE, and so the ELSE of this program will never execute via evaluation of the IF. This is why you often see the following very useful construct in programs:

 

If someswitch control ON

and someswitch control not OFF

Then

do something when switch turns on

Else

do something else when switch turns off

 

--Mark