Time of Day

[zerop]

Didn't know how exactly to search for this subject.

 

I currently have a program to run from sunset to 6:30pm (same day) everyday.  At sunset some lights are turned on and at 6:30pm the lights are turned off.

 

This time of year it is no problem as sunset is at about 5:00pm.  What happens later in the year (and especially after the time change) when sunset is after 6:30pm?  Will the program run backwards?  Say sunset is at 7:00pm.  Will the lights be turned off at 6:30pm (they would already be off) and then at sunset (at 7:00pm) they would be turned on?

[stusviews]

Yes, the sequence of events will be reversed. Turning off a device that's already off is like pressing the channel2 button on your TV remote when the TV is already on channel 2. The IR signal will be sent, but nothing will happen.

 

But, in your example the lights would turn on a 7:00 PM and remain on until 6:30 PM the next day, then turn off until the sunset program runs.

 

BTW, you can have the off time in the sunset program to be 1 ½ hrs. after sunset.

Edited January 15, 2015 by stusviews

[zerop]

Ok then, what's the difference between these two?

 

From Sunset

For 2 hours

 

Then turn light on

Else turn light off

 

-----and this one-----

 

From Sunset

To Sunset + 2 hours

 

Then turn light on

Else turn light off

 

 

Anything?

[LeeG]

No difference.  Both have a True evaluation at Sunset and a False evaluation at Sunset+2 hours.

 

EDIT: this assumes the To Sunset is coded

 

From Sunset

To Sunset +2 hours (same day)

Edited January 16, 2015 by LeeG

[zerop]

Ok, how about this?  My goal is to have the outside lights turn on from sunset until 6:30pm.  That is until sunset becomes after 6:30 pm then the lights just shouldn't turn on.  In other words the lights would turn on and be on for a less and less amount of time each day until sunset becomes later than 6:30pm.

 

 

Variable Sunset is an integer and is set to 0 at sunrise (see program 3).

 

 

---------------------------------------

PROGRAM 1 (Sunset):

If

        From    Sunset 

        To      Sunset  +  2 hours  (same day)

 

Then

        $Sunset += 1

        Run Program 'LightsOn' (If)

 

Else

        $Sunset  = 0

---------------------------------------

 

 

 

---------------------------------------

PROGRAM 2 (LightsOn):

If

        From    Sunset 

        To       6:30:00PM (same day)

    And $Sunset is 1

 

Then

        Set 'OutsideLights' On

 

Else

        Set 'OutsideLights' Off

---------------------------------------

 

 

 

---------------------------------------

PROGRAM 3 (SunsetReset):

If

        From     6:30:00PM

        To      Sunrise (next day)

 

Then

        $Sunset += 1

 

Else

        $Sunset  = 0

---------------------------------------

Edited January 16, 2015 by zerop

[apostolakisl]

You don't need any crazy programming like that.

 

Just

 

If 

From Sunset 

To 6:30 pm same day

 

Then

Set lights on

 

Else

Set lights off

 

The program runs twice, at sunset and at 6:30 pm

 

It always runs false at 6:30 (lights turn off, if already off . .. nothing happens)

It runs true at sunset if it is before 6:30 (lights turn on, or stay on if someone manually turned them on)

It runs false at sunset if it is after 6:30 (lights turn off if they had been manually turned on, if already off, nothing happens)

 

Just keep in mind that if you manually turned the lights on, this program will turn them off at sunset when it occurs after 6:30.

Edited January 16, 2015 by apostolakisl

[zerop]

You don't need any crazy programming like that.

 

Just

 

If 

From Sunset 

To 6:30 pm same day

 

Then

Set lights on

 

Else

Set lights off

 

The program runs twice, at sunset and at 6:30 pm

 

It always runs false at 6:30 (lights turn off, if already off . .. nothing happens)

It runs true at sunset if it is before 6:30 (lights turn on, or stay on if someone manually turned them on)

It runs false at sunset if it is after 6:30 (lights turn off if they had been manually turned on, if already off, nothing happens)

 

Just keep in mind that if you manually turned the lights on, this program will turn them off at sunset when it occurs after 6:30.

 

That is not what user "stusviews" said above (if I understood his post correctly).

[stusviews]

The program apostolakisl posted runs as you want

[larryllix]

Interesting that when you cross the times the whole program "If" doesn't get evaluated either way (true or false) even if other logic is injected. I tried various additional logic that should have tested true and false but no operations were experienced.

 

Here is my test program. No lights ever operated.

Test times - [ID 005B][Parent 0001]

If
        From     9:35:00PM
        To       9:27:00PM (same day)
     Or $cTRUE is $cTRUE
 
Then
        Set 'Gathering Room / Floor Lamp' Fast Off
        Wait  1 second
        Set 'Gathering Room / Floor Lamp' Fast On
 
Else
        Set 'Gathering Room / PotLight over Desk' Fast Off
        Wait  1 second
        Set 'Gathering Room / PotLight over Desk' Fast On

[stusviews]

"To" must be later than "From." What kind of variable is $cTrue?

[larryllix]

"To" must be later than "From." What kind of variable is $cTrue?

$cTrue and $cFalse are constants equating and initialised to 1 and 0 respectively.

 

I use many Integer variables as constants to make  programs more self-documenting. I have requested this feature of UDI by simply adding another tab to the variable typecasting. Hopefully it will show up in v5. User definable tabs would be even better to organise the long list of variables we end up using for our moments of creation.

 

I use them for room definitions in many programs to pass variables and of course True and False prefixed in the usual ISY style using the "$c" prefix.

[Xathros]

Larry-

 

The variable must be a State variable and it's value must change for it to trigger an evaluation.

 

Integer variables are evaluated when a program is triggered but they do not trigger a program when their value changes.

 

-Xathros

[apostolakisl]

That program will trigger at both 9:35 and 9:37 and be true both times, only because of the "or $cTrue is $cTrue".  Without that clause it would run at both times and be false.  As mentioned, if the variable is a state variable, then it will act as a trigger also whenever it changes.  If it is integer, it will just sit idle waiting for some other trigger regardless of what happens to its value.

 

Always the "From" time and the "to" time are triggers.  If from time is after the to, then it will be false.  If anything else triggers the program, that particular clause will be false always.  Of course adding an "or" statement connecting a by definition true statement will in turn cause this program to always be true.

Edited January 19, 2015 by apostolakisl

[larryllix]

That program will trigger at both 9:35 and 9:37 and be true both times, only because of the "or $cTrue is $cTrue".  Without that clause it would run at both times and be false.  As mentioned, if the variable is a state variable, then it will act as a trigger also whenever it changes.  If it is integer, it will just sit idle waiting for some other trigger regardless of what happens to its value.

 

Always the "From" time and the "to" time are triggers.  If from time is after the to, then it will be false.  If anything else triggers the program, that particular clause will be false always.  Of course adding an "or" statement connecting a by definition true statement will in turn cause this program to always be true.

My testing demonstrated cross times never triggers at all on either time node. I thought that I could force further evaluation by putting known true or false conditions in with it. As my example shows cross times will not trigger a program true or false.

 

This appears to be by UDI design to stop sunset/sunrise triggers from doing nasty things.

 

This surprised me but IIRC this was discussed about  year  back in another thread.

Try it. I may have been insane at the time.

 

 

Edit: I found the thread where this was discovered  a year ago. Seems like an anniversary maybe?

http://forum.universal-devices.com/topic/12251-sunrise-program-question/?hl=%2Bcrossed+%2Btimes&do=findComment&comment=100168

Edited January 20, 2015 by larryllix

[apostolakisl]

OK, my bad, I guess I knew last year that crossed from/to times don't trigger and somehow forgot.  I swear at one point they did.

 

the summary page shows a crossed from/to program has a scheduled run time, but it doesn't actually run despite saying it will.

[larryllix]

Larry-

 

The variable must be a State variable and it's value must change for it to trigger an evaluation.

 

Integer variables are evaluated when a program is triggered but they do not trigger a program when their value changes.

 

-Xathros

State variable usage may have confused my demonstration / investigation and yielded different results. This may be experimented with further.

 

The integer variable usage was intentional to investigate the crossed times not triggering at all despite another condition logic attempting to force ISY back into line with it's usual logic. ISY must be previewing these crossed times and just locks out the program completely from executing whatsoever. Maybe by UDI design and maybe by evolution happenstance. Either way it seems like a necessary evil in the logic of triggers for "real-time made easy" for the masses.

 

Oh those time triggers!  Half the forum is based on that confusion.   Need to remove the trigger from the "To" clause, or add Ap's checkbox

Edited January 20, 2015 by larryllix

[Xathros]

State variable usage may have confused the investigation and yielded different results. Maybe experimented with further.

 

The integer variable usage was intentional to investigate the crossed times not triggering at all despite other conditions forcing ISY back into line with it's usual logic. ISY must be previewing these crossed times and just locks out the program completely from executing whatsoever. Maybe by UDI design and maybe by evolution happenstance. Either way it seems like a necessary evil in the logic of triggers for "real-time made easy" for the masses.

Gotcha.

 

-Xathros

[Teken]

Here's a novel idea on a related matter.

 

How about a real drop down calendar widget so people can select days, weeks, months, holidays, with out having to craft some giant program which is just a massive kludge.  

 

Having a calendar would save people lots of time, frustration, and provide a much better user experience. This isn't 1930, its 2015 and this should be on the *To Do* list for 5.XX

[larryllix]

OK, my bad, I guess I knew last year that crossed from/to times don't trigger and somehow forgot.  I swear at one point they did.

 

the summary page shows a crossed from/to program has a scheduled run time, but it doesn't actually run despite saying it will.

Sure surprised me, again. Defies logic so I can't remember those things. Maybe the "cloud" isn't so bad if it matches our brains.

[larryllix]

Here's a novel idea on a related matter.

 

How about a real drop down calendar widget so people can select days, weeks, months, holidays, with out having to craft some giant program which is just a massive kludge.  

 

Having a calendar would save people lots of time, frustration, and provide a much better user experience. This isn't 1930, its 2015 and this should be on the *To Do* list for 5.XX

+1

...and a clock?

[Teken]

+1

...and a clock? 

 

Well, since we're asking might as well ask for the moon!   My feed back is from the view of a new user which I had to deal with for ages.

 

I am tired of being beat up because the ISY has no basic calendar / clock. This is considered basic 101 for almost all the software and platforms I have worked with in other systems.

 

Its hard to show off all the power of the ISY when two days later the client rings you up and says *Where is the calendar* and I reference them to those two massive programs to do dates.

 

You don't even want to know what comes out of their mouth . . .

[Xathros]

As long as 5.X breaks the date into separate month/day/year fields, then I think we have what we need to do calendaring - just not pretty.

 

-Xathros

Edited January 20, 2015 by Xathros

[larryllix]

Wild cards. We have to have wildcards.

 

Geeesh! There must be a pulldown calendar built into Java already. All the hype for a product that was laying on it's death bed a few years ago (

"We will never produce a 64 bit version"), surely they must have some fancy tools in the API.

Edited January 20, 2015 by larryllix

[Teken]

As long as 5.X breaks the date into separate month/day/year fields, then I think we have what we need to do calendaring - just not pretty.

 

-Xathros

 

At this point I will take that over that massive *date program*! Kudos to those who took the crazy amount of time to craft and share it to the membership.

 

But, the reality is it was a real hard sell to get even two people to get it going. I am a technician not a salesmen so don't have the time to lay down the fluff about how to make it work.

 

When it should be a native feature by default.

Edited January 20, 2015 by Teken

[Xathros]

I am a technician not a salesmen so don't have the time to lay down the fluff about how to make it work.

 

In my experience, it's the salesmen that promise the world and me as the technician that has to deliver and make it work.

 

 

Just sayin...

 

-Xathros