How to turn a device OFF for 6 hours then back ON?

[Goose66]

This documents presents a perfect example:

 

If

( Status 'Light 1' is On

Or Status 'Light 2' is On

Or Status 'Light 3' is On )

And Control 'Switch 1' is switched On

 

Then

Set 'Light 4' On

 

Else

- No Actions -

 

In this example, it is clear that the intent is to only have the program run when an ON command from Switch 1 is received, no? Further, I think the desired status for the program would be what was the outcome of the evaluation of Light 1 is ON or Light 2 is ON or Light 3 is ON the last time the program ran. Can we agree on that?

 

However, in the current implementation, the program will be run whenever Switch 1 is turned on AND whenever the status of Light 1, Light 2, or Light 3 changes. This is probably not desired and would be unexpected by the uninformed. Further, upon change in status of Light 1, Light 2, and Light 3, the status of the program will necessarily be FALSE, because the Control Switch 1 condition will fail. This also creates situations that differ from teh expected result, IMO.

 

Please know that I understand and can work with the current implementation just fine, and this conversation and the posted references should help everyone. I am not criticizing the current implementation, either. I see some advantages to it, especially in that the program conditions are more concise. But, because this forum and UD has been so open to suggestions, I wanted to express my opinion that having trigger conditions and if statements as seperate items would be a clearer implementation with less unexpected results.

[Sub-Routine]

Hi kingwr,

 

That would be a great use for a folder.

 

This documents presents a perfect example:

 

If

( Status 'Light 1' is On

Or Status 'Light 2' is On

Or Status 'Light 3' is On )

And Control 'Switch 1' is switched On

 

Then

Set 'Light 4' On

 

Else

- No Actions -

 

[dansmith]

Wow, this thread has been really helpful. As a newbie I panicked the other night when I noticed that one of my programs was showing TRUE when I thought that it should be FALSE. It is one of those If Time=11:39 PM then turn off living room light. It was 5:30pm and the program was true. I was thinking that something was wrong with my ISY.

 

Rand just suggested that this switch example would be a good candidate for a folder. So would the folder condition be based upon Switch 1 or upon the status of lights 1 to 3? I am trying to figure out why a folder might make a difference as opposed to the way that the example is shown in the wiki.

[Sub-Routine]

Hi dansmith,

 

Because kingwr doesn't want the program to run unless one of the lights is On the status of the three lights would be used in the folder conditions. Note that if this was a dimmer you may prefer to use a condition of > Off to refer to any value above 0%.

 

However the folder conditions will not affect the status of the program (true/false), the conditions only enable/disable the program.

 

 

Rand

 

Wow, this thread has been really helpful. As a newbie I panicked the other night when I noticed that one of my programs was showing TRUE when I thought that it should be FALSE. It is one of those If Time=11:39 PM then turn off living room light. It was 5:30pm and the program was true. I was thinking that something was wrong with my ISY.

 

Rand just suggested that this switch example would be a good candidate for a folder. So would the folder condition be based upon Switch 1 or upon the status of lights 1 to 3? I am trying to figure out why a folder might make a difference as opposed to the way that the example is shown in the wiki.

[Goose66]

I think my point is missed. But let me belabor it further:

 

It's not about a specific program I am trying to accomplish. It is about how counterintuitive the implementation of "programs" are in the ISY. As a programmer, I think of it this way: When an event happens, execute a program. This is not structured this way in the ISY. The IF statement contains both triggers for the program (inherently ORed) and conditions for the THEN branch (which may be ORed or ANDed). There are many other counterintuitive aspects as well. For instance, the way the IF is reevaluated at the end of a WAIT or REPEAT takes most if not all ISY users by surprise. Adding the layers of folders on the programs also is counterintuitive, as the above question suggests. Why would the conditions for the IF inside the program come before the trigger for the program? That's pretty wacky, and not what kingwr intended at all.

 

I am sure there are reasons it is done the way it is done (I imagine it stems from how the programs are serialized in the XML). But a much better implementation for me would be let me write a script, and then tie that script to events that occur on the ISY. It may take more programming to accomplish some of the same things, but it is a model that can be understood intuitively by all.

[Michel Kohanim]

Hi kingwr,

 

Thanks so very much for your feedback. It's indeed appreciated.

 

I am not sure I understand the question. In the above example the intended behavior is:

