Raspberry Pi 3, Time Set Wrong On Power Up Vantage Pro2

iss....@gmail.com

unread,

May 23, 2018, 8:54:09 AM5/23/18

to weewx-user

I am running WeeWX on a Raspberry Pi 3 connected to a Vantage Pro2 Station.

If I power down the Pi, when I power it back up the time on the Vantage Pro is incorrect and is set to the time the Pi was powered down.

This, I assume, is due to the fact the Pi does not have a RTC and gets its time from the network.

I also assume that WeeWX is starting before the network is up.

What is the best way to get the correct time to the Vantage

Thanks

Greg Brougham

unread,

May 23, 2018, 9:24:33 AM5/23/18

to weewx...@googlegroups.com

Iss, have a look at the following

https://www.modmypi.com/raspberry-pi/accessories-198/real-time-clocks-rtc-1080/rasclock-raspberry-pi-real-time-clock-module-v3.0

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andrew Milner

unread,

May 23, 2018, 9:25:45 AM5/23/18

to weewx-user

The simplest, easiest and best way is to get a RTC module for the RPi. Cost is under £10. Removes all the hassel of the RPi not having the correct time. weewx tries to wait for time to have been set as best it can.

See the wiki for more information on running weewx with an RPi

https://github.com/weewx/weewx/wiki/Raspberry-Pi

iss....@gmail.com

unread,

May 23, 2018, 9:48:35 AM5/23/18

to weewx-user

I was hoping for a simple software solution like inserting a delay into the WeeWX startup routine to give the Pi time to Gert the correct time

John

Andrew Milner

unread,

May 23, 2018, 9:56:23 AM5/23/18

to weewx-user

Nearly all the software 'solutions' have a downside of one sort or another. Since you have an expensive weather station I truly do not see the problem in spending another £8 on a clock for your computer. I even fit clocks to my pi-zeros because without a reliable clock the Pi is pretty naff.

You could always try and fiddle even more with the start up script - but believe me th\t many many have been there before you. The current weewx solution will wait for a time to be within the past year I believe to get around the totally stupid epoch zero times - but this does not work well when the fake hardware clock on the pi is involved as the time could be just an hour or so adrift. If you disable hardware clock completely weewx will wait for a time before starting - but other parts of your rpi system will then be running with the epoch zero date/time. People have tried waiting for NTP to be available - but that also has not been 100% reliable - hence the current evolution in weewx. Truly, the best and most foolproof way is to fit a b....y clock and be done with it. Unless you are a masochist and want to spend the resy of your life chasing oddball issues …….

iss....@gmail.com

unread,

May 23, 2018, 4:17:57 PM5/23/18

to weewx-user

Ok - many thanks for you advice.

Looking on amazon.co.uk could you recommend one of the RTCs listed there.

It needs to work with a Raspberry Pi 3

Again many thanks

John

Dave Webb KB1PVH

unread,

May 23, 2018, 4:22:07 PM5/23/18

to weewx...@googlegroups.com

Just go to Amazon and search for raspberry pi rtc

Dave-KB1PVH

Sent from my Galaxy S9

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

Dave Webb KB1PVH

unread,

May 23, 2018, 4:29:14 PM5/23/18

to weewx...@googlegroups.com

This one should do just fine.

https://www.amazon.com/dp/B00ZOXWHK4/ref=cm_sw_r_cp_awdb_t1_I4CbBbHK8NDYP

Dave-KB1PVH

Sent from my Galaxy S9

On Wed, May 23, 2018, 16:18 <iss....@gmail.com> wrote:

iss....@gmail.com

unread,

May 25, 2018, 5:31:03 AM5/25/18

to weewx-user

Many thankd

David Beach

unread,

Jun 25, 2018, 6:30:52 PM6/25/18

to weewx-user

I would like to avoid installing an RTC on my RPi Zero W because none of the modules I have fit within the RPi Zero case. And, for several reasons, I want to keep all the 'stuff' within that small case. It would be less of an issue if I used a regular-sized RPi and case - but I want to use the tiny RPi Zero W.

From the standpoint of programming 'elegance,' it seems too bad to have to fit extra hardware to overcome what - at least from what I have read - seems to be a weeWX program and/or OS problem.

If anyone figures out a software solution to this problem that avoids an RTC, I'd be interested in hearing about it. In the meantime, I'm keeping my RPi on a UPS so it almost never shuts down...

By the way, has anyone desoldered and re-soldered an RTC module in a way that allows it to be squeezed into an RPi Zero case? Not much extra room in there but it might be do-able... I would prefer to avoid that solution for this specific problem, but an RTC that would fit into the RPi Zero case would be useful for many projects.

David

Greg Troxel

unread,

Jun 25, 2018, 6:59:33 PM6/25/18

to David Beach, weewx-user

David Beach <david....@gmail.com> writes:

> I would like to avoid installing an RTC on my RPi Zero W because none of
> the modules I have fit within the RPi Zero case. And, for several reasons,
> I want to keep all the 'stuff' within that small case. It would be less of
> an issue if I used a regular-sized RPi and case - but I want to use the
> tiny RPi Zero W.
>
> From the standpoint of programming 'elegance,' it seems too bad to have to
> fit extra hardware to overcome what - at least from what I have read -
> seems to be a weeWX program and/or OS problem.
>
> If anyone figures out a software solution to this problem that avoids an
> RTC, I'd be interested in hearing about it. In the meantime, I'm keeping my
> RPi on a UPS so it almost never shuts down...

I am currently running weewx on a laptop (with an RTC) under NetBSD, so
my detailed experience isn't that useful to you, but it seems relatively
straightforward to ensure that the time has been set before weewx
starts.

Two separate thoughts:

1)

Assuming you are running an OS with a concept of things to be done on
boot, and an ordering of them, I would

A) have a really early stage that removes /var/run/synchronized (a
BSD-style path, but of course it doesn't matter)

B) change ntpdate to i) write /var/run/synchronized after the time is set
and ii) continue to operate until it is synchronized, and then either,

C) change the weewx start script to just wait until
/var/run/synchronized appears, and then start weewx, running in the
background if necessary, or

D) ensure that the init system is tolerant of really waiting until
ntpdate finishes before running anything that depends on it

Option D is probably trouble, because while you want weewx not to start
until time is synched, you probably do want ntpdate to time out and sshd
start, so you can fix ntpdate.

Adding this to the init scripts is probably hard. However, you could
put something in cron to start weewx, running every 5 minutes, which
basically:

if weewx running, exit

check if system is synchronized by asking ntpd if it is synced, or do
ntptrace to someplace and look at offsets, or soemthing like that. if
not, exit.

start weewx

Then you should end up with weewx running after sync, at the expense of
some delay, which given archive records in the station, should be ok, or
at least better than now.

2)

