Device state as condition, but not trigger for program

[beninsteon]

Hi,

Can anyone suggest how to use the state of a device as a condition for program execution, rather than as a condition and trigger, which is the default IoX behaviour.

I've managed this problem in the past by using integer variables to track device states, but this is overly complex. Wondering if there are other ways to achieve this.

Thanks.

[Techman]

Post a copy of the program in question

[Goose66]

This is solved by using two programs, the first enabled and executing the other, disabled program. This approach is discussed in many (many) places in these forums.

Edited March 18 by Goose66

[paulbates]

iox has 2 programming methods in the IF drop down:

• "Control" - which responds at the exact moment the device is activated locally
• "Status" - What is the devices state at any one point in time.

You want to use "Status"

[beninsteon]

54 minutes ago, Goose66 said:

This is solved by using two programs, the first enabled and executing the other, disabled program.

Thanks. Just to make sure I understand what you're suggesting, the disabled program will still run and conditions in the IF statement evaluated when called from another program (Run if), but since it's disabled ISY won't use those conditions as triggers?

[beninsteon]

41 minutes ago, paulbates said:

iox has 2 programming methods in the IF drop down:

• "Control" - which responds at the exact moment the device is activated locally
• "Status" - What is the devices state at any one point in time.

You want to use "Status"

This won't work - monitoring the status of an Ecobee thermostat. All I can use is Status, and this triggers the IF.

[IndyMike]

Similar to @Goose66's approach - you can create a "conditional folder" use the "status" of your Ecobee thermostat to enable it.  Place your trigger program in the conditional folder.

This will give you a visual of when the folder is enabled (Green - Enabled, Red - Disabled).  Running a disabled program will absolutely work, but I'm old and often forget that some programs SHOULD be disabled (it hurts my brain).

[Goose66]

1 hour ago, beninsteon said:

Thanks. Just to make sure I understand what you're suggesting, the disabled program will still run and conditions in the IF statement evaluated when called from another program (Run if), but since it's disabled ISY won't use those conditions as triggers?

Exactly. Also, it allows predictable use of Else branches. Else branches are problematic in regular programs because it's often not obvious what the set of trigger events is (the negative of the triggers implied by the specified conditions) that could cause the program's Else branch to execute. By using the two-program approach, you can define a explicit set of trigger events in the first program that allow the program to run, and have a testable set of state conditions in the second program to determine whether you want the Then branch or Else branch to execute.

There are several users in these forums that utilize the two-program approach for just about everything.

[Goose66]

The classic example:

If
        'Front Door Motion' is switched Motion
    And From    Sunset 
        To      Sunrise (next day)
 
Then
        Set 'Front Entry Light' On
        Wait  15 minutes 
        Set 'Front Entry Light' Off
 
Else
        - No Actions -
 

The clear intent of this program is that if there is motion at the front door at night, I want to turn on the front porch lights. However, what you will quickly find is that if motion occurs just a few minutes before sunrise, the light is turned on but never turned off, because the "To Sunrise (next day)" condition generates a trigger event that cancels the Wait and runs the Else branch. This can be mitigated by putting a "Set 'Front Entry Light' Off in the Else branch, but then you have the problem that, at Sunset, the front porch lights will be turned off even if you had just set them On, e.g., in anticipation of a pizza delivery.

While this example is somewhat benign, it does demonstrate the somewhat unpredictable and often unwanted effects of having every condition imply a trigger event. It is much more straightforward, IMHO, to just put conditions for trigger events in a first, enabled program, and conditions for, erh..., conditions in a second, disabled program, and have the first call the second. Programs created with this paradigm are self-documenting and straightforward. If you want events to happen at sunset and/or sunrise (e.g., clean up the outside lights), then just create separate programs for that.

Edited March 18 by Goose66