Tom,
It seems that with Acurite no matter what setting is for record
generation it is really always using software. I have run a couple of tests
with different archive_interval settings that indicate there is some kind
of issue with the accumulator (accum.py) code that triggers this shutdown.
If I use an archive_interval value that is integer divisible into the
1440mins, I used 360 for my test, of a 1 day cycle the timestamp for
weewx.sdb record additions matches to the minute with the system time stamp
in the syslog log. However, if I use the archive_interval of 7min (420), or
I suspect 14min (840) the timestamps for weewx.sdb get off track pretty
quickly (the issue that Gary pointed out).
As you say this is likely a small issue, but may make sense at some point
to not allow certain archive intervals given that they cause issues for
accumulated stat generation processes.
As an aside, why does cmon skin always have the correct and exact match to
the system timestamp for its record add time? I'm assuming it is because it
does not need to do accumulated stats so it just grabs the system time
instead of calculating time as accum.py, manager.py, and engine.py do.
Thanks,
Bryan
On Tuesday, February 5, 2019 at 9:43:58 AM UTC-5, Thomas Keffer wrote:
>
> On Tue, Feb 5, 2019 at 6:22 AM mwall <[email protected] <javascript:>>
> wrote:
>
>> the OutOfSpan failure killed the report thread, and that brought down
>> weewx. imho this is a bug - weewx should continue to collect data, even if
>> the report thread cannot do its job.
>>
>
> I'm not seeing that. When the engine shuts down, it calls the shutDown()
> method of all running services. Then the engine exits. I think what you are
> seeing is the results of calling StdReport.shutDown().
>
> Perhaps this could be made more clear by having the engine put a message
> in the log to the effect ("Engine exiting; starting shutdown of all
> services") before calling all the shutDown() methods.
>
> As to the root cause, it's probably the unusual archive interval (420
> seconds). There may be an underlying assumption in the code that the
> midnight boundary will always fall at the end of an archive interval and,
> when it doesn't, this failure occurs. I'd have to test.
>
> But, is it important? Yes, there's probably a bug, but it's a pretty minor
> one. Alternatively, we could test the archive interval to make sure it's
> divisible into 60 and refuse to run if it isn't.
>
> -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 [email protected].
For more options, visit https://groups.google.com/d/optout.
