Timer runs fast

[n4bos]

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]

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]

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]

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]

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]

V5.xx offers much more accurate methods of doing cyclic timers based directly on ISY's internal clocks..

[larryllix]

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
       --

[n4bos]

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]

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.

[n4bos]

Think I'll tie a knot in the Ethernet cable tonight and see if that stops him.....  

[Michel Kohanim]

LOL!

 

With kind regards,

Michel

[n4bos]

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