C-7 Hub, v2.2.3.135, NTP Time


I see in the release notes for below a fix for the NTP time sync not occurring after a reboot of the hub when the Internet connection is not immediately available (at least that is what I hope was fixed :wink: )

NTP time validation after hub boot.

So, I decided to run a quick test. I performed an orderly shutdown of my C-7 hub. I then unplugged the Ethernet cable from the hub, and cycled power. I waited a few minutes after the hub came up with a green light, and then plugged the Ethernet cable back in. When I browsed to the hub's settings page, I noticed that the time was still incorrect. I waited about 20 minutes and checked again, however the time is still incorrect.

Was this the issue that was addressed in the latest platform version? Or something different?



Yes, it pings Google NTP server, time.google.com.
I've checked your logs, and see a recurring "could not obtain Google time" message. That makes me think that not every router allows NTP. There are some REST based services out there, but none are major.
I think the next step is publish our own HTTP endpoint and use that. All routers like HTTP.


Interesting... I am running a Ubiquiti Unifi Dream Machine. I have no problems using NTP time synchronization on any machines in my home. If I reboot the C-7 hub, I am 99.99% certain that it will happily sync its time.

I'll reboot it and will let you know the results...

If you had the Internet off across the hub's reboot, wouldn't DNS fail too and thus time.google would be unresolved?

1 Like

As expected, the hub's time is perfect after a simple reboot with the internet access available.

This seems likely to be the root issue... The hub needs to realize the difference between failing to resolve a DNS lookup versus an NTP time sync failure.

If that is done, please consider making it a selectable choice:

(1) Hubitat.com HTTP endpoint (default, if you wish)
(2) Google NTP
(3) our choice of URL for NTP

That would let users spin up their own local NTP or change to Google (or whatever) if Hubitat.com ever went down for some time.


I think the concept of using HTTP for time retrieval is moving farther away from mainstream. It would not have addressed this problem as it appears to be a DNS resolution issue.

Instead of depending upon a hardcoded NTP entity by name, I would very like to see the hub use the NTP/SNTP server provided in the DHCP assignment. I think it's okay to use a hard coded entity as a back up, but if a server is provided in the DHCP assignment it is expected to work. And a DHCP provided entity does not depend upon DNS.


and this one
(4) just use the NTP server returned in the DHCP response (I have one running on my network)


Wouldn't the NTP Client driver by Daniel Terryn be the best route to take if this is a issue with the C7?

Granted I have my own sat/gps network time server at home but this driver should still work using time.google.com right?

This issue has been present for all generations of the Hubitat Hub, all the way back to the original C-3 from my recollection. The hub seems to never recover its time synchronization if it is started up without an internet/network connection. This often happens after a power outage, where the Hubitat Hub finishes booting up faster than some routers/cable modems.


Yes I know that but I would have thought the C7 would have been designed better since then but apparently not. For something that is very important and still not working right after at least 3 hub generations is just sad.


To add, im stunned the C7 still doesnt include a RTC battery.

1 Like

I’m still stunned it will take an NTP assignment from DHCP and do nothing with it. To me this goes against the local/private concept.


I want a pony.


I mean you can poke fun all you want, I feel that taking decades old standards and intentionally ignoring them in favor of some cloud service is short sighted. I mean the DNS used to be hard coded to and at least that is fixed

and the NTP request has been around for a while as well

Not to mention the long term discussion on static IPs.


Yes, I agree that it should obey the DHCP value.

I'm sure it is on Hubitat's "to do" list somewhere. Whether they will ever get to it or not is another matter altogether. :slight_smile:

In the meantime people should use the NTP client driver. As there is a valid workaround, I'm not sure that this is that pressing.


Until you have a slow down or other issue and you need to disable all custom code.

While I personally don't think this is crazy pressing issue, I find this issues to be cause for concern for the other internals of the platform. I think that Hubitat has a great talent pool for things like drivers and groovy code, but I am unsure of the resouces availabe that maintains the actual OS platform and kernel of the device. Its a bunch of small nagging things like these DNS and NTP "Features", the fact that mDNS on the device presents itself as an FTP server, and other issues people have noticed with the network stack (this device has the lowest health rating of any device on my Unifi Network). None of them by themselves is a huge concern, however seeing all them makes my nerdy spidey sense go off.

While I'm not concerned about it at all, I am not arguing with you. I would like to see them change that behavior/add that feature too. :+1:


From a hardware development standpoint adding a true RTC and associated battery/supercap adds components to the board, could increase size of the board, increases cost, increases failure rates, and in the case of a battery complicates shipping. For a device that should be plugged into a UPS anyway, I don't see this as a compelling hardware need.

However, I do think the networking stack should pick up the NTP DHCP option and honor it.