Victor,
I see in the release notes for 2.2.3.135 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 )
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...
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.
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.
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.
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 8.8.8.8 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.
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.
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.
)
