Jump to content

Turn on lights based on sunset to sunrise period


frankv

Recommended Posts

Tried this program to turn my porch lights on every night, but it's not executing:

 

If

 

From Sunset

To Sunrise (next day)

 

Then

Set 'Front Porch Lights' 50%

 

Else

- No Actions - ...

 

Program Summary shows:

- Name: Front Porch Lights nightly

- Enabled: On

- Activity: Not Saved

- Status: False

- Next Scheduled Run: Mon 2011/08/08 08:12:49PM

all other fields are blank

 

Current time displayed is Tue 08/09/2011 01:21:10AM

 

Any advice?

 

Thx,

Frank

Link to comment

frankv

 

The "Not Saved" indicates the Program has not been saved which means it is not functional yet. Click on the Save Changes button in the lower left corner of the Program | Details screen when this Program has been selected.

 

Lee

Link to comment

D'oh - but in my defense, that button is hidden by my laptop which sits in front of my big monitor, and its placement is a unique UI design choice. What surprises me is the fact that it was listed on the Program Summary tab with a status of "On" for "Enabled" prior to it being saved, but I just tried to duplicate it and now it shows blank for "Enabled".

 

Thanks for your continued help!

Link to comment

Haven't been able to test the porch lights as my family keeps turning them on/off manually. I have set up another program that is similar to turn on some other lights in the evening, and those lights came up as scheduled tonight.

 

oberkc, I'm still trying to figure out exactly how the ISY translates these programs into triggers and actions, especially when you specify a timeframe. Based on your suggestion am I correct that the following program will create three events that will execute at the (translated based on locale) start and end times respectively:

 

If
  From Sunset
  To    Sunset (next day)

Then
  Set 'Porch Lights' 50%

Else
  Set 'MBR Light' On
  Set 'Porch Lights' Off

 

(Logical) ISY event table:

 

When            Action
08:10:29pm    Set 'Porch Lights' 50%
06:15:58am    Set 'MBR Light' On
06:15:58am    Set 'Porch Lights' Off

 

What puzzles me is when I create (and save ;)) a program like the one above without any "Else" actions after sunset, the next scheduled runtime under Program Summary is 06:15:58am. Perhaps because it needs to run to set the status flag if nothing else?

 

Taking this a bit further, what if I add another condition:

 

If
        From Sunset
        To    Sunset (next day)
  And Status 'Porch Lights' is Off

Then
  Set 'Porch Lights' 50%

Else
  Set 'MBR Light' On
  Set 'Porch Lights' Off

 

Not that it matters, but the reason may be to ensure that the porch lights only get turned on to 50% if nobody has turned the lights on yet. But for this to work, the ISY has to evaluate the status when the events get triggered. So the scheduled time(s) just determine when the program executes, and it evaluates the conditions each time to determine which branch to run? Which means every program needs some kind of schedule defined for it to run, unless it's only called by other programs?

 

Sorry for my ramblings, I'll post an update of what happens with my programs tomorrow.

Link to comment
I'm still trying to figure out exactly how the ISY translates these programs into triggers and actions

 

Yes, there have been many posts on this topic here. In the case of from/to, this will be "triggered" at sunset and sunrise (in your case) and evaluated as "true" starting at sunset and "false" starting at sunrise.

 

am I correct that the following program will create three events that will execute at the (translated based on locale) start and end times respectively

 

Yes. I expect this program to set the porch lights on (50%) at sunset. At sunrise, I expect the porch lights to turn off and the MBRl lights to turn on.

 

What puzzles me is when I create (and save ) a program like the one above without any "Else" actions after sunset, the next scheduled runtime under Program Summary is 06:15:58am. Perhaps because it needs to run to set the status flag if nothing else?

 

The program will run, regardless of whether there are any actions in the "then" or "else" sections. Scheduled runs are based on "if" conditions. Yes, using programs as a status flag is one application for this.

 

Taking this a bit further, what if I add another condition:

 

 

Code:

If

From Sunset

To Sunset (next day)

And Status 'Porch Lights' is Off

 

Then

Set 'Porch Lights' 50%

 

Else

Set 'MBR Light' On

