Timers - excellent example post

[arw01]

Much thanks to Apostolakis for the examples below. I will follow up with my interpretation and my attempt to put what has been so graciously shared into a real world application on my own system.

 

Alan

 

 

Michael, sorry to be vague.

 

Coming from misterhouse we used a timer object that let us do the following:

 

set some_timer_variable_name 60*5

 

If expired some_timer_variable_name then turn off light

 

if some event occurs restart some_timer_variable_name

 

If some event occurs expire some_timer_variable_name

 

We could do comparisons on the timer, e.g.

 

If some_timer_variable_name < 300 then some action I want to occur

 

If active some_timer_variable_name then do some other action

 

For how the ISY does timers, I've not gotten my head around them yet.

 

So for a occupancy timer you would just do something like this instead of the program calling a program that I haven't understood well yet:

 

If motion_sensor State = "ON"

Then restart house_empty_timer

 

 

If some of the actual perl code would be more helpful, I can dig it out

 

Nearly all of these things can be done using a "wait" command. You might need multiple programs depending on the details. I have illustrated this below separating all the different situations into individual programs, but many times they can be merged into a single program.

 

The root timer program would be this: I have named it program 'x'

 

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

Then
       Wait  300 minutes 
       Set 'whatever you want' Off
       Run Program 'x' Else path

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

 

To expire the timer

 

If
  - Put the condition here for expiring timer

Then
       Run Program 'x' (Else Path)

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

 

To start (or restart) timer

If
  - Put the condition here for starting (or restarting) timer

Then
       Run Program 'x' (Then Path)

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

 

To do something if the timer is active

If
       Whatever you want to cause ISY to check if timer is running
And  Program 'x' is True

Then
  - Whatever you want to happen if timer active

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

 

To do something if the timer is inactive

If
       Whatever you want to cause ISY to check if timer is running
And  Program 'x' is False

Then
  - Whatever you want to happen if timer inactive

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

 

As far as I know, you can't compare the current location of a wait to anything else. Like if the wait had more than 60 minutes left versus less than 60 minutes.

 

Many of the situations I listed above would not require multiple programs, but the multiple program best illustrates how you could make it do anything you want.

[arw01]

SO If I understood correctly, this little program should reset the timer in the IF statement ANYTIME any of those items in the IF happen. Therefore the basement lights should not go off for 60 minutes after all these items have NOT occured for 60 minutes causing the wait to reset itself.

 

If
       Status  'Motion_1-Sensor' is On
    Or Status  'Motion_2-Sensor' is On
    Or Control 'Basement_stairs_OH' is switched On
    Or Control 'Media_Exercise' is switched On
    Or Control 'Media_Middle' is switched On
    Or Control 'Basement_stairs_OH' is switched On
    Or Control 'Media_Popcorn' is switched On
    Or Control 'Media_Middle' is switched Off

Then
       Wait  1 hour 
       $OCC_basement_svr  = 0
       Set Scene 'Basement_Off' Off

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

60 minute timer for any motion in the basement, if no motion, no switch activity, in that time, turn off all the basement lights

[apostolakisl]

SO If I understood correctly, this little program should reset the timer in the IF statement ANYTIME any of those items in the IF happen. Therefore the basement lights should not go off for 60 minutes after all these items have NOT occured for 60 minutes causing the wait to reset itself.

 

If
       Status  'Motion_1-Sensor' is On
    Or Status  'Motion_2-Sensor' is On
    Or Control 'Basement_stairs_OH' is switched On
    Or Control 'Media_Exercise' is switched On
    Or Control 'Media_Middle' is switched On
    Or Control 'Basement_stairs_OH' is switched On
    Or Control 'Media_Popcorn' is switched On
    Or Control 'Media_Middle' is switched Off

Then
       Wait  1 hour 
       $OCC_basement_svr  = 0
       Set Scene 'Basement_Off' Off

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

60 minute timer for any motion in the basement, if no motion, no switch activity, in that time, turn off all the basement lights

 

Yes, I think you are saying the right thing. You have 8 items in the if section. All of those 8 items are trigger events, meaning that should they happen, this program will end the "wait" clause, and start over from scratch. If it so happens that the "if" event was true, the timer (wait) will start over, If the "if" event is false, the else clause will run, which in this case is empty.

[arw01]

