EmonPi gone mental

Wratty · 2019-07-19T12:21:47.067Z

I wonder whether I should just wipe the SD card and start from scratch. Slightly annoying as I bought a compiled one to stop me from having to do that, but it is what it is I guess.

*puts big hammer away (for now lol)

borpin · 2019-07-19T13:39:28.918Z

I’d suggest so - however,

leave it alone for about an hour on first boot to be sure all the updates have been done (OS and emoncms)
check and see if it is working before loading your backup data.

Bill.Thomson · 2019-07-19T15:59:06.876Z

Silly question time…
Has the emonPi clock been verified it’s set to the correct time?
I searched the thread to see if this question has already been asked,
but didn’t find anything that suggests it had.

Wratty · 2019-07-19T16:27:17.459Z

pi@emonpi:~ $ date
Fri 19 Jul 16:25:44 UTC 2019

Current actual time 17:28

Not sure how you check NTP on these but this sure doesnt appear to?

pi@emonpi:~ $ sudo service ntp stop
Failed to stop ntp.service: Unit ntp.service not loaded.
pi@emonpi:~ $ sudo service ntp start
Failed to start ntp.service: Unit ntp.service not found.
pi@emonpi:~ $

Bill.Thomson · 2019-07-19T18:00:50.567Z

Wratty:

Not sure how you check NTP on these but this sure doesnt appear to?

ntp was dropped starting with the Raspbian Stretch.
The ntp client was replaced with systemd-timesyncd
More info here:

raspberrypi.stackexchange.com

NTP is not enabled (doesn't exist) but Pi figures out timezone and time. How?

ntp

asked by Steven Lu on 06:35PM - 09 Aug 18 UTC

Bill.Thomson · 2019-07-19T18:10:07.371Z

Wratty:

pi@emonpi:~ $ date
Fri 19 Jul 16:25:44 UTC 2019

Current actual time 17:28

I don’t know about current versions of emonCMS, as I haven’t run it for 3 years, but I do
remember - with the version that was current at the tme - if the system clock wasn’t set to
the correct time, the symptom you’re seeing (the update delay) would present itself.

Robert.Wall · 2019-07-19T18:39:37.543Z

Bill.Thomson:

Current actual time 17:28

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

Bill.Thomson · 2019-07-19T18:42:29.341Z

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?

Robert.Wall · 2019-07-19T18:51:23.963Z

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.

Bill.Thomson · 2019-07-19T18:57:44.441Z

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

Wratty · 2019-07-19T18:59:05.821Z

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

Robert.Wall · 2019-07-19T19:04:29.877Z

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.

Wratty · 2019-07-19T19:07:06.191Z

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.

Wratty · 2019-07-19T19:10:11.171Z

checking that against

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

its spot on correct

Wratty · 2019-07-19T19:14:41.683Z

Can I change it to poll from

1.uk.pool.ntp.org

pb66 · 2019-07-19T20:01:12.667Z

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.

Wratty:

Online version now gets regular updates - local version still screwed, but oddly reports up online correctly now it seems

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?

Bill.Thomson · 2019-07-19T21:29:12.355Z

Wratty:

Can I change it to poll from…

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

borpin · 2019-07-19T21:43:44.132Z

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 .

[Edit]

Bill.Thomson:

if the system clock wasn’t set to
the correct time, the symptom you’re seeing (the update delay) would present itself.

Perhaps not so red after all…

Wratty:

Fri 19 Jul 16:25:44 UTC 2019
Current actual time 17:28

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)

Wratty:

Warning: systemd-timesyncd.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.

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)

borpin · 2019-07-19T21:56:36.701Z

pb66:

Can you expand on that? What does “screwed” mean here exactly?

@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!

borpin · 2019-07-19T22:41:42.545Z

pb66:

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.

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