C-7 Hub, v2.2.3.135, NTP Time

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.


It's on my list, just haven't been high enough priority so far.


I'm sure most/all of us are much happier that you are working on your higher priorities!!!!

Also a continued thank you for taking the time to respond on these forums. I think it really helps connect HE with the community..

:clap: :raised_hand_with_fingers_splayed:


Would an offer of beer or cookies help things along?


1 Like

+1 To not going HTTP to a Hubitat server for time.

Why implement such a custom, proprietary and cloud based solution for a device that is supposed to be able to work all Local Only, and dispose a proven and sound protocol that has been the standard used across billions of devices around the world for decades?