There is an underlying assumption in WeeWX that, somewhere, there is a
clock that can be depended on. It is simply impossible to write data
acquisition software without a definitive time source. In the long run,
strategies to get around that are just going to make things worse.
-tk
On Tue, Sep
> Is this check only done at startup?
Yes. It’s a check only at startup during a catchup phase meant to insert
archive records that might have been generated by the device since the time of
the last archive record inserted in the weewx database.
My reply was a narrow one, responding only to
Is this check only done at startup? I am seeing this happen during the
ecowitt update sent via the station itself. The interceptor driver is
receiving an update from the station with a timestamp in the future. Once
it is processed no more updates are added to the database until after the
time
This is done already for catchup at startup time. See engine.py “Reject any
records with a timestamp in the future.” It uses the current time and allows
archive_delay seconds for clock drift.
> On Sep 14, 2020, at 6:54 PM, vince wrote:
>
>
>> On Monday, September 14, 2020 at 5:03:23 PM
On Monday, September 14, 2020 at 5:03:23 PM UTC-7, YB322 wrote:
>
> It is clearly something with the station itself, but not sure why it is
> randomly throwing a time in the future, think it is some kind of bug in the
> latest firmware as I have now seen a couple of other posts with the same
>
After a few weeks of success the problem appears to have resurfaced. I have
done some extra research, the weather station is randomly throwing records
with a date in the future. See below:
A correct log (UTC 19:58 - 05:58 local time):
Sep 15 05:59:08 raspberrypi weewx[15243] DEBUG
Just a quick update in case it helps someone.
I was reminded that there was a power outage around the same time this
started happening. Not one to believe in coincidence, I restored the
database from a backup of the day before the power outage, and filled the
missing data using wee_import from
Yes, that is the unit I am using. I use the WS View to configure it, the is
no option to update the timezone, it may have been an option when I first
setup, it was a while ago I don't remember if it was. I will try a factory
rest on the station and re-configure and see if there is.
Thanks
Thought the 9 hour difference seemed familiar but thought it was the other
side of GMT. I'm in Brisbane.
That's interesting about no timezone because the WU format packet coming
from your station includes a UTC format date-time string so the station
must somehow know what timezone it is in.
Thanks Gary,
Timezone is Sydney\Australia (AEST - UTC+10). The station doesn't have a
timezone setting just date and time, which does look correct.
It is really strange the setup had been working well for years and just
started doing it this week. I created a new server with Ubuntu 20.04 as a
Adam,
Definitely a time issue, what timezone are you in and is the timezone set
correctly in you stations console?
Gary
On Saturday, 29 August 2020 at 20:25:41 UTC+10 YB322 wrote:
> Thanks Gary
>
> Appreciate you taking a look. I have stared at the log for the last week
> and not noticed that
Thanks Gary
Appreciate you taking a look. I have stared at the log for the last week
and not noticed that one.
I have pasted the debug here https://pastebin.com/vrsDg0G6
unit is a PanTech WH2900. It does have a time setting, although it does
look correct.
Thanks
Adam
On Saturday, 29
Hi,
I’d say you are suffering from a little temporal displacement:
Aug 29 08:00:38 weewx weewx[2328] DEBUG user.interceptor: raw packet:
{'dateTime': *1598684400*, 'usUnits': 1, 'rain_total': 0.0,
'temperature_in': 64.6, 'temperature_out': 47.7, 'dewpoint': 41.5,
'windchill': 46.8,
13 matches
Mail list logo
