Set variable twice in THEN statement

[daxiang28]

Hi,

 

Just started to get into the fun programming of my new ISY99 and ran into a problem when setting a variable after a WAIT command. If I do it sequentially, the second setting works, but if i insert a WAIT, it never gets to it. Is this a bug? In general, I am looking for a good light/motion program to reset itself for a dining room.

 

If
       Elk Zone 'Dining Motion' is Violated
   And $Dining_Motion <= 1

Then
       $Dining_Motion  = 2
       Wait  4 seconds
       $Dining_Motion -= 1

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

 

Thanks,

Steve

[LeeG]

The variable is a State variable. When the Program changes the State variable value and then does the Wait the Program is triggered again because the State variable changed value. Because the variable value is no longer <= 1 the If is evaluated as False so the Else clause is run. The statement(s) after the Wait are never executed.

 

If the Program is meant to trigger only on the Zone violation then the variable should be an Integer rather than State. If the Program is meant to trigger both on a Zone violation and a State variable value change the Program should be split into two Programs. The current Then processing is moved to the second Program which has nothing in the IF section. When the State variable value is changed it will not affect the execution of the statements after the Wait. The first (current) Program invokes the second Program from the Then clause.

[daxiang28]

Thanks LeeG,

 

I have the Variable set as an Integer in the ISY program. Is this still considered state? When I run the program without the Wait in the Then statement, it correctly changes the value of the Integer.

 

If

Elk Zone 'Dining Motion' is Violated

And $Dining_Motion <= 1

 

Then

$Dining_Motion = 2

$Dining_Motion -= 1

[LeeG]

If the variable is an Integer the problem is the Zone is no longer violated before the Wait completes. Same situation in that the If conditions have changed before the Wait completes. The solution is to split the logic into two Programs as previously described.

 

As an FYI, both the Wait and Repeat functions allow the If to be reevaluated. A change in the If conditions being checked can prevent statements after the Wait from executing. The UDI Wiki has a good explanation of how Wait and Repeat statements operate. They both allow the If to be reevaluated. Without the Wait (or Repeat) the statements are considered atomic. Without a Wait or Repeat all the statements will execute even should the If conditions change before all the statements are executed. This aspect is also well described in the UDI Wiki.

[Goose66]

Also, don't forget to disable your second program, so that it will never be executed by the ISY outside of the call from the first program. This is not technically necessary for an integer variable, but is good practice when using other nested programs with IF statements that you don't want to also be program triggers.

[LeeG]

Good point. Thanks. If the second Program had conditions in the If section that complemented those is the first Program the second Program should not be marked Enabled so that the ISY cannot independently trigger the second Program based on any of its If condition. In this example it does not matter as the If in the second Program will be null so the ISY will never independently trigger Program two.

[apostolakisl]

Here it is in the least words possible.

 

During a "wait" or "repeat" the program will terminate and start over when anything in the "if" section triggers.

 

As pointed out above:

If your dining room motion status changes during the wait (all "status" conditions are triggers with ANY change in status, Elk zones included).

Since your variable is integer, it never triggers. .. so no prob. (State variables are the opposite. . .think "STATe and STATus)

[Goose66]

Because the IF statements in an ISY program embody both a decision as to which branch of the program to execute AND which events can trigger your program, you often must write programs in two levels. For example, consider your situation below:

 

Program 1 'On Dining Motion' (enabled):

If
       Elk Zone 'Dining Motion' is Violated
Then
       Run Program 'Handle Dining Motion'

Program 2 'Handle Dining Motion' (disabled):

If
       $Dining_Motion <= 1
Then
       $Dining_Motion = 2
       Wait 4 seconds
       $Dining_Motion -= 1

[daxiang28]

Thanks everyone for the info. The thing that got me stumped was that I didn't know that the Wait or Repeat commands reset the if statement. It's a bit different than what I'm used to with other web languages (js/php, etc).

 

Steve

[biredale]

We have all likely been burned on this at first.. Welcome to the club!

 

Thanks!

 

Brian

[apostolakisl]

It has been a hot topic many a time.

 

Personally I would like to see a check box next to each "if" condition that could be used to allow/disallow it as a program trigger. But I guess the frimware developers aren't keen on it since it would be a major re-write and there is a current work around (separating your if's into multiple programs) that works perfectly.

 

Elk rules only allow the first line to be a trigger. But that also requires multiple programs if you want multiple triggers.

[Goose66]

Sometimes the quirkiness of the ISY programming architecture has some perhaps surprising advantages. For example, consider the following program:

If
       From    Sunset 
       To      Sunrise (next day)
   And Control 'Outdoor / Driveway Motion-Sensor' is switched On

Then
       Set Scene 'Outdoor / Driveway Floods on Motion' On
       Wait  8 minutes 
       Set Scene 'Outdoor / Driveway Floods on Motion' Off

Else
       Set Scene 'Outdoor / Driveway Floods on Motion' Off

The first advantage is that as long as there is motion on the driveway, the program will continuously be restarted, and the flood light will stay on 8 minutes past the last detected motion. The second advantage is that if sunrise occurs while the floodlight is on, it will be turned immediately off, even if the 8 minutes hasn't expired. The disadvantage is that it will send OFF commands to the driveway flood throughout the day as driveway motion occurs -- needless Insteon traffic. The OFF in the else is necessary, however, because if you happen to be leaving the house just minutes before sunrise (something that occurs for several days for me two times a year), then your floodlight gets left on all day (the sunrise trigger preempts the WAIT before the OFF and goes to the Else branch).

 

But alas, the quirkiness is often just too complex to think through the various states. So you may just want to stick with the two level programming described above and avoid the use of Else branches, just to keep it simple until a more robust programming environment becomes available.