alx9r Posted March 8, 2015 Posted March 8, 2015 Last night's daylight savings time switch revealed a weakness when using "repeat every x minutes/seconds" programs. Summary Changing the clock on the "Configuration=>System" tab causes programs of the following style to stop running: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 1 minute $Minute_Ticker_s += 1 $Minute_Ticker_v = $Minute_Ticker_s Else - No Actions - (To add one, press 'Action') Reproduction To reproduce the problem, do the following: set up a program like the program above Run the program. programs=>summary should look like something like this: on the "Settings=>System" tab change the clock back 1 hour programs=>summary should show the same program as stopped: Impact Wherever a timer program of this style is used to periodically increment a variable whose value drives other programs, that timer program and all programs that depend on the incrementing value stop working when the ISY's clock is adjusted. The stoppage seems to occur whether the clock is adjusted manually or using NTP as long as the adjustment is large enough. That means that such programs will most likely halt during a daylight savings time switch. They will probably also halt if the ISY's clock is abruptly adjusted using NTP if, for example, the NTP server could not be contacted for an extended period of time, or the ISY's real-time clock drifts enough between regular updates. Workaround? I've been trying to find a workaround that allows me to create a periodically-incrementing variable that continues to increment even after an abrupt clock adjustment. I have not found a solution yet. Is there a way to achieve this? Thanks for your help, Alex
Teken Posted March 8, 2015 Posted March 8, 2015 Hello Alex, This would explain what I saw too last night! Much thanks for that insight as I thought I was going mad with all the other issues I've been seeing as of late! Ideals are peaceful - History is violent
JimsEvilTwin Posted March 9, 2015 Posted March 9, 2015 Noticed this also on programs using a Wait statement across the DST change -- they were interrupted and marked False. A few (but not all) of my other programs which were neither running nor dependent on the Waiting programs inexplicably went False. Easily recreatable. I'm using an ISY994 with Firmware v.4.2.18.
Michel Kohanim Posted March 11, 2015 Posted March 11, 2015 Hi alx9r, Thanks so very much for the details. We'll take a look immediately. This said, every time ISY's time is changed, all programs are reevaluated and since this program has no condition, it will stop unless the other program that activates this program restarts it. What you might want to do is add a comdition that is always true. For instance, a state variabe that is not ever changed. With kind regards, Michel
larryllix Posted March 11, 2015 Posted March 11, 2015 (edited) v5 should be able to fix this. If $systime.minute >= 0 then do code else -- Edited March 11, 2015 by larryllix
JimsEvilTwin Posted March 11, 2015 Posted March 11, 2015 This said, every time ISY's time is changed, all programs are reevaluated and since this program has no condition, it will stop Thanks for the reply. Does this only apply to DST changes or any time change such as a NTP adjustment?
alx9r Posted March 11, 2015 Author Posted March 11, 2015 (edited) Hi Michel, I just tested your suggestion to add a condition that always evaluates to true to the if statement. The program looks like this: 5-second timer - [ID 01BC][Parent 0013][Run At Startup] If $always_zero_v is 0 Then Repeat Every 5 seconds $Second_Ticker_5__s += 5 Else - No Actions - (To add one, press 'Action') I did the following: RunIf (it runs continually as expected) Changed clock back 1 hour (it stopped running) Here's what programs=>summary looks like after changing the clock: You can see that the if statement is evaluating correctly "state=true" but it stopped running "Activity=Idle". I ran this test using both an integer and a state variable. The results were the same. Is there any other workaround I should try? Alex Edited March 11, 2015 by alx9r
Michel Kohanim Posted March 12, 2015 Posted March 12, 2015 Hello Alex, Thanks so very much. I will add this as a bug. I will check to set whether or not there's and easy fix and/or workaround and let you know. With kind regards, Michel
Michel Kohanim Posted March 12, 2015 Posted March 12, 2015 Hi Alex, Just wanted to let you know that it's a confirmed bug (#171) and we are going to work on it as soon as the first release of 5.x is out. Unfortunately there is no workaround. I am sorry. Thanks again and with kind regards, Michel
paulbates Posted March 12, 2015 Posted March 12, 2015 ... as soon as the first release of 5.x is out..... At the risk of a thread hijack, that sounds promising.....
alx9r Posted July 24, 2015 Author Posted July 24, 2015 Hi Michael, This bug just bit me again. Can you confirm whether bug #171 is resolved in any versions of firmware yet? Thanks for your help, Alex
Michel Kohanim Posted July 27, 2015 Posted July 27, 2015 Hi Alex, Unfortunately not in 4.3.x and we are working on it for 5.x. With kind regards,Michel
apostolakisl Posted July 28, 2015 Posted July 28, 2015 (edited) I had requested a system variable "epoch time" in the next version of 5.x firmware and it seems as though Michel said OK to that. Epoch time would become your minute counter, just divide by 60 since epoch time is in seconds. Epoch time is a continuous second counter since 1/1/1970 midnight UTC. So you will never have a duplicate value regardless of time zone or DST. This would not be a program trigger however, so if you need your minute counter to trigger a program, then you will need to make other arrangements. But if you have a program that simply needs to check the current minutes when something else triggers it, then this is perfect. In the mean time, this gives you epoch time. Again, divide by 60 to get epoch time in minutes. This only works in 5.0 firmware. And also, it is affected by time zone and dst, so you'll get repeat minutes or skipped minutes when dst turn on/off. New Program - [ID 014C][Parent 014B] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $total_day = [Current Year ] $total_day -= 1901 $total_day *= 365.25 $total_day += 366 $total_day += [Current Day of Year] $Epoch = $total_day $Epoch -= 25569 $Epoch *= 86400 $Epoch += [Seconds since start of day] Else - No Actions - (To add one, press 'Action') Edited July 28, 2015 by apostolakisl
alx9r Posted March 13, 2016 Author Posted March 13, 2016 My clocks just changed and, like clockwork the timers stopped again. FWIW I have a pretty reasonable workaround working for this: create a program call "Restart Timers" that invokes "Run Program" for each of the timer programs prone to stalling use a control condition from a rarely used insteon switch to invoke "Restart Timers" When the timers stall (which, in my case is three or four times per year), press the designated insteon switch. The timers should start again. Alex
larryllix Posted March 13, 2016 Posted March 13, 2016 (edited) My clocks just changed and, like clockwork the timers stopped again. FWIW I have a pretty reasonable workaround working for this: create a program call "Restart Timers" that invokes "Run Program" for each of the timer programs prone to stalling use a control condition from a rarely used insteon switch to invoke "Restart Timers" When the timers stall (which, in my case is three or four times per year), press the designated insteon switch. The timers should start again. Alex Anytime I use the "repeat Every x time" loop I always include a few daily triggers to restart should this fragile structure stall. If time is 12:01 AM Or time is 6:00 AM Or time is 12:01 PM Then repeat every 1 minute xxxxxxx Else -- Edited March 13, 2016 by larryllix
larryllix Posted March 13, 2016 Posted March 13, 2016 (edited) My ISY clock jumped and caused an ISY Query at 3:00 AM last night. This resulted in an I/O Link sensor to report the wrong status and I spent some time investigating why my PV battery charging system failed at 3:00 AM ! I have saved the logs but haven't figured out why my ISY was doing a query at 3:00 AM when I have mine set to go at 4:00 AM each night. I also have to figure out where the false report came from, the inverter algorithm, the I/OLink, wiring, or ISY. Some other program non-completion happened, cancelling my beepers from shutting off. We woke up to two BuzzLinks beeping continuously instead of the allocated 2-3 seconds worth. grrrrrr...... Edited March 13, 2016 by larryllix
DennisC Posted March 13, 2016 Posted March 13, 2016 My ISY clock jumped and caused an ISY Query at 3:00 AM last night. This resulted in an I/O Link sensor to report the wrong status and I spent some time investigating why my PV battery charging system failed at 3:00 AM ! I have saved the logs but haven't figured out why my ISY was doing a query at 3:00 AM when I have mine set to go at 4:00 AM each night. Hmmm, not sure if you follow DST at your location, but clocks changed last night. Wonder if timing was out of sync..... Dennis
Recommended Posts