I have a use case where I want to implement a repeating coded event. It does not have to be super accurate but I do want it to feel like it is "accurate". My first pass was to use the octoprint.util repeatimer to accomplish this but it felt not accurate enough. I can do it in a simple thread+loop and produce a sleep setup but I have a feeling that the Util repeatimer was not create just for fun. Is there something I am missing that should compel me to use the releattimer ?
How far off was it? I use that in several of my plugins and haven't really timed it's accuracy, but seemed to be good enough for my needs with checking status of power plugs for example. It's using a threading.event().wait() with the interval provided, so not sure why that would be any different than a thread with sleep. I think the compelling use case for it is if you want to deal with conditions to continue or handle other callbacks when it's cancelled, etc.
As far as the accuracy. I was seeing as much as 1 second off (almost always long) from one interval to another and it seemed to be dependent on if a print was running or if other plugins were doing things. I got the impression that it was sorta loop checked as part of the greater OctoPrint processing thread. As in if there was a lot to do in that loop, it could take longer for timer event to fire off. Doing the sleep version is very consistent.
The concern I have in just doing it as seems to work the best(thread+Sleep) is if doing it this way is there some potential that the thread could somehow interfere with OctoPrints main job of running a print.
Having the timing be less than accurate in this case would mean explaining why it was inaccurate to a user of the plugin. That I think could create a bit of support over head. If I can avoid that overhead, I will but not at the cost of potentially messing up someone's print.
As long as you set the thread up with daemon=True then this shouldn't be a concern.
Thanks for that pointer. Makes sense. Also makes me realize I have a couple of things I should update to include this. Appreciate the guidance.
Yeah, if you don't do that then when OctoPrint tries to shutdown or restart it has to forcefully close those threads after a timeout of some kind. It makes the process take a while longer than needed. When that flag is set, when OctoPrint starts to stop those threads instantly just quit is my understanding.