Looking at my UDP data coming from my ‘Tempest’ Hub and my ‘Sky/Air’ Hub… I am seeing the live data with a timestamp that is 10 seconds apart comparing the SKY and TEMPEST rapid_wind packet… So that begs the question…
How… or is the Hub even doing it… is the Hub time set? Does it regularly query a time server and correct itself?
–Sam
ANYONE have any insight?
@dsj @WFsupport @WFstaff
Anyone?
And… noticing that the timestamps returned are not near realtime. They actually are about 2 minutes off from my GPS time, PC time, Phone time…
Reboot both Hubs at the same time and then check the timestamps. I remember David discussing this but don’t remember what he wrote.
I’m trying to search for it.
Reboot = power cycle?
The Hub checks multiple NTP servers every 4 hours. And there is a backup time sync mechanism via the Tempest cloud that we added in case the NTP servers are unreachable for some reason.
Rebooting will force the time check that normally happens every 4 hours.
Ok, but… how do we know if it is working or not? Is there any way to tell that a sync was attemtped?
Also, do the original SKY/AIR Hubs have this as well?
Reboot both Hubs and check the timestamp against the NIST time servers.
there’s no easy way to tell if it’s working or not.
Some questions:
Does the hub have an RTC with battery backup in case there’s no internet connection after a power loss event?
Is it possible to use a local NTP server on the LAN? In case Internet is not available for a long period. Some users have local NTP servers using GPS instead of relying only on internet sync.
Thanks.
It has an RTC, but no battery. The Hub is actually pretty poor at keeping time on its own.
It’s not possible to set your own NTP host but if you can use a local DNS server or some fancy iptable tricks you might be able to fool it. These are the hosts the Hub will check (it chooses the first one randomly, then cycles through the list):
time.weatherflow.com
0.weatherflow.pool.ntp.org
1.weatherflow.pool.ntp.org
2.weatherflow.pool.ntp.org
3.weatherflow.pool.ntp.org
time.google.com
time.nist.govDavid - what does the clock initialize to on power reset ? Unix epoch ?
Also, does the Hub block if it doesn’t get time on powerup ? Other questions are along the lines of whether the UDP broadcasts will queue up (or just not happen even…) if a station is powered up without Internet access.
(asking because there are questions about this in the weewx-users group reasonably frequently, so I wanted to point them here for the time-related thread).
That means that at every reboot, if there’s no internet access, the clock is reset at epoch time zero, correct? So it sends UDP packets timestamped 01-01-1970. That would explain why I found this strange record in my weewx database. Can I ask why you decided to go without a small battery?
Yes dns spoofing is a way, another is some fancy fw rules to redirect all NTP traffic. A more elegant way would be to have the hub pickup a local NTP server through DHCP option 42, since the hub is a DHCP client. If this NTP server does not work, it can then cycle through the list. What do you think about it? The fact that the hub doesn’t have a battery backed RTC makes it totally dependent from internet. A preferential local NTP server would make it much more resilient to time-sync issues.
Thanks for your feedback.
Vince, it was me you were discussing with in the conversation on weewx-users group. 
Well you ‘do’ meet the nicest people there too
So true. It’s a small world.
That’s correct, but the hub does use the time from the Tempest to set its internal clock if the Internet is down or the NTP servers can’t be reached. That system works as long as the Tempest doesn’t loose power while the hub is offline.
The module we’re using tied the RTC power net to the VCC of the module. There was no way of powering up the RTC without powering up the entire chip.
Adding it to the DHCP server config is a good idea. I’ll see if I can get it added for a future release.
Also, the hub shouldn’t report any data until the clock is correctly set. I will add the 1970 issue to our bug tracking system and make sure that’s fixed in the next release (it’ll be after the v154 release).
Thanks,
-Rob
If internet is down, public NTP servers used by the hub can’t be reached, and the hub’s fw hasn’t been designed to use a local NTP server. The DHCP option 42 solution would make it more resilient to this scenario, or you could create an option in the mobile app to configure a local NTP server that would be the first in the list of NTP servers the hub uses.
The idea of using the Tempest, that is battery-backed, as a time source in case no NTP servers are reachable is good, but something happened in my case, in which a record with epoch time zero was recorded by weewx. I don’t know the details of how exactly the system works, but I’m sure you’ll find why this can actually happen and fix it.
A RTC without a battery doesn’t make much sense for these use-cases. Time-sync is very important, if not critical.
Yes, it’s a clean solution, but take into account the fact that, unfortunately, not all routers allow you to configure advanced DHCP options and even when possible, it would still require some tech knowledge. The best solution would be to have this “Local NTP server” option configurable in the mobile app, imho.
Thank you for this. The idea of this bug came out in a discussion with @tkeffer and @vinceskahan, because we found this strange record in the weewx db that is used for my Tempest and Tom suggested it could have been the Tempest.
Thanks for answering and all the support, much appreciated.