What is wrong - time lights stay on?

[redsfancfp]

Trying to have two lights turn on for 2 minutes when garage doors are opened...

I want to do this only when it is dark outside. They come on but don't turn off...

 

From Sunset

To Sunrise (next day)

And Elk Zone 'garage1' is violated

or Elk Zone 'garage2' is violated

 

Then

Send X10 '03/On (3)'

Set 'garagecornerflood' On

wait 2 minutes

send x10 '03/off (11)'

set 'garagecornerflood' off

[apostolakisl]

Because Elk zone garage 1 and garage 2 are triggers.

 

If you close the door before 2 minuts have passed, the zones become secure, the program re-triggers, the wait terminates, the program evaluates as false which runs the else.

 

If you want to fix this, make the else clause say the same stuff as the then clause. Then it will turn off 2minutes after the door is closed, or 2 minutes after the door is opened if no one closes the door.

 

Also, you need paranthesis around the two elk zones.

 

From sunrise

to sunset

And

(elk zone 1

or elk zone 2)

[dimensionzero]

Still new to ISY programming so maybe someone can double check this for me, but I think what I would do is break the program out into 2 parts...

 

A folder with the conditions to check if either of the garage doors are opened.

 

Then a program inside of that to check if the time is from sunset to sunrise... If it is, turn the lights on and off as you have it..

[redsfancfp]

Because Elk zone garage 1 and garage 2 are triggers.

 

If you close the door before 2 minuts have passed, the zones become secure, the program re-triggers, the wait terminates, the program evaluates as false which runs the else.

 

If you want to fix this, make the else clause say the same stuff as the then clause. Then it will turn off 2minutes after the door is closed, or 2 minutes after the door is opened if no one closes the door.

 

Also, you need paranthesis around the two elk zones.

 

From sunrise

to sunset

And

(elk zone 1

or elk zone 2)

 

 

OK so I added

Else

set x10 o3 off

set 'garagecornerflood' off

 

 

This made the lights go off as soon as the doors closed which is much better than staying on but not what I wanted. I understand what you are saying with the garage trigger causing the problem....I just don't know how to fix it. I have several zones where I want a violated to cause lights to come on for a certain time period and then go off. I guess I have no idea how to make that happen based upon this. Do you have any other suggestions?

 

This is "MUCH" easier to do in ELK RP. I guess I have been spoiled by it.

[LeeG]

redsfancfp

 

It will work if you follow the instructions provided by apostolakisl

 

"If you want to fix this, make the else clause say the same stuff as the then clause."

 

Then

Send X10 '03/On (3)'

Set 'garagecornerflood' On

wait 2 minutes

send x10 '03/off (11)'

set 'garagecornerflood' off

 

What was added to the Else is not what is in the Then clause. It turns the lights Off immediately because that is how the Else is coded.

 

OK so I added

Else

set x10 o3 off

set 'garagecornerflood' off

[apostolakisl]

right, you didnt' put the wait 2 minutes in the else.

[redsfancfp]

Ok. That does the trick. I am not really sure when to add else's but I guess I will learn.

 

Thanks for your help.

[LeeG]

redsfancfp

 

The ISY Program characteristic that is key here is using Wait and/or Repeat statements allows the Program If section to be reevaluated when something the If is checking has changed. Without a Wait or Repeat statement the If section is not reevaluated. The change in state/status often results in the If going from True (running the Then clause) to False (running the Else clause). When this happens the statements after the Wait or Repeat in the Then clause are not executed.

 

One solution is to split the single Program into two Programs where the If in the second Program has nothing to be reevaluated. Another solution is to add logic in the Else clause that executes when the If reevaluation drives the Else clause.

 

It is the possible reevaluation of the If when a Wait or Repeat statement is used that is the driving force. Whether additional logic is added to the Else or the single Program is split into two Programs with nothing in either Else clause are two of the possible solutions.

 

Understanding the implications of using a Wait or Repeat statement which allows If reevaluation is most important in understanding how to code ISY Programs.

[apostolakisl]

Putting this in the context of Elk.

 

Elk rules only trigger on the FIRST line (whatever is listed immediately after "whenever").

ISY Programs will trigger off of any line.

