Hi,
This gives us a clue to what is going on and the possible cause of the
OutOfSpan error :
Feb 2 07:19:17 bdp-rpiz1 weewx[21597]: manager: Added record 2019-02-02 07:
19:17 EST (1549109957) to database 'cmon.sdb'
Feb 2 07:19:17 bdp-rpiz1 weewx[21597]: manager: Added record 2019-02-02 07:
19:17 EST (1549109957) to daily summary in 'cmon.sdb'
Feb 2 07:19:18 bdp-rpiz1 weewx[21597]: manager: Added record 2019-02-02 07:
14:00 EST (1549109640) to database 'weewx.sdb'
Feb 2 07:19:18 bdp-rpiz1 weewx[21597]: manager: Added record 2019-02-02 07:
14:00 EST (1549109640) to daily summary in 'weewx.sdb'
I suspect that the large difference between the actual system time and the
timestamp of the archive record being saved to weewx.sdb is upsetting WeeWX
when the accumulators change at midnight. The WeeWX accumulators work on a
midnight-to-midnight period and the recipt of the first loop data
timestamped after midnight causes a new accumulator to be created and used.
Once WeeWX has moved on to a new accumulator for the current day it does
not like to see an old data from the previous day. Restarting WeeWX may
deal with the fatal error but it will certainly not cure it, it will
continue to occur shortly after midnight.
You might try to edit weewx.conf and under [StdArchive] set record_generation
= software, the Acurite driver does not support downloading archive records
from the station and WeeWX should fall back to software record generation
but let's force it right from the start. I would also put the archive
interval back to 300, having it at 420 will do nothing to help with the
issue, rather the odd interval only serves to make interpreting the logs
more difficult. [StdArchive] should look something like (changes
highlighted):
[StdArchive]
# If the station hardware supports data logging then the archive
interval
# will be downloaded from the station. Otherwise, specify it (in
seconds).
archive_interval = 300
# If possible, new archive records are downloaded from the station
# hardware. If the hardware does not support this, then new archive
# records will be generated in software.
# Set the following to "software" to force software record generation.
record_generation = software
....
After making these changes save weewx.conf then restart WeeWX. Monitor the
logs to see what happens around midnight.
If this does not fix the problem could you run WeeWX directly
<http://weewx.com/docs/usersguide.htm#Running_directly>. This will display
on the console (screen) the loop data from your station (indicated by lines
starting with LOOP:) as well as the archive records generated by WeeWX
(indicated by lines starting with (REC:). Let this run for 10-15 minutes
and post a capture of the data displayed on the console.
Gary
On Monday, 4 February 2019 03:06:57 UTC+10, Bryan Peter wrote:
>
> I have been seeing the following Error/Exit of weewx over the past several
> days. Here are the details of my configuration:
>
> Wx Station: Acurite 01525 with 5 in 1 sensor
> Server: Rpi Zero W with attached powered USB 3.0 Hub with attached hard
> drive for /var and /home
> OS: Linux bdp-rpiz1 4.14.79+ #1159 Sun Nov 4 17:28:08 GMT 2018 armv6l
> GNU/Linux
> weewx version: 3.8.2
> extensions: cmon 0.16, exfoliation 0.45
>
> Installation info and details:
>
> I have been running weewx for a few years successfully on various versions
> of Rpi and Intel systems using Acurite stations
> This install was a fresh install on the Pi Zero W. I had this station
> running on an Intel box that suddenly lost its Wifi so decided to
> transition to the Zero as a lower energy replacement.
> ran the simulator station type for several days to make sure install
> working and found no issues. Made cut over from Intel to Pi zero by doing
> the following:
>
> 1) stop weewx on RpiZ
> 2) wee_config (to add the Acurite driver to my config file)
> 3) deleted the old simulator mode database files from /var/lib
> 4) stop weewx on Intel box
> 5) wee_database --drop-daily (on Intel box)
> 6) wee_database --rebuild-daily (on Intel box)
> 7) copied cmon.sdb, forecast.sdb, weewx.sdb form Intel box to RpiZ
> 8) restart weewx on RpiZ
>
> Monitored logs for a time and things looked good except I was seeing that
> the RpiZ was having trouble keeping up with Image generation, forecast file
> generation cycles taking 4X longer than on my Rpi3. So ran into some
> StdReport Thread aborts due to current report still running.
> I let this go for the first day or so things seemed fine then I saw the
> first OutOfSpan error log with weewx halting during the overnight (just
> after midnight). It was very strange though as the system did not show
> weewx running in the process status table or systemctl status data, but
> attempts to restart weewx via "sudo service weewx start", did not work. I
> found I had to issue "sudo service weewx stop" to clean some system status
> up to restart weewx. (note: reboot cleans things up as well, have done that
> too).
>
> Next I reviewed the OutOfSpan: Attempt to merge an accumulator whose
> timespan is not a subset (Benson, et.al) from 2014 which different
> because it is aculink and not acurite for the driver at the time. It
> suggested in on part of thread to adjust the archive_interval time in 60
> sec increments to eliminate the issue so I adjusted the interval in my
> system to 420 from default 300. This seemed to give the RPiZ enough time to
> always finish a StdReport cycle before the next one started.
>
> The system got through an overnight without any issues so I thought the
> issue was fixed. However, it failed the next overnight again with the same
> OutOfSpan error.
> Reviewing the system logs seems to indicate that that error only occurs
> when the archive cycle crosses over the 0 hour boundary of a new day. In
> particular the archive update to the cmon.sdb happens without issue, but
> the weewx.sdb update fails with the OutOfSpan error.
>
> I have turned on debug mode to show all activity and have added the Rsync
> skin as I'm looking to shorten the effort on the RpiZ by removing the FTP
> skin so I can get back to default archive cycle and use another server to
> do FTP upload. However, the latest overnight did not cause the error as
> archive cycle did not cross the 0 hour. I will update with the debug mode
> log when I get the failure again.
>
> I have not seen this issue on a separate station that I have running on an
> Rpi3 using weewx version 3.6.1, same acurite 01525 and acurite.py v0.24
> driver. I checked the most recent 7 syslog files on that server and none of
> them have the archive crossing the 0 hour boundary. But it must have been
> the case in the past given random restart times, etc.
>
> I have included 3 syslog files and my weewx.conf file
>
> 1) syslog.1 - Last nights with debug mode turned on No failure, but let me
> know if it has the detail needed
> 2) syslog.2 - Overnight Failure log no debug mode
> 3) syslog.4 - Overnight No Failure log no debug mode
>
> Looking for inputs and help resolving this error other than a separate
> system monitor that forces a weewx restart due to lack of index.html update
> which I have implemented as a patch to keep things going.
> Thanks in advance for the help!
> Please let me know any additional info needed
>
> -Bryan
>
>
>
>
>
--
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
