One thing I noticed (it may/may not help you) when I was having an issue with my 2 new hubs not updating time after reboots (they were an hour ahead of my coordinator hub) so after each reboot I had to go to hub settings and update time from browser to fix.
After I went into "Locations and Modes" setting and added my postal code, then moved the "hub icon" on the google map to my actual current location....
I no longer have any issues having to update the time after reboots.
As always, I do appreciate the suggestion. This did not fix my issue with shutdown/restart causing me to have to sync the clock to my browser, unfortunately.
@bravenel
I have to agree with not forcing the ntp pool as this should be a setting instead that defaults to the ntp pool.
For me this is a problem because my network is already a Stratum 2 time clock and my network time is part of the ntp pool.
Your profile is currently public , mark it private
Email: sgrayban@removed
Hostname: time-clock.borgnet.us
IP: 63.230.134.161
Current score: 17.7
Stratum: 2
Zones: @ north-america us
My first post. And it's a necro-bump, sorry. This thread is top google hit.
I'm a wink refugee.
Hubitat Elevation not impressing this am.
Currently running version: 2.2.0.128
Power out yesterday at ~4:00pm. Restored around 11pm based on the oven clock. This am, internet is up (albeit slow), and nothing sunrise dependent on the Hubitat executed. Hubitat thinks it's 11:11pm on the wrong day.
I gather from this thread that the internet was not up when the Hubitat booted. OK, can't control that. It was also implied somewhere that it would continue to check NTP (hard coded).
So, how come my Hubitat, which by my observation had an internet connection, could not get it's bearings in the 6 hours 'til sunrise to actually do what I told it to do?
Pi Hole: I have a pi hole, and the router will tell all DHCP'd devices to use it for DNS. I gather from this thread that the point is moot because DNS is also hard coded in the Hubitat to 8.8.8.8.
Router DHCP will hand out a 'static' ip to the Hubitat's MAC ID.
I see an update is available, and I will now go update.
But given the above I would have expected it handle this and calc a correct sunrise, and update it's time.
There is a community NTP Client driver available to update time based on a local ntp server:
Welcome to Hubitat!
A small UPS for the Hubitat Hub is really a best practice to ensure it can run smoothly through power blips/outages. It does not have a built-in battery backed up RTC, thus it needs to be able to access the Internet to set its clock. Unfortunately, if the Hubitat hub is up and running before your DHCP server and Internet connection is up, it seems to get itself into trouble with respect to automatically correcting its time.
My advice to you is to send your 'feature request' to support@hubitat.com to make sure this issue stays on their list.
I have my Hubitat hub, cable modem, and router all on an APC UPS. This has completely avoided this issue for me. Also, since the hub is really a full computer, running everything locally including a relational database, losing power can result in corruption of its internal database. The hub can usually detect this, and will restore a recent automatic internal database backup. However, if you had added new devices and automations that same day, those changes might be lost as the automatic backup occurs at ~2am each day. Make sure you manually download a Hub database backup after making significant changes.
Yes I saw that in my searches. However the author mentions 'via API call', and it is not clear to a Hubitat noob how to enable this feature, assuming I had a time server on the network, router does not appear to support it, so I have some pi's around, I could do that. But first I must figure out how to enable this feature.
Via an API call in the driver code - no enabling necessary. After saving the driver code, Create a virtual device and change it to the code then fill in the properties and you should be good to go.
I suppose this a reasonable thing to do.
So what if the outage exceeds the hold up time?
And I then there is the constant lead acid battery issues with APC.
Is there a consensus Li-Ion battery bank solution?
You can also point the NTP Device to an Internet based NTP Time server, I believe. Youāll need to figure out the IP address, though.
Wait - how often have you encountered this?
Genuinely curious, because I've had APC UPS units dating back to the early '90s, and I've never had a lead acid battery in an APC UPS leak on me.
I've had batteries lose their capacity to retain a charge and have replaced them when that happens. I have an APC unit at work that dates back to December 1999, and have replaced the batteries in there probably 2 or 3 times. And even that old behemoth remains compatible with apcupsd.
Then, you have to make sure that your Hubitat hub is rebooted after the other devices come back online. No real way around a long-lasting power outage, except a whole home automatic backup generator.
Good point. Also, this is a good reason to use some method of detecting power outages so the Hubitat (and other devices) can be shut down gracefully before backup power runs out.
Hence my use of apcupsd ...
Almost every week where I work, with 80-100 rack-mounted units scattered around the facility in every wiring closet. I just received a new alarm overnight for another APC unit that failed its bi-weekly self-test with less than 2 years on the batteries.
Ever since Schneider took over, APC has definitely jumped the shark.....
Agreed. I refuse to buy APC at work for this same reason.
S.
Nice idea.
I have a GPS-disciplined stratum 1 NTP server on my LAN that provides NTP services to the house regardless of Internet status. I'd like to see this as well.
Regards,
Don
At one point, I pleaded to convert all of the edge closets to equipment that could run on DC from telco-style battery piles to get away from APC. I had one blow me across the room as it threw a plasma-type arc bubble out of the front panel while I was trying to turn it on, with no emergency battery disconnect to shut it down while it went "China Syndrome" other than using a screwdriver to remove the front panel to pull the battery plugs inside the melting down unit! Needless to say, there is no APC in my house.
Also, one "bit" me a few years back while handling the battery pack:
The only good thing about this is that the electrical burn self-cauterized, with no blood lost and no infection.....
You can use @dan.t's NTP client that installs as a driver to set the time on your HE from your own NTPd.
Looks like this:
I force an update via NR once a day.
Wow, great! Will try it tonight!
Don
Download the Hubitat app