weewx doesn't cope well with the time being wrong, and presumably far in
the past. The standard approach on this list is to fix the time
problem. However, it seems possible to make weewx detect that the time
is odd (perhaps different from the station time, if that works, or that
it's before records that have been recorded, and wait until it's fixed.

Alternatively, weewx could be adjusted to recover from bad time or
records with bad time, and cope. This is surely nontrivial or someone
would have done it, but it seems that it should be doable.

I suspect that all the people who might do this have an RTC one way or
the other.

signature.asc

Andrew Milner

unread,

Jun 25, 2018, 8:55:21 PM6/25/18

to weewx-user

David

If you use an RPI zero case with the gpio slot then you CAN fit an rtc to the RPi zero where it would fit over the top of the case. I guess the case with the slot is made for a reason!!!!!

With the rpi3 it is not just less of an issue - it is a totally resolved issue.

A lack of RTC is far more a hardware/keep cost down issue than a software issue. ALL pc's and most of the pi competitors include a RTC - again for a reason - they are needed. Using the RPI for a serious 24/7 production machine does demand that it be upgraded in many respects for satisfactory outcomes such as providing rtc, powered usb hubs and maybe even using ssd rather than just sd cards

David Beach

unread,

Jun 25, 2018, 10:04:56 PM6/25/18

to weewx-user

Thanks for your suggestions. I was hoping that someone out there might have figured out a solution that I could just copy - but it looks like I will have to do some experimenting 'under the hood.' I don't care if it takes half an hour for the RPi to boot - I think my Vantage can store many days, even maybe a couple of weeks, of data. I just don't want to have to manually clear the log every time the RPi restarts. I'd like it to restart and start reporting data (in my case, to the WeatherUnderground) without me having to manually tinker with it.

I hope to have some free time over the summer. I'll give it a go. If I am successful, I'll post the results. If anyone figures out a solution before that, let me know!

David

David Beach

unread,

Jun 25, 2018, 10:38:16 PM6/25/18

to weewx-user

The RTC would 'fix the problem'. I just wish it was not necessary - if only the RPi could start, get its time via NTP and then start weeWX. And not get muddled.

From reading interviews with Eben Upton and others, the lack of an RTC was a cost issue when the RPi was being designed. Even so, it was a truly amazing board when it was introduced in 2012 for $35 (OK, sort of $35!) It is too bad that the subsequent revisions haven't had built-in RTCs but I know, from reading interviews, that it was considered but didn't make the cut. The board was conceived as an educational tool, not an industrial component, so maybe the RTC - which hackers and makers would love to have built-in - wasn't considered 'necessary'. Even the new 3B+ is "RTC-free" as far as I know.

I have a couple of DS3231 clock modules. I'm going to try to do a software fix first but, if that doesn't work, I'll see if I can 're-engineer' my module to fit inside the case. Worst case scenario - I'll have it stick out of the case like the proverbial sore thumb. Ugh.

David

Andrew Milner

unread,

Jun 25, 2018, 10:53:45 PM6/25/18

to weewx-user

Simplest and best answer …..

do not use a custom made rpizero case, mount rtc and just use any other box/case and cut out the required power and usb holes with a craft knife and/or drill or even put the rpizero+rtc+picase into another box for the cosmetics - or make a box of yr own!!

time is critical to weewx operation and really should not be compromised.

the main problem areas (from memory) are when the fake hwclock is only an hour or so adrift - it is hard to determine if this is a valid ntp time or the 'stale' fake hwclock time. If you clear the fakehwclock time somehow when booting up, weewx will then wait for a valid time before starting - which will presumably be after the rpi has obtained a current time from ntp servers.

vince

unread,

Jun 26, 2018, 12:06:23 AM6/26/18

to weewx-user

On Monday, June 25, 2018 at 7:38:16 PM UTC-7, David Beach wrote:

The RTC would 'fix the problem'. I just wish it was not necessary - if only the RPi could start, get its time via NTP and then start weeWX. And not get muddled.

Are you running the dpkg or setup.py method of installation ?

Wasn't this worked and dealt with months ago ?

Do not install fakehwclock, and weewx should suppress startup until ntp catches up (shouldn't it ?)

Andrew Milner

unread,

Jun 26, 2018, 1:48:20 AM6/26/18

to weewx-user

I just cannot remember if it is as simple as just removing/uninstalling the fake hwclock or if there is more you have to do.

gjr80

unread,

Jun 26, 2018, 1:55:37 AM6/26/18

to weewx-user

Should be and it should have been the case since 3.4.0 was released on 16 January 2016. https://github.com/weewx/weewx/commit/92904d4d25b7c824cbe06d0c6fd8624485b8a341#diff-5c5fa8bd3042a3e3815da70f6a58dd4e refers.

Gary

Andrew Milner

unread,

Jun 26, 2018, 2:00:30 AM6/26/18

to weewx-user

Well I know weewx waits for the sane time - my uncertainties are over whether one needs to do anything else to keep the RPi running sweetly (not just weewx) if one just uninstalls/disables fake hwclock, and also how to actually correctly do the uninstall/disable.

Glenn McKechnie

unread,

Jun 26, 2018, 2:49:32 AM6/26/18

to weewx-user

At the weewx wiki there's a good explanation and the section, B. Remove the fake clock

sudo apt-get purge fake-hwclock

which will also delete the config file, /etc/fake-hwclock.data

Not sure if the pi zero has ntp installed by default?
sudo apt-get install ntp should be enough to install it, and perhaps edit /etc/ntp.conf if you know of a better timeserver (default entries will work though).

Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

David Beach

unread,

Jun 26, 2018, 7:18:21 AM6/26/18

to weewx...@googlegroups.com

I followed those instructions and, for reasons not clear to me, my RPi/weeWX/Vantage Vue combo still has issues on startup.

Sadly, I am neither an expert in Linux/Raspian nor weeWX/Python.

A related discussion (which included some of the current participants) wondered if the Stretch version of Raspian may have been part of the problem.

David

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/6zToC6kdfuU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

Glenn McKechnie

unread,

Jun 26, 2018, 7:59:22 AM6/26/18

to weewx-user

David,

Okay, Test to see if you have ntp installed and running.

Enter these commands and paste the output for the group.

sudo systemctl status systemd-timesyncd

sudo systemctl status ntpd

and / or

sudo /etc/init.d/ntp status

ls -al /etc/ntp.conf

If the above returns a filename, What's the output of
cat /etc/ntp.conf

finally

sudo ntpq -pn

Cheers
Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

David Beach

unread,

Jun 26, 2018, 8:25:42 AM6/26/18

to weewx...@googlegroups.com

Will do. Off to work!

David

vince

unread,

Jun 26, 2018, 1:01:10 PM6/26/18

to weewx-user

Short answer is 'purge fake-hwclock' and 'add and enable ntp' it seems.

Too long experimentation and discussion follows......

More for the record here than anything, I fired up a pi-zero that I had sitting around to run a few tests. This one is on the network via a Edimax USB wifi dongle and a Zero4U USB hub card to give the zero some USB ports...

Fake-hwclock:

By default, Raspbian has that fake-hwclock thing enabled. To delete it (as Glenn said):
sudo apt-get purge fake-hwclock

Systemd controlling the clock:

Raspbian initially is set up to get system time via systemd (ugh) but does 'not' have ntp installed. Poking around in /lib/systemd/system/systemd-timesyncd.service.d led me to a config file saying systemd timedatectl 'should' come up disabled if ntp is installed. Don't know if that's true. Personally I like disabling systemd stuff here just to know for certain.

To disable systemd timesync:
sudo timedatectl set-ntp false

To check the status of systemd timesync:
pi@raspberrypi:~ $ timedatectl status
Local time: Thu 2016-11-03 17:19:43 UTC
Universal time: Thu 2016-11-03 17:19:43 UTC
RTC time: n/a
Time zone: Etc/UTC (UTC, +0000)
Network time on: no
NTP synchronized: no
RTC in local TZ: no

Default initial date of a Pi-Zero running Raspbian:

Now that the fake-hwclock is removed and systemd is out of the way, I powered off the system (sudo poweroff), unplugged the power, and powered the zero back up, and it comes up with an initial system date of Nov-13-2016 every time.

How long does ntp take to fix the clock on bootup:

To enable ntp (the daemon) you need to add the package:
sudo apt-get update
sudo apt-get install -y ntp
sudo systemctl enable ntp
sudo systemctl start ntp
sudo ntpq -pn

Power the system off again (sudo poweroff), unplug the power, and power it up yet again,

Basically ntp fires up right after the box is on the network successfully for my wifi case. It takes about 8 seconds here for ntp to complete its thing once it starts, which is about 30 seconds into the boot sequence here (take a little bit for the zero to boot and get wifi situated fully). So the total time on my wifi zero is about 35-40 seconds or so for the clock to get corrected on powerup.

How long does it take systemd timedatectl to fix the clock on bootup

Lastly just for grins I redid the 'how long does it take for time to be correct' test with ntp purged and systemd timedatectl enabled. Looks like it also tries to start in about 40 seconds or so, with some interesting syslog messages...

Nov 3 17:20:32 raspberrypi systemd-timedated[442]: Set NTP to enabled
Nov 3 17:20:32 raspberrypi systemd[1]: Starting Network Time Synchronization...
Nov 3 17:20:32 raspberrypi systemd-timesyncd[469]: System clock time unset or jumped backwards, restoring from recorded timestamp: Tue 2018-06-26 16:04:35 UTC
Jun 26 16:04:35 raspberrypi systemd[396]: Time has been changed
Jun 26 16:04:35 raspberrypi systemd[1]: Started Network Time Synchronization.
Jun 26 16:04:35 raspberrypi systemd[1]: Time has been changed
Jun 26 16:04:35 raspberrypi systemd[1]: apt-daily.timer: Adding 9h 52min 14.755890s random time.
Jun 26 16:04:35 raspberrypi systemd[1]: apt-daily-upgrade.timer: Adding 4min 44.779491s random time.
Jun 26 16:04:35 raspberrypi systemd[1]: Reached target System Time Synchronized.
Jun 26 16:29:01 raspberrypi systemd-timesyncd[469]: Synchronized to time server 216.93.242.12:123 (0.debian.pool.ntp.org).
Jun 26 16:29:01 raspberrypi systemd[396]: Time has been changed
Jun 26 16:29:01 raspberrypi systemd[1]: Time has been changed

Notice how systemd 'also' seems to be stashing its last known time - the clock jumps to the stored time of 16:04 and 'then' it jumps to the true time of 16:29 some (unknown) short time later. I haven't found where that file might be stashed.

Regardless, I think we still have the scenario for weewx where the right thing is to 'purge' fake-hwclock and 'add and enable' ntp to get all this other cruft out of the way.

David Beach

unread,

Jun 26, 2018, 1:26:40 PM6/26/18

to weewx-user

Thanks, Vince, for your note. I am learning more (than I ever wanted to know, perhaps!) about the Raspberry Pi and Raspian. Tt looks like the time-setting process has some unexplained things going on. And what is it with 13 Nov 2016?!

Would it be worth posting your questions about the implementation of time setting on one of the Rasp Pi Foundation forums? Maybe posting under "Using the Raspberry Pi/Advanced Users" or "Operating System Distributions/Raspian" would get a response from someone 'steeped' in Raspian - or maybe even one of the architects of Raspian? I don't know enough about Raspian/Linux commands and modules to carry on a sensible conversation. Or maybe there are some other Raspian experts on this group.

(I was hoping, originally, for an easy software solution to my RPi/weeWX problems. The hardware RTC seems like the easiest solution but it just doesn't strike me as the best solution for my problem. I may have to cave in eventually.)

David

vince

unread,

Jun 26, 2018, 2:22:33 PM6/26/18

to weewx-user

On Tuesday, June 26, 2018 at 10:26:40 AM UTC-7, David Beach wrote:

Thanks, Vince, for your note. I am learning more (than I ever wanted to know, perhaps!) about the Raspberry Pi and Raspian. Tt looks like the time-setting process has some unexplained things going on. And what is it with 13 Nov 2016?!

Dunno. Every computer comes up with a default clock setting on first-boot. I've seen lots of values over the years on different gear.

Would it be worth posting your questions about the implementation of time setting....

Think not. We just have to understand the nuances and deal with them. Running ntp (or systemd equivalent) is generally the way to go anyway, with/without a RTC, although a battery-backed up RTC is the preferred thing.

Note re: RTC and battery-backed up clocks on motherboards. They aren't accurate either. They tend to run slow, but stay close enough to handle normal scenarios like a brief power outage or being shut down for some period of time. That's why most os set the RTC on the way 'down' whenever you do an orderly shutdown....so it's as good as it can be the next time the system comes up.

David Beach

unread,

Jun 27, 2018, 9:42:42 AM6/27/18

to weewx-user

I followed your instructions as closely as I could. I think I had already uninstalled fake-hwclock already but went through the commands to uninstall again. Then I disabled systemd timesync and then enabled the ntp daemon (was it ever disabled?) following your instructions.

When I run 'timedatectl status' I get:

pi@weatherpi:~ $ timedatectl status

Local time: Wed 2018-06-27 09:12:43 EDT

Universal time: Wed 2018-06-27 13:12:43 UTC

RTC time: n/a

Time zone: America/Toronto (EDT, -0400)

Network time on: no

NTP synchronized: yes

RTC in local TZ: no

Some interesting things. When I rebooted the computer, I kept asking for 'date' repeatedly and got this:

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Wed Jun 27 08:51:06 2018 from 192.168.1.14

pi@weatherpi:~ $ date

Thu Nov 3 13:17:57 EDT 2016

pi@weatherpi:~ $ date

Thu Nov 3 13:18:05 EDT 2016

pi@weatherpi:~ $ date

Wed Jun 27 08:53:32 EDT 2018

It clearly took a while (? a minute or so) to get the RPi to display the current/true date. As you pointed out, it booted up thinking it was 3 Nov 2016!

Looking at the syslog shortly after that:

pi@weatherpi:~ $ sudo tail -f /var/log/syslog

Jun 27 08:54:40 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:42 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:44 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:45 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:46 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:48 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:48 weatherpi weewx[428]: cheetahgenerator: Generated 14 files for report StandardReport in 9.46 seconds

Jun 27 08:54:48 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:49 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:50 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

Jun 27 08:54:50 weatherpi weewx[428]: vantage: No <ACK> received from console

Jun 27 08:54:50 weatherpi weewx[428]: vantage: LOOP try #1; error: No <ACK> received from Vantage console

Jun 27 08:54:51 weatherpi weewx[428]: imagegenerator: Generated 12 images for StandardReport in 2.80 seconds

Jun 27 08:54:51 weatherpi weewx[428]: copygenerator: copied 0 files to /var/www/html/weewx

Jun 27 08:54:56 weatherpi weewx[428]: engine: Launch of report thread aborted: existing report thread still running

So, I stopped weeWX, then restarted it and then looked as the syslog:

pi@weatherpi:~ $ sudo /etc/init.d/weewx stop

[ ok ] Stopping weewx (via systemctl): weewx.service.

pi@weatherpi:~ $ sudo /etc/init.d/weewx start

[ ok ] Starting weewx (via systemctl): weewx.service.

pi@weatherpi:~ $ sudo tail -f /var/log/syslog

Jun 27 08:56:41 weatherpi weewx[1184]: manager: Starting backfill of daily summaries

Jun 27 08:56:41 weatherpi weewx[1184]: restx: StationRegistry: Registration not requested.

Jun 27 08:56:41 weatherpi weewx[1184]: restx: Wunderground-PWS: Data for station IPRINCEE45 will be posted

Jun 27 08:56:41 weatherpi weewx[1184]: restx: PWSweather: Posting not enabled.

Jun 27 08:56:41 weatherpi weewx[1184]: restx: CWOP: Posting not enabled.

Jun 27 08:56:41 weatherpi weewx[1184]: restx: WOW: Posting not enabled.

Jun 27 08:56:41 weatherpi weewx[1184]: restx: AWEKAS: Posting not enabled.

Jun 27 08:56:41 weatherpi weewx[1184]: engine: Starting up weewx version 3.8.0

Jun 27 08:56:41 weatherpi weewx[1184]: engine: Clock error is 0.08 seconds (positive is fast)

Jun 27 08:56:41 weatherpi weewx[1184]: engine: Starting main packet loop.

Jun 27 09:00:15 weatherpi weewx[1184]: manager: Added record 2018-06-27 09:00:00 EDT (1530104400) to database 'weewx.sdb'

Jun 27 09:00:15 weatherpi weewx[1184]: manager: Added record 2018-06-27 09:00:00 EDT (1530104400) to daily summary in 'weewx.sdb'

Jun 27 09:00:17 weatherpi weewx[1184]: restx: Wunderground-PWS: Published record 2018-06-27 09:00:00 EDT (1530104400)

Jun 27 09:00:38 weatherpi weewx[1184]: cheetahgenerator: Generated 14 files for report StandardReport in 20.92 seconds

Jun 27 09:00:56 weatherpi weewx[1184]: imagegenerator: Generated 36 images for StandardReport in 17.38 seconds

Jun 27 09:00:56 weatherpi weewx[1184]: copygenerator: copied 9 files to /var/www/html/weewx

Jun 27 09:03:08 weatherpi ntpd[344]: 144.217.65.183 local addr 192.168.1.19 -> <null>

Jun 27 09:03:08 weatherpi ntpd[344]: 206.108.0.131 local addr 192.168.1.19 -> <null>

Jun 27 09:03:10 weatherpi ntpd[344]: 144.217.65.182 local addr 192.168.1.19 -> <null>

Jun 27 09:03:42 weatherpi ntpd[344]: 149.56.47.60 local addr 192.168.1.19 -> <null>

Jun 27 09:04:49 weatherpi ntpd[344]: 206.108.0.132 local addr 192.168.1.19 -> <null>

Jun 27 09:05:52 weatherpi ntpd[344]: 199.19.167.36 local addr 192.168.1.19 -> <null>

Jun 27 09:06:33 weatherpi ntpd[344]: 209.115.181.106 local addr 192.168.1.19 -> <null>

Jun 27 09:06:37 weatherpi ntpd[344]: 159.203.8.72 local addr 192.168.1.19 -> <null>

Jun 27 09:07:04 weatherpi ntpd[344]: 158.69.125.231 local addr 192.168.1.19 -> <null>

Jun 27 09:07:04 weatherpi systemd[1]: Starting Cleanup of Temporary Directories...

Jun 27 09:07:04 weatherpi systemd[1]: Started Cleanup of Temporary Directories.

Jun 27 09:08:08 weatherpi ntpd[344]: 129.128.12.20 local addr 192.168.1.19 -> <null>

Jun 27 09:10:15 weatherpi weewx[1184]: manager: Added record 2018-06-27 09:10:00 EDT (1530105000) to database 'weewx.sdb'

Jun 27 09:10:15 weatherpi weewx[1184]: manager: Added record 2018-06-27 09:10:00 EDT (1530105000) to daily summary in 'weewx.sdb'

Jun 27 09:10:16 weatherpi weewx[1184]: restx: Wunderground-PWS: Published record 2018-06-27 09:10:00 EDT (1530105000)

Jun 27 09:10:25 weatherpi weewx[1184]: cheetahgenerator: Generated 14 files for report StandardReport in 8.44 seconds

Jun 27 09:10:27 weatherpi weewx[1184]: imagegenerator: Generated 12 images for StandardReport in 2.52 seconds

Jun 27 09:10:27 weatherpi weewx[1184]: copygenerator: copied 0 files to /var/www/html/weewx

After the stop/start, weeWX seems to be sending info to the WeatherUnderground and to my local (on the RPi) web page successfully. And I did not have to use the '--clear-memory' command which seemed to help in the past. However, I don't know what the lines that look like:

Jun 27 09:03:08 weatherpi ntpd[344]: 144.217.65.183 local addr 192.168.1.19 -> <null>

mean. I don't ever recall seeing lines like this before. The fact that 'ntpd' shows up makes me think that the clock/time issues are involved here!

So, after all that:

1) I'm a bit concerned that something is amiss with that odd message above, even though the clock seems to have been set correctly.

2) Would things work *if* the weeWX program was modified so that it would not start until the clock read a date/time very close to today (and *after* Nov 2016)? Gary (gjr80) pointed out some code in the program:

+ # be sure that the system has a reasonable time (at least 1 jan 2000).
		+ # log any problems every minute.
		+ ts = time.time()
		+ n = 0
		+ while ts < 946684800:
		+ if n % 120 == 0:
		+ syslog.syslog(syslog.LOG_INFO,
		+ "engine: waiting for sane time. current time is %s"
		+ % weeutil.weeutil.timestamp_to_string(ts))
		+ n += 1
		+ time.sleep(0.5)
		+ ts = time.time()
		+

If I just changed the time stamp to 16 June 2018 (for example). Would weeWX look at the Nov 2016 date and NOT run until the clock updated? The original 'wait until after 2000' was reasonable if the clock actually went back to 1970 but it is clear that it does not - at least in the current Stretch version of Raspian. Maybe modifying weeWX is easier than fiddling with Raspian. I have almost no Python experience but could I just use a text editor to replace that date code? (Hey, what could happen?! I suppose I can always re-install...)

Anyway, I hope this information helps.

David

mwall

unread,

Jun 27, 2018, 10:28:32 AM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 9:42:42 AM UTC-4, David Beach wrote:

If I just changed the time stamp to 16 June 2018 (for example). Would weeWX look at the Nov 2016 date and NOT run until the clock updated? The original 'wait until after 2000' was reasonable if the clock actually went back to 1970 but it is clear that it does not - at least in the current Stretch version of Raspian. Maybe modifying weeWX is easier than fiddling with Raspian. I have almost no Python experience but could I just use a text editor to replace that date code? (Hey, what could happen?! I suppose I can always re-install...)

yes. we used the date of 2000 because we just needed something sane. the experience at the time was that an unset clock had a value of 0, which puts the time in the 1970s. apparently something is now making that default time 03nov2016 (systemd, is that you mucking about again with things you have no business touching?)

it makes sense to use a more recent time stamp, even 01jan2018 if you want.

m

David Beach

unread,

Jun 27, 2018, 11:15:41 AM6/27/18

to weewx-user

I just did a quick edit of the engine.py file, changing the 1 Jan 2000 date to 1 Jan 2018. It seems to work! Yahoo! Maybe a software solution is near. There are still a few odd bits.

The strange

Jun 27 10:55:08 weatherpi ntpd[340]: 206.108.0.131 local addr 192.168.1.19 -> <null>

statements are still appearing in the syslog at the rate of a couple every minute which bugs me. Eventually, this was logged:

Jun 27 10:58:34 weatherpi ntpd[340]: 144.217.65.183 local addr 192.168.1.19 -> <null>

Jun 27 10:59:48 weatherpi systemd[1]: Starting Cleanup of Temporary Directories...

Jun 27 10:59:49 weatherpi systemd[1]: Started Cleanup of Temporary Directories.

So, the statements stopped appearing - for about 7 minutes then on more appeared. Hmm. So far, it doesn't seem to affect the overall function of weeWX. Anybody know why these statements appear, then seem to stop only to start again later?

Here is a copy of the syslog, in case that helps:

pi@weatherpi:~ $ sudo tail -f /var/log/syslog

Jun 27 10:46:08 weatherpi weewx[417]: manager: Starting backfill of daily summaries

Jun 27 10:46:08 weatherpi weewx[417]: restx: StationRegistry: Registration not requested.

Jun 27 10:46:08 weatherpi weewx[417]: restx: Wunderground-PWS: Data for station IPRINCEE45 will be posted

Jun 27 10:46:08 weatherpi weewx[417]: restx: PWSweather: Posting not enabled.

Jun 27 10:46:08 weatherpi weewx[417]: restx: CWOP: Posting not enabled.

Jun 27 10:46:08 weatherpi weewx[417]: restx: WOW: Posting not enabled.

Jun 27 10:46:08 weatherpi weewx[417]: restx: AWEKAS: Posting not enabled.

Jun 27 10:46:08 weatherpi weewx[417]: engine: Starting up weewx version 3.8.0

Jun 27 10:46:08 weatherpi weewx[417]: engine: Clock error is -0.39 seconds (positive is fast)

Jun 27 10:46:08 weatherpi weewx[417]: engine: Starting main packet loop.

Jun 27 10:50:15 weatherpi weewx[417]: manager: Added record 2018-06-27 10:50:00 EDT (1530111000) to database 'weewx.sdb'

Jun 27 10:50:15 weatherpi weewx[417]: manager: Added record 2018-06-27 10:50:00 EDT (1530111000) to daily summary in 'weewx.sdb'

Jun 27 10:50:16 weatherpi weewx[417]: restx: Wunderground-PWS: Published record 2018-06-27 10:50:00 EDT (1530111000)

Jun 27 10:50:37 weatherpi weewx[417]: cheetahgenerator: Generated 14 files for report StandardReport in 20.82 seconds

Jun 27 10:50:40 weatherpi weewx[417]: imagegenerator: Generated 12 images for StandardReport in 2.81 seconds

Jun 27 10:50:40 weatherpi weewx[417]: copygenerator: copied 9 files to /var/www/html/weewx

Jun 27 10:55:08 weatherpi ntpd[340]: 206.108.0.131 local addr 192.168.1.19 -> <null>

Jun 27 10:55:47 weatherpi ntpd[340]: 209.115.181.108 local addr 192.168.1.19 -> <null>

Jun 27 10:55:47 weatherpi ntpd[340]: 206.108.0.133 local addr 192.168.1.19 -> <null>

Jun 27 10:56:48 weatherpi ntpd[340]: 149.56.47.60 local addr 192.168.1.19 -> <null>

Jun 27 10:57:23 weatherpi ntpd[340]: 209.115.181.107 local addr 192.168.1.19 -> <null>

Jun 27 10:57:26 weatherpi ntpd[340]: 206.108.0.132 local addr 192.168.1.19 -> <null>

Jun 27 10:57:51 weatherpi ntpd[340]: 144.217.65.182 local addr 192.168.1.19 -> <null>

Jun 27 10:58:05 weatherpi ntpd[340]: 192.95.27.155 local addr 192.168.1.19 -> <null>

Jun 27 10:58:34 weatherpi ntpd[340]: 144.217.65.183 local addr 192.168.1.19 -> <null>

Jun 27 10:59:48 weatherpi systemd[1]: Starting Cleanup of Temporary Directories...

Jun 27 10:59:49 weatherpi systemd[1]: Started Cleanup of Temporary Directories.

Jun 27 11:00:15 weatherpi weewx[417]: manager: Added record 2018-06-27 11:00:00 EDT (1530111600) to database 'weewx.sdb'

Jun 27 11:00:15 weatherpi weewx[417]: manager: Added record 2018-06-27 11:00:00 EDT (1530111600) to daily summary in 'weewx.sdb'

Jun 27 11:00:15 weatherpi weewx[417]: restx: Wunderground-PWS: Published record 2018-06-27 11:00:00 EDT (1530111600)

Jun 27 11:00:23 weatherpi weewx[417]: cheetahgenerator: Generated 14 files for report StandardReport in 8.16 seconds

Jun 27 11:00:35 weatherpi weewx[417]: imagegenerator: Generated 24 images for StandardReport in 11.44 seconds

Jun 27 11:00:35 weatherpi weewx[417]: copygenerator: copied 0 files to /var/www/html/weewx

Jun 27 11:06:57 weatherpi ntpd[340]: 159.203.8.72 local addr 192.168.1.19 -> <null>

Jun 27 11:10:15 weatherpi weewx[417]: manager: Added record 2018-06-27 11:10:00 EDT (1530112200) to database 'weewx.sdb'

Jun 27 11:10:15 weatherpi weewx[417]: manager: Added record 2018-06-27 11:10:00 EDT (1530112200) to daily summary in 'weewx.sdb'

Jun 27 11:10:16 weatherpi weewx[417]: restx: Wunderground-PWS: Published record 2018-06-27 11:10:00 EDT (1530112200)

Jun 27 11:10:24 weatherpi weewx[417]: cheetahgenerator: Generated 14 files for report StandardReport in 8.50 seconds

Jun 27 11:10:26 weatherpi weewx[417]: imagegenerator: Generated 12 images for StandardReport in 2.54 seconds

Jun 27 11:10:27 weatherpi weewx[417]: copygenerator: copied 0 files to /var/www/html/weewx

David

vince

unread,

Jun 27, 2018, 11:53:19 AM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 8:15:41 AM UTC-7, David Beach wrote:

I just did a quick edit of the engine.py file, changing the 1 Jan 2000 date to 1 Jan 2018. It seems to work! Yahoo! Maybe a software solution is near. There are still a few odd bits.

The strange

Jun 27 10:55:08 weatherpi ntpd[340]: 206.108.0.131 local addr 192.168.1.19 -> <null>

try "sudo ntpq -pn" and verify that ntp is working ok.

It should look something like:

remote refid st t when poll reach delay offset jitter
==============================================================================
-23.239.26.89 216.218.254.202 2 u 166 1024 337 71.975 2.606 0.873
+162.210.110.4 216.218.254.202 2 u 874 1024 377 11.968 -0.179 0.628
+104.236.116.147 128.59.0.245 2 u 564 1024 377 90.327 -2.113 2.336
*198.60.22.240 .XMIS. 1 u 241 1024 337 44.195 0.569 0.415

(your values will differ since you'll synch to different servers almost certainly)

Thomas Keffer

unread,

Jun 27, 2018, 12:22:57 PM6/27/18

to weewx-user

Try this version of engine.py.

It will make sure that the system time is later than the creation time of the configuration file, weewx.conf, which should always be in the "recent past."

If it works, I think we can sneak it into the V3.8.1 release, due RSN.

-tk

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

engine.py

vince

unread,

Jun 27, 2018, 12:33:53 PM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 9:22:57 AM UTC-7, Thomas Keffer wrote:

Try this version of engine.py.

It will make sure that the system time is later than the creation time of the configuration file, weewx.conf, which should always be in the "recent past."

Tom - can you add a weewx.conf switch to let us suppress that behavior (for any crazy edge cases that might be out there) ?

Thomas Keffer

unread,

Jun 27, 2018, 12:37:41 PM6/27/18

to weewx-user

How about

touch weewx.conf

-tk

--

Andrew Milner

unread,

Jun 27, 2018, 1:32:24 PM6/27/18

to weewx-user

What a superb solution Tom, and so obvious when one thinks about it. Could be even 'cleverer' by saying system time must be > latest created file in images, public_html, etc etc …...

Thomas Keffer

unread,

Jun 27, 2018, 1:42:37 PM6/27/18

to weewx-user

I thought of that, but there is no guarantee that those files have been generated. Indeed, that they will ever be generated.

The weewx.conf file must be present, and it must have a creation date greater than or equal to the last upgrade. So, it seemed like the safest bet.

-tk

vince

unread,

Jun 27, 2018, 2:13:09 PM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 9:37:41 AM UTC-7, Thomas Keffer wrote:

How about

touch weewx.conf

I was looking for something we could set and forget once for those cases.

I 'guess' as a workaround they could put the touch in rc.local so it runs every boot, but that seems a little kludgey to me, but it'll of course work.

David Beach

unread,

Jun 27, 2018, 2:32:31 PM6/27/18

to weewx...@googlegroups.com

Vince: here is what that command shows on my RPi:

pi@weatherpi:/ $ sudo ntpq -pn

remote refid st t when poll reach delay offset jitter

==============================================================================

0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002

1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002

2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002

3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.002

+158.69.226.90 213.251.128.249 2 u 316 1024 377 45.341 1.129 0.954

*198.100.148.213 129.6.15.30 2 u 410 1024 377 32.839 -0.371 0.672

+129.128.12.20 129.128.153.62 2 u 481 1024 377 71.355 -1.062 1.068

+208.81.1.244 216.218.254.202 2 u 267 1024 377 44.989 -0.273 1.187

-199.19.167.36 208.90.144.52 3 u 125 1024 377 32.509 3.559 2.988

+208.73.56.29 216.218.254.202 2 u 88 1024 377 93.979 -0.207 1.503

Does that make any sense to you?

David

Thomas Keffer

unread,

Jun 27, 2018, 2:34:13 PM6/27/18

to weewx-user

I can imagine a failure mode where the creation timestamp for weewx.conf is somehow way in the future. In that case, 'touching' it would fix the problem.

Are you seeing a mode that I'm not seeing?

-tk

Greg Troxel

unread,

Jun 27, 2018, 2:56:02 PM6/27/18

to Thomas Keffer, weewx-user

I am not really familiar with the details of the time sync struggles
(having a machine with a clock and using NetBSD not linux), but:

the theory is that it's trouble to run when the system clock is in the
past, relative to archive records that are already in the db

so

how about when weewx starts, it figures out from the db what the
latest archive record time is, and if that's in the future, logs an
error and waits?

That should avoid writing things to the db that are trouble, at the
expense of making somebody clean up a bad db before continuing.

But maybe I am missing something.

signature.asc

vince

unread,

Jun 27, 2018, 3:07:03 PM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 11:34:13 AM UTC-7, Thomas Keffer wrote:

I can imagine a failure mode where the creation timestamp for weewx.conf is somehow way in the future. In that case, 'touching' it would fix the problem.

Are you seeing a mode that I'm not seeing?

Picture somebody with a station and a small display that box (a pi maybe) can drive to make a local console. They can set up the pi at home 'on' the network so the clock would by default be correct. They take that known-good pi+station out someplace, say a RV or boat or vacation home, to a location with no internet. Boot that previously-working setup up and weewx will hang forever awaiting time.

Again, touching weewx.conf in rc.local would definitely handle that case as a workaround, if they could somehow log into the pi (remember, it's off the grid).

Reason I bring it up is I see some folks in the WeatherFlow forums who seem to want to run their units off the network with a local display they'd cook up with weewx....but definitely an edge case to the normal pi user scenarios we see rather often.

David Beach

unread,

Jun 27, 2018, 3:19:26 PM6/27/18

to weewx...@googlegroups.com

I loaded the 'new' engine.py tk sent and shutdown/unplugged my RPi then rebooted. weeWX seems to work! I think maybe we have a working fix. I'll try abusing my system by simulating some power failures along with orderly shutdowns.

I know-nothing about the innards of weewx but how often does the weewx.conf file date change? Only when you install the program or manually change a configuration? I was just wondering if the 3 Nov 2016 date that seems carved into Raspian Stretch will change with an update/upgrade of the system, changing to a date newer than the conf file. I suppose the fix would be to just change something in the weewx.conf file.

Are there any Raspian architects on this list who know why Stretch has this 3 Nov 2016 date that keeps appearing?

Sadly, the funny ntpd statements are still appearing. If anyone has ideas how to get rid of them, let me know!

pi@weatherpi:~ $ sudo tail -f /var/log/syslog

Jun 27 15:00:04 weatherpi systemd[1268]: Startup finished in 144ms.

Jun 27 15:00:04 weatherpi systemd[1]: Started User Manager for UID 1000.

Jun 27 15:00:16 weatherpi weewx[417]: manager: Added record 2018-06-27 15:00:00 EDT (1530126000) to database 'weewx.sdb'

Jun 27 15:00:16 weatherpi weewx[417]: manager: Added record 2018-06-27 15:00:00 EDT (1530126000) to daily summary in 'weewx.sdb'

Jun 27 15:00:16 weatherpi weewx[417]: restx: Wunderground-PWS: Published record 2018-06-27 15:00:00 EDT (1530126000)

Jun 27 15:00:39 weatherpi weewx[417]: cheetahgenerator: Generated 14 files for report StandardReport in 22.40 seconds

Jun 27 15:00:53 weatherpi ntpd[339]: 206.108.0.131 local addr 192.168.1.19 -> <null>

Jun 27 15:00:56 weatherpi ntpd[339]: 206.108.0.134 local addr 192.168.1.19 -> <null>

Jun 27 15:00:57 weatherpi weewx[417]: imagegenerator: Generated 36 images for StandardReport in 17.62 seconds

Jun 27 15:00:57 weatherpi weewx[417]: copygenerator: copied 9 files to /var/www/html/weewx

Jun 27 15:01:56 weatherpi ntpd[339]: 144.217.181.221 local addr 192.168.1.19 -> <null>

Jun 27 15:03:13 weatherpi ntpd[339]: 206.108.0.132 local addr 192.168.1.19 -> <null>

Jun 27 15:03:37 weatherpi ntpd[339]: 206.108.0.133 local addr 192.168.1.19 -> <null>

Jun 27 15:05:26 weatherpi ntpd[339]: 209.115.181.108 local addr 192.168.1.19 -> <null>

Jun 27 15:05:26 weatherpi systemd[1]: Starting Cleanup of Temporary Directories...

Jun 27 15:05:26 weatherpi systemd[1]: Started Cleanup of Temporary Directories.

Jun 27 15:06:28 weatherpi ntpd[339]: 158.69.125.231 local addr 192.168.1.19 -> <null>

Jun 27 15:07:38 weatherpi ntpd[339]: 144.217.65.184 local addr 192.168.1.19 -> <null>

David

To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/6zToC6kdfuU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+unsubscribe@googlegroups.com.

vince

unread,

Jun 27, 2018, 6:37:04 PM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 12:19:26 PM UTC-7, David Beach wrote

Sadly, the funny ntpd statements are still appearing. If anyone has ideas how to get rid of them, let me know!

Are they hurting something ?

Jun 27 15:00:53 weatherpi ntpd[339]: 206.108.0.131 local addr 192.168.1.19 -> <null>

Jun 27 15:00:56 weatherpi ntpd[339]: 206.108.0.134 local addr 192.168.1.19 -> <null>

https://serverfault.com/questions/625279/understanding-ntpd-entry-in-syslog says they mean that the system previously was set to use those as upstream time servers, but they're not reachable now.

Does "ntpq -pn" show you successfully synchronizing with upstream servers ?

If so, you're probably ok as is....

If you want to dig deeper, try "sudo grep ntpd /var/log/syslog" and google any funny looking entries....

Greg Troxel

unread,

Jun 27, 2018, 6:56:05 PM6/27/18

to vince, weewx-user

vince <vince...@gmail.com> writes:

> On Wednesday, June 27, 2018 at 11:34:13 AM UTC-7, Thomas Keffer wrote:
>>
>> I can imagine a failure mode where the creation timestamp for weewx.conf
>> is somehow way in the future. In that case, 'touching' it would fix the
>> problem.
>>
>> Are you seeing a mode that I'm not seeing?
>>
>>>
>>>
> Picture somebody with a station and a small display that box (a pi maybe)
> can drive to make a local console. They can set up the pi at home 'on'
> the network so the clock would by default be correct. They take that
> known-good pi+station out someplace, say a RV or boat or vacation home, to
> a location with no internet. Boot that previously-working setup up and
> weewx will hang forever awaiting time.

Which is correct. When the time is set manually to close, it will be
fine. A computer with no RTC and no network for ntpd (and no GPS
receiver to set the time) just cannot correctly deal with logging data
with timetamps.

> Reason I bring it up is I see some folks in the WeatherFlow forums who seem
> to want to run their units off the network with a local display they'd cook
> up with weewx....but definitely an edge case to the normal pi user
> scenarios we see rather often.

Sure, but if you want to do that, you need to figure out a way to have
time set.

signature.asc

vince

unread,

Jun 27, 2018, 7:41:07 PM6/27/18

to weewx-user

On Wednesday, June 27, 2018 at 3:56:05 PM UTC-7, Greg Troxel wrote:

vince <vince...@gmail.com> writes:

> Boot that previously-working setup up and
> weewx will hang forever awaiting time.

Which is correct. When the time is set manually to close, it will be
fine. A computer with no RTC and no network for ntpd (and no GPS
receiver to set the time) just cannot correctly deal with logging data
with timetamps.

I would suggest that software should never hang forever under any circumstances......

Incidentally if you really want to blow weewx's mind, mess with the time setting systemd time control on/off while the report thread is running. The report thread gets verrrry confused to say the least.

Jun 27 23:37:23 raspberrypi weewx[298]: imagegenerator: Generated 12 images for StandardReport in 4.87 seconds
Jun 27 23:37:23 raspberrypi weewx[298]: copygenerator: copied 0 files to /var/www/html/weewx
Jun 27 23:37:25 raspberrypi weewx[298]: manager: Unable to add record 2016-11-04 09:25:00 UTC (1478251500) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
Jun 27 23:37:28 raspberrypi weewx[298]: manager: Unable to add record 2016-11-04 09:30:00 UTC (1478251800) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
Jun 27 23:37:28 raspberrypi weewx[298]: engine: Launch of report thread aborted: existing report thread still running
Jun 27 23:37:31 raspberrypi weewx[298]: manager: Unable to add record 2016-11-04 09:35:00 UTC (1478252100) to database 'weewx.sdb': UNIQUE constraint failed: archive.dateTime
Jun 27 23:37:32 raspberrypi weewx[298]: engine: Launch of report thread aborted: existing report thread still running

Not to belabor the point, but I guess for the "don't care about any db" case the safest thing would be to run /home/weewx/archive in tmpfs so that it gets created anew on every bootup.

David Beach

unread,

Jun 27, 2018, 8:02:35 PM6/27/18

to weewx...@googlegroups.com

Those mystery reports just annoy me because I don't know what they mean (though I an finding out more) and because I hate 'useless' stuff that consumes CPU cycles and accomplishes nothing. Not that my RPi is overloaded but code that you don't execute is unlikely to cause problems. (Like to old adage for writing clean, compact code that "Code you don't write doesn't have bugs.")

Take a look at my post of 2:32 pm today. It shows the output of the "sudo ntpq -pn" command from my RPi.

Here is the result of running the "sudo grep ntpd /var/log/syslog" command. I have put in one section that began after what I think was a reboot:

....

Nov 3 13:16:57 weatherpi ntpd[333]: ntpd 4.2....@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1): Starting

Nov 3 13:16:57 weatherpi ntpd[333]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:118

Nov 3 13:16:57 weatherpi ntp[307]: Starting NTP server: ntpd.

Nov 3 13:16:57 weatherpi ntpd[339]: proto: precision = 2.000 usec (-19)

Nov 3 13:16:57 weatherpi ntpd[339]: Listen and drop on 0 v6wildcard [::]:123

Nov 3 13:16:57 weatherpi ntpd[339]: Listen and drop on 1 v4wildcard 0.0.0.0:123

Nov 3 13:16:57 weatherpi ntpd[339]: Listen normally on 2 lo 127.0.0.1:123

Nov 3 13:16:57 weatherpi ntpd[339]: Listen normally on 3 lo [::1]:123

Nov 3 13:16:57 weatherpi ntpd[339]: Listening on routing socket on fd #20 for interface updates

Nov 3 13:16:58 weatherpi ntpd[339]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)

Nov 3 13:16:59 weatherpi ntpd[339]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)

