Time periods after midnight

[larryllix]

Like @gviliunas posted, folders do not support Else statements. Programs do support Else statments, and can provide space for programs to clean up when the conditions change.

If I didn't need any Wait or Repeats, I would have saved money and just purchased an Insteon Hub. Programs inside a folder being autonomous has yet to be tested. I am not afraid of using Variables. They make programming much easier to troubleshoot and are useful in many places inside ISY while still maintaining some sort of filing order for larger systems.

Edited June 10, 2020 by larryllix

[lilyoyo1]

1 hour ago, larryllix said:

Programs inside a folder being autonomous has yet to be tested. 

I'm not understanding the point you're making

While the folder itself doesn't use or else the program itself can along with variables and anything else you want to use in a program within the conditions you set for that folder. 

[apostolakisl]

5 hours ago, larryllix said:

Like @gviliunas posted, folders do not support Else statements. Programs do support Else statments, and can provide space for programs to clean up when the conditions change.

 

Folders do have both a "then" and "else"

Then: programs are enabled

Else: programs are disabled.

I can't think of how a folder condition could ever have any other "then" or "else".

[larryllix]

5 hours ago, apostolakisl said:

Folders do have both a "then" and "else"

Then: programs are enabled

Else: programs are disabled.

I can't think of how a folder condition could ever have any other "then" or "else".

LOL. That's not a Then or Else. That is a True and False. No programs are enabled during False times and no programs will be run to clean up the mess of programs stopping abruptly.

Edited June 11, 2020 by larryllix

[apostolakisl]

4 minutes ago, larryllix said:

LOL. That's not a Ten or Else. That is a True and False. No programs are enabled during False times and no programs will be run to clean up the mess of programs stopping abruptly.

true or false is not an action.  Enabled and Disabled is the action taken based on true or false.

As I mentioned, only programs with repeats/waits would ever be "abruptly" terminated.  Repeats and Waits are of course also abruptly terminated by their own "if" clauses.  As is always the case, you need to be careful using those statements, folder conditions or not.

[larryllix]

3 minutes ago, apostolakisl said:

true or false is not an action.  Enabled and Disabled is the action taken based on true or false.

As I mentioned, only programs with repeats/waits would ever be "abruptly" terminated.  Repeats and Waits are of course also abruptly terminated by their own "if" clauses.  As is always the case, you need to be careful using those statements, folder conditions or not.

When a program containing a wait or repeat line, is interrupted by it's own If logic triggers, the program knows i,t and terminating action can be taken in the Else section.

This is not possible for a folder condition. When a folder condition becomes false the programs inside are not aware of the change, and cannot take any alternative action. Lights and devices can be left in undesirable states.

[apostolakisl]

9 hours ago, larryllix said:

When a program containing a wait or repeat line, is interrupted by it's own If logic triggers, the program knows i,t and terminating action can be taken in the Else section.

This is not possible for a folder condition. When a folder condition becomes false the programs inside are not aware of the change, and cannot take any alternative action. Lights and devices can be left in undesirable states.

True, but that requires you put the logic to run the else inside the "if" of your program that isn't in a conditioned folder.  So what is to stop you from putting that same logic in the "if" section of your program inside a conditioned folder?  For the handful of programs (for most people) using waits/repeats a simple "if time is not x" where x slightly precedes the end time of the folder.   Or, if you are in the minority and use a lot of waits/repeats, one program that does a "run else" and lists out all those programs that need to terminate.  Lots of ways to handle it, and like I said, when you use waits/repeats, you are going to have to do something no matter what to ensure the proper outcome.

 

[lilyoyo1]

I keep my folder logic simple. If it's about time, I schedule the folder to be active during the time the program will be active. This allows any waits or other conditions to process. 

Many simply separate what happens based on different conditions which makes it easier to track different programs

 

[lhranch]

On 6/9/2020 at 9:16 PM, apostolakisl said:

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.

Yeah, I understand all that.

