n4bos Posted June 3, 2016 Posted June 3, 2016 I have a program that runs every hour. To implement that, I have a separate timer routine listed below. Hour timer - [iD 0022][Parent 0023]If $s.Cycle_Timer_1 is not 60 Then Wait 1 minute $s.Cycle_Timer_1 += 1 Else $s.Cycle_Timer_1 = 0 This is a one hour timer. $s.Cycle_Timer_1 is a State variable. This program works fine but consistently runs slow... not a lot but in a 24 hour period, it will be off by about one minute. It is reset to "0" at 12:00:00AM. When the counter resets every hour, the update time will slowly get later and later... For example, by noon, monitoring the variable shows it was updated at 12:00:28. I would have thought the timer in the ISY would be crystal controlled closer than that. It is NOT consistent... sometime sit loses more than other times. Anyone have a better timer program or is this normal and to be expected with the ISY944? I'm running 4.3.26 firmware and UI. Thanks, Steve
Techman Posted June 3, 2016 Posted June 3, 2016 It's possible that if you're running a lot of programs or queries that it could effect your timer. There's no other option that I know of that would give you a more accurate count.
n4bos Posted June 3, 2016 Author Posted June 3, 2016 Thanks Techman, I'm only using the timer in one program that dumps data to a "storage" variable every hour so I don't think I'm hitting it too much. I guess it's just the inaccuracy of the crystal. I'm surprised because even a cheap clock is (much) more accurate than that. Steve
Techman Posted June 3, 2016 Posted June 3, 2016 Thanks Techman, I'm only using the timer in one program that dumps data to a "storage" variable every hour so I don't think I'm hitting it too much. I guess it's just the inaccuracy of the crystal. I'm surprised because even a cheap clock is (much) more accurate than that. Steve It's also possible that as your timer program executes you're dropping a few clock cycles.
LeeG Posted June 3, 2016 Posted June 3, 2016 n4bos The problem is result of the Program taking longer than 1 minute per iteration the way it is coded.. The If counts to 60. The Then takes 1 minute + (Wait 1 minute + time to run the remainder of Then). The amount of time taken can be more accurate if the Wait is for a longer time, say Wait 1 hour but this depends on what you are trying to accomplish with timer.
larryllix Posted June 4, 2016 Posted June 4, 2016 V5.xx offers much more accurate methods of doing cyclic timers based directly on ISY's internal clocks..
larryllix Posted June 4, 2016 Posted June 4, 2016 (edited) ISY self cycling clocks can stall for various reasons. Here is my kickstarter program to ensure it will start again. All my HVAC equipment, fan, HRV, and humidifier are synchronised to this clock. The program has been stripped for simplicity of viewing. HVAC.clock.kickstart - [iD 011F][Parent 00BD] If ( Time is 3:10:00AM Or Time is 9:10:00AM Or Time is 3:10:00PM Or Time is 9:10:00PM ) And From Last Run Time for 'HVAC.clock' + 1 hour and 15 minutes For 99 hours Then Run Program 'HVAC.clock' (If) Else - No Actions - (To add one, press 'Action')----------------------------------------------------------------- Here is my 1 hour clock program. HVAC.clock - [iD 0119][Parent 00BD][Run At Startup] If Then Wait 15 seconds Repeat Every 59 minutes $sHVAC.sync.clock = $cTRUE Wait 1 minute $sHVAC.sync.clock = $cFALSE Repeat 1 times Else -- Edited June 4, 2016 by larryllix
n4bos Posted June 5, 2016 Author Posted June 5, 2016 As an update and in case anyone else ever finds this thread... I created two additional timers for testing. One that has no programs depending on it and counts in one minute increments just as the timer in question. I created a second timer that updates once per hour as suggested in the thread. I also added a line to the original timer that sends an email whenever the original timer resets to "0" and tells me the system time. The results: The new "independent" count-by-minute timer loses time at exactly the same rate as the one that is used in the original program so it appears that using a particular timer in a program has no discernible effect on its inaccuracy. All the timers saw their biggest loss at 3:00AM.... when the "Query All" program runs. The "normal" loss for the one minute incrementing timers seems to peak at about 1 second per hour, and seems to be dependent on the activity of the ISY. Both timers that increment at one minute intervals lost about 15 seconds when "Query All" ran and about 4 seconds in the next hour.... Although I don't know exactly when it happened, the count-by-hour timer lost 16 seconds between midnight and 5:00 AM and no more after that. I suspect its loss was at 3:00AM during the "Query All" just like the other timers. That timer IS much better in terms of accuracy, showing virtually no additional loss over a 24 hour period. Overall the message I get is that for the best accuracy, make the time interval as long as possible and be aware that high program activity, like "Query All" will make the timers lose time. Steve
larryllix Posted June 5, 2016 Posted June 5, 2016 (edited) As an update and in case anyone else ever finds this thread... <snipped> Overall the message I get is that for the best accuracy, make the time interval as long as possible and be aware that high program activity, like "Query All" will make the timers lose time. Steve Thanks for the report and information! This seems to be proof that Santa Michel slides down the chimney Ethernet cable into our ISY boxes each night at 3:00am (I hope it isn't aliens causing time gaps).. I see a nickname developing here. Edited June 5, 2016 by larryllix
n4bos Posted June 5, 2016 Author Posted June 5, 2016 Think I'll tie a knot in the Ethernet cable tonight and see if that stops him.....
n4bos Posted June 6, 2016 Author Posted June 6, 2016 Hi Michel, If you can, you might change the title of this thread to "Timer Runs Slow". I was thinking upside down when I wrote it.... Steve
Recommended Posts