Nov 3 13:17:00 weatherpi ntpd[339]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)

Nov 3 13:17:01 weatherpi ntpd[339]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)

Nov 3 13:17:03 weatherpi ntpd[339]: bind(23) AF_INET6 fe80::2d44:5da4:e953:f7b%2#123 flags 0x11 failed: Cannot assign requested address

Nov 3 13:17:03 weatherpi ntpd[339]: unable to create socket on wlan0 (4) for fe80::2d44:5da4:e953:f7b%2#123

Nov 3 13:17:03 weatherpi ntpd[339]: failed to init interface for address fe80::2d44:5da4:e953:f7b%2

Nov 3 13:17:05 weatherpi ntpd[339]: Listen normally on 5 wlan0 [fe80::2d44:5da4:e953:f7b%2]:123

Nov 3 13:17:08 weatherpi ntpd[339]: Listen normally on 6 wlan0 192.168.1.19:123

Nov 3 13:18:05 weatherpi ntpd[339]: Soliciting pool server 174.94.155.224

Nov 3 13:18:05 weatherpi ntpd[339]: Soliciting pool server 206.108.0.133

Nov 3 13:18:05 weatherpi ntpd[339]: Soliciting pool server 144.217.65.184

Nov 3 13:18:06 weatherpi ntpd[339]: Soliciting pool server 207.210.46.249

