My DHCP server put's out the time server info and the Hubitat doesn't use it. Neither does a few other devices like Ooma, Vizio TV's. etc.
I put a log rule to count NTP packets from the HE about a week ago, it has logged precisely zero packets. So I think we can assume HE is not running ntpd. Probably it runs something like ntpdate only once at boot time and then is free running thereafter. I would expect to see some drift over time if that was the case, and indeed my HE time is about 8 seconds off ntp time right now, my hub has been up 15 days.
So to the HE devs, it sure seems like running the ntp daemon would be a good idea to a) keep it synced, and b) to let it sync by itself if ntp isn't immediately available at boot time.
1 Like
+1 to the feature requests to both:
- Allow us to specify a NTP server, I run one locally on a rPi that with a LONG battery backup
- Actually run ntpd or regular ntp updates to ensure the local clock doesn't drift too much
3 Likes
Thanks for your work on this Jon.
There doesn't appear to be a way to set the time in the browser. And this "locally running" Hubitat needs internet, but only uses it once when it boots? Why not just let user set it than? Sheesh.
I'm starting to wonder what I got myself into.
You can set it in the browser, its under Settings Hub Details.
I haven't verified this locally yet but you could potentially have your server that runs ntpd for your local network cron this curl command (with your hub's IP):
curl 'http://192.168.0.999/location/updateTime' -H 'Content-Type: application/x-www-form-urlencoded; charset=UTF-8' --data "`date +"%d %b %Y %l:%M:%S"`"
The Update Time from Browser Time button just does a POST to that /location/updateTime URL with a string formatted like '19 Sep 2019 10:11:22'
3 Likes
Looks like it doesn't like the left-padded hour, but it does work with a 0 padded hour.
I just verified this works locally for me (change hubitat to your hub's IP/hostname)
curl 'http://hubitat/location/updateTime' --data "$(date +"%d %b %Y %H:%M:%S")"
I guess the next step is to package this into a shell script, handle the responses, and alert you if there is an error. The two responses I see look like:
{"status":"time changed successfully","currentTime":"2019-09-21 9:30:01 AM PDT"}
{"status":"time changed failed","currentTime":"2019-09-21 9:31:06 AM PDT"}
Both are returned with a HTTP 200 status code.
Just a little teaser: in 2.1.5 there will be a method available to drivers and apps to set the hub time. It will accept a Date object.
4 Likes
Yay! well I'm not going to bother with any more effort then.
Any chance we could just configure a ntp server target and have the hub just run ntpd?
If not sounds like 2.1.5 will let us create a ntp proxy app.
It's one of the many items on the list of improvements. We actually used to run ntpd but shut it off and now use a call to a server to sync time due to some ISPs blocking ntp (I'm looking in your direction at&t!)
1 Like
But that's a cloud dependency......
I was thinking with your solution a driver could call the router and get the current time, from a quick look it appears there is an API and you can call it to get the current time.
1 Like
Yes that will certainly be possible. For now, I have been fine-tuning a script that runs on the Mikrotik to do the updatetime http call periodically. Ill post it here when its been tested a bit more.
I think in fact the hub still does do a udp/123 ntp call at boot time, perhaps its ignored?
Awesome... I have been working on an NTP driver... But HE does not response to http post calls made to itself...
I have a NTP driver done that can sync the time from a local NTP server, just waiting for the hub release to come out and then I release it.
5 Likes
This is great, I am about half way through writing an NTP client driver also. I have it requesting the time from the server and parsing the reply into a timestamp. Im also awaiting the built in commands to finish it up. Im sure @dan.t 's will be an awesome driver.
Take a look here:
