When I start a timer with a duration, the countdown starts a few seconds less than the duration. Let’s say i set the duration to 10 seconds; when starting the timer the countdown starts at 6 or 7 seconds. It’s random how much “earlier” the duration is.
To duplicate the issue, just create a new timer with Helpers. Specify a duration. Then open the timer and click start.
I cant reproduce this. This is a 10 second timer:
I tried starting it many times. It always started at 10 seconds.
What hardware and install type are you using.
I’ve noticed this with very short timers where you start the timer from a voice assistant.
By the time the assist has replied with ‘timer started for xxx.’ a few seconds has gone, and the time then displayed on the assist device (in this case an s3 box3) starts showing from around 6 or 7 seconds (for a 10 second timer), but thats because the timer has actually been running for a few seconds already and will correctly run for its full intended duration.
This is an issue when your frontend and backend clocks are a few seconds out of sync.
E.g. a 1 minute timer is started at 12:00PM (backend) and scheduled to end at 12:01PM.
If the frontend thinks it is 12:00:10 when backend is 12:00:00, it will think as soon as you start the timer that it will expire in 50 seconds instead of 60.
The timer will still run for a full 60 seconds, but once it hits 0 in the frontend it will continue to report “Active” for another 10 seconds until it actually finishes in the backend.
This is b cause the front end does not update every second.
Tom_l version works, because he sets and starts the timer and view it right after the action.
If he had set the timer and started it and has a delay, like 3 seconds, then the next frontend update after the start might first occur 2 secs later and he will have lost the viewing of the first 2 seconds, but the timer was started on time and counting correctly.
It’s on a VM, running docker.
How do you sync the back end? I’m using docker and I’d imagine that’s providing the clock.
I guess it downloads from NTP every time it restarts, I don’t think there’s any explicit option.
It does not load from NTP when the timer starts.
It just use the internal clock of the server.
And you can not make it work otherwise.
A frontend controlled clock will still be off, due to the sync issue and 1sec updates of the GUI will be a heavy burden on even a quite powerful machine, so a ESP32 will not be able to handle it.
Check the Host OS of your VM has its NTP client set up correctly.
Also check your PC and phone are set to synchronise time automatically.
It seems my Windows Host was drifting, even though it’s setup properly to update. This program adjusted my time and now the timer is only off one second. I also went into the guest OS and synced that with “internet time” with the thinking that if both Host/Guest use the same source to update then their clocks should be nearly identical. Guess not.
I’ll take this as a “win”.
Your host OS should be able to keep time, but a VM have a hard time due to pauses and slow down, when the host OS or other VMs need resources.
The issue is the SNTP client used by HAOS and replacing it with another SNTP client will not help.
It might correct the time when you run the command, but if it drifted before then it will just drift again after the correction.
Switching to a NTP client instead will make sure HAOS is on time and the Chrony addon is available for exactly this job.
