Gary - FYI - there are only 3 countries who change clocks back at midnight
- Brazil, Cuba and I think one other - everyone else changes at 0200 or
0100, so on your reasoning would not have any issues. A specific fudge may
therefore not be too unreasonable an approach.
On Wednesday, 14
tks!
:)
Em qua, 14 de nov de 2018 às 11:19, gjr80 escreveu:
> Yes that link is exactly the same problem. Seems the issue was identified
> but never fixed. I know that a gambiarra was posted in that thread but I
> don't think that is really a viable long term solution. As I said earlier
> this
Yes that link is exactly the same problem. Seems the issue was identified
but never fixed. I know that a gambiarra was posted in that thread but I
don't think that is really a viable long term solution. As I said earlier
this is a presentation issue and not affecting the data going to database
oo my mistake! The link that I've sent includes Brazilian language
set...and yes, 'eu' means "I" ;)
Em ter, 13 de nov de 2018 às 22:24, gjr80 escreveu:
> I think I now understand why a fresh install still encounters the same
> error, weeWX uses a whole pile of different timespans to
I think I now understand why a fresh install still encounters the same
error, weeWX uses a whole pile of different timespans to work out
aggregates over a whole pile of different periods, some into the past. If
one of those timespans happens to include midnight when daylight savings
cuts in
Yeah.I thought the same about brazilian saving time change..that's
why I've uninstalled everything and cleared all database files so Weewx
create a new one on startup.but as you know, no success.
Maybe this can help?!
Thanks Jonis,
The following log extract captures the error along with a few extra details
from tags.py, in particular the timespan being used by the $week.wind.avg
call that caused the error
Nov 13 12:31:52 SkyWeather weewx[17639]: ObservationBinder._do_query:
timespan=[2018-11-03 00:00:00
Gary, I've sent logs direct to you.
Em seg, 12 de nov de 2018 às 23:17, gjr80 escreveu:
> Tom is the author/developer, the rest of us just help out where/when we
> can.
>
> I have attached a version of tags.py with some extra logging to
> hopefully give us a clue why things are happening.
Tom is the author/developer, the rest of us just help out where/when we can.
I have attached a version of tags.py with some extra logging to hopefully
give us a clue why things are happening. What I would like you to do on
your problem install is:
1. rename /usr/share/weewx/weewx/tags.py as
I'm not sure who is the mais author/developer, but I can give you access to
my station. It's in use right now, but is not imperative to keep online
24/7, so you can access and check/test. The only thing is that I'm using my
old mysql databasebut. like I said before, I've made tests with clean
Tom, yes knew that was going on as soon as I saw the error message. Just having
a trouble finding out why. Somewhere a timestamp must be missing a day boundary
but I haven't yet worked out which. Particularly confusing when a clean
database exhibits the same problem immediately. Also odd that
Gary: one thing I'm noticing is that the tag
DaySummaryManager.getAggregate() is using its superclass version,
Manager.getAggregate(), presumably because the boundaries of the query are
not falling on midnight.
A clue, perhaps...?
-tk
On Sun, Nov 11, 2018 at 3:03 PM gjr80 wrote:
> I have set
Yes Andrew, same problem. Like I said before, I've tried with a fresh-new
install, with all default configs and no mods, including skins, just
default installation and Standard skin/configuration, including default
sqlite database. Problem is alwayd the same.
I'm running new skin now because
The site URL you gave is not running the standard weewx skin, but is
instead appears to be using the Belchertown skin and using Highcharts to do
the graphing. Do you get the same 'problems' if you just use the Standard
skin which comes with weewx What else have you loaded on top of the
Yes, I'm using this file: weewx_3.8.2-1_all.deb
Currently I'm using with MySQLthe problem persist (wind error in logs),
but archive is being generated. http://weather.jonis.com.br/
Em dom, 11 de nov de 2018 às 21:03, gjr80 escreveu:
> I have set up a Stretch VM using the same locale and
I have set up a Stretch VM using the same locale and timezone settings as
you running a .deb weeWX install and I cannot reproduce the fault you are
experiencing. This really brings me back to the your database. I will
instrument one of the weeWX files with some extra logging so we can see
Sure!
And one more info: this error (wind) happens on all skins.
pi@SkyWeather:~ $ locale
> LANG=en_GB.UTF-8
> LANGUAGE=
> LC_CTYPE="en_GB.UTF-8"
> LC_NUMERIC="en_GB.UTF-8"
> LC_TIME="en_GB.UTF-8"
> LC_COLLATE="en_GB.UTF-8"
> LC_MONETARY="en_GB.UTF-8"
> LC_MESSAGES="en_GB.UTF-8"
>
I have not forgotten this. Definitely starting with a clean database:
Nov 5 10:02:31 SkyWeather weewx[30088]: manager: Created and initialized
table 'archive' in database 'weewx.sdb'
Nov 5 10:02:31 SkyWeather weewx[30088]: manager: Created daily summary
tables
Interesting that the only
Yes, logs from fresh install yesterday.
Nov 5 10:02:31 SkyWeather weewx[30084]: engine: Initializing weewx version
>> 3.8.2
>
> Nov 5 10:02:31 SkyWeather weewx[30084]: engine: Using Python 2.7.13
>> (default, Sep 26 2018, 18:42:22) #012[GCC 6.3.0 20170516]
>
> Nov 5 10:02:31 SkyWeather
Ok, the problem is that if you are starting from a clean install (including
database) running the simulator after a daylight savings change the
timezone/daylight savings state of your system is irrelevant, all
times/timestamps are drawn from the system clock and if it is not changing
(since
FWIW, this is a recent install (for all the time periods):
cer8000_/home/weewx/weewx-3.8.2/skins/Standard> grep gustdir * | & grep tmpl
index.html.tmpl: $day.wind.max from $day.wind.gustdir at
$day.wind.maxtime
Chris
--
You received this message because you are subscribed to
Ok, let me explain:
1) Remove all packages and files relates to weewx (including all dir and
subdirs on /etc/weewx, /usr/share/weewx, /var/lib/weewx or /usr/lib/weewx,
don't rememebr now). Everything
2) Install from .deb package and accept default settings (name, location,
driver=simulation,
On Tuesday, 6 November 2018 01:57:22 UTC+10, Jonis Maurin Ceará wrote:
>
> Content of /tmp/weather.data:
>
> rainRate=0.0
> windSpeed=10.0466685247
> windGust=16.3395133004
> pressure=28.0709227
> outTemp=84.2
> outHumidity=71.169482
> windDir=0.0
> UV=1.59
> VIS=554
>
OK, so dateTime is not
Content of /tmp/weather.data:
rainRate=0.0
windSpeed=10.0466685247
windGust=16.3395133004
pressure=28.0709227
outTemp=84.2
outHumidity=71.169482
windDir=0.0
UV=1.59
VIS=554
But the problem is that this errors ocours even with simulator on fresh
install
Em seg, 5 de nov de 2018 às
That report indicates there are no future dated records. Just out of interest
what s the content of the file that the fileparse driver is reading,
/var/weather.data, it doesn't have a field named dateTime does it?
Gary
--
You received this message because you are subscribed to the Google
Sure!
Log attached
I tought about thatdaylight saving started yesterday (should be started
a week ago, when problem started, but was delayed one week by our
president).
The only thing that I don't understand is that even with empty database
fresh created by weewx, the problem persist!
In
This is unlikely to be a MySQL or SQLIte error and it definitely is not due to
a missing wind or gustdir field. The original missing wind field error is
possibly because your archive has some future dated records which causes some
of the aggregates to misbehave. To rule this out we need to see
Thomas, I mixed my answers...but is not config mistake. I've made tests
with both drivers, sqlite and MySQL, both has the same problem/error (with
their corresponding errors/drivers).
Em segunda-feira, 5 de novembro de 2018 11:16:39 UTC-2, Thomas Keffer
escreveu:
>
> Hello, Jonis
>
> You say
Hello, Jonis
You say you are using MySQL, but your first error was actually raised by
the sqlite driver. Check weewx.conf and make sure it is using the database
you think it is using.
-tk
On Mon, Nov 5, 2018 at 4:32 AM Jonis Maurin Ceará wrote:
> Hi.
>
> I have weewx 3.8.1 running on my RPi
29 matches
Mail list logo