if (A && then C

where A = x && y && z

 

The concept of short-circuit in logic suggests that C should not even be evaluated if A is false. And that's precisely what's happening.

 

Furthermore, C is transient: so, it follows that if C is taken place then A should be evaluated and thus the whole condition should be re-evaluated.

 

Am I missing something?

 

Would you elaborate on why folders are counter-intuitive? This is quite surprising because folders are the organizational units that allow you re-use of conditions without having to repeat them. For instance, Christmas folder will only be evaluated during Christmas (provided the correct constraints).

 

I do agree that scripts are quite powerful and much easier for developers and we are in fact investigating scripts. This said, however, scripts would be quite difficult for the non-developers.

 

With kind regards,

Michel

 

 

 

I think my point is missed. But let me belabor it further:

 

It's not about a specific program I am trying to accomplish. It is about how counterintuitive the implementation of "programs" are in the ISY. As a programmer, I think of it this way: When an event happens, execute a program. This is not structured this way in the ISY. The IF statement contains both triggers for the program (inherently ORed) and conditions for the THEN branch (which may be ORed or ANDed). There are many other counterintuitive aspects as well. For instance, the way the IF is reevaluated at the end of a WAIT or REPEAT takes most if not all ISY users by surprise. Adding the layers of folders on the programs also is counterintuitive, as the above question suggests. Why would the conditions for the IF inside the program come before the trigger for the program? That's pretty wacky, and not what kingwr intended at all.

 

I am sure there are reasons it is done the way it is done (I imagine it stems from how the programs are serialized in the XML). But a much better implementation for me would be let me write a script, and then tie that script to events that occur on the ISY. It may take more programming to accomplish some of the same things, but it is a model that can be understood intuitively by all.

[dansmith]

I think my point is missed. But let me belabor it further:

 

For instance, the way the IF is reevaluated at the end of a WAIT or REPEAT takes most if not all ISY users by surprise.

 

My apologies if my question regarding folders and the specific example got this discussion off track. I was wanting some clarification in my own mind that folders, whether intentional or not, are actually a method of implementing your Trigger/IF model that you suggested. My previous controller was an Ocelot which uses ladder logic type programing. As having spent 12 years some time ago programming PLCs, it was very easy for me to program in the Ocelot. However the organization of the program and the ability to have different programs enabled at different times was very cumbersome. I am now trying to wrap my brain around folders and IF statements and how and when they are evaluated.

 

Apologies again if I take this off track, but the reevaluation of the IF at the end of the WAIT has taken me by surprise. If I have a very simple program like the following, does the IF get reevaluated at the end of the WAIT? If so, why?

 

Program Outside Porch Light On

 

If Time=6:45 pm

 

Then

Wait 3 Minutes

Turn Porch Light On

[oberkc]

but the reevaluation of the IF at the end of the WAIT has taken me by surprise.

 

That is a surprise to me, also. I will re-read the post, but where did you get this idea? I understood that program conditions are only evaluated when one or more of the conditions change.

[Michel Kohanim]

Hello all,

 

Wait is interruptible (so is Repeat): if the condition for the program in which the Wait is specified turns false, then the statements after the Wait are not executed.

 

I am not certain where the notion that the condition is re-evaluated after a Wait stems from. Conditions are evaluated based on events; if ANY statement - and regardless of the program causing it to execute - creates events for which there are conditions, those conditions are re-evaluated as they should be.

 

With kind regards,

Michel

[apostolakisl]

So you are saying that a program in the midst of a "wait" commnad will terminate (along with all "then" stuff following the wait) in the event that the "if" section is triggered again prior to the termination of the "wait"?

 

So if time = something is the only "if" command, then the program should trigger at that time, and unless another program forces a re-trigger, the program will run to its conclusion.

 

But if you had a "such and such light is switched on" as a trigger with a "wait" as part of the "then", if someone did anything to that switch during the "wait" period, the program would re-trigger and the previous "wait" period would be aborted along with whatever followed?

 

If the re-trigger event occurs but doesn't change the status of the program (ie it stays true), does the "wait" start over from scratch or does it keep going along the time line started by the first trigger?

[Michel Kohanim]

Hello apostolakis,

 

Excellent questions!

 

Please see my comments below.

 

With kind regards,

Michel

 

So you are saying that a program in the midst of a "wait" commnad will terminate (along with all "then" stuff following the wait) in the event that the "if" section is triggered again prior to the termination of the "wait"?

Yes

 

So if time = something is the only "if" command, then the program should trigger at that time, and unless another program forces a re-trigger, the program will run to its conclusion.

Yes

 

But if you had a "such and such light is switched on" as a trigger with a "wait" as part of the "then", if someone did anything to that switch during the "wait" period, the program would re-trigger and the previous "wait" period would be aborted along with whatever followed?

 

If the re-trigger event occurs but doesn't change the status of the program (ie it stays true), does the "wait" start over from scratch or does it keep going along the time line started by the first trigger?

Wait terminates if and only if the condition turns to false. During the wait, if the condition does NOT change (regardless of the permutation of the events that keep it true) then the program continues with its current execution and does NOT restart from the beginning

[markens]

To amplify a bit on Michel's reply (since precise details are important in this discussion):

 

if you had a "such and such light is switched on" as a trigger with a "wait" as part of the "then", if someone did anything to that switch during the "wait" period, the program would re-trigger and the previous "wait" period would be aborted along with whatever followed?

Yes, with the clarification that Control events "trigger" only when that specific event is received, not for any Control action for that switch. For example, a "Control xxx is switched On" condition triggers only when that switch is physically turned on, not off. Status events trigger whenever the status changes, no matter what status is being tested for.

 

If the re-trigger event occurs but doesn't change the status of the program (ie it stays true), does the "wait" start over from scratch or does it keep going along the time line started by the first trigger?

Wait terminates if and only if the condition turns to false. During the wait, if the condition does NOT change (regardless of the permutation of the events that keep it true) then the program continues with its current execution and does NOT restart from the beginning

I think two different concepts are being confused here: program status vs logical result of IF conditions. It seems that apostolakisl is asking about program status, and Michel is answering with respect to IF conditions. But beyond that:

 

Michel, your answer does not seem to jibe with results I observe in my ISY. Specifically, I have a very simple program:

 

If
       Control '[fdoor E]' is switched On
Then
       Send X10 'H7/On (3)'
       Wait  15 seconds
       Send X10 'H7/Off (11)'
Else
       Send X10 'G1/Off (11)'

 

The only possible logical result of the IF is TRUE (since it is "triggered" only when the "switched On" event is received, and should do so every time that event is received). The switch is turned On and the THEN waits. Turning the switch off does not affect the wait (as expected). Turning it back On after, say, 10 seconds does cause the Wait to terminate: program Last Finish Time and Last Run Time are both updated to this time, and the program summary shows it running the Then. 15 seconds later (as confirmed by event viewer and Last Finish Time) the Wait completes and the X10 command is issued. So all values stay TRUE, but it is apparent that the program has restarted from the beginning due to the received event.

 

edit: I updated the test program above to make it even clearer what's happening when looking at the program summary page and event viewer.

 

--Mark

[Goose66]

I as well have observed different behavior than described. For instance:

 

If
       Control 'Outdoor / Driveway Motion-Sensor' is switched On

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

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

 

When motion is detected, the Outdoor floods switch on. Each subsequent motion ON seems to reset the wait timer. This is amply demonstrated in the fact that 4 minutes after the light is turned on, the dusk/dawn system kicks off and no more motion ONs are sent. The log clearly shows the floods OFF is sent 12 minutes after the initial motion, not 8 minutes after the initial motion. Each subsequent ON does appear to reset the timer, even though the condition remains the same.

 

Again, its not that this isn't handy behavior; in this case it actually is. However, it is not clear or intuitive behavior. That is my point.

[Sub-Routine]

Yes, a Control will always be noticed, if Status does not change the program will not be reevaluated.

[apostolakisl]

Ohhhh, the nuances or this thing.

 

So restarting a "wait" timer really goes to rules of "trigger". If a program re-triggers, any "wait" command running will be aborted and potentially restarted when appropriate.

 

The program statement: "if control 'ligth switch' is switched on" only is a trigger if the "on" button is hit. Anything else you do to that switch will not trigger the program and the "wait" command will run its course unaffected?

 

The program statement: "If status 'light switch' is 43%" is a trigger anytime someone does anything to that switch and therefore will restart the wait command?

 

Is there a wiki page that outlines the rules of what constitutes a trigger with reference to each of the different types of "if" statements possible?

[oberkc]

The program statement: "If status 'light switch' is 43%" is a trigger anytime someone does anything to that switch and therefore will restart the wait command?

 

The program condition would be evaulated any time one of the conditions (status being one type of condition) changes. In your example, if it changes to a condition other than 43%, then the condition would be false. If a wait command was originally executing as a result of a true condition (then path), then the wait would halt as a result of the condition becoming false (which would trigger the else path).

 

There are lots of triggers, or conditions. Besides "on" and "off", there are "not on", "not off", "XX%" Status is one of several conditions, including time, and control.

 

I have never been much good at finding things in the wiki, so I cannot help you there. I have found, however, that the logic employed here to be consistent with my understanding of "if, then, else" construct and boolean logic. The most difficulty I have had with the programming is understanding the difference between the conditions of "status" and "contol".

[markens]

As I see it, apostolakisl (and others) are asking fairly precise questions, and are getting fuzzy answers that are true primarily for specific, non-generalized examples.

 

The program condition would be evaulated any time one of the conditions (status being one type of condition) changes.

But exactly what constitutes a change in a condition? The subtle point being that different types of conditions "change" in different ways, and there seems to be no authoritative list defining them.

 

In your example, if it changes to a condition other than 43%, then the condition would be false. If a wait command was originally executing as a result of a true condition (then path), then the wait would halt as a result of the condition becoming false (which would trigger the else path).

This is essentially what Michel said. I am trying to say this is not a precise way to define the behavior, and leads to confusion for people who don't already understand it. Specifically, defining the behavior in terms of previous or new logic values of the IF conditions doesn't get to the heart of the matter. Ultimately, the rules that determine how and when a condition gets (re)evaluated ("triggered") don't depend on these logic values at all. So why define them in those terms?

 

There are lots of triggers, or conditions. Besides "on" and "off", there are "not on", "not off", "XX%" Status is one of several conditions, including time, and control.

And the question is: precisely what causes each type of condition to be (re)evaluated, with the side effect of terminating an already running program?

 

Is there a wiki page that outlines the rules of what constitutes a trigger with reference to each of the different types of "if" statements possible?

I've seen plenty of examples using various conditions, but no concise list of this nature. I think it would be a great addition to info in the wiki.

 

--Mark

[johnmsch]

 

AmpWasOn

If
  - No Conditions - (To add one, press 'Schedule' or 'Condition')

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

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

 

 

As a side question, is there a way to copy/paste code examples like this from the admin console?

[Goose66]

Yes, right-click on the program name in Program Details and select "Copy to Clipboard" from the context menu.

[johnmsch]

Yes, right-click on the program name in Program Details and select "Copy to Clipboard" from the context menu.

 

Sweet!

[apostolakisl]

Here is what I am trying to figure out. What triggers a program to evaluate the if statement.

 

As I understand, whenever a program is triggered, anything currently running in the "then" or "else" section is terminated.

 

As I also understand, an object that is in an "if" statement may or may not re-trigger a program depending on whether it is evaluated as a "status" or "control". For example "status" objects will re-trigger a program any time the status of that object is addressed, regardless of whether it changes or not. At the same time, a "control" object will only re-trigger a program if it is addressed with the exact command written in the rule.

 

In the programming section we have lots of potential commands to put in the "if" section. Which ones will cause a trigger under what circumstances is the question?

 

Schedule

1) time is - causes a trigger at the specific time listed

