NTP Client / Local NTP Server support

I think that you're right!
It looks like it's not happening again.

Thanks!

2 Likes

If I am reading this right, I can use this to make sure the time is getting updated even without a local time server? How does one get the IP of a remote time server? Or determine which one to use?

I really don't think it makes sense to set this driver up with a remote server. That is exactly what Hubitat is already doing today. It uses NTP with a remote server.
This driver allows you to specify any NTP server, but it is really meant to provide an ability to use a local (on you home network) NTP server.

You can set it up with a remote server, no questions, but you don't gain any benefit.

To get the IP of a remote NTP server, you can just use ping, e.g.:

ping pool.ntp.org
PING 171.66.97.126 (171.66.97.126) 56(84) bytes of data.
64 bytes from 171.66.97.126: icmp_seq=1 ttl=39 time=62.7 ms
64 bytes from 171.66.97.126: icmp_seq=2 ttl=39 time=62.7 ms
64 bytes from 171.66.97.126: icmp_seq=3 ttl=39 time=62.7 ms

The IP would be 171.66.97.126

1 Like

I guess what I was thinking here. I read somewhere that HE checks the time at midnight or something. If it couldn't read the time then it would be 24 hours before checking again. But I may be mistaken on that. So many posts to look thur it's easy to miss something.

The max drift in 24 hours would be on the order of a few seconds. As I understand it, @dan.t's NTP client, along with a local ntpd, solves an issue where HE gets hung booting if the internet is unavailable.

Yes, that is really where most, if not all, of the problems have been seen.
e.g. After a power outage, your Hubitat and Internet Modem boots up. Most of the time, your hubitat boots faster than your internet being available and Hubitat can't get the current date/time. That is where my driver comes in, it can check a local NTP server and set the hubs time and it can do it on a configurable time interval.

2 Likes

I am not sure if that is 100% accurate, but even if it is, the problem only comes in if the hub time was wrong in the first place. Based on my testing with this driver, I have not seen a large drift of time by the hub that would justify the need to check a NTP more frequently.

1 Like

I see very little drift on my Hubitat I do run this just to be safe and have it connected to my Stratum 1 Raspberry-PI time server. I also capture port 123 requests on my router and re-write the requests to go to my Pi. I got tired of Android, Apple, and the others that want to use their own time servers.

The Pi was a geek project to work on with my son and we stood up Pi-vpn, Pi-hole, and the time server as a summer project.

What are using to keep Raspberry’s time up to date?

@ronv42 says its a Stratum 1 RPi, so it has to be directly connected to a hardware reference clock.

2 Likes

A Stratum 1 server receives its time from a GPS receiver that is connected to the PI and delivers the time intervals in pulse per second

5 Likes

A GPS receiver...

3 Likes

I added a line to the minTimeDiff enum -

1000 : "1 Second",

As I noticed my two hubs were in a persistent >4 second time difference from each other. Is 3 minutes really the minimum time difference that should be respected before updating the local time from the server? Seems like a very large drift before correcting!

I just tried to do a new install with this month's new version, and received this error:

"unexpected token: else @ line 110, column 5."

FWIW, there is already a report filed on GitHub from someone else who received the exact same error.....

1 Like

I had a similar experience with a first time install
Rolled in the previous version FROM HERE and all is up and running until newest update is fixed

1 Like

tagging @dan.t

I think the issue is simply a missing 'if' on line 108's 'else' statement. It should be an 'else if'

Try changing the code as shown below

From

    if (Integer.parseInt(settings.pollInterval) < 60)
        schedule("0 0/${settings.pollInterval} * 1/1 * ? *", refresh)
    else (Integer.parseInt(settings.pollInterval) == 60)
        runEvery1Hour(refresh)
    else
        schedule("0 0 0/${Integer.parseInt(settings.pollInterval)/60} 1/1 * ? *", refresh)

to

    if (Integer.parseInt(settings.pollInterval) < 60)
        schedule("0 0/${settings.pollInterval} * 1/1 * ? *", refresh)
    else if (Integer.parseInt(settings.pollInterval) == 60)
        runEvery1Hour(refresh)
    else
        schedule("0 0 0/${Integer.parseInt(settings.pollInterval)/60} 1/1 * ? *", refresh)
2 Likes

Thanks!!! Yes, that was the issue. I corrected that on github.

5 Likes

I added the "if" to line 108 earlier this week, and it did install on the HE after that. Just wanted to be sure that the change didn't break the logic, since compiling cleanly doesn't necessarily mean that it will still work.....

@chuck.schwer -- is this still true:

I'm running 2.2.0.126 on 2 hubs, and just checked them and the time on both were wrong. One was more than a minute behind correct time, and the other almost a minute ahead. Neither have been rebooted since I updated to 2.2.0.126. If checking for time nightly, they shouldn't be off by this much at 7am. I saw this thread and thought I'd use this driver to set up NTP checking, but according to your posts that should not be necessary. Could Hubitat perhaps add the option to specify the NTP server, rather than hard coding in your own (or whatever you are using)? In any case, how can it be that mine are off by so much if they check time every day? I reset them from my browser, but still that should not be necessary...

Wow, this works perfectly!

I have a Stratum 1 GPS disciplined NTP serve on the local LAN. It's actually part of a lightning detection network that use nanosecond-level accuracy GPS time to measure the arrival time of detected lighting strikes all over the world and triangulate those with detected events from other stations. The local NTP is an added feature of the home-built unit.

The unit use the PPS (Pulse Per Second) rising edge signal to get the nanosecond-level accuracy. This NTP code here can't do that, but even with the local delays in the LAN and devices, I'm getting 35 ms difference between NTP and Hubitat time.

NTP_Server

Great job and many thanks!

Regards,

Don

2 Likes