Time periods after midnight

[lhranch]

If I write a program that begins:

      If the current time is between 10 PM and sunrise the next day...

I expect it to work properly between 10 PM and midnight of the current day; but is it going to work if invoked after midnight of the current day?

[lilyoyo1]

Midnight starts a new day so it can't be the current day. However, it'll run until sunrise since that is what you're asking it to do

[larryllix]

Copy and paste your program here and people can take a look at it.

ISY time triggers can be complex as they can act as filters to screen blocks of time and also as trigger themselves.

Eg:

If
       any trigger
      AND
       From 8:00 PM
       To 4:00 AM (next day)
Then
      runs at 8:00 PM each day and also any trigger between 8:00 PM and 4:00 AM
Else
      runs at 4:00 AM each day and also any trigger between 4:00 AM and 8:00PM each day

[kclenden]

16 hours ago, lhranch said:

If the current time is between 10 PM and sunrise the next day

Without any other conditions in your IF, that program will only run twice:

• At 10PM - it will run the THEN
• Sunrise the next day - it will run the ELSE

If you add other conditions (that are triggers) then "between 10PM and Sunrise the next day" becomes a filter that determines whether the IF evaluates TRUE or FALSE and consequently whether the THEN or ELSE is executed.

[lhranch]

Quote

Without any other conditions in your IF, that program will only run twice:

Well, yes and no.

In my case, there is another program that does a few things, and as the last thing, runs this program to reset the lighting to its "resting state" for the time of day. Now, that other program can be triggered at any time (it's linked to a motion sensor).

Again, if motion is detected between 10 PM and midnight, I would expect everything to run fine.

The question is, if motion is detected at, say, 1 AM, and this program gets run as a consequence, is it going to choose the ELSE because "well, it's not after 10PM today"?

@larrylix, above, says it will run THEN; @lilyoyo1 says it will run ELSE.

I think to be safe I may just bust up the boolean into "between 10 PM and midnight OR between midnight and sunrise" and just avoid the ambiguity of "next day."

[larryllix]

1 hour ago, lhranch said:

<snipped>

@larrylix, above, says it will run THEN; @lilyoyo1 says it will run ELSE.

I think to be safe I may just bust up the boolean into "between 10 PM and midnight OR between midnight and sunrise" and just avoid the ambiguity of "next day."

Not quite. Read the program more carefully. The posted program has an additional trigger that was mentioned @kclenden addresses this in his final paragraph. @lilyoyo1 did not discuss the program.

@lhranchBTW: You have to select the attention getting @ technique from the pulldown search resultant or it doesn't function just typing the name. Look for the reverse video difference.

[lilyoyo1]

7 hours ago, lhranch said:

Well, yes and no.

In my case, there is another program that does a few things, and as the last thing, runs this program to reset the lighting to its "resting state" for the time of day. Now, that other program can be triggered at any time (it's linked to a motion sensor).

Again, if motion is detected between 10 PM and midnight, I would expect everything to run fine.

The question is, if motion is detected at, say, 1 AM, and this program gets run as a consequence, is it going to choose the ELSE because "well, it's not after 10PM today"?

@larrylix, above, says it will run THEN; @lilyoyo1 says it will run ELSE.

I think to be safe I may just bust up the boolean into "between 10 PM and midnight OR between midnight and sunrise" and just avoid the ambiguity of "next day."

The last thing you want to do is add unnecessary complexity to a simple program because you are uncertain. What happens during certain hours is based off of what you want to happen. From time >to time will run the if and or else if that what you set

If time is from 10p to 6a the next day

Then turn light on

Or else turn light off. 

That will run the then at 10p and the  or else at 6a

If you add extra parameters to the if, then they'll trigger during certain hrs. 

If time is from 10p to 6a the next day

AND motion is switched on

Then turn light on

wait 2min

Turn light off

 

Personally, I separate my off program from my on. 

This allows me to potentially have other programs running without needing to disable anything

[oberkc]

7 hours ago, lhranch said:

I think to be safe I may just bust up the boolean into "between 10 PM and midnight OR between midnight and sunrise" and just avoid the ambiguity of "next day."

No need to do this.  I don't believe there is any ambiguity.  "Between 10pm and sunrise (next day)" is unambiguous.  

 

7 hours ago, lhranch said:

@larrylix, above, says it will run THEN; @lilyoyo1 says it will run ELSE.

I do not see where lilyoyo1 claims it will "run else".

Of course, your original conceptual program was pretty simple, but you have not posted the actual program.  Furthermore, you later mentioned motion sensors which were not part of the original post.  As programs include additional conditions, it can oftentimes be harder to figure out all the different triggers and logical conclusions.

[lhranch]

8 hours ago, oberkc said:

No need to do this.  I don't believe there is any ambiguity.  "Between 10pm and sunrise (next day)" is unambiguous.  

 

It becomes ambiguous the minute "the next day" becomes "today." That's really the crux of my problem statement.

[apostolakisl]

The program will be true at all times between 10pm and sunrise.  It doesn't matter when it is "invoked".  So a second program that calls a "run if" on this program at, for example, 1am will still run "then".  It doesn't matter that it is a different day.  ISY logic doesn't reset at MN.

[lilyoyo1]

3 hours ago, lhranch said:

It becomes ambiguous the minute "the next day" becomes "today." That's really the crux of my problem statement.

What's the Crux of your problem? Once you hit midnight a new day begins hence the next day statement. 

You refuse to post your program so we can't help figure out what's going on so there's not much more we can do until you either explain the full situation of what you're trying to do and post what you have

[larryllix]

What's the Crux of your problem? Once you hit midnight a new day begins hence the next day statement. 
You refuse to post your program so we can't help figure out what's going on so there's not much more we can do until you either explain the full situation of what you're trying to do and post what you have

Actually we would need both so we can poke holes in it and help fix it.

Sent using Tapatalk

[oberkc]

15 hours ago, lhranch said:

It becomes ambiguous the minute "the next day" becomes "today." That's really the crux of my problem statement.

Think of “next day” being relative to start time.  Alternatively, consider the logic without “next day”...from 10:00pm to sunrise...would that suggest a start time AFTER the end time?  

remember, too, that there is a day-of-week aspect to this condition.  Is not the full condition more like:

on monday, from 10:00pm to sunrise (next day)

Besides....it is less important what you believe and more important what the ISY believes.  Even if you find it grammatically ambiguous, the ISY does not.

[gviliunas]

I agree with @larryllix that using time conditions along with other trigger conditions can be tricky and can produce unexpected results

On 6/7/2020 at 5:19 AM, larryllix said:

If
       any trigger
      AND
       From 8:00 PM
       To 4:00 AM (next day)
Then
      runs at 8:00 PM each day and also any trigger between 8:00 PM and 4:00 AM
Else
      runs at 4:00 AM each day and also any trigger between 4:00 AM and 8:00PM each day

Over the years, to make things easier, I have used time ranges to set and reset "enabling integer variables" and then use these in other programs to achieve the correct result.

Eg.

Program 1: Night lights Enable

If
       From 8:00 PM
       To 4:00 AM (next day)
Then
      $i_Night_Lights_Enable = 1                    // Integer variable set to 1 each day at 8:00PM
Else
      $i_Night_Lights_Enable = 0                     // Integer variable set to 0 the next day at 4:00AM

 

Program 2: Night "Any Trigger" detected

If
       any trigger
      AND
       $i_Night_Lights_Enable = 1
      
Then
      runs if any trigger between 8:00 PM and 4:00 AM
Else
      runs if any trigger between 4:00 AM and 8:00PM each day

---------

Doing it this way, I avoid those "sneaky" possibly unwanted extra triggers at 8:00PM and 4:00AM 

[larryllix]

13 minutes ago, gviliunas said:

I agree with @larryllix that using time conditions along with other trigger conditions can be tricky and can produce unexpected results

Over the years, to make things easier, I have used time ranges to set and reset "enabling integer variables" and then use these in other programs to achieve the correct result.

Eg.

Program 1: Night lights Enable

If
       From 8:00 PM
       To 4:00 AM (next day)
Then
      $i_Night_Lights_Enable = 1                    // Integer variable set to 1 each day at 8:00PM
Else
      $i_Night_Lights_Enable = 0                     // Integer variable set to 0 the next day at 4:00AM

 

Program 2: Night "Any Trigger" detected

If
       any trigger
      AND
       $i_Night_Lights_Enable = 1
      
Then
      runs if any trigger between 8:00 PM and 4:00 AM
Else
      runs if any trigger between 4:00 AM and 8:00PM each day

That does make it simpler looking and eliminates the "trick" triggers that most people forget, or are not aware of. That transfers the "sneaky triggers" over to whether State or Integer variable types are used. Further if any trigger is using control/switched, it doesn't matter, but if using status, the type of enable variable becomes paramount.

I have always wanted to create a logic table for this, but was never sure whether the forum would take HTML code.

[gviliunas]

28 minutes ago, larryllix said:

Further if any trigger is using control/switched, it doesn't matter, but if using status, the type of enable variable becomes paramount.

How True! On the surface, ISY programming is simple however, there are case-specific tricks and traps. Several of my enabling programs have both a State and an Integer variable set and reset. Sometimes it is more appropriate to use State variable in other programs to cause a trigger when the enable variable is changed and other programs just use the Integer variable and trigger only when Control XXX or other State variables change value. Good catch. Thanks!

Program 1a: Night lights Enable

If
       From 8:00 PM
       To 4:00 AM (next day)
Then
      $i_Night_Lights_Enable = 1                    // Integer variable set to 1 each day at 8:00PM

      $s_Night_Lights_Enable = 1                    // State variable set to 1 each day at 8:00PM. Any programs using this condition will also run
Else
      $i_Night_Lights_Enable = 0                     // Integer variable set to 0 the next day at 4:00AM

      $s_Night_Lights_Enable = 0                    // Integer variable set to 0 the next day at 4:00AM. Any programs using this condition will also run.

[apostolakisl]

I am baffled by this thread.  There is all kinds of arguing about a "problem" that does not exist.  ISY logic handles the condition perfectly. 

If
   From [any time condition you like ie sunrise/sunset/specific time]
   to [any time condition you like] (next day)
Then
   whatever
Else
   whatever

The above runs true any time the "if" clause executes between the two times.  Period.  It does not matter if it is before MN of day 0 or after MN next day.

Just try it.  change the parameters however you like and do a manual "run if".  It will give the correct true/false 

EDIT:

Here, I did it myself.  The sun rose here at 6:20, or about 3 and a half hours ago. (currently 9:55am)

Below runs false.

New Program - [ID 017E][Parent 0093]

If
        From    10:00:00PM
        To      Sunrise +  3 hours  (next day)
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')
 

Below runs true

New Program - [ID 017E][Parent 0093]

If
        From    10:00:00PM
        To      Sunrise +  4 hours  (next day)
 
Then
   - No Actions - (To add one, press 'Action')
 
Else
   - No Actions - (To add one, press 'Action')
 

 

[oberkc]

Quote

 There is all kinds of arguing about a "problem" that does not exist

agreed.  

[larryllix]

7 hours ago, gviliunas said:

How True! On the surface, ISY programming is simple however, there are case-specific tricks and traps. Several of my enabling programs have both a State and an Integer variable set and reset. Sometimes it is more appropriate to use State variable in other programs to cause a trigger when the enable variable is changed and other programs just use the Integer variable and trigger only when Control XXX or other State variables change value. Good catch. Thanks!

Program 1a: Night lights Enable

If
       From 8:00 PM
       To 4:00 AM (next day)
Then
      $i_Night_Lights_Enable = 1                    // Integer variable set to 1 each day at 8:00PM

      $s_Night_Lights_Enable = 1                    // State variable set to 1 each day at 8:00PM. Any programs using this condition will also run
Else
      $i_Night_Lights_Enable = 0                     // Integer variable set to 0 the next day at 4:00AM

      $s_Night_Lights_Enable = 0                    // Integer variable set to 0 the next day at 4:00AM. Any programs using this condition will also run.

I have only ever had to create one variable in State type as well as Integer type for my programs. I hate having to do that.

However, maybe we should not bicker over this agreement anymore. We don't want to upset anybody.   ? ?

[apostolakisl]

@gviliunas

Have you considered putting your night light programs in a folder with condition from 8pm to 4am next day?  Any program in the folder would become "available" to run from 8pm to 4am, but would not automatically trigger at those times.  No variables needed. 

Any programs that you want to trigger at 8pm and 4am need to say from 8pm to 4am within the "if" clause.  Again, no need for any variables.  Or, have a nighttime program that is blank aside from "if time is from 8pm to 4am next day".  Then any other program you want to trigger at those times states "if program nightime is true".   A program referenced in an "if" clause will be a trigger when it changes state.  Again, no variables needed.  And it allows you to adjust your times on all programs by just changing one.  Though, it is quite likely that anything you want to happen at 8pm (true) and 4am (false) can all be contained in the same single program with multiple items in the "then"/"else" clause.  Or better yet, a single scene may encompass the whole lot so your "then"/"else" may each contain only a single line turning on/off that scene.

Both of these schemes require the same or fewer programs you currently have and require no variables.  

 

[lhranch]

17 hours ago, oberkc said:

Think of “next day” being relative to start time.

I'm happy to think of it that way, now that I have an assurance that this is in fact how the hub thinks of it. ?

[apostolakisl]

15 minutes ago, lhranch said:

I'm happy to think of it that way, now that I have an assurance that this is in fact how the hub thinks of it. ?

the need for next day/same day and the built-in ISY logic becomes quite evident in the following example.

From 8am to sunrise.

In the winter, sun rises maybe at 9am, light turn on at 8am and off at 9am.  Sounds good.

Now in the summer, the sunrise might be 7am.  So, now the lights turn on at 8am and turn off the next day at 7am, only to turn back on an hour later.

ISY logic fixes that.  By using the "same day" in this example, the summer time lights never turn on.  The statement triggers false at both times.

[gviliunas]

@apostolakisl Thanks for the suggestion! I use folder conditions in very limited situations. Someone else on this forum, possibly @larryllix, warned long ago to be aware of special considerations when using folder conditions.... 

Folder conditions can be confusing to troubleshoot, especially with nested folders, since right-clicking to manually run Then or Else doesn't work. Also, when the conditions disable the folder, any currently running programs will stop abruptly instead of running to their termination(s). 

I'm old so don't want to cause myself too many problems ?. 

[apostolakisl]

27 minutes ago, gviliunas said:

@apostolakisl Thanks for the suggestion! I use folder conditions in very limited situations. Someone else on this forum, possibly @larryllix, warned long ago to be aware of special considerations when using folder conditions.... 

Folder conditions can be confusing to troubleshoot, especially with nested folders, since right-clicking to manually run Then or Else doesn't work. Also, when the conditions disable the folder, any currently running programs will stop abruptly instead of running to their termination(s). 

I'm old so don't want to cause myself too many problems ?. 

Timed folder conditions and the fact that programs simply don't run at all outside of those times regardless of everything should be thought of as a useful feature.  Outside of the folder conditions, programs within the folder effectively don't exist.  This is of course not the case otherwise since aside from a conditioned folder, all programs can be forced to run despite its own "if" conditions not being met.  When you truly only want a program to run during certain conditions, a folder is the only option.  Typically speaking, night time lighting is ideally suited to conditioned folders.

The only type of program that could fail to complete within a conditioned folder would be a program with a "wait" or "repeat".  Using wait/repeat is tricky no matter where you use them by the very nature that they can be interrupted regardless of how/where you use them.  Those programs always require thoroughly considered "if" conditions not only within the programs own "if" clause but any "if" condition outside of the program that reference it, including other programs, network resources, and folder conditions.

[lilyoyo1]

45 minutes ago, apostolakisl said:

Timed folder conditions and the fact that programs simply don't run at all outside of those times regardless of everything should be thought of as a useful feature.  Outside of the folder conditions, programs within the folder effectively don't exist.  This is of course not the case otherwise since aside from a conditioned folder, all programs can be forced to run despite its own "if" conditions not being met.  When you truly only want a program to run during certain conditions, a folder is the only option.  Typically speaking, night time lighting is ideally suited to conditioned folders.

The only type of program that could fail to complete within a conditioned folder would be a program with a "wait" or "repeat".  Using wait/repeat is tricky no matter where you use them by the very nature that they can be interrupted regardless of how/where you use them.  Those programs always require thoroughly considered "if" conditions not only within the programs own "if" clause but any "if" condition outside of the program that reference it, including other programs, network resources, and folder conditions.

I see it as a feature as well and utilize it often. If I need to test something, Its a simple matter of moving it out of the program, testing, and dropping it back in