You'll notice that "Whenever it is dark outside" is not an option because that has no trigger time. It is only offered as a secondary condition to be checked whenever something else triggers (like Whenver zone x is violated)

 

Elk rules have no "OR" statements. That means you would need an entire rule for every "or" you want.

 

Elk rules have no "ELSE" clause. Meaning that again you would need two rules to do what one program can do in ISY

 

Once an Elk rule triggers a timer, the timer is no longer part of the rule. The timer runs independently. In ISY, the timer is running within the program, so if the program gets interupted, the timer stops. This feature can confuse people, but it does give the program more control. As Lee mentioned, "wait" statements and "repeat" statements both offer the opportunity for interuption. You'll also notice in Elk rules, when you write a rule to trigger a timer, it offers you the option to restart if already running, that option exists because the timer is a separate thing.

 

There are ways to get around this interupting of a program in a wait. It requires using 2 programs where the first program calls the second program. This is really the only situation where ISY requires two programs to do what Elk could do in one rule. But no worries, ISY has enough room for a gazillion programs, Elk is very constrained in the number of rules. ISY also lets you organize your programs in folders so you can follow your logic later on when you want to do some editing.

[redsfancfp]

OK so what I thought I was doing to limit the action to dark didn't work. It comes on day and night. I'm not certain how to do what you guys are saying.

 

I only want this stuff to happen during dark hours and in my prior posts I showed how I thought I could do that but it didn't work. What would accomplish this? I know 2 programs but I'm not sure how to do that. If possible could someone look at my above steps and tell me how to break that down to accomplish the goal?

[LeeG]

It would be good to post your actual Program. Right click Program name, select Copy to Clipboard and paste to the forum.

 

Did you add the parens as noted earlier by someone

 

If

From Sunset

To Sunrise (next day)

And

(

Elk Zone 'garage1' is violated

or Elk Zone 'garage2' is violated

)

 

Without the parens the Elk Zone is not included in the Time range check.

 

EDIT: also the statements in the Else run when the If is False which means they run day and night, any time the Program is triggered and the If is False. Requires using two Programs so the Wait is not bothered by the If reevaluation.

 

Was the Program broken into two Programs

[LeeG]

Program 1

 

If

From Sunset

To Sunrise (next day)

And

(

Elk Zone 'garage1' is violated

or Elk Zone 'garage2' is violated

)

Then

Run Program 2

Else

 

Program 2

 

If

Then

Send X10 '03/On (3)'

Set 'garagecornerflood' On

wait 2 minutes

send x10 '03/off (11)'

set 'garagecornerflood' off

Else

[redsfancfp]

OK I tried these steps for another zone and I still gets lights on in the day time... I am copying here. By the way I do thank everyone for all of your help. This board is amazing...

 

 

 

If

From Sunset

To Sunrise (next day)

And (

Elk Zone 'Foyer' is Violated

Or Elk Zone 'upstairs' is Violated

)

 

Then

Run Program 'Foyer Light Program 2' (If)

 

Else

Run Program 'Foyer Light Program 2' (If)

 

 

 

Foyer Light Program 2

If

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

 

Then

Send X10 'M5/On (3)'

Wait 2 minutes

Send X10 'M5/Off (11)'

 

Else

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

[LeeG]

Get rid of the Else in the first Program! As coded whether the If is True (between Sunset and Sunrise) or False (during the day) the same thing happens, invoking Program 2.

[apostolakisl]

This post of mine on a previous thread may help you to understand the logic.

 

Two 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 physically taken on that switch (responding to a program or scene is NOT a physical act on that switch). 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). (Note: with motion detectors, the act of "physically pushing" is actually the act of presenting motion to it.

- - Status: Triggers with a change in status regardless of what caused the change. ie 'Status on' will trigger with every change in status regardless if being "on" ever occurred and regardless if the change occured because the switch itself was pressed or because it responded to a scene or program. 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

- - Most Elk events are triggers (like zone status change, or armed change, but not voltage)

 

2) Once a trigger event occurs, then EVERY line is evaluated, and either the "THEN" or "ELSE" clause will execute every time.

- - 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. (NOTE: if the to time is before the from time, the program will not be a trigger. Like if you say sunrise to 7am, and sunrise at that time of year is after 7am, then neither the from nor to are triggers, and if something else triggers it, it will be false)

 

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.