TL;DR: Vera (Plus, Edge, and likely Secure) has a broken init script that actually sets a worse default time at system boot than the system itself chooses, and this causes TimeJump reloads later. If you system does not have /dev/rtc0, then run the commands below to let OpenWrt’s default clock adjustment control until ntpclient can contact time servers.
rm -f /etc/rc.d/S115-mios_fix_time*
chmod 000 /etc/init.d/mios_fix_time*
Detail:
As part of my work on decoupling Vera from its cloud services, I discovered an interesting bug that I believe is the cause of many TimeJump reloads.
When Vera boots (either cold boot from power off or warm boot from /sbin/reboot), the sysvinit script S115-mios_fix_time looks to see if the system has an RTC (Plus systems do not – see footnotes below), and if not, it looks for the file /etc/cmh/datetime. If that file exists, it sets the system clock to the last-modified time of that file plus a small offset. If it doesn’t exist, it sets the system clock to the default of midnight Jan 1, 2000.
Often, LuaUPnP will start up faster than ntpclient can sync the system clock to the cloud time server pool. This is particularly true after a power failure, where it is often the case that Vera will boot up faster than your Internet reconnects. As a result, some time will elapse before ntpclient can sync time. When it does, the time jumps dramatically, and this causes LuaUPnP to reload again.
The problem on at least Plus and Edge systems (I don’t have a Secure to test with, but Plus and Secure are generally almost identical in builds), is that it appears that prior revisions of firmware would touch a file /tmp/.time_synced in a specially hacked build of ntpclient, which is the file that mios_fix_time looks for to know it needs to create /etc/cmh/datetime. But it appears that recent firmware builds have the stock ntpclient without the hack, so /tmp/.time_synced is never created, and therefore /etc/cmh/datetime is never created, and your system always gets the garbage Jan 1 2020 clock set at boot.
As it turns out, OpenWrt has its own way of setting a reasonable default clock when there’s no RTC on the system. Its sysvinit script scans the entire /etc directory looking for the latest modified file, and then sets the system clock to that as a default during boot. Because the Vera writes userdata into /etc/cmh/user_data.json.lzo every six minutes (i.e. frequently modified), that means OpenWrt’s default would be far more accurate than Vera’s (a few minutes vs >20 years). It would also provide a reasonable default when your Vera crashes or suddenly loses power, as well, which Vera’s attempted solution does not (Vera’s solution requires an orderly shutdown to work – how often does that really happen?). The problem is that Vera’s init script runs after and undoes this better estimate.
The workaround for this is dead easy: SSH into your Vera and run the commands shown at the top of this post in the “TL;DR” section. This will disable Vera’s poor default from being set at boot, leaving OpenWrt’s more reasonable default in place, and that should eliminate at least those TimeJumps.
The other possibility for TimeJumps is that a pool time server is reporting a bogus time, and ntpclient has either shifted its queries to it or away from it (since it’s a pool, it’s dynamic). It’s harder to get around this; occasionally these well-known services just go wrong. The default servers are well-known Internet defaults, not Vera-specific cloud servers. The best way to eliminate that possibility, if you feel you must, is to create your own Stratum 1 time server (easier than it sounds – a RPi with a GPS hat can do it) and reconfigure your Vera to use it exclusively for time server.
Notes:
- To see if your system has an RTC, SSH in and see if the file
/dev/rtc0exists; it does not exist on systems without a hardware real time clock. - It should be clear that this is a lesson in why you don’t hack system packages in unobvious ways to do weird stuff – some future person building may not know about it and it gets lost in the shuffle.
- Because Veras have a higher probability of rebooting during Internet outages as they try to contact the mother ship, the chance of it coming up with the bad default clock are quite high – even though power has not failed or you haven’t reboot the Vera, it has been shown to do it to itself during Internet outages, and this then leaves you with a broken clock until Internet service is restored (and that causes a TimeJump reload on unmodified systems). These random reboots during Internet outages are pretty much eliminated by decoupling your system from the cloud services.
- If your system boots with a bad clock, your time/date-based automations will go nuts.
