Programming: What can trigger a program and what cant?

[gduprey]

Howdy,

 

I've been using several ISYs for a few years, but there are a few conditions and situations where I've never gotten a good handle on.  One of them is what can be used to "trigger" a program to run and what wont.

 

Previous (referenced in a thread from 2 weeks ago), I had it in my head that IF statements that checked a Status of a device (vs Control statements) would not be triggered when that status changed (that only Control statements allowed for an enabled program to be triggered and Status statements were for conditional evaluation only).  Based on responses and to my surprise, that turned out to be bunk and Status checks worked fine in an IF to cause a program top run/trigger.

 

I know that at least with variables, the big difference between regular variable and state variables is changes in a regular variable won't trigger a programs IF where changes in a State variable can.

 

So to get final clarity on the topic, are there any other items that you can include in a programs IF statement that will not result in it being triggered (i.e. regular variables)?  Or is it "beware of variables for triggering" and everything else you can reference in an IF is capable of triggering the IF to evaluate/execute?

 

And in a similar vein, are there things that if evaluated (i.e. something else does a "Run (If)" vs an event the ISY processes) won't work except as a trigger?  I'm wondering about Control type events -- those strike me as strictly "something happens for that instant of time" and subsequent evaluation of a If with a Control in it will fail because the event has passed)

 

Gerry

Edited February 21, 2017 by gduprey

[Michel Kohanim]

Hi Gerry,

 

With regards to:

 

 

Previous (referenced in a thread from 2 weeks ago), I had it in my head that IF statements that checked a Status of a device (vs Control statements) would not be triggered when that status changed

 

It should read:

IF statements that checked a Status of a device (vs Control statements) would be triggered when that status changed. It would not be triggered if the status does not change. i.e. if a device is ON and you turn it ON again, the program will not be evaluated (because the status didn't change). For Control, every physical action to that device causes the program to be evaluated. i.e. If the device is on and you go to the switch and press the on button again, the associated program will be evaluated/run.

 

 

Run If, uses the last state of the program. If the state is true, it will run (then). If false, it will run (else).

 

With kind regards,

Michel

[gduprey]

So there are no other items you can include an in IF statement that will NOT trigger the program if they change?  Only non-state variables?

Also:

Run If, uses the last state of the program. If the state is true, it will run (then). If false, it will run (else).

So if I use Run (If) from another program, it does NOT evaluate the target program, it just uses the last known state for it?

If true, does that means that the ISY is effectively evaluating all programs pretty much constantly so the last true/false state of a program is always "current"?

Thanks,

Gerry

[Michel Kohanim]

Hi Gerry,

 

Don't know what 'evaluating' means in your vernacular. It will NOT go query devices and see whether or not the states are true. It does evaluate the conditions based on the values that have already been evaluated based on previous events.

 

No to the latter. ISY evaluates programs IF AND ONLY IF something happened to a condition on which a program depended.

 

With kind regards,

Michel

[gduprey]

By evaluating, I mean the ISY looking over the programs IF statement and deciding to execute it or not.  I totall understand that the ISY will not reach out to devices and query them as part of an IF statement.

 

As for the later, the statement:  

ISY evaluates programs IF AND ONLY IF something happened to a condition on which a program depended

 

1) Except for non-state variables (i.e. if they are part of an IF and change, they do not trigger the "IF AND ONLY IF something happened"), right?

2) If this is the case and if a "Run Program (If)" only looks at the result of the last execution (i.e. last time something changed), what happens if something (like a non-state variable) did change and was part of a programs If?  The Run Program (If) will not evaluate the logic in the IF statement and depend on the 'last result'?

I can see this mostly working unless you use a non-state variable in an IF statement (excepting that the ISY will not trigger a program because of it, but Running a program from another program might).

Consider if I have program that is not enabled (I only want to Run it, not have it respond to things), and has logic like
 

New Program - [ID 0013][Parent 0001]
If
        $Occupied is 0
Then
        Set 'Office Overhead Lights' On
Else
   - No Actions - (To add one, press 'Action')

and assume that the $Occupied is a non-state variable.  If another program changes the variable value to 0 and then Runs the above program, the program will NOT re-evaluate the If condition (because you said it relies on the last true/false result and this program is both not enabled and using a non-state variable)?

Gerry

 

[oberkc]

Gerry,

 

If there are conditions besides an integer variable that do not act as program triggers, I am having trouble remembering what they would be. The bigger issue is understanding when (not if) a specific condition would trigger a program. For example, a "control-on" condition acts as a trigger only when that particluar device is acted upon locally, and only when triggered on (regardless of current state).

Of course you could completely disable a program is you do not wish it to self trigger.

[stusviews]

Devices:

Control will trigger a program each time the condition is met (usually requiring a manual action). For example, if On is the condition, then the program will trigger each and every time the device sends an On.

