Hubitat needs the local time to be correct for various local services to work (eg. time-based Automations). It currently uses a hardwired, Internet-required, Time service (eg. pool.ntp.org on a C5) to get this information (initially, upon boot) and refresh/update it over time (for drift)
As an alternative, it's provided a manual over-ride, allowing a user to set the time based upon the Browser's time.
Hubitat doesn't have a battery backup for it's RTC, so if Hubitat goes offline whilst it's disconnected from the Internet (eg. it's intentionally standalone) then the time will be lost and certain automations either may not occur, or may not occur at the expected time)
Issue
There are a number of discussions that are all rooted in issues with the NTP that's required to get time in sync. They're not all related to the disconnected use-case, but they're all indicating how sensitive the device is to it's environment, esp when NTP may be blocked (eg. by the ISP).
Formally add the ability to over-ride the time server (host, port) that's used by Hubitat (so it can truly be detached)
Specifically:
a) Provide an end-user settable (persisted) config that specifies the NTP Server to use.
b) Observe the DHCP Option 42 (NTP Server) settings, as an override for (a).
Ths setting is currently requested during Hubitat's boot/DHCP cycle, but the DHCP NTP-Server response is ignored. I have mine set to use my Router, where I can configure how to source the information.
c) If neither of the above it set, fallback to the current default (pool.ntp.org, IIUC)
With these in place you'll provide users, with tricky and/or disconnected operating environments, with a way to (automatically) setup the time in all the correct places.
The C4 seems to use Canonical's NTP servers, which indicates its likely running Ubuntu.
A big +1 vote here for this feature. In particular, the DHCP Option 42.
I would add that the NTP client needs to try the servers for longer after boot and more often too, and keep trying if it cant find one. The problems I had with time being wrong after power was restored after a lengthy outage would not have happened had the HE tried a few more times before giving up.
C5 owner here - I am impacted by this issue, My ISP is not blocking access to pool.ntp.org servers (verified via tracert and ping).
Ever since I shutdown/unplugged my hub and rebooted it, my C5 has been going crazy trying to hit #.pool.ntp.org ever 1-2 seconds. Here's what I see via my Pi. The slight dip was when I had my hub unplugged for 5 minutes.
I've tried changing my DNS from Cloudflare, to OpenDNS, to Google (8.8.8.8) and nothing seems to enable the C5 Hub to feel satisfied and stop it from continually trying to access #.pool.ntp.org. I can reproduce the issue where my hub tells me to register and my clock on the hub becomming incorrect by simply going to settings > shutdown then unplugging and plugging the hub back in.
@craigspree
Try setting the time manually once, via the Button at the bottom of the Settings / Hub Details screen (Update Time from Browser Time)
I suspect once it’s initially right then the subsequent NTP calls will go through (no significant drift)
It shouldn’t make a significant impact as to which DNS servers are used, although the geo-DNS may return slightly different IPs, depending upon which one you’re asking.
That was the first thing I tried. If I don’t do that, then the hub tells me I need to register it and goes into an infinite loop of trying and failing to register.
Thus, I need to set the clock to match my browser via settings and reboot the hub. But the #.pool.ntp.org requests continue to persist at a high pace with no variation in duration or volume.
I've also got an issue with pool.ntp.org being blocked by both ISPs available here; however, I have had zero response from support, and basically have a non-functional hubitat from the day I bought it.
@craigspree Can you tell me what the resolution was?
I did, emailed; the day I received the unit, which was a few days ago now. I have not received any response yet however.
I can 'sometimes' get into the UI, but it's minutes at a time between when I can load a page and not, and navigation, changing any settings, etc., is next to impossible.
When I do get in, it tells me something similar to the OP, wherein it says it's unregistered, I register it, or it says it's already registered, or it registers okay then moments later says it's not registered again, etc...
Browser time is set; I've been deleting stock apps to try and get things back to factory as there doesn't seem to be a factory reset.
Browser timeout, 404, empty page, sometimes get to the UI.
Those are symptoms of network trouble. You have a duplicate address? Did you set a static address in your router so that DHCP will give the hub the exact same address each and every time?
Do you have IPv6 running? (a report several months ago had that as a cure for something similar.)
IPv4 reservation set, no network issues. 404 is an http response direct from the hub. Known good wired connection, verified with other devices at high bandwidth. Eyeballing TCP/UDP traffic, connections there, the hub itself is just not replying, or doing so slowly enough that things seem to spin forever.
4th try at registering, it's now downloaded the update and said it was applying it. Now it's been sitting a minute or two at 'You will be automatically redirected to your Hubitat Elevation.'
Interface has now finally loaded, went through the intro slides and into Settings, same 'Cloud connection is unavailable' system message, and 10-20 second page load times.
Ok, you have a "fresh Hub" -- how about a full and complete power cycle? Settings, shutdown, when the light goes RED, pull the power, wait 10 seconds, plug it back in and connect again??
You do have a network problem.. just not clear where it is. The power cycle I just advised was targeting a wobbly hub ethernet connection.
I have a brand new hub too.. it's my 4th one, but still, it's new to me AND my first C-5 (with internal radios.) I received it on Saturday.. so.. 6.5 days ago??
I followed along with my advice, factory resetting, shutdown, etc. I even went into my DHCP and gave it a different IP. It got re-registered and now portal sees it at the new address. Exactly as I'd expect, all with sub second responses... which is to be expected for 1.6ms ping times.
64 bytes from 192.168.7.65: icmp_seq=1 ttl=64 time=1.62 ms
64 bytes from 192.168.7.65: icmp_seq=2 ttl=64 time=1.45 ms
64 bytes from 192.168.7.65: icmp_seq=3 ttl=64 time=1.46 ms
64 bytes from 192.168.7.65: icmp_seq=4 ttl=64 time=1.51 ms
64 bytes from 192.168.7.65: icmp_seq=5 ttl=64 time=1.46 ms
That's yet another indicator that a network problem exists for the Hub. It can't 'phone home' and is telling you twice. It can't reach the cloud, and because of that, can't reach the registration server.
The registration server "need" is usually time related. The hub is on EST and should be on Pacific, for example. In settings there's Hub Details where you can set the Hub's time based on your browser. Then a reboot would generally fix the registration issue. But your's probably would not because, there's no cloud connection either.
I sent off an email to support@hubitat.com and got the robo response in a couple minutes.
it contains the assigned case number:
Thank you for contacting Support Services at Hubitat. Your request has been received outside of our normal hours of operation and will be reviewed by our support staff during the next scheduled business day.
Our hours of operation are 9:00 am to 6:00 pm EST.
In the meantime, you can find user documents at docs.hubitat.com.
Hubitat Elevation also has a very active community with many friendly members ready to offer assistance outside of our normal business hours. Search answers or post your own at community.hubitat.com
You can reply to this email and add any comments to your request that may help us better serve you. Please be sure to refer to case number: 12858.