2) to/from - ??? a trigger when it hits "from" and another at the "to" ???

 

 

Condition

1) status - a trigger every time the object (insteon device) is sent a signal regardless of whether it is a change or not or whether it is the status listed in the "if" statement.

2) control - a trigger only when the exact command listed is sent (ie "on") other commands do not trigger. The current state is not relevant (in other words it would not have to become "on", an "on" command to an already on device would still be a trigger)

3) program - ?? triggers when the listed program runs regardless of what happens to its true/false status ??

4) IR - ?? triggers every time that specific IR command is received (like pressed) while other commands on the ir freq may occur without triggering, similar to how "control" works ??

5) X10 - don't care, I have none

6) Module - don't even know what to guess here

[dansmith]

Here is what I am trying to figure out. What triggers a program to evaluate the if statement.

 

As I understand, whenever a program is triggered, anything currently running in the "then" or "else" section is terminated.

 

Apostolakis has clearly defined the question that we have all been wrestling with and not been able to articulate it so well. What triggers a program to evaluate the if statement. Just speaking for myself, I have a handle on the Boolean logic, but it is confusing for me what triggers the program to re-evaluate the IF statement.

 

Schedule

1) time is - causes a trigger at the specific time listed

 

In programming my old Ocelot I had a couple of time choices which obviously work differently than in the ISY. For example in Ocelot if I had the following statement:

 

If Time = 6:25 pm

 

This would be true as long as the time is 6:25 pm. Once the time became 6:26pm the IF statement would become false and remain false until 6:25 pm the next day. However, the THEN statement would continuously execute for the one minute from 6:25pm until 6:26 pm which I would expect.

 

There was also a statement in the Ocelot which was:

 

If Time becomes 6:25 pm

 

This would be true the moment that the internal clock reached 6:25 pm and the THEN statement would execute. If would then go false during the next execution of the program logic. (One shot type of logic).

 

Now my understanding is the same as outlined by Apostolakis above. The ISY triggers the program to evaluate the IF statement and run the THEN statement only when the time becomes 6:25pm. This only occurs once and occurs at the moment that the internal clock hits 6:25:00. However where some of us are getting confused is that the program status that contains this IF statement remains TRUE even after 6:25 pm. I can live with this, but a wiki to spell this out would be really helpful so that we are aware of it.

 

Condition

1) status - a trigger every time the object (insteon device) is sent a signal regardless of whether it is a change or not or whether it is the status listed in the "if" statement.

...

6) Module - don't even know what to guess here

 

I have the climate module and have been trying to use light levels to control my lights. Again, let me say that I understand the IF logic, but it is only by trial and error that I have been able to understand what causes the IF statement containing the climate module to be evaluated. What I thought would work actually didn't work (this is related to the WAIT statement but lets ignore that for now). I will simplify the code and only show what I have found true with regard to the program triggering the IF statement a

 

