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.