simplextech Posted March 8, 2019 Posted March 8, 2019 This may seem a bit silly however it is a common discussion point with other controllers and I've learned each vary somewhat and have their own uniqueness. This is what my current understanding of the ISY time program scheme is and I'm looking for corrections/updates/addendum to ensure I understand what and how the ISY is working so to best structure my own programs efficiently and correctly. Programs and Time....time to program.... FROM -> TO If the time FROM -> TO is the first line of the program the "trigger" for the program is the FROM Time for the THEN clause or the TO time for the ELSE clause. If there is a CONDITION (AND) to the IF clause and the time is between the FROM->TO time period the THEN clause is executed Time period In the programs there is the nice drop down of same day / next day which is great. Question is about actual time/hour. Is 12:00 TO 00:00 valid or does it have to be a 12:00 TO 23:59? Is the same true though for a 00:00 to 06:00 (same day). Can the time reference use the 00:00 for either beginning or ending of the time knowing that is midnight and follow a 24 hour clock correctly using the same/next day drop down? This is a issue with other systems where it's a 12 hour clock of 00:00 to 23:59 and causes quite the confusion at first.
palayman Posted March 8, 2019 Posted March 8, 2019 (edited) I would hope that it follows some standard like ISO where 0:00 is the start of the day and 23:59 is the end. This should mean that 12:00 to 23:59 should be almost the same (one second short) as 12:00 to 0:00 (next day). This means 12:00 to 0:00 (same day) should never be true. Edited March 8, 2019 by palayman
mwester Posted March 8, 2019 Posted March 8, 2019 (edited) Good discussion. But, humans make mistakes, sometimes in coding, sometimes in judgement, sometimes in assumptions... and having spent my life in the field as the guy that parachutes in when a customer's systems go all wrong, I've adopted some seemingly-extreme but generally effective defensive techniques. As they relate to this topic, I'd be worried that whatever we figure out and document on this thread might change should some future programmer at UDI fix a long-standing bug report regarding date/time, or whatever. So, here's my rules for time periods: - avoid midnight, noon, and on the ISY, avoid the 3AM to 4AM hour. As noted above, when exactly is 00:00 tomorrow? Same as 00:00 without any qualifier? Or does 00:00 without a qualifier refer to the very first moment that happened today (i.e. in the past)? Similarly, 12:00 is an error-prone time spec -- is that midnight via 12-hour clock, or noon? And as for 3AM, the ISY is so busy swamped with its queries at 3:05 AM that any schedule starting or ending in the middle of that will at best be shifted by some amount, and possibly even lost (don't know the latter for sure, but I know that node server activity was lost when the system was swamped doing that query back a few versions ago...) - avoid anything on-the-hour. Humans schedule things for the hour. We're funny that way. So, if my automation does something, for example, sends me an alert or a reminder or a notification, I'll be way too busy clearing off one customer conference call and trying to dial into the next, and I'll ignore that reminder. Then hours later, I'll wonder why my system didn't tell me that the garage door was left open (when it did, but I was just too busy and ignored it). And of course, if all your schedules fire on the hour or half-hour, well, then the ISY has a flurry of activity not unlike the infamous 3:05AM query, and things get likewise squirrely. I have lots of schedules that start a random times, e.g. 17 seconds past 3:52 PM rather than 4:00PM exactly. - avoid complex from-to events. This thread's existence is based on a discussion about such oddities. It seems that it isn't just humans that get confused with complex conditionals, but also the ISY. We can assume that UDI will fix the ISY's logic problem, but I'm afraid my logic problem is only going to get worse as I age. I prefer to have multiple programs -- the first one is only schedule-based, it kicks off the "if" clause on sub-ordinate programs, which then evaluate the other logic (variables or devices). It's simpler to understand, and the ISY can handle hundreds of programs, so it's not an issue for the ISY to do it that way either. - do not use "wait" as a replacement for a schedule! I avoid long waits in programs - there's just so many things that can cause a program to terminate or restart, such as trigger events, or power failures, etc. Schedules are clear and unaffected -- the from and to times won't shift, and there's a provision to catch up schedules on reboot, even! So, I know that might not fit with the OP intent to clarify schedule obscurities, but life has taught me that the best thing to do is to avoid the edge cases as opposed to trying to define them or even understand them ('cause Murphy's Law says that the moment we all understand all the edge cases, someone at UDI will change something somewhere, and it'll all change...) Edited March 8, 2019 by mwester
simplextech Posted March 8, 2019 Author Posted March 8, 2019 Here's the reason I'm asking about the time: Test.Program - [ID 0007][Parent 0001] If From 12:00:00AM To 12:00:00AM (same day) Then In 'ms.FR-Desk.Motion' Set 'Family Room / fl.FR-Light' To default Else - No Actions - (To add one, press 'Action') From the "editor" stand point it allows it to be entered. From a logical stand point it's the same time and not valid. I've seen this issue/question before about other systems and the valid is use should be... Test.Program - [ID 0007][Parent 0001] If From 12:00:00AM To 11:59:00PM (same day) Then In 'ms.FR-Desk.Motion' Set 'Family Room / fl.FR-Light' To default Else - No Actions - (To add one, press 'Action') So I'm asking/double checking that I'm not missing something with how time works with ISY. However the (same day / next day) is a really nice feature for spanning a time period across two days
simplextech Posted March 8, 2019 Author Posted March 8, 2019 7 minutes ago, mwester said: ('cause Murphy's Law says that the moment we all understand all the edge cases, someone at UDI will change something somewhere, and it'll all change...) I think I found a new tagline
simplextech Posted March 8, 2019 Author Posted March 8, 2019 Just now, lilyoyo1 said: How is your family room scene configured It's not. That was a dummy program that I used to copy/paste from and things I'm toying with so ignore the Then statement it's not relevant. I'm just trying to make sure I understand the use structure of time within ISY versus what the editor allows
lilyoyo1 Posted March 8, 2019 Posted March 8, 2019 (edited) 15 minutes ago, simplextech said: Here's the reason I'm asking about the time: Test.Program - [ID 0007][Parent 0001] If From 12:00:00AM To 12:00:00AM (same day) Then In 'ms.FR-Desk.Motion' Set 'Family Room / fl.FR-Light' To default Else - No Actions - (To add one, press 'Action') From the "editor" stand point it allows it to be entered. From a logical stand point it's the same time and not valid. I've seen this issue/question before about other systems and the valid is use should be... Test.Program - [ID 0007][Parent 0001] If From 12:00:00AM To 11:59:00PM (same day) Then In 'ms.FR-Desk.Motion' Set 'Family Room / fl.FR-Light' To default Else - No Actions - (To add one, press 'Action') So I'm asking/double checking that I'm not missing something with how time works with ISY. However the (same day / next day) is a really nice feature for spanning a time period across two days If you simply want it to turn between 12 and 12 then the second way is how you would write it. However if that's the case I would do away with the time anyway since it's supposed to happen regardless. No use adding extra steps when none is needed Edited March 8, 2019 by lilyoyo1
lilyoyo1 Posted March 8, 2019 Posted March 8, 2019 17 minutes ago, mwester said: Good discussion. But, humans make mistakes, sometimes in coding, sometimes in judgement, sometimes in assumptions... and having spent my life in the field as the guy that parachutes in when a customer's systems go all wrong, I've adopted some seemingly-extreme but generally effective defensive techniques. As they relate to this topic, I'd be worried that whatever we figure out and document on this thread might change should some future programmer at UDI fix a long-standing bug report regarding date/time, or whatever. So, here's my rules for time periods: - avoid midnight, noon, and on the ISY, avoid the 3AM to 4AM hour. As noted above, when exactly is 00:00 tomorrow? Same as 00:00 without any qualifier? Or does 00:00 without a qualifier refer to the very first moment that happened today (i.e. in the past)? Similarly, 12:00 is an error-prone time spec -- is that midnight via 12-hour clock, or noon? And as for 3AM, the ISY is so busy swamped with its queries at 3:05 AM that any schedule starting or ending in the middle of that will at best be shifted by some amount, and possibly even lost (don't know the latter for sure, but I know that node server activity was lost when the system was swamped doing that query back a few versions ago...) - avoid anything on-the-hour. Humans schedule things for the hour. We're funny that way. So, if my automation does something, for example, sends me an alert or a reminder or a notification, I'll be way too busy clearing off one customer conference call and trying to dial into the next, and I'll ignore that reminder. Then hours later, I'll wonder why my system didn't tell me that the garage door was left open (when it did, but I was just too busy and ignored it). And of course, if all your schedules fire on the hour or half-hour, well, then the ISY has a flurry of activity not unlike the infamous 3:05AM query, and things get likewise squirrely. I have lots of schedules that start a random times, e.g. 17 seconds past 3:52 PM rather than 4:00PM exactly. - avoid complex from-to events. This thread's existence is based on a discussion about such oddities. It seems that it isn't just humans that get confused with complex conditionals, but also the ISY. We can assume that UDI will fix the ISY's logic problem, but I'm afraid my logic problem is only going to get worse as I age. I prefer to have multiple programs -- the first one is only schedule-based, it kicks off the "if" clause on sub-ordinate programs, which then evaluate the other logic (variables or devices). It's simpler to understand, and the ISY can handle hundreds of programs, so it's not an issue for the ISY to do it that way either. - do not use "wait" as a replacement for a schedule! I avoid long waits in programs - there's just so many things that can cause a program to terminate or restart, such as trigger events, or power failures, etc. Schedules are clear and unaffected -- the from and to times won't shift, and there's a provision to catch up schedules on reboot, even! So, I know that might not fit with the OP intent to clarify schedule obscurities, but life has taught me that the best thing to do is to avoid the edge cases as opposed to trying to define them or even understand them ('cause Murphy's Law says that the moment we all understand all the edge cases, someone at UDI will change something somewhere, and it'll all change...) I avoid 5s and 0s for that very reason and add a couple of seconds to minimize the change of something happening at the same exact time I want something else to run
larryllix Posted March 8, 2019 Posted March 8, 2019 (edited) 34 minutes ago, lilyoyo1 said: I avoid 5s and 0s for that very reason and add a couple of seconds to minimize the change of something happening at the same exact time I want something else to run I avoid usage of 13s for .....never mind. Wife, two S-I-Ls, and M-I-L were all born on the 13th. Edited March 8, 2019 by larryllix
palayman Posted March 8, 2019 Posted March 8, 2019 5 minutes ago, larryllix said: I avoid usage of 13s for .....never mind. Anyone have an ISY above the Arctic Circle? Sunrise (next day) could be interesting on certain dates.? 1 1
larryllix Posted March 8, 2019 Posted March 8, 2019 Just now, palayman said: Anyone have an ISY above the Arctic Circle? Sunrise (next day) could be interesting on certain dates.? ISY CPU hung ....divide by Zero error ****************
kclenden Posted March 8, 2019 Posted March 8, 2019 (edited) 2 hours ago, simplextech said: Is 12:00 TO 00:00 valid or does it have to be a 12:00 TO 23:59? The only way you're going to know is to test it with a program. Set one variable in the THEN and another variable in the ELSE. Then you can check the time those variables are changed. Still, as mwester says, there's no guarantee that behavior won't change in the future. Case in point - there is currently a bug using "Sunset + x". If "Sunset + x" is before midnight then it works as expected (i.e. it runs every day at Sunset +x). If "Sunset + x" goes past midnight then it only runs every other day at Sunset +x. Edited March 8, 2019 by kclenden
palayman Posted March 9, 2019 Posted March 9, 2019 1 hour ago, kclenden said: Set one variable in the THEN and another variable in the ELSE. Then you can check the time those variables are changed. How do you check them? I am setting a state variable in a program and don't see it in the log. Is there a log setting that I am missing?
palayman Posted March 9, 2019 Posted March 9, 2019 57 minutes ago, palayman said: How do you check them? I am setting a state variable in a program and don't see it in the log. Is there a log setting that I am missing? I see they show up in the event viewer, not the log file.
kclenden Posted March 9, 2019 Posted March 9, 2019 20 minutes ago, palayman said: I see they show up in the event viewer, not the log file. I always look at them in the Event Viewer so not sure if they show up in the log. But even without looking at the Event Viewer, you can look in the "Variables" tab, at the "Last Changed" time.
simplextech Posted March 9, 2019 Author Posted March 9, 2019 17 minutes ago, kclenden said: But even without looking at the Event Viewer, you can look in the "Variables" tab, at the "Last Changed" time. This is what I've been doing... my event viewer is scrolling too much to be able to watch there
lilyoyo1 Posted March 9, 2019 Posted March 9, 2019 (edited) Is what's showing in your event viewer the same exact device? It could be something constantly running which is slowing down your system Edited March 9, 2019 by lilyoyo1
palayman Posted March 9, 2019 Posted March 9, 2019 16 hours ago, kclenden said: I always look at them in the Event Viewer so not sure if they show up in the log. OK, I had a look at them in the event viewer using them to monitor some Insteon commands. Problem is they don't seem to line up time sequence wise with the Insteon commands. They seem to pile up and get recorded in the log in a group sometime after.
kclenden Posted March 9, 2019 Posted March 9, 2019 4 hours ago, palayman said: They seem to pile up and get recorded in the log in a group sometime after. Yeah, I reported that in a different thread. The ISY gives priority to Insteon communication, so lower priority tasks queue up until the ISY has no more Insteon communication to handle. I don't think that there is simply a delay in recording them in the log, I think they don't actually execute until the time displayed in the log.
Michel Kohanim Posted March 10, 2019 Posted March 10, 2019 Just to be clear again: 1. Order of precedence + 2. Short circuit From Time to the same Time is equal to Time Is. So, logically, you can use either. With kind regards, Michel
Recommended Posts