My point is: If you read the rule as saying "8 PM on any day to sunrise the next day," the operation is clear. If you read the rule as saying "8 PM today to sunrise the next day," it is absolutely unclear. The actual wording of the rule is totally ambiguous as far as what it means, and the manual doesn't discuss the issue.

[apostolakisl]

14 minutes ago, lhranch said:

Yeah, I understand all that.

My point is: If you read the rule as saying "8 PM on any day to sunrise the next day," the operation is clear. If you read the rule as saying "8 PM today to sunrise the next day," it is absolutely unclear. The actual wording of the rule is totally ambiguous as far as what it means, and the manual doesn't discuss the issue.

I don't follow.  It doesn't say "today".  That would be confusing.  You can choose between everyday or just days of the week when writing the program and then it displays it as follows.  Which seems to follow common English understanding in my way of thinking.  I suppose you could have it say "On Everyday" for the everyday one like it says for just specific days, but to me, just saying at 8pm in a schedule means every time it is 8pm.

[lilyoyo1]

25 minutes ago, lhranch said:

Yeah, I understand all that.

My point is: If you read the rule as saying "8 PM on any day to sunrise the next day," the operation is clear. If you read the rule as saying "8 PM today to sunrise the next day," it is absolutely unclear. The actual wording of the rule is totally ambiguous as far as what it means, and the manual doesn't discuss the issue.

I think clarity is in the eyes of the beholder and how they choose to interpret something. My wife is my guinea pig on simplicity. As smart as she is with her line of work, when it comes to this stuff; it might as well be in farsi. Anyhow, I wrote a quick line  that said from 7pm to 5am the next day then turn on the light.

Her interpretation (without explantion) of 7pm to 5am the next day was the light would be on from 7 at night until 5 in the morning. When I asked how she figured that, her response was the next day starts at midnight.

People's minds work differently. For some, a new day begins when they wake up or the sun comes up. However when it comes to time itself, a new day starts at midnight. The same for the week. I know many (due to work schedules) who look at a new week starting on Monday vs Sunday. They know when the week truly starts but in their mind it starts on Monday. I think this may be the same situation that you are in. You're processing the next day as when you wake up vs Midnight when a new day actually starts.

 

 

[apostolakisl]

Here is the the final deal. 

1) from "a time" is that time every day unless otherwise stated.   Like a hotel says "check-in is 3pm", they don't qualify that with "everyday" or "today" unless it isn't the same everyday.

2) To (same day/next day) means a day as defined by the calendar (meaning 12pm start time).

3) That line of code is always true between those two times no matter when you check.

4) If "to" time is after "from" time, it is false, but is NOT a trigger at either time.

All of those seem pretty self evident to me except the last one, which is just the convention ISY chose so you just have to know it and write programs accordingly.

[oberkc]

20 minutes ago, apostolakisl said:

but is NOT a trigger at either time.

Did not know that.

[apostolakisl]

2 minutes ago, oberkc said:

Did not know that.

Neither did I.  But good to know!  Had to edit my post like 4 times as I tested and eventually narrowed it all down.

Edited June 14, 2020 by apostolakisl

[larryllix]

16 hours ago, apostolakisl said:

Neither did I.  But good to know!  Had to edit my post like 4 times as I tested and eventually narrowed it all down.

UDI did some real head scratching for some of that logic.

Program Logic Test
    From 11:59 PM
    To 12:00 PM (same day)   <-------- 11 hours, 59 minutes earlier
Then
   Will Never Run
Else
    -------

Edited June 15, 2020 by larryllix

[kclenden]

3 hours ago, apostolakisl said:

(meaning 12pm start time).

 

45 minutes ago, larryllix said:

From 11:59 PM
    To 12:00 PM (same day)

Doesn't the day start at 12:00 AM?

[kclenden]

3 hours ago, apostolakisl said:

4) If "to" time is after "from" time, it is false, but is NOT a trigger at either time.

Should that be 'If "to" time is before "from" time'?

