@bobbyD sent me a new c-5 hub preloaded with Hubitat software
I had to go into settings, hub detail, update time from browser (it was showing the year as 2014 or something strange - the time needed to be accurate for things to work)
Then I rebooted, reserved a local IP address for the hub and gave @bobbyD my local IP address for the hub and my public IP address
After instructed to, I did one more reboot and I was good to go.
Note, every time that I power down/shut down the hub and turn it back on, I have to do step 2 over again to have it reset the hub clock to use my browser otherwise the hub says itās not registered. This is a bug Iāve reported to support and hope to see a fix soon.
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.
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.
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.
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.
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.....
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.
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:
