lhranch Posted June 7, 2020 Posted June 7, 2020 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 Posted June 7, 2020 Posted June 7, 2020 (edited) 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 Edited June 7, 2020 by lilyoyo1
larryllix Posted June 7, 2020 Posted June 7, 2020 (edited) 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 Edited June 7, 2020 by larryllix
kclenden Posted June 8, 2020 Posted June 8, 2020 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. 1
lhranch Posted June 8, 2020 Author Posted June 8, 2020 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 Posted June 8, 2020 Posted June 8, 2020 (edited) 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. Edited June 8, 2020 by larryllix
lilyoyo1 Posted June 8, 2020 Posted June 8, 2020 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 Posted June 8, 2020 Posted June 8, 2020 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. 1
lhranch Posted June 8, 2020 Author Posted June 8, 2020 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 Posted June 8, 2020 Posted June 8, 2020 (edited) 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. Edited June 8, 2020 by apostolakisl
lilyoyo1 Posted June 8, 2020 Posted June 8, 2020 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 Posted June 8, 2020 Posted June 8, 2020 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 Posted June 9, 2020 Posted June 9, 2020 (edited) 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. Edited June 9, 2020 by oberkc 3
gviliunas Posted June 9, 2020 Posted June 9, 2020 (edited) 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 Edited June 9, 2020 by gviliunas 2
larryllix Posted June 9, 2020 Posted June 9, 2020 (edited) 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. Edited June 9, 2020 by larryllix
gviliunas Posted June 9, 2020 Posted June 9, 2020 (edited) 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. Edited June 9, 2020 by gviliunas
apostolakisl Posted June 9, 2020 Posted June 9, 2020 (edited) 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') Edited June 9, 2020 by apostolakisl 1
oberkc Posted June 9, 2020 Posted June 9, 2020 Quote There is all kinds of arguing about a "problem" that does not exist agreed. 2
larryllix Posted June 9, 2020 Posted June 9, 2020 (edited) 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. ? ? Edited June 9, 2020 by larryllix 1
apostolakisl Posted June 10, 2020 Posted June 10, 2020 @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 Posted June 10, 2020 Author Posted June 10, 2020 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 Posted June 10, 2020 Posted June 10, 2020 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 Posted June 10, 2020 Posted June 10, 2020 @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 ?. 1
apostolakisl Posted June 10, 2020 Posted June 10, 2020 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. 2
lilyoyo1 Posted June 10, 2020 Posted June 10, 2020 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 1
Recommended Posts