I messaged @dan.t about this, but I'm not sure he's still around, so...
Dan's tried-and-true NTP Client driver is now throwing a warning with every refresh:
I think this started with the previous update (before .172).
Doesn't fix the driver but if you have the IP for the NTP server you could just set it directly using:
http://<Hub IP Address>/hub/advanced/ntpServer/<NTP IP Address>
Interestingly, I'm running 2.5.1.172 on my hubs. The NTP client driver continues to work fine on my C8 Pro:
But it is getting the same errors on my C7:
@gopher.ny is something different on the different hubs?
C8s and C7s have different JVMs IIRC
FYI, I'm getting those warnings on all three of my C-8 Pros.
@thebearmay I've got the "ntpServer" set on all three. Do you happen to know when/how often the system calls that server to (re)set the time?
I know it does one at reboot, and then I believe you get one shortly after the sunrise and sunset events.
My 2nd C-7 isn't using Dan's NTP driver, and no ntpServer is set, so it defaults to using the Google NTP servers. The clock matches my other two hubs (both using Dan's driver). I wonder if I really need the driver at all anymore.
FWIW, I haven’t used it in a couple of years. Still wish the hub would use an NTP server set by DHCP options, but I don’t believe it does. @gopher.ny - is this still true?
None of my IoT devices use the NTP settings delivered in the DHCP payload. It's common for them to only trust their source of time which is sometimes the NTP Region pool, other times google or something else, in worse case their private time server. I have been running stratum 1 servers here at home for over 5 years and have all my DHCP responses have both servers in the payload. My firewall logs show that they are always reaching out.
I did try to capture and redirect the requests to my time server and many times it broke the device.