If - Then - Else Logic:, How literal is the else?

[paulbates]

I'm a new ISY user and trying to work out some basic logic. I'm writing a following program to replace similar logic in my previous HA system. What I want is for Fan Temp Sensor, to turn on the attic fan when its triggered. When it turns back off, I want to wait 20 minutes, and then turn the fan off. If the Fan Temp Sensor turns back on again in that time, I want things to start all over again and wait for Fan Temp Sensor to turn off again.

 

This functionality is time tested in my house, I don't want the fan cycling on and off, the 20 minute wait makes sure that the attic is really cooled down enough for the fan to go off. Here is the sample program:

 

If
        Control 'Attic / Fan Temp Sensor-Sensor' is switched On
 
Then
        Set 'Attic / Fan Low Speed' On
 
Else
        Wait  20 minutes
        Set 'Attic / Fan Low Speed' Off
 

Here is my question: How literal the 'Else' ?

 

Is it literally the opposite of the If statement, meaning If that sensor turns off instead of on, the 'else' becomes true?

 

Or will any other conditions besides that IOlinc switching on are will trigger the else?

 

Thanks

Paul

 

 

[LeeG]

The Else is not driven with the If Control.  The Else clause executes when the If is False which does not occur with a simple "If Control xxxx is switched On/Off"

 

If
        Control 'Attic / Fan Temp Sensor-Sensor' is switched On
Then
        Set 'Attic / Fan Low Speed' On
Else

 

 

If
        Control 'Attic / Fan Temp Sensor-Sensor' is switched Off

 Then
        Wait  20 minutes
        Set 'Attic / Fan Low Speed' Off
Else
       

Edited August 20, 2014 by LeeG

[paulbates]

Thanks for that clarification Lee, that gives me what I need

 

Regards

Paul

[stusviews]

If
        Status 'Attic / Fan Temp Sensor-Sensor' is not Off
 
Then
        Set 'Attic / Fan Low Speed' On
 
Else
        Wait  20 minutes
        Set 'Attic / Fan Low Speed' Off

[paulbates]

Hi Stu

I picked control because that made sense to me.. Why does status work with one program and control requires 2?  I like 1 program better, but I don't fully get it.

 

Regards

Paul

[apostolakisl]

If you need the else clause to trigger on a control clause then do the following

 

 

If

control device x is switched on

and 

control device x is not switched off

Then

do something

Else

do something else.

 

The reason the "else" clause does not ever run in your program is because there is no trigger for a false event.  "control switched on" is triggered when an "on" command is received, of course it is then true.  Nothing else triggers the program so thus there is no false state.

 

The "is not" terminology allows you to include "switched off" as a trigger, which will then be false, because it was switched off.

Edited August 20, 2014 by apostolakisl

[stusviews]

Control is an instruction to do something when a specified event happens. In your case, the instruction is to turn the fan on it the sensor turns on--the "if" statement is true. There is no instruction for what to do if the sensor turns off, that is, when the 'If" statement is false. In other words, if the statement is true then do something, if the statement is false, then do nothing.

 

OTOH, status actively monitors actual state of the device. While, not if, the statement is true, then do something. As soon as it becomes false, then do something else.

[LeeG]

So long as the If section is a single item using "If Status" and Else section is fine.   The problems arise when additional items are added to the If section such as a Time range.  Multiple items in the If section can force a False condition driving the Else when not wanted.  The two program approach using "If Control" does not have that issue.   As long as the If section remains a single test one Program is fine.

[apostolakisl]

Paul,

 

This is a common ISY new user issue.

 

Understand 2 concepts:

1) Trigger.  Something that triggers the "if" clause to be run.  If there is no trigger event, then there is no true or false execution at all.

2) Post Trigger Evaluation State:  After the program "if" is triggered to evaluate, is it true or false (then or else clause).  Always one will run.  Often times the "else" is blank so nothing happens, but when the "else" and "then" are used, you always have an action take place. . . sometimes with un-intended executions of an "else" clause.  This makes using "else" clauses a little more complex, especially with multiple "if" statements.

 