Since the Else clause would indicate something happened either by motion or a activation of a switch in the list, then I should be setting the variable for occupancy to 1 in the else.

[Vyrolan]

As a small aside, you have in your conditions On,On,On,On,On,Off....I think you mean On,On,On,Off,Off,Off... You should also check for Fast On and Fast Off.....and potentially also check for Brighten and Dim for dimmers....to fully check for all local control. Essentially you want to check On, Off, Fast Off and Fast On for every switch to see if anybody changed anything.

[arw01]

That did not work as expected. I put the else clause in, made a trip down stairs which tripped both motion sensors a few times (only verified by the red led blink), and I turned on Media Middle and then turned off Media middle.

 

When I returned to my console the occ_basement_svr was still sitting at 0. I expected it to have been at 1 due to my hitting the motion sensors and the switch. The program was listed as RUNNING, so obviously the wait condition was active.

 

When I manually ran the program if condition, it immediately set the variable to 1 from the else clause.

 

If

Status 'Motion_1-Sensor' is On

Or Status 'Motion_2-Sensor' is On

Or Control 'Basement_stairs_OH' is switched On

Or Control 'Media_Exercise' is switched On

Or Control 'Media_Middle' is switched On

Or Control 'Basement_stairs_OH' is switched On

Or Control 'Media_Popcorn' is switched On

Or Control 'Media_Middle' is switched Off

 

Then

Wait 1 hour

$OCC_basement_svr = 0

Set Scene 'Basement_Off' Off

 

Else

$OCC_basement_svr = 1

 

60 minute timer for any motion in the basement, if no motion in that time, turn off all the basement lights

[apostolakisl]

"control is switched" can never be false, either it does nothing, or it is true (if it is the only trigger in a program)

 

"control is not switched" can never be true, either it does nothing, or is false. (if it is the only trigger in a program)

 

"control" statements are a trigger whenever the exact thing listed after that happens:

ie , control is switched on requires an "on" press. Any other press is ignored. So if you push "on" it triggers, and it evaluates true

control is not switched on . . . when "on" is pressed, it triggers, but "is not" causing a false condition and the else runs.

 

If the program runs for some other reason than the "control" item happening, it will always be false, because the switch wasn't acted on at all, let alone how it was listed.

 

 

Your "status" statements can evaluate to false. Anytime the status CHANGES it triggers, and if the change ends up as true, the "then" runs, and vice-versa.

 

So if the light is off and you push on

"status is off" runs false (it changed from off to on, this triggered the line, but it is not off, so it is false

 

Unlike control, however, "status" can evaluate to true just sitting there. If the program triggers for any reason, a "status" line can be true. A control line, in contrast, can only be true by directly doing what it says. In other words, a control line must be the trigger and you must have done, and by definition thus it will run true for "is" and false for "is not"

 

Since your program is filled with lots of "or's", only a single item need be true for the whole thing to be true. When you left the room, you said you turned "media middle" off. This triggered the program as per the last line of your program, and indeed you pushed the "off" button, which is just what it asks for, thus it is true, and the "then" ran.

[arw01]

I don't understand why the else is not triggered automatically. When I ran the if statement manually the else triggered.

 

Anyways I think I had a logic error there. I wanted occ_basement_svr to be true whenever the timer was running, so I have set it true before the wait starts now instead of trying to use the else clause.

 

I assume that is because the program does not evaluate dozens of times a second like I was used to with the misterhouse perl loop we I used to use before buying the ISY to make life easier on me and my wife.

 

That else clause would only occur if I ran it manually or used another program to run it.

 

If
       Status  'Motion_1-Sensor' is On
    Or Status  'Motion_2-Sensor' is On
    Or Control 'Basement_stairs_OH' is switched On
    Or Control 'Media_Exercise' is switched On
    Or Control 'Media_Middle' is switched On
    Or Control 'Basement_Stairs' is switched On
    Or Control 'Media_Popcorn' is switched On
    Or Control 'Media_Middle' is switched Off

Then
       $OCC_basement_svr  = 1
       Wait  1 hour 
       $OCC_basement_svr  = 0
       Set Scene 'Basement_Off' Off

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

60 minute timer for any motion in the basement, if no motion in that time, turn off all the basement lights

[apostolakisl]

Because everything is connected by an "or". This means every statement must be false.

 

When you force a run by executing the "if" clause from outside of the program, you actually can have all the statements be false.

 

1) All of the "control" statements will be false. I explained how that works in the previous post

