NTP Client / Local NTP Server support

I force an NTP sync every 24 hours. Over the course of that time the correction ranges from ~500-900 ms.

Good info, thanks.

I have a power failure detection routine, based upon a systemStart event, that checks the time and sets one of three time-based modes to set all the devices in their proper default state for that period.

I was considering adding an NTP time set to that routine, after a suitable delay for the NTP server to recover and GPS lock, as it is not backed up with battery.

The periodic timer in the function doesn't handle more than 720 minutes. Is there a way to disable that periodic timer in favor of an external Rule so a 24-hour update could be done?

Don

This driver support the Refresh Capability, which is exactly the command called each time the recurring timer expires. Therefore, you should be able to have Rule Machine just call this devioce's 'refresh()' command based on whatever logic you'd like. This will not impact the recurring timer whatsoever, so maybe you can leave the built-in scheduling alone?

3 Likes

I can't figure out how to call the 'refresh()' command from Rules Machine. Since the driver is custom, there seems to be no suitable device in the Custom Actions drop down.

Thanks for any help.

Don

Use Actuator as the device type.

Just choose the Refresh action, as shown below. No custom action required.

2 Likes

Thanks, gentlemen.

Both methods worked fine.

I ended up with:

Regards,

Don

1 Like

Thanks a lot for this. I was looking for it since HE doesn't provide options to point to a different NTP server.

Question: does this driver disable the internal NTP sync process of the hub, or does it work in parallel?

It works in parallel.

Thanks. I hope they'll export some kind of NTP options panel in the settings of the Hub for a better integration.

Over the weekend, I added a USD $10.00 GPS satellite receiver module to a Raspberry Pi 2 to create a Stratum 1 Network Time Protocol (NTP) server.

Most Internet-connected devices (including Hubitat) get their clock time from the Internet, but if connectivity is lost, they are unable to update their internal clock. This addition supplies the ability for my home automation and other devices to sync up to the correct time even with an Internet outage. A pulse-per-second output from the receiver supplies accurate time to a few tens of nanoseconds! The device under the Pi 2 in the video clip is an ADSB radar receiver that tracks air traffic via in a 250 mile radius around my house.

A bit of configuration twiddling is needed to get it all to work, but not too difficult. A cheap and easy upgrade. The unit is on a UPS to guard against power failures.

NTP Server video clip

Don

6 Likes

Really nice. I'll think about it. I have an old Raspberry somewhere I could use.

I was very much surprised about the design flaw in HE clock management. I chose HE mainly because I don't want my automation to be dependent on internet, and that was the approach I immediately noticed Hubitat embraced, and the lack of a battery for the internal clock worsens things. At least they should provide the option to customize the ntp server to sync with, so I could use my NTP servers (my router as main source, and my NAS as my second source, all under UPS).

I hope they will rethink about this in future hw/fw versions, HE is the best hub and community I found, they've done a great job, but this is a big flaw, IMHO.

2 Likes

Take a look at NTP Client / Local NTP Server support

1 Like

Thanks. This one supplements another NTP server on my LAN, integrated into a lightning detector appliance. This one is on a UPS, so should be more robust.

The NTP driver for Hubitat works really well with the new server.

Don

1 Like

We are writing in that thread. :slight_smile:

2 Likes

Yes, and does this not work for you?

It would be "nice" if it were built into the system, but since there is a working and published workaround for this, I'm not sure what the real problem is?

Nope, it doesn't work like it should, otherwise there would be no need of this driver for a basic/critical functionality like internal clock sync. This is a workaround, and works in parallel to the internal ntp sync process, which by the way I read is causing issues to some users (a lot of traffic, continuous syncs every second, etc.). I will start sniffing my network to see if I have this issue, without even knowing.

We are discussing about the fact that if the philosophy of the HE project is to be independent of the internet, having the internal clock dependant on internet availability, and also without a battery to keep the clock from getting totally out of sync, is not consistent nor logical. Hope you now understand what the real problem is.

I love HE, my house and my family are totally dependent on the automation I implemented thanks to it and this great forum, and I recommended it to many friends. I hope this doesn't mean we can't discuss what should be improved. It's called constructive criticism, it's a best practice in smart communities like this one.

Can we discuss? Of course...

but in two years this has been discussed over and over, covering the exact same ground. It's clear the C-3's, the C-4's and the C-5's are not going to get a battery retrofit. What the future brings is unknown to all but the small group of Hubitat Employees, and even there, I bet half don't have a strong opinion.

There's nothing new being discussed unfortunately. And when that happens, in threads like this it turns personal, or ugly, or both. This is a good, educational thread and it would be sad to have it get thrown into the Lounge/Debate Chamber in my Opinion. :slight_smile:

4 Likes

I asked does the workaround not work for you, not whether you think this should be built in to the base system or not.

Duly noted - you feel strongly that this should be in the base system. There is nothing wrong with making feature requests. I'm sure Hubitat has seen the request, and it is on the to-do list.

Last I'll say on this is that it is probably pretty low on the to-do list versus new functionality or bugs, as there is a functional workaround. But only Hubitat knows that for sure.

2 Likes

didn't expect a battery retrofit, we can workaround that with a good UPS. but we could hope for some basic options in settings to manage NTP: ntp-servers list, sync frequency, etc.

But I'm sure this has already been requested since 2 years, I'm late to the party, sorry. :slight_smile:

I don't think so. Sometimes it's good to remind through new users like me that there's some basic stuff missing. No personal issues from my side. I'm a happy user/customer of this product, I hope I can say in this forum if I feel some very basic stuff like 2 ntp options are missing from the hub settings panel, without getting people taking it personally like I talked about their fiancΓ©. It's an automation hub. :slight_smile:

2 Likes