Offline Hub cannot keep accurate date time


If my clock randomly goes to a different day / time without reboot, is this a concern?


Obviously would depend on what you define as random.

What date does it randomly go to and when?

I'd probably open a support ticket since I've never heard of this before.


Thanks for asking. For me, it goes back to 7/30/19 which was when I originally bought and installed the device. However, other users have also mentioned this issue on thread (Offline Hub cannot keep accurate date time) as an example.

I did reach out to support on this (case: 14077). Do you think you can help investigate?


When does it revert? Is it nightly? What happens when you manually update the time?

Are your rebooting via the web interface or just pulling the plug?


It happens nightly. Manual update fixes it. Not rebooting at all.


You are not the only one. My unit started doing the same. Seems to happen every night around 20 after midnight. The date gets thrown back to May.

dev:1932019-05-14 20:04:49.799 debug[name:switch, value:off]

dev:1932019-05-14 20:04:49.792 debugdescription is read attr - raw: 36630300060800001000, dni: 3663, endpoint: 03, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

dev:1932019-08-13 00:23:20.483 debug[name:switch, value:off]

dev:1932019-08-13 00:23:20.475 debugdescription is read attr - raw: 36630300060800001000, dni: 3663, endpoint: 03, cluster: 0006, size: 08, attrId: 0000, encoding: 10, command: 0A, value: 00

dev:1312019-08-13 00:23:01.076 debugreturnedresult: status=open|time=2d|sensor=0|base=4085|signal=-61

After that time on the unit starts to skew and is not correct. It is 10 hours since the logs recorded the time issue and hubitat thinks about 5.5 hours have passed.

When synced with browser it seems to keep time till what ever is happening hits.

I have tried reboots , shutdown and power up and different versions of hubitat code. So far no luck in finding a fix


Thank you all for your feedback. Engineers have identified an issue and a fix will be deployed in the next release. A manual fix is available for those who would like the time issue fixed sooner. Please PM with your Hub UID.



  1. set up one or more of your own time servers on your private network (rapsberry Pi's are good for this as well as #2 & #3) You can link to external stratum 0/1/2 servers, or use a GPS hat on your Pi for truly Internet-free time services
  2. set up one or more of your own DNS servers on your private network
  3. set up your own DHCP server on your private network (I can recommend using dnsmasq to do both #2 &#3)
  4. create an alias that redirects whichever * and other timeserver group(s) that Hubitat (and any other servers you have within your local network) that points them to your time server (not sure off the top of my head which ones Hubitat uses)

I've done this, and virtually every device in my house (including visitors' phones) has the same exact time within a few milliseconds of each other...


I have this setup on my asus router and it works great. It solved a lot of problems but I believe there is a different issue causing the date to fall back at 20 minutes past the hour for some people, myself included. Which hour it happens may be different depending on the timezone. I am ET and my date gets rewound at 10:20PM each night.


My hub is not offline and time and date is correct in settings. However, I just did a backup and it put tomorrows date on it.


I agree with storageanarchy, I have a Pi with time services running and a RTC module in case it boots with no internet to sync time from. I have set the DHCP server to assign the time services to the Pi if the DHCP client supports it and also I have about 8 different aliases that captures the Microsoft, ooma, and other devices that use hard coded time name lookups. It took a while to make sure all my devices got their time from the Pi but it was worth it.


This is the list of DNS time server targets that I have aliased to my local timeserver (a stratum 0 server using the rPi GPS hat):

I guess I'm missing some, because I don't have one for Microsoft - @ronv42, would you mind sharing your list of aliases?


@storageanarchy, I have 2 and 3 configured with dnsmasq. What do you use to setup the ntp server on your pi and do you see any problem with using the same pi that runs dnsmasq as the ntp server?


It depends a bit. If you use a stratum 0 or stratum 1 setup (getting the time from a radio like GPS with PPS) then no, it shouldn't affect anything. If you setup a "normal" NTP server (stratum 2), it will get the time from the internet. You need to be careful with your DNS redirects so your NTP server can actually get the time from the internet and won't be redirected to itself by the DNS server.

Makes sense?

In regard to how to set it up, do you have a HAT module on your PI or a GPS module that supports PPS? If so, you can go completely "offline" and use the time from GPS but the setup is a bit different.


I don't have a hat or a GPS module. It looks like have reading to do on this (no clue what stratum 0/1/2 means). I'll do some googling to wrap my head around the terminology and options so I can at least ask more intelligent questions.


That means that you want to setup a "stratum 2" time server. Look for a "standard" NTP server setup, like this here:

Next, you need to figure out which DNS queries your system uses to redirect them via DNS to your NTP server. @storageanarchy gave a good start here:

The easiest to redirect these dns names to your local NTP server is to add entries in your /etc/hosts file where 192.168.XXX.XXX is the IP of your NTP server, like:


Now, you need to make sure that your NTP server setup does NOT use any of these NTP servers. In the /etc/ntp.conf you configure the servers to use. The guide I send you uses *
Make sure that you actually get the time from these servers and not from you own.


It is trivial (seconds) to setup a stratum 2 time server.

To do a stratum 0 setup like Dan did is obviously more work - for instance no GPS that I tried would work inside my house. I could get it to work if I put the rpi next to the window, but that wasn't a good option for me and I don't want an external GPS antenna. So I live with stratum 2.

For the redirection, it depends on the network setup. In my network I just redirect all port 123 traffic to my local time server (except the time server rpi IP itself - so it can get time externally). No need to redirect all of the pool DNS that way.

Of course none of that above helps with Secure ntp though (not to be confused with sntp = simple ntp), obviously... Encrypted connections don't like to be redirected to a host they weren't intended for...


This is the most elegant solution as it is transparent. Some routers don't let you do that though. E.g. I have an ORBI mesh network and the granularity of firewall rules is really geared to the the "standard" user.

100% agreed, nothing you can do there outside of breaking it completely......


True. Luckily (?) most keyed/authenticated NTP setups I've seen still use port 123, so they get broken automatically on the port redirect method. Which I'm fine with.

Of course, nothing stopping anyone from using a different port for NTP requests, then it is a cat and mouse game (or a protocol identification/fingerprint game - depending on the technology available and complexity/admin burden you want).

Oh, one more thing.... If you have Docker available, there are a number of containers that implement NTPD as a stratum 2 server. Can spin one of those up in <10 seconds (if you are a Docker user, of course, and if you aren't, you should be. :wink: ).


I have: **odd one sometimes android use this other times U.S. Regional's