2) The "status" statements could be true, but if there is no motion, then indeed they would be false.

 

Thus, all statements are false, the else runs.

 

When you triggered the program by pushing the "media middle" button, that line of the program was true. Thus the whole program is true since you used "or" everywhere.

 

If you changed the last line to "is not", and on your way out of the room pushed "media middle" off, then it would run false (assuming the motion detectors weren't picking you up.)

[arw01]

I think I have it. The program does not run at all unless one of those devices has an event, regardless of what the event was. So if by theory, I could sneak around the motion detectors, and trigger a device in the if clause with a off that was not part of the if's, then the else should run?

 

Alan

[apostolakisl]

No.

 

None of the "control" statements will run false if it is the trigger as you have written it. When a control statement is the trigger, it will only run false if you use "control is not"

 

Every single line in that program needs to be false for the program as a whole to be false (because all are connected by "or" statements).

 

So, every "control" condition that wasn't the trigger (the button wasn't pushed) will be false. .. no problem there.

 

The one button that you do push, must also be false and that can only happen with the action you took followed by "is not".

[arw01]

I am still struggling with when it will evaluate the if statement.

 

Also my logic here does not work as I expected as I was moving all over the basement and the lights went out on me. The motion detectors SHOULD have kept that wait restarting a few times unless I don't understand that either.

 

I was expecting any motion status to re-do the then clause. So if after 5 minutes I trigger the motion status on again, it would restart the wait.

 

If we simplify this to make it easier for me to get my head around.

 

If status motion_1 is ON

 

Then start the timer

 

Else nothing

 

 

I think it should run that timer when I see the red light on the motion signal my motion. Then each time I see the red light on that motion sensor again, then it should redo the THEN causing the timer to start over?

[LeeG]

I have not read this topic from beginning to end. The Motion Sensor options (Sensing mode which is occupancy mode, On Only mode, and the timeout interval) all affect when the Motion Sensor will send Motion On messages. The Motion Sensor options may not be set as needed to keep the Program Wait from timing out.

 

"I think it should run that timer when I see the red light on the motion signal my motion. Then each time I see the red light on that motion sensor again, then it should redo the THEN causing the timer to start over? "

 

This may or may not be true. The Red LED blinking means the Motion Sensor has sensed motion. It does NOT mean the Motion Sensor has sent a Motion On message. Again it depends on the options that are in effect.

[arw01]

I will check that lee, I think I have them sending on constantly with motion.

 

Reading some wiki entries, some threads, I still cannot quite get my head around the non-standard way the ISY deals with the if then else process.

 

After reading I understand the program will get re-evaluated when the device changes status if you use status. And will get re-evaluated with control if the particular control test occurs.

 

Thanks to an example from the wiki, I know understand that control device is not off causes the if to evaluate for on, brighten, dim as well.

 

Oh well, will sleep on this one and see if I can get my head around it tomorrow!

[apostolakisl]

Your last statements were correct.

 

2 concepts

 

1) Triggers

2) True vs False after the trigger

 

1) Most ISY statements are triggers under certain situations. Some things (like integer variables) are never triggers.

- - Control: Triggers whenever the action listed is taken. ie Control switched on will trigger with an "on" press every time. It does not matter if it is already on to start with. NOTHING else you do to that switch is a trigger. Dim up, dim down, off, fast on, etc, etc will NOT trigger no matter what (however they still will evaluate when the program runs by some other trigger)

- - Status: Triggers with a change in status. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred. For example, on to Off, 50% to 55%, On to 45%, etc. will all trigger. It will not trigger if it is on and you press on, or off and you press off. The trueness or falseness of the statement is independent of whether it was the trigger.

- - State variables: Trigger on any change in the variable's value.

- - From:To times: Both the from and the to time itself is a trigger.

- - An outside program or manual "run if" is a trigger

 

2) Once a trigger event occurs, then EVERY line is evaluated.

- - Control statements are always false unless it was the trigger. If something else triggered the program, then it would be impossible to simultaneously have received an "on" or "off" or whatever was listed. A control statement is true if 1) it is the trigger, and 2 it is written as an "is" statement. It will run false if written "is not".

- - Status statements will be true if at the time of the trigger the status is as listed, regardless of how the program was triggered. Use "is not" is commonly used with status for "is not off" so that the light dimmed to any level will run true.

- - State and Integer variables evaluate the same way. If the actual value is as the program line asks, it is true, otherwise it is false. It doesn't matter how the program was triggered.

- - From:To times: The from time is a trigger and will be "true" when self triggered at that time. The "to" time will trigger the program and evaluate to false at that self trigger. If something else triggers the program, a from:to line will be true between the times, and false otherwise.

 

Motion Detectors have a feature to only send "on" commands as lee mentioned. Choices are to only send an "on", or to send "on" followed by "off" according to an internal timer if no further motion is detected. If set to only send "on", they will only trigger "control on" statements. They will never trigger a "status" statement since the status is always on and thus never changes. If set to the on mode, they statement "status is on" will never be a trigger and always evaluate to true. So the combo of using the "on only" mode and a "status" statement serves no purpose. Think of a light switch that is always on, and every time you walk in the room, you hit the "on" switch even though it is already on.

 

Multiple lines in a program connected by "OR" statements require only one line to be true for the entire statement to be true

Multiple lines connected by "AND" statements will be false unless all lines are true.

Using paranthesis combined with 'AND/OR' statements allows for various combinations and follows the standard rules you learned in high school algebra.

[MikeD]

Hi all,

 

Installed my ISY about a month ago and learning much by reading posts on this forum - thank you for helping us newbies.

 

I too was fuzzy on how the ISY handles conditions and finding this conversation very enlightening. However one thing that has helped me understand how programmed conditions are handled is to watch the Programs-Summary tab as I use a SwitchLinc next to my PC to trigger an event. The explanations given by apostolakisl in this thread become very clear when I setup a program using 'Control' vs. 'Status' and watch the program run in real time. The program response when using the 'Control' command was not what I expected. But now I understand after watching when the program runs and when it does not.

 

This by no means clears everything up but it does help!

 

~Mike

[arw01]

Most excellent. Certainly a wiki worthy post there, and I think maybe, just maybe I have it.

 

The timer has been set to 5 minutes so I can see if it works as intended this time and does not shut off the lights while I am down here moving around.

 

I have tweaked my occupied basement program to:

 

If
       Control 'Motion_Media-Sensor' is switched On
    Or Control 'Motion_Stairs-Sensor' is switched On
    Or Control 'Basement_Stairs' is switched Off
    Or Control 'Media_Exercise' is switched On
    Or Control 'Media_Middle' is switched On
    Or Control 'Basement_Stairs' is switched On
    Or Control 'Media_Popcorn' is switched On
    Or Control 'Media_Middle' is switched Off
    Or Control 'Media_Keypad' is switched On

Then
       $OCC_basement_svr  = 1
       Wait  1 hour 
       $OCC_basement_svr  = 0
       Set Scene 'Basement_Off' Off

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

60 minute timer for any motion in the basement, if no motion in that time, turn off all the basement lights

 

I am sitting here watching my motion sensor Media. I watched the ISY update to on status and am just waiting on the time out now. I have confirmed the dogs do not activate the stairs sensor as they race up and down the stairs to bark at the no see ums.

 

The time out has come and gone and the status updated to off.

 

Here is how I have that motion sensor configured:

 

[apostolakisl]

Since you have changed the program to "control motion sensor on" instead of "status motion sensor on" it really doesn't matter if you have the motion sensor set to time-out with an "off" command. The program as you have it will ignore an "off" statement from the motion sensor both as a trigger and as an evaluated item.

 

In fact, since you only have "control" statements and since none of them are "is not", this program will run "true" every single time (at least every time it self triggers, an external trigger will always run false). And if I understand the intent of this program correctly, that should be just fine.

 

However, if you choose to use the motion sensor in another program or if you choose to link the sensor directly to some other device, it may make a difference. It just all depends on what else you may want to do with it.

[arw01]

Well the status didn't seem to be helping keep the lights on while I moved around the basement. The control method I have watched, as another astute member posted above, the summary tab confirms every 10 seconds it sends another motion on and resets the program timer.

 

I would like to thank you again for your extreme patience getting the way it works through. I should bookmark this thread to re-read in the next day or so and really get it all sunk in.

 

Alan