EmonPi gone mental

We’re UTC+1 now, so it’s only a matter of a minute or so wrong.

OK. But the result of the date command (16:25:44 UTC 2019) suggests his Pi thinks it’s off
by an hour and a minute, doesn’t it?

No - he posted at 5:27 pm local, you posted 8 min ago at 7:42 local, so the Pi is 1 minute (or so) adrift.

accounting for UTC+1, 1625 vice 1728 - more like ~3 mins then, right?

I’m in the UK - so as far as british summer time goes - the pi is 1hr 2mins adrift. As far as GMT/UTC it is 2mins out

Time between copying, looking at clock and posting ≈ 3 mins? Probably not that much, but some of the numbers must have been rounded/truncated.

So I’d say it’s not a long way out, but it may well be 120 s or the 132 or 133 s as in the screenshots.

pi@emonpi:~ $ sudo systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
└─disable-with-time-daemon.conf
Active: active (running) since Fri 2019-07-19 09:12:04 UTC; 9h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 260 (systemd-timesyn)
Status: “Synchronized to time server 176.58.109.199:123 (2.debian.pool.ntp.org).”
CGroup: /system.slice/systemd-timesyncd.service
└─260 /lib/systemd/systemd-timesyncd

Jul 19 09:12:04 emonpi systemd[1]: Starting Network Time Synchronization…
Jul 19 09:12:04 emonpi systemd[1]: Started Network Time Synchronization.
Jul 19 09:12:43 emonpi systemd-timesyncd[260]: Synchronized to time server 176.58.109.199:123 (2.debian.pool.ntp.org).
Warning: systemd-timesyncd.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.

checking that against

https://www.worldtimeserver.com/current_time_in_UTC.aspx

its spot on correct

Can I change it to poll from

1.uk.pool.ntp.org

It’s unlikely to be a time issue. Everything is done in UTC (epoch timestamps), the time on the pi is right(ish) just on a different TZ, the “time” is correct. When (the emon-pi variant of ) emonhub posts to emoncms it uses a “sentat=” in the api call, which means that the emoncms server will look at the time it was sent at and if adjust each timestamp by the difference between “sentat” and the current timestamp, this removes any time mismatch as it is re aligning the timestamps to the server time regardless of what time the pi might think it is.

If you look at emonhub.log, each bulk upload to emoncms.org will have a sentat= timestamp, if you can check that timestamp is ok and that the timestamps in the same request are all within 30s of that timestamp, that should mean all if fine from the emonpi end.

When posting to a local emoncms, the timestamp is allocated by emoncms on arrival, there is no possibility of a time mismatch because only one clock is used. The current mqtt implementation has no timestamp passed with the data.

If you are seeing delays at emoncms.org, that is most likely a backlog in one of the input queues, it does happen now and again, and since it usually needs manually clearing, it’s bound to happen it will be when the whole OEM shop staff are abroad! (as they are currently) It would be handy if @TrystanLea could check but for now I would say, do not focus too much on that aspect.

Can you expand on that? What does “screwed” mean here exactly? Is it currently working at all? Are all the services running on the admin page? I have to admit I have not read the whole thread, but it sounds like you are trying various things so I’m not sure if the older comments are still valid or not, putting aside the delay at emoncms.org for a moment, what else is not working correctly?

Yes. In /etc/systemd/timesyncd.conf add the server or servers you want to poll in the line NTP=
(separate multiple entries with a space as per the example)

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

I suspect it is a red herring but anyway…

I wrote a blog ages ago about time and Raspbian as I was having issues getting it to sync.

To check the status

timedatectl status

As to fixing the NTP servers - read the blog :laughing:.

[Edit]

Perhaps not so red after all…

So about 120 seconds or so… about the length of the delay (local is BST = UTC+1 so 16:25 UTC is 17:25 BST)

That is an interesting warning - do as it says (I had it too)

sudo systemctl daemon-reload
sudo systemctl restart systemd-timesyncd

[edit2]
You might wonder how, if there are no time servers specified, it knows what to use. The answer is that the default configuration is set at compile time (as with every other default setting within the systemd ecosystem). timesyncd.conf (do note this is systemd 242 and Stretch installs V232 so some commands are different)

@pb66, @Wratty is seeing the input being delayed and only appearing every 120 seconds or so. Been through the MQTT and checked; the emonhub log says it is sending the data and the emoncms log says it is is receiving it, but the inputs page refuses to show that and the feeds page equally updates slowly. Manually subscribed to mqtt and that shows regular publishing of data.

They got a new SD from the shop, uploaded a data backup but it still does the same. they also have an emoncms.org account and that was doing the same (IIRC). I am stumped!

Just realised though, it will be different to the browser time…

If both emoncms.org AND the local emoncms on the emonpi are both showing a 120(ish) second delay, I would hazard a guess and say the PC that the browser is open on, is 2 minuets fast.

As explained above, any time diff between the emonpi and emoncms.org is removed by the “sentat=” option of the api call and there is no timestamp on the local mqtt inputs, so when data arrives at emoncms now it is timestamped as now, there is no way a 120s delay can creep in, unless the inputs page thinks it is 2mins in the future, that way now is 120s ago.

I had thought there was only a delay at emoncms.org and there was a different issue locally, but if they are both 120s delayed, it has to be the time is wrong in the browser.

My reading of that: the delay is only seen in the local emoncms… emoncms.org is displaying correctly.

It is the time on my estate… My DC was not syncing with the atomic time clock. Now I have fixed that, off my DC the update rate is showing as correct…

Now I just need to suss why this time is not syncing with my DC clients…

This explains why it made no sense, the pi is operating correctly after all!!!

2 Likes

and bingo

Well there it is… your PC needs to be syncing exactly as the Pi.

Thanks for everyone’s help, it is truly appreciated. I never noticed that the time sync on my estate was not correct, I guess as it was within a couple of mins, it just never occurred to me, I had always just assumed the PC clock was right as it was on a DC. But the DC is a VM which was ignoring the DC time sync settings as integration services “sync from host” was enabled.

Well I have learnt something today!

1 Like

If the EmonPi time is out would that not cause issues at emoncms.org, or would it be a constant mismatch? If EmonPi was fast, would the data get rejected?

One to add to the knowledge bank!

Ah assumptions… Mother of all Foul (or insert your own word beginning with F) ups.