Set 'Porch Lights' Off

 

 

So...this newest program has adds a second condition to the original.. The "trigger" for evaluation continues to include sunrise and sunset (from the original condition), but adds a trigger for any time the porch light status CHANGES. Therefore, this program will trigger an evaluation any time you change the status of your porch light.

 

Also, be aware that you have just introduce a condition (status of porch lights) that is affected by one of your program actions (set porch light to 50%, set porch light off). This can result in some interesting complications at times.

 

I assume that your porch light is on a dimmer, so beware that this introduces some interesting status possibilities. Consider "on" versus "not off". Or "off" versus "not on". Is a light "on" if it is set to 50%? Just beware that there are a lot more possible status than simply "on" or "off".

 

So the scheduled time(s) just determine when the program executes, and it evaluates the conditions each time to determine which branch to run?

 

Correct.

 

Which means every program needs some kind of schedule defined for it to run, unless it's only called by other programs?

 

Also correct. Inherent in conditions are triggers (that can be schedule or event-based) that force an evaluation.

Link to comment
Taking this a bit further, what if I add another condition:

 

 

Code:

If

From Sunset

To Sunrise (next day)

And Status 'Porch Lights' is Off

 

Then

Set 'Porch Lights' 50%

 

Else

Set 'MBR Light' On

Set 'Porch Lights' Off

 

 

So...this newest program has adds a second condition to the original.. The "trigger" for evaluation continues to include sunrise and sunset (from the original condition), but adds a trigger for any time the porch light status CHANGES. Therefore, this program will trigger an evaluation any time you change the status of your porch light.

 

Also, be aware that you have just introduce a condition (status of porch lights) that is affected by one of your program actions (set porch light to 50%, set porch light off). This can result in some interesting complications at times.

 

I assume that your porch light is on a dimmer, so beware that this introduces some interesting status possibilities. Consider "on" versus "not off". Or "off" versus "not on". Is a light "on" if it is set to 50%? Just beware that there are a lot more possible status than simply "on" or "off".

 

The trigger effect of the status condition is not what I intended or would have expected, but interesting. I'm starting to see where some of the recommendations here for separate programs are coming from. How about this approach:

 

If
        From Sunset
        To    Sunrise (next day)
Then
  Run Program 'Sunset' (If)
Else
  Set 'MBR Light' On
  Set 'Porch Lights' Off


Program Sunset:

If
  Status 'Porch Lights' is Off
Then
  Set 'Porch Lights' 50%
Else
  - No Actions -

 

The idea is that the Else statements get executed at sunrise irrespectively of the status of the porch lights, but that the porch lights (at sunset) ONLY get set to 50% IF they are presently off. Since the Sunset program now has a trigger AND condition, I have to disable it so that only the trigger in the calling program can run it. Correct?

 

BTW, the porch lights did turn off this morning (with the Else statement turning it off explicitly).

Link to comment
The trigger effect of the status condition is not what I intended or would have expected, but interesting. I'm starting to see where some of the recommendations here for separate programs are coming from.

 

The separate programs are often needed when the "then" or "else" statements drive a change to the "if" condition. In some cases (typically when the statements include a wait or repeat), this can cause execution of the program to stop mid-stream. Separating the programs is a method to solve that problem. I just wanted you to be aware of the possibility. In your current example, however, I don't believe that separating the programs is necessary, but it is one way of doing it. Keeping it this way may avoid future problems, though, so perhaps keeping it separated is prudent.

 

Since the Sunset program now has a trigger AND condition, I have to disable it so that only the trigger in the calling program can run it. Correct?

 

It sounds to me like you have a good grasp of things. Yes, this will trigger on it's own at any change in status. If the change to the porch light status is to turn off (such as at sunrise, for example), this program would execute on it's own. So, if you fail to disable this program, I would not be surprised to see the lights turn off at sunrise, followed immediately by the lights turning to 50% when the first program turns the lights off and the second program triggers itself.

Link to comment

Thanks for your patience and continued assistance, oberkc!

 

If
        From Sunset
        To    Sunrise (next day)
  And Status 'Porch Lights' is Off

Then
  Set 'Porch Lights' 50%

Else
  Set 'MBR Light' On
  Set 'Porch Lights' Off

 

Let me make sure I get this 100% correct. In the example above, will this program execute

a. at sunset

b. at sunrise

c. every time the status of 'Porch Lights' changes (and evaluate to true and execute the "Then" statements if the

current time is between sunset and sunrise AND the status of 'Porch Light' is off, or execute the "Else" statements any

other time of day OR any other status)

d. every time the status of 'Porch Lights' changes between sunset and sunrise only, and execute "Then" if the status of

'Porch Light' is Off, or "Else" if it is in any other state

 

a,b, and c?

a,b, and d?

?

 

Not sure I like either answer, problem being is that the status change acts as a trigger in itself if I interpret you correctly. Here's an example UD shows in their manual:

 

If
  (
           Time is 9:45:00PM
     And Status 'BasementControls1A' is On
  )
 Or (
           Time is 10:00:00PM
     And Status 'BasementControls1A' is Off
  )

This program will execute only if the time is 9:45pm and the BasementControls1A device is On OR if the time is 10:00pm and the BasementControls1A device is Off.

 

That statement makes you belief that the status is ONLY evaluated at the specified time, not every time the status changes. Now in my example we are dealing with a timeframe, so if we apply the logic from their example, you would think it's either only at sunset and sunrise, or sunset/sunrise/any time in between that the status changes. Then again, their statement "program will execute only..." is suspect to me as well, shouldn't it be "program will evaluate to true" or something to that effect?

 

You almost have to know the internals of their code to figure out how this stuff works, or do a lot of experimenting which I'm trying to do as well as much as possible, but this evening I got a nice error message on my UD Admin console:

 

Failing Communicating With

Cannot Communicate With Front Porch Door Lights (3 17 93 1). Please check connections.

OK

 

Then it had the same error message for the foyer lamps, but those had come on nevertheless, whereas the porch lights did not (but their "current state" in the console shows 50%).

 

Ok, got part of the answer. Just changed the status to 53% in the admin console to see if I could turn on the porch lights "manually", and they started going on, off, on, off, etc - checked the program and I had basically the same logic as above, so I deleted the "And" condition/trigger and saved the changes which stopped the madness. The status change is definitely a trigger, question remains if that trigger is valid all day or only during sunset to sunrise.

 

Ran another test program with a from-to AND Status ... condition, the status change does indeed trigger the program to run at any time (it evaluates to false/else outside the from-to timeframe, and true/then inside the timeframe).

 

For those of you still awake reading this, hope it helped a bit. Now I have to figure out what's causing these communication errors (still popping up even if issuing commands from the console, though some of them execute despite the error msg).

Link to comment
Let me make sure I get this 100% correct. In the example above, will this program execute

a. at sunset

b. at sunrise

c. every time the status of 'Porch Lights' changes (and evaluate to true and execute the "Then" statements if the

current time is between sunset and sunrise AND the status of 'Porch Light' is off, or execute the "Else" statements any

other time of day OR any other status)

d. every time the status of 'Porch Lights' changes between sunset and sunrise only, and execute "Then" if the status of

'Porch Light' is Off, or "Else" if it is in any other state

 

a,b, and c?

a,b, and d?

?

 

My expectation would be a, b, and c.

 

That statement makes you belief that the status is ONLY evaluated at the specified time, not every time the status changes.

I agree. This is not my understanding. Perhaps your confusion and mine is with terminology. Compare "trigger", "evaluate", and "execute". I suggest that the meaning of the word "execute" includes to run a program action (then or else). Is it possible that, in this example, there is no "else" statement, therfore there would be no "execution" if the condition is triggered and evaluated as false? In different words, this program is triggered and evaluated many times, but only "executed" if evaluated as "true" (because of the lack of an "else" statement). This program is only evalated as "true" under the conditions described.

 

The status change is definitely a trigger, question remains if that trigger is valid all day or only during sunset to sunrise.

 

Nice experiment. This is how many of us learned the ins-and-outs of the ISY-99. I believe that you will find status change is a trigger all day. It is just that your program will always evaluate as FALSE after sunrise and before sunset.

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...