Web EMONCMS and App feed/input differences and NTP troubleshooting

Emoncms
1

11.3.22 low write EMONCMS on EmonPi (original)
1.12.3 (33) iOS

I noted today that all of the Inputs and feeds in the web interface to Emoncms showed red most of the time and had a “last seen” which appeared to be 60 sec greater than when the input/feed was last updated. The iOS app shows the inputs/feeds green and with “last seen” times of a few seconds.

Looking at Emonhub logs in realtime suggests that they are one minute behind ntp time server time so this looks like an time error on the local EmonPi

EmonPi was cold and warm rebooted, with no change.

Followed trouble shooting at Troubleshooting — OpenEnergyMonitor 0.0.1 documentation and “sudo service ntp stop” resulted in no error, but “sudo service ntp start” returned “Failed to start ntp.service: Unit ntp.service not found.”. I think the advice is out of date as I believe that systemd now handles time synchronisation.

Using timedatectl returned:

pi@emonpi:/etc $ timedatectl
               Local time: Mon 2024-04-22 14:23:56 BST
           Universal time: Mon 2024-04-22 13:23:56 UTC
                 RTC time: n/a
                Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

So there appears to be an active time service, and checking syslog from cold boot there was indeed an ntp sync.
Apr 22 12:22:18 emonpi systemd-timesyncd[358]: Synchronized to time server for the first time 139.162.219.252:123 (2.debian.pool.ntp.org)

At this point I noticed that the EMONCMS web interface was back to normal, so I assume that running the timedatectl command must have sorted matters out, although no additional NTP sync was recorded in syslog.

Wierd. Happy to get any hints as to what might have been going on!

2

There is a FIX and improvements like show inactive feeds last date in gray, here.
Lets wait for @TrystanLea to approve.

Problem is server and client time not correct, but also network lag.
This fix takes in account all and present real values. Something i’ve implemented in v9 and lost mid v10.

3

Thanks. Intrigued by this, but can’t follow the code. Do you mean app/web by client and EMONCMS by server?

I should have mentioned that “date” run at the command line of the ssh terminal gave the minute too low time up until “timedateqry” was run, including across the hard reboot. That suggests that the ntp time at boot was not utilised, or was corrupted somehow. The ntp server gave the exact same time as the Microsoft time server on the browser client (I checked!).

4

Yes thats ir.