Nov 3 13:18:06 weatherpi ntpd[339]: Soliciting pool server 144.217.65.183

Nov 3 13:18:06 weatherpi ntpd[339]: Soliciting pool server 198.100.148.213

Nov 3 13:18:07 weatherpi ntpd[339]: Soliciting pool server 199.182.221.110

Nov 3 13:18:07 weatherpi ntpd[339]: Soliciting pool server 209.115.181.108

Nov 3 13:18:07 weatherpi ntpd[339]: Soliciting pool server 209.115.181.107

Nov 3 13:18:08 weatherpi ntpd[339]: Soliciting pool server 129.128.12.20

Nov 3 13:18:08 weatherpi ntpd[339]: Soliciting pool server 144.217.245.233

Nov 3 13:18:08 weatherpi ntpd[339]: Soliciting pool server 206.108.0.134

Nov 3 13:18:08 weatherpi ntpd[339]: Soliciting pool server 206.108.0.131

Nov 3 13:18:09 weatherpi ntpd[339]: Soliciting pool server 206.108.0.132

Nov 3 13:18:09 weatherpi ntpd[339]: Soliciting pool server 2600:1f11:2f8:1000:d631:43d8:783:a196

Nov 3 13:18:10 weatherpi ntpd[339]: Soliciting pool server 144.217.181.221