Status will trigger a program each time the condition is changed to the desired state. For example, if On is the condition, then the program will trigger only if the device state changes from something else to On.

 

Variables:

Integer will never trigger a program.

State will trigger a program at the whenever the variable is set to the specified value.

[gduprey]

Okey doke -- details seem to be coming along well.

 

Given all the discussion of when a program is triggered, when is the Else section triggered?  For example, if you have a IF condition on a state variable (like $myState is 1), is the "else" section run constantly or only when the variable value changes but wasn't the value specified?

How about in control conditions? What would be the "else" case for an "If Control 'Overhead Lights' is Switched On'? 

I could imagine it *might* be -- "if anything associated with the If statement changes but does not meet the conditions of  the If statement, the Else statement runs". 

 

Gerry

[oberkc]

Once a program is triggered, the entire condition is evaluated. Theat evaluation will return either TRUE or FALSE. Based upon the evaluation, THEN (true) or ELSE (false) will run.

 

In some cases, yes, it is possible that one path could never run. It all depends on the entire condition.

[gduprey]

Which is sort of what I thought.  A "IF" condition is really two things -- a list of "triggerable" (things to look for changes in) and an expression.  Once any triggerable item in the If statements causes the program to be triggered, then the condition is evaluated and if true, Then is run and if false, Else is run.

 

Gerry

[oberkc]

Which is sort of what I thought.  A "IF" condition is really two things -- a list of "triggerable" (things to look for changes in) and an expression.  Once any triggerable item in the If statements causes the program to be triggered, then the condition is evaluated and if true, Then is run and if false, Else is run.

 

Gerry

that sounds about right to me.

 

And, ues, some programs will always be true (if control xxx is switched on) when self-triggered.  Some will always be false (if control xxx is not switched on).  Some can be either (if control xxx is switched on and time is from sunrise to sunset). 

[stusviews]

If Control is a trigger, then Else will not run if the trigger changes. That's because there's no statement defining what to do in the event of a different condition. There is a workaround if desired. Add the negation of the opposite state. For example:

 

If
        Control 'device' is switched On
 

will not run Else if the device is switched Off, but

If
        Control 'device' is switched On
    And Control 'devicel' is not switched Off

 

will run Else if the device is switched Off

Edited February 21, 2017 by stusviews

[apostolakisl]

If Control is a trigger, then Else will not run if the trigger changes. That's because there's no statement defining what to do in the event of a different condition. There is a workaround if desired. Add the negation of the opposite state. For example:

 

If

        Control 'device' is switched On

 

will not run Else if the device is switched Off, but

 

If

        Control 'device' is switched On

    And Control 'devicel' is not switched Off

 

will run Else if the device is switched Off

 

Exactly.

 

Just remember

"Control is . . ." statements are only triggers on the exact thing listed.  Nothing Else

 

The "control is not. . ." language is easy to remember as just the same as "control is. .." but opposite result (its a double negative)

 

Also Remember

if you have multiple triggers for a program (either other if statements or an external trigger), "control is" will ALWAYS be false whenever one of the other triggers activates.  Similarly, "control is not" will always be true.  Control statements are confined to the precise instant of the control event (someone pushes a switch).

 

So breaking down the logic for an on press on the above example.

 

IF

Control device x is switched on  - - - true, the on paddle was pressed

And

Control device x is not switched off  - - - true, "off" event never happened (false), but this is opposite, so its true.

 

Result - Then runs

 

 

Now for an off press

 

IF

Control device x is switched on  - - - false, the on paddle was never pressed

And

Control device x is not switched off  - - - false, "off" event happened (true), but opposite, so its false.

 

Result - - Else runs

Edited February 21, 2017 by apostolakisl

[JWBDolphins]

Excellent thread!  Stusview's Post #12 finally snapped in my head!

 

I've been wondering for way too long why so many examples have the added condition "And Control 'devicel' is not switched Off" added to them, to the point that I've been adding it to my programs "just because".  There are a lot of posts that touch on this, but that post Finally explicitly makes sense to me - thank you!  

 

And I should add, apostolakisl's post (#13) containing the previous post and an excellent explanation would be something I would consider making sticky as far as "how to program the ISY".  I've bookmarked this discussion.  Maybe I'm just dense, but up until now I never really got it.

Edited February 25, 2017 by JWBDolphins

[JWBDolphins]

Maybe stating it this way might be useful - this is what was confusing me.

For this type of program:

 

IF

Control device x is switched on

And

Control device x is not switched off

 

The Switched On made perfect sense to me, and the Not Switched Off I took literally.

I thought a Fade Up would mean the "Switched On" would fail while the "Not Switched Off" (because it was a Fade Up) would succeed.  The combination AND'd would fail, so the Else path would run.

