If the emonPi does not have an active internet connection on bootup the system time might not be correct. This can happen after a power outage when the RasPi boots up before the router/modem has connected, or when using a 3G GSM modem which takes a while to connect. It’s possible to force an NTP update at anytime by running:
rpi-rw
sudo service ntp stop
sudo ntpd -q -g
sudo service ntp start
rpi-ro
I’ve wrapped up the above command into a bash script in the emonpi repo and a corresponding sudo_crontab entry to run every hr to force an NTP update. These additions won’t effect existing emonPi unless you add the following entry to the root contab:
I would like to give some feedback regarding my experience with a date issue on EmonPi for anyone encountering the same one.
I have an EmonPi with the emonpiRelease: emonSD-17Oct19 (a bit old I know).
The EmonPi has been running for several years without any problem. But recently I had to power it off for a day due to electrical maintenance. When it booted up, everything started normally (in the admin panel, all services were green). But when checking data more closely, I noticed that the date and time of the EmonPi was off by roughly one day (it started back from when I turned it off).
I tried to reboot, shutdown (unplug cables, re-plug and power on), but time was still off by ~one day.
I tried to force ntp update as mentioned above, but had the following results during the process:
pi@emonpi:~ $ sudo ntpd -q -g
5 Nov 21:39:27 ntpd[1823]: ntpd [email protected] (1): Starting
5 Nov 21:39:27 ntpd[1823]: Command line: ntpd -q -g
5 Nov 21:39:27 ntpd[1823]: proto: precision = 1.458 usec (-19)
5 Nov 21:39:27 ntpd[1823]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
5 Nov 21:39:27 ntpd[1823]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2020-06-28T00:00:00Z last=2017-01-01T00:00:00Z ofs=37
5 Nov 21:39:27 ntpd[1823]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): expired less than 1226 days ago
5 Nov 21:39:27 ntpd[1823]: Listen and drop on 0 v6wildcard [::]:123
5 Nov 21:39:27 ntpd[1823]: Listen and drop on 1 v4wildcard 0.0.0.0:123
5 Nov 21:39:27 ntpd[1823]: Listen normally on 2 lo 127.0.0.1:123
5 Nov 21:39:27 ntpd[1823]: Listen normally on 3 eth0 [EMON_IP_ADDR_v4]:123
5 Nov 21:39:27 ntpd[1823]: Listen normally on 4 lo [::1]:123
5 Nov 21:39:27 ntpd[1823]: Listen normally on 5 eth0 [EMON_IP_ADDR_v6]:123
5 Nov 21:39:27 ntpd[1823]: Listen normally on 6 eth0 [EMON_IP_ADDR_v6l]:123
5 Nov 21:39:27 ntpd[1823]: Listening on routing socket on fd #23 for interface updates
5 Nov 21:39:38 ntpd[1823]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
5 Nov 21:39:48 ntpd[1823]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
5 Nov 21:39:58 ntpd[1823]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
5 Nov 21:40:08 ntpd[1823]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
5 Nov 21:40:44 ntpd[1823]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
^C 5 Nov 21:40:53 ntpd[1823]: ntpd exiting on signal 2 (Interrupt)
After some investigation on the Temporary failure in name resolution (-3) issue, I have read that it could be a DNS issue.
Then, I temporally change the file /etc/resolv.conf with nano as follows:
# Generated by resolvconf
# nameserver [SOME_IP_ADDRESS]
nameserver 8.8.8.8
Re-run the command sudo ntpd -q -g and this time the date could be updated correctly.
I reverted the /etc/resolv.conf to the original version and will now investigate why the DNS is not working…
So, in my case, the date and time issue on bootup was due to a DNS server issue.
Very old. I suggest a new SD Card before this one dies (it will) and a supported OS.
NTPD is old hat and no longer part of the default OS. The systemd service timedatectl is the method used now (and take care not to have ntpd running at the same time).