Posts: 1,505
Threads: 143
Joined: May 2007
I am using the Timer driver to help with determining the Runtimes on my AC Units along with the RunTimer driver - I didn't realize the Count Up timer resets on system restarts, which definitely defeats the purpose of keeping Daily, Weekly, and Monthly percentage run totals.  
I could always save the time when the daily, weekly, and monthly timert was reset, and then place them in the timer on the reboot, but from what I can tell that is not possible based on the Docs.  Is there a way?
I guess an alternate method would be to use another field in the RunTimer driver, since that retains the data.
Posts: 1,505
Threads: 143
Joined: May 2007
I am thinking I overthought this too much, if I just save the time I reset into the CQC Variables driver and have it persist, I think this would solve my problem, and I wouldn't need the Timer Driver for anything, just the RunTimer Driver.
Posts: 40,483
Threads: 491
Joined: Aug 2002
09-11-2018, 05:51 PM
(This post was last modified: 09-11-2018, 05:52 PM by Dean Roddey.)
The logic server has an elapsed time field for this type of purpose, but that will also reset if you restart the system. Any type of field data would. It's particularly nice in that it will automatically count up the time that a field in a particular state, not just how long since some particular time. So it would do a lot of the work for you, but it's not persistent.
What you are wanting is really more of a historical data collection thing, which is sort of beyond the scope of the timer or logic server drivers. There is a third party database logging driver that is useful for that types of things.
You can ask the variable driver to persist particular field values. So if there's some clear point at which you want to store a time stamp and then calculate from that, you could create variable driver fields for those. You can also use the SetFldDefault field to force it to persist one of the fields' value. So, if there's a known point at which they need to be reset, you could reset and them and proactively ask the variables driver to persist the new value right then. Then it would come back up with that after a restart no matter what.
But, if the other timer driver persists the info, that would probably be easier.
Dean Roddey
Explorans limites defectum
Posts: 1,505
Threads: 143
Joined: May 2007
(09-11-2018, 05:51 PM)Dean Roddey Wrote: But, if the other timer driver persists the info, that would probably be easier.
Yes, the RunTimer driver does persist, so setting a Variable Driver Start Time that persists, and subtract it from the current time allows it to handle it.
I am now testing RunTimer2, which rbroders wrote as an upgrade from RunTimer.  It keeps a running 24 hour total, which I like much better, so will probably go to that.  It will also allow you to have one driver for all 18 of the runtimes I want to track, which would require several instances of the older RunTimer.
Posts: 40,483
Threads: 491
Joined: Aug 2002
One of these days I'll do a more full featured timer type driver. It's something that would be useful.
Dean Roddey
Explorans limites defectum
Posts: 4,225
Threads: 365
Joined: May 2005
Which run time driver are you using?
I use the one that was crated a few years ago - its listed as Run Timer by Beezleware. As far as I remember it does not reset when the server restarts - but I could be wrong - I have not look at it for a long time as it just sits there working for me.
Mykel Koblenz
Illawarra Smart Home