But that's not what it does - a "Fade Up" would never cause this program to run in the first place - That's the part I was missing.

The Only Control messages being looked for to trigger this program are "On" and "Off", and then the "is" and "is not" are evaluated as part of the IF.

 

As apostolakisl said:

 

 

Just remember

"Control is . . ." statements are only triggers on the exact thing listed.  Nothing Else

 

 

[apostolakisl]

 

Maybe stating it this way might be useful - this is what was confusing me.

For this type of program:

 

IF

Control device x is switched on

And

Control device x is not switched off

 

The Switched On made perfect sense to me, and the Not Switched Off I took literally.

I thought a Fade Up would mean the "Switched On" would fail while the "Not Switched Off" (because it was a Fade Up) would succeed.  The combination AND'd would fail, so the Else path would run.

But that's not what it does - a "Fade Up" would never cause this program to run in the first place - That's the part I was missing.

The Only Control messages being looked for to trigger this program are "On" and "Off", and then the "is" and "is not" are evaluated as part of the IF.

 

As apostolakisl said:

 

 

 

 

 

Think of it this way.

 

The whole purpose of the 

 

"And control device x is not switched off"

 

is to include pressing the off paddle as a trigger to the program.  Otherwise, the only trigger would be a press of the on paddle.  You might include other control statements if applicable, like fade.

 

Also, keep in mind, that "control" statements ALWAYS refer to an action taken locally AT THAT SWITCH.  A switch that turns on as a result of responding to a remote command (scene) was not "control switched" anything.

 

Here is another possible example where pressing "on" or "fade up" is true, and pressing "off" or "fade down" is false.

 

IF

 

(

   Control device x is switched on

   or

   Control device x is switched fade up

)

And

(

    Control device x is not switched off

    or

    Control device x is not switched fade down

 )

[JWBDolphins]

That makes perfect sense - Thank You!  Once it <Clicked> in my head, it clicked.  It just took way too long to click than I want to admit!  

[stusviews]

Consider a truth table for the following statement:

 

If the sun shines, then I'll take a walk.

 

The sun shines and do I take a walk.

The statement is True.

The sun shines and I don't take a walk.

The statement is False.

 

The sun doesn't shine and I do take a walk.

The statement is True.

The sun doesn't shines and I don't take a walk.

The statement is True.

 

The latter two actions are true because the statement referred only to what should occur if the sun does shine. There's no mention of what to do if the sun doesn't shine.

[jgcharlotte]

Ok, what about a program that turns something on via status, and it is behind a folder to limit time of day.

Specifically, I have a space heater controlled by a wireless thermostat, but I only want it to run between 10 pm and sunrise, as specified in folder conditions.

It works great unless the thermostat is already calling for heat at 10 pm when the folder is enabled.  The status does not get read and the heater does not turn on.

Thanks guys, great thread!

 

This does not work if the thermostat is already calling for heat (status ON) when the folder is enabled at 10 pm.

 

Space Heater Auto ON - [iD 00D7][Parent 00D6]

 

If

        Status  '_MBR-Thermostat Heating' is On

 

Then

        Set 'MASTER-Space Heater' On

 

Else

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

Edited March 5, 2017 by jgcharlotte

[oberkc]

Being in a folder causes, basically, the program to be enabled or disabled, based upon the folder conditions.  In your case, the program is essentially enabled at 10pm and disabled at sunrise.  Only once enabled will the conditions trigger an evaluation and response. 

 

With "status" conditions, only a change of status would trigger an evaluation.  So, at between 10 and sunrise, the program is looking for change in status as a trigger.  If the status does not change after 10:00, it will never get triggered.

[stusviews]

Try:

 

If
        Status  '_MBR-Thermostat Heating' is Calling for Heat

[jgcharlotte]

Try:

 

If

        Status  '_MBR-Thermostat Heating' is Calling for Heat

 

Lost me on that one I have 'on', 'off,' and 'responding'.

[jgcharlotte]

Ok, so this seems like a bit of a workaround but it works.  I just added a program that looks at the status of the auto control folder.  When it goes 'true' at 10 pm, it forces the 'auto on' program to run and turn on the heater if the thermostat is calling for heat.  After that, it will run as usual.  There may be more elegant ways to do it, but it does work!

 

Space Heater Auto Folder Status - [iD 00E5][Parent 00CE]

 

If

        Folder  'Space Heater Auto' is True

 

Then

        Run Program 'Space Heater Auto ON' (If)

 

Else

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

[stusviews]

Lost me on that one I have 'on', 'off,' and 'responding'.

 

Other than temperature and humidity, I have 14 options. Are you using an Insteon thermostat?

[jgcharlotte]

Ok. . . no, this is the Insteon wireless companion thermostat 2441ZTH

Edited March 6, 2017 by jgcharlotte