"Control" statements only trigger on the precise action listed.  "control is switched on" is only a trigger when an "on" command is sent through the power lines.  Thus "control is switched on" by itself can only be true and only will run when an "on" command is sent through the power lines.

 

"Status" statements trigger on all CHANGES in status.  They can be true or false.  One trick here is that they do not trigger if the status didn't change. In other words, if a switch is on, and someone pushes the on paddle again, this will not do anything.  A "control switched on" however will run the if clause again and start over.

 

"is not" can get your brain tied in knots.  Simply think of it as the same thing as "is" but the "else" clause will run instead of the the "then" clause.

 

 

In my example above, I used the "is not switched off" clause to allow an "off" command to 1) trigger the program and 2) evaluate it to false with that "off" trigger.  LeeG did that using 2 separate programs having them both run true and using the "then" clause in both.  The end result is identical.  You may find it easier to get your brain around using 2 programs, especially at first.  You could also use "status" in this situation.  With insteon devices that do not have dim levels (they are either on or off), status and control programs tend to behave almost the same.  The main difference would be if something is already on/off, and a new on/off command is sent from the device.

Edited August 20, 2014 by apostolakisl

[paulbates]

All of your feedback is great and very much appreciated. It helps me to understand different ways of looking at this. Thank you

 

I started with an ideal world of one program for a particular function. However the ISY's folder structure lets things be organized and filed discretely which keeps it organized for management. Multiple programs should be fine if I organize my HA life well in the ISY Admin Console.

 

I'm guessing I am not losing a lot of memory, resources or performance from my ISY by having multiple programs for a function vs one program for a function with an 'else'. Programming logic is programming logic.

 

I will start with 2 programs as proposed by Lee, get some experience and practice, and move forward carefully. The reasoning is that my HA system has gone from 'hobby' to 'production' over the years, and I owe it to those at home to be able count on it. Which counts on me knowing what I am doing

 

Moving functions to the ISY is proving to be very straightforward. Again, thanks for sharing your knowledge on how if-then-else functions in my ISY.

 

Regards,

Paul

[Teken]

Paul,

 

This is a common ISY new user issue.

 

Understand 2 concepts:

1) Trigger.  Something that triggers the "if" clause to be run.  If there is no trigger event, then there is no true or false execution at all.

2) Post Trigger Evaluation State:  After the program "if" is triggered to evaluate, is it true or false (then or else clause).  Always one will run.  Often times the "else" is blank so nothing happens, but when the "else" and "then" are used, you always have an action take place. . . sometimes with un-intended executions of an "else" clause.  This makes using "else" clauses a little more complex, especially with multiple "if" statements.

 

"Control" statements only trigger on the precise action listed.  "control is switched on" is only a trigger when an "on" command is sent through the power lines.  Thus "control is switched on" by itself can only be true and only will run when an "on" command is sent through the power lines.

 

"Status" statements trigger on all CHANGES in status.  They can be true or false.  One trick here is that they do not trigger if the status didn't change. In other words, if a switch is on, and someone pushes the on paddle again, this will not do anything.  A "control switched on" however will run the if clause again and start over.

 

"is not" can get your brain tied in knots.  Simply think of it as the same thing as "is" but the "else" clause will run instead of the the "then" clause.

 

 

In my example above, I used the "is not switched off" clause to allow an "off" command to 1) trigger the program and 2) evaluate it to false with that "off" trigger.  LeeG did that using 2 separate programs having them both run true and using the "then" clause in both.  The end result is identical.  You may find it easier to get your brain around using 2 programs, especially at first.  You could also use "status" in this situation.  With insteon devices that do not have dim levels (they are either on or off), status and control programs tend to behave almost the same.  The main difference would be if something is already on/off, and a new on/off command is sent from the device.

 

Your ability to dumb it down for the masses is greatly appreciated!

 

After all these years I continue to struggle with the operations of these operators and how best to craft programs that not only make sense, but are small, clean, and just plain work!

 

Thank You!

[apostolakisl]

All of your feedback is great and very much appreciated. It helps me to understand different ways of looking at this. Thank you

 

I started with an ideal world of one program for a particular function. However the ISY's folder structure lets things be organized and filed discretely which keeps it organized for management. Multiple programs should be fine if I organize my HA life well in the ISY Admin Console.

 

I'm guessing I am not losing a lot of memory, resources or performance from my ISY by having multiple programs for a function vs one program for a function with an 'else'. Programming logic is programming logic.

 

I will start with 2 programs as proposed by Lee, get some experience and practice, and move forward carefully. The reasoning is that my HA system has gone from 'hobby' to 'production' over the years, and I owe it to those at home to be able count on it. Which counts on me knowing what I am doing

 

Moving functions to the ISY is proving to be very straightforward. Again, thanks for sharing your knowledge on how if-then-else functions in my ISY.

 

Regards,

Paul

 

No problem.

 

And one point that I think is worthy to make.

 

"control" conditions in programs always are INITIATED AT THE DEVICE ITSELF.  In other words, "control device x is switched on" means that the command started at device x.  For most devices, that means someone physically pushed the button on it.  (other types of devices like motion detectors requires that the device itself experienced motion)  Please realize, that if you have a scene where a switch is turned on in RESPONSE to that scene, then a "control is switched on" didn't happen and a "control" condition will not trigger and the program will not run at all.  Yes, the light switch did switch on, but it was not a "control", it was a response to some other device being "controlled"..

 

If you want a program to trigger based on the switch changing status by any means (whether by direct action on it or by it responding to some other device's command), then use "status"..

Edited August 20, 2014 by apostolakisl

[Teken]

No problem.

 

And one point that I think is worthy to make.

 

"control" conditions in programs always are INITIATED AT THE DEVICE ITSELF.  In other words, "control device x is switched on" means that the command started at device x.  For most devices, that means someone physically pushed the button on it.  (other types of devices like motion detectors requires that the device itself experienced motion)  Please realize, that if you have a scene where a switch is turned on in RESPONSE to that scene, then a "control is switched on" didn't happen and a "control" condition will not trigger and the program will not run at all.  Yes, the light switch did switch on, but it was not a "control", it was a response to some other device being "controlled"..

 

If you want a program to trigger based on the switch changing status by any means (whether by direct action on it or by it responding to some other device's command), then use "status"..

 

I don't  think that aspect has ever been so clearly explained before.

 

Thank You

[LeeG]

Keep in mind this is a "temperature sensor".   A SwitchLinc or KPL button cannot send a command to the sensor to indicate it is some degree of temp that does not actually exist (the Sensor is a Controller node only). It is great to pass on information about various Insteon device capability and how Programs can be adjusted to handle those capabilities.   However, passing on information that is not related and impossible for the current situation without indicating the information cannot be applied to the current environment can confuse a new user.

[apostolakisl]

Keep in mind this is a "temperature sensor".   A SwitchLinc or KPL button cannot send a command to the sensor to indicate it is some degree of temp that does not actually exist (the Sensor is a Controller node only). It is great to pass on information about various Insteon device capability and how Programs can be adjusted to handle those capabilities.   However, passing on information that is not related and impossible for the current situation without indicating the information cannot be applied to the current environment can confuse a new user.

 

Appreciate the thought, but Paul has clearly stated he is moving an entire home automation system over.  It would benefit him greatly to realize that what he is doing here may apply differently elsewhere.

 

He is free to ignore the extra info if he likes.

[oberkc]

To which I add that the points made about triggers, evaluation state, status, and control are all applicable to a temperature sensor when part of a program condition.  I found apostalakisl comments quite relevent to this case.  What did I miss?

[LeeG]

"If you want a program to trigger based on the switch changing status by any means (whether by direct action on it or by it responding to some other device's command), then use "status".."

 

The Red part of the explanation does not apply to this situation.  The information is fine as a general comment but if the OP decides to use STATUS because of the desire to change the device Status from another device it will not work.  A comment to the effect that it does not apply to the OP example would have been helpful.

 

Edited August 20, 2014 by LeeG

[apostolakisl]

Wild guess, but most people don't try to tell a thermometer what temperature it should say.

 

Anyway, I answered his question quite directly and succinctly in the first post, and made it clear that the other posts were to assist him (and any other random user) of the bigger picture.

Edited August 21, 2014 by apostolakisl