[larryllix]

13 hours ago, kclenden said:

 

Doesn't the day start at 12:00 AM?

Yes, but it was an example of @apostolakisl's posted logic  where the "To" time is before the "from" time.

Let me post the whole thing again so it doesn't get it's meaning misconstrued.
Program Logic Test
    From 11:59 PM
    To 12:00 PM (same day)    <-------- 11 hours 59 minutes earlier
Then
   Will Never Run
Else
    -------

Edited June 15, 2020 by larryllix

[TrojanHorse]

Scratching head. Can the smart minds here agree somehow and distill this into the wiki (or whatever document / source we’re to follow and keep on our nightstand). And to be blunt, that’s a request to un-F this and make it easy to follow for current and future users. Joking sorta but respectfully that’s a suggested fix

Or are we all supposed to parse through this?


Sent from my iPhone using Tapatalk

[lhranch]

16 hours ago, lilyoyo1 said:

Her interpretation (without explantion) of 7pm to 5am the next day was the light would be on from 7 at night until 5 in the morning. When I asked how she figured that, her response was the next day starts at midnight.

You're processing the next day as when you wake up vs Midnight when a new day actually starts.

No. It's clear some people are not understanding what the valid point of confusion is here.

I've worked on OS system date, time and time-zone APIs over the past 50 years... and two major questions the coder always has needs to have specified is, "when is a time expression evaluated, and what is it evaluated relative to?" This is especially important when you choose whether to express and store time values as either strings (to be evaluated later) or binary clock values (evaluated at the present time and place), and when to perform the conversion.

For example, I use a personal financial package that routinely screws up regularly scheduled deposits and withdrawals when I am traveling with my laptop. It stores scheduled transactions dates as binary times, evaluated at the time and place of the schedule's creation. So instead of logging a scheduled transaction on the 13th of each month (it chooses midnight), when I am traveling, it often logs it on the 12th late evening because I am in a different time zone, and then all the accounts fail to balance. I've fixed this type of problem in various OSes. So these are details I am sensitive to that most people might overlook.

It's easy to look at a program that turns on at 7 PM and turns off at 5 AM the next day, and predict (assume) what it will do, if the only triggers are passing through those clock times. But if you knew that a trigger could occur at 3 AM that would invoke this code, it's hard to determine for sure whether the condition would evaluate true or false unless the manual tells you (or you stay up late and test it). At 3 AM on any given day, is the time between 7 PM (relative to what day?) and 5 AM on the "next" day (again, relative to what day)?

Now that I know that there is an implicit "of any day" in the expression, it makes things clear.

So perhaps I "overthink" such problems, but it's from hard experience of the downsides of failing to think them through beforehand.

Edited June 15, 2020 by lhranch

[lilyoyo1]

44 minutes ago, lhranch said:

No. It's clear some people are not understanding what the valid point of confusion is here.

I've worked on OS system date, time and time-zone APIs over the past 50 years... and two major questions the coder always has needs to have specified is, "when is a time expression evaluated, and what is it evaluated relative to?" This is especially important when you choose whether to express and store time values as either strings (to be evaluated later) or binary clock values (evaluated at the present time and place), and when to perform the conversion.

For example, I use a personal financial package that routinely screws up regularly scheduled deposits and withdrawals when I am traveling with my laptop. It stores scheduled transactions dates as binary times, evaluated at the time and place of the schedule's creation. So instead of logging a scheduled transaction on the 13th of each month (it chooses midnight), when I am traveling, it often logs it on the 12th late evening because I am in a different time zone, and then all the accounts fail to balance. I've fixed this type of problem in various OSes. So these are details I am sensitive to that most people might overlook.

It's easy to look at a program that turns on at 7 PM and turns off at 5 AM the next day, and predict (assume) what it will do, if the only triggers are passing through those clock times. But if you knew that a trigger could occur at 3 AM that would invoke this code, it's hard to determine for sure whether the condition would evaluate true or false unless the manual tells you (or you stay up late and test it). At 3 AM on any given day, is the time between 7 PM (relative to what day?) and 5 AM on the "next" day (again, relative to what day)?

Now that I know that there is an implicit "of any day" in the expression, it makes things clear.

So perhaps I "overthink" such problems, but it's from hard experience of the downsides of failing to think them through beforehand.

My very first words were clarity is in the eyes of the beholder, implying what's clear to some may not be for others. Due to your background, how you read things may be and probably is different than those without such background. It's like when I was in boot camp. The Drill Sergeants talked about those accustomed to hunting would have a harder time on the range than those who didn't (they were right). 

Programming the isy is a different beast than programming systems or coding. They have to make it so that a person with no programming knowledge can use it. Due to this, those with a programming background have a harder time grasping the different nuances that comes with the Isy.

Unfortunately when it comes to examples, there are way too many variables and ways to accomplish a task without causing confusion.

Have you seen the isy cookbook? It may have some examples of things that you may come across in the future. https://wiki.universal-devices.com/index.php?title=Main_Page#ISY_Cookbook

[apostolakisl]

14 hours ago, kclenden said:

Should that be 'If "to" time is before "from" time'?

Oops. Yes.

[apostolakisl]

1 hour ago, lhranch said:

No. It's clear some people are not understanding what the valid point of confusion is here.

I've worked on OS system date, time and time-zone APIs over the past 50 years... and two major questions the coder always has needs to have specified is, "when is a time expression evaluated, and what is it evaluated relative to?" This is especially important when you choose whether to express and store time values as either strings (to be evaluated later) or binary clock values (evaluated at the present time and place), and when to perform the conversion.

For example, I use a personal financial package that routinely screws up regularly scheduled deposits and withdrawals when I am traveling with my laptop. It stores scheduled transactions dates as binary times, evaluated at the time and place of the schedule's creation. So instead of logging a scheduled transaction on the 13th of each month (it chooses midnight), when I am traveling, it often logs it on the 12th late evening because I am in a different time zone, and then all the accounts fail to balance. I've fixed this type of problem in various OSes. So these are details I am sensitive to that most people might overlook.

It's easy to look at a program that turns on at 7 PM and turns off at 5 AM the next day, and predict (assume) what it will do, if the only triggers are passing through those clock times. But if you knew that a trigger could occur at 3 AM that would invoke this code, it's hard to determine for sure whether the condition would evaluate true or false unless the manual tells you (or you stay up late and test it). At 3 AM on any given day, is the time between 7 PM (relative to what day?) and 5 AM on the "next" day (again, relative to what day)?

Now that I know that there is an implicit "of any day" in the expression, it makes things clear.

So perhaps I "overthink" such problems, but it's from hard experience of the downsides of failing to think them through beforehand.

ISY evaluates time expressions at the start time and end time by default (except where they are swapped chronologically as previously discussed.)

ISY evaluates "if" statements (with or without time expressions) whenever triggered.  Lots of ways to be triggered include external "run if", change in status of a listed device or variable, and other stuff.

ISY evaluates time statements as per common English understanding of from/to.  Like, "I work the third shift, from 10pm to 6am the next day."   It is obvious to anyone reading that when this person will be at work.  

[lilyoyo1]

21 minutes ago, apostolakisl said:

 

ISY evaluates time statements as per common English understanding of from/to.  Like, "I work the third shift, from 10pm to 6am the next day."   It is obvious to anyone reading that when this person will be at work.  

Perfect example

[oberkc]

7 hours ago, lhranch said:

So perhaps I "overthink" such problems, but it's from hard experience of the downsides of failing to think them through beforehand.

Yes, a bit of overthinking here in my estimation.  Ironically, it seems that it is often those with many years of programming experience that have trouble.  It seems to me that many come in with assumptions about how the ISY works, based on experience with other operating systems and languages and, when the assumptions fail to hold up, confusion reigns.