For example,

 

If Module Climate Light >15 

Then Turn Living Room Light Off

 

I have the Climate module set at its default polling of every 60 seconds. Thus every 60 seconds the Climate module goes out to weatherbug and gets all the weather data including the light level. What I expected was that when the Light level increased above 15, the THEN statement was executed and the Living Room Light would turn off. This happened exactly as I had expected.

 

What I did not expect was that every 60 seconds, when the polling of the weatherbug site occurred, the program would be triggered to evaluate the IF statement and even though the light level was still above 15, the IF statement would be evaluated and then THEN statement would be executed. In other words, when the light level was above 15, every 60 seconds the ISY would send the command to turn on the Living Room lights.

 

This also is the case for an IF statement with light level containing an =. Every 60 seconds (default polling) the program would cause the IF statement to be evaluated and the THEN would execute if the light level had not changed. I give this example because it is different from how STATUS LIGHT = ON or TIME=6:25 operates.

 

To summarize:

 

If a program contains the statement IF time = 6:25 pm the THEN statement following will only be executed once - when the time becomes 6:25 pm. This is what I would call a One Shot.

 

If a program contains the statement IF Module Climate Light = 15, the THEN statement following will be executed every time that the ISY polls the Weatherbug data source (every 60 seconds) and as long as light level = 15.

 

Same construct of an IF statement, but the result in the two cases is different.

[apostolakisl]

Dan et al,

 

Thanks for your comments. I am trying to outline the situation here. I did my best to outline the true/false determination and with that discovered that only by also understanding triggers could one predict the true/false status.

 

So, true/false and triggers are separate by highly interrelated topics. You need to know the nuances of both to predict how your programs will run.

 

In short, I would love to see the owners manual, or at least the wiki have two sections back to back.

1) understanding true/flase

2) understanding triggers

 

I have a lot less experience using the isy than a lot of people on this forum, but think I at least did an OK job outlining things. My inexperience in some sense I think helps as I have very few preconceived notions about how this works and therefore developed my concepts from a starting point that is likely not going to skip any concepts that the new ISY person would need to know.

 

Again, I really think that having this stuff outlined in the wiki would be great and save a lot of needless confusion and questions for a lot of isy programmers.

 

Lou

[Sub-Routine]

Hi guys,

 

All very good questions. I will put something together for the Wiki based on this thread.

 

Thanks, Rand

 

In short, I would love to see the owners manual, or at least the wiki have two sections back to back.

1) understanding true/flase

2) understanding triggers

[Goose66]

Also, my understanding is that much of this is only applicable if the THEN or ELSE branch contains a WAIT or a REPEAT. This was mentioned before, but was lost in the last few posts. So, just to make sure we are all clear, the only time a subsequent triggering of a program may occur that would pre-empty the currently running program is when there is a WAIT or a REPEAT, I think.