Nov 3 13:18:11 weatherpi ntpd[339]: Soliciting pool server 158.69.125.231

Jun 27 14:51:51 weatherpi ntpd[339]: receive: Unexpected origin timestamp 0xdbc5efd5.be42de12 does not match aorg 0000000000.00000000 from ser...@207.210.46.249 xmt 0xdede5b47.4b93d852

Jun 27 14:51:51 weatherpi ntpd[339]: receive: Unexpected origin timestamp 0xdbc5efd5.be242345 does not match aorg 0000000000.00000000 from ser...@206.108.0.131 xmt 0xdede5b47.4c7c86ea

Jun 27 14:51:51 weatherpi ntpd[339]: receive: Unexpected origin timestamp 0xdbc5efd5.be3de158 does not match aorg 0000000000.00000000 from ser...@144.217.65.183 xmt 0xdede5b47.4e1db9aa

Jun 27 14:51:51 weatherpi ntpd[339]: receive: Unexpected origin timestamp 0xdbc5efd5.be4bcd9f does not match aorg 0000000000.00000000 from ser...@174.94.155.224 xmt 0xdede5b47.5080be89

Jun 27 14:51:51 weatherpi ntpd[339]: receive: Unexpected origin timestamp 0xdbc5efd5.be3808bf does not match aorg 0000000000.00000000 from ser...@209.115.181.108 xmt 0xdede5b47.4fb3ed7d