Hi Gary. Couldn't add apptime on my main file using 4.0.0b18 several day
errors even after using rebuild daily. As a work round I added appTime
perfectly ok on v3.9.2 waited several cycles without errors then
transferred the sdb file to v4.0.018b and thats been working fine. Phil
On Tue, 7 Apr
Ooops sorry I can see that now Didn't realize that. Thanks Vince
I was trying to upgrade a database that didn't have appTemp in it and that
failed.
Will retry Garys change and see what happens
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
> First of all I
You are using the extended schema for v4, which already has appTemp in it.
https://raw.githubusercontent.com/weewx/weewx/master/bin/schemas/wview_extended.py
Part of the reason for the bigger/extended default schema in v4 is so you
don't have to add frequently added things any more :-)
--
You
Just pause on my last post. Didn't spot you added _extended on line 1
which I missed
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
> First of all I hope everybody is staying safe and well
>
> Before I go into to many details should weewx v4.0.0b18 work
Either way of specifying a schema should work with V4. If it's not, that's
a bug.
On Tue, Apr 7, 2020 at 6:36 AM gjr80 wrote:
> V4 actually uses the wview_extended schema which is specified in a
> slightly different format to that used in V3. Pat's instructions are V3
> specific. Try using the
Sorry Gary it didn't work
schema_extended = {'table': schemas.wview_extended.table + [('appTemp',
'REAL'), ('windrun', 'REAL')], 'day_summaries' :
schemas.wview_extended.day_summaries}
AttributeError: module 'schemas' has no attribute 'wview_extended'
I think its what you had written ??
Phil
V4 actually uses the wview_extended schema which is specified in a slightly
different format to that used in V3. Pat's instructions are V3 specific.
Try using the following as the step 2 code (untested):
import schemas.wview_extended
schema_extended = {'table': schemas.wview_extended.table +
Tom, OK, so sort of the right answer but for the wrong reason!
I don't know why it took so long for me to tweak but I now know why the
following TypeError was occurring:
Apr 5 13:00:19 raspberrypi weewx[604] ERROR weewx.cheetahgenerator:
TypeError: '>' not supported between instances of
Hi Guys
With Garys help with getting a gauge-data.txt file to generate I decided to
try the next step (Logs were all clear) and add 'appTemp' and 'windrun'
using Pat O Brien ADDING A NEW OBSERVATION TYPE TO THE WEEWX DATABASE
I did this on 3.9.2 and it worked fine but on 4.0.0b18 and after using
Gary,
Makes sense.
To gather data for a plot, version 3.9 called Manager.getSqlVectors(),
which hit the database. Only types that appear in the database schema can
be plotted. Because many databases are case-insensitive, rainRate and
rainrate are treated the same, so it works.
By contrast,
For what it’s worth, rainRate has been a problem as I have it fixed in my copy
of gauges. I don’t know when I changed it as it is in my initial check in
(Jan. 6) of my private (and modified) github copy. In particular, I don’t know
if I needed to change it for WeeWX 4.
> On Apr 6, 2020, at
Well looking into the rainrate/rainRate issue has been most interesting.
First up rainrate has been used in skin.conf for the rain rate plot as
follows since the SteelSeries Weather Gauges first directly supported WeeWX:
[[images]]
x_label_format = %H:%M
show_daynight = true
I used steelseries-2.7.4.tar.gz
Phil
On Mon, 6 Apr 2020, 19:46 steeple ian, wrote:
> Phil,
> Could it be that you downloaded your installs from different places? I
> have just worked out that there are two out there.
> Ian
>
> On Mon, Apr 6, 2020 at 4:38 PM Thomas Keffer wrote:
>
>> As far as
Phil,
Could it be that you downloaded your installs from different places? I have
just worked out that there are two out there.
Ian
On Mon, Apr 6, 2020 at 4:38 PM Thomas Keffer wrote:
> As far as weewx is concerned, it's always been rainRate.
>
> I don't know how Steelgauges works, but it's
As far as weewx is concerned, it's always been rainRate.
I don't know how Steelgauges works, but it's possible it's only used in
case-insensitive database queries.
-tk
On Mon, Apr 6, 2020 at 8:12 AM Phil Owers wrote:
> This is interesting
> I have a pi running 3.9.2 (Python2) which runs OK
This is interesting
I have a pi running 3.9.2 (Python2) which runs OK with rainrate
(Steelgauges 2.7.4) ( yes all lower case)
But on a pi running v4.0.0.b18 (Python3) with Steelgauges 2.7.4 rainrate
generates an error in the log which is corrected if its changed to rainRate.
Phil
On
Phil,
Your are correct. In the skin.conf and the .tmpl file it is rainrate not
rainRate.
Ian
On Mon, 6 Apr 2020 at 15:23, Phil Owers wrote:
> Gary
> Couldn't understand where rainrate came from so Just wee_extension --
> install steelseries-2.7.4tar.gz onto a spare pi and rainrate and not
>
Gary
Couldn't understand where rainrate came from so Just wee_extension --
install steelseries-2.7.4tar.gz onto a spare pi and rainrate and not
rainRate is in the ss/skin.conf file.
Any chance somebody else could try just to make sure.
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil
Yep case sure does, log clear. Apologies for that part no idea where that
came from
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
> First of all I hope everybody is staying safe and well
>
> Before I go into to many details should weewx v4.0.0b18 work on
As Gary noted, it's rainRate, not rainrate. Case matters.
-tk
On Mon, Apr 6, 2020 at 6:44 AM Phil Owers wrote:
> Here is the log
>
> Apr 6 14:40:17 raspberrypi weewx[612] ERROR weewx.reportengine: Caught
> unrecoverable exception in generator 'weewx.imagegenerator.ImageGenerator'
> Apr 6
Here is the log
Apr 6 14:40:17 raspberrypi weewx[612] ERROR weewx.reportengine: Caught
unrecoverable exception in generator 'weewx.imagegenerator.ImageGenerator'
Apr 6 14:40:17 raspberrypi weewx[612] ERROR weewx.reportengine:
rainrate
Apr 6 14:40:17 raspberrypi weewx[612] ERROR
Gary
That worked and generated a gauge-data.txt file and it showed 0.2mm of
hourly rain which is correct.
The log still has UnknownType rainrate when it try's to produce images
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
> First of all I hope everybody
It rained this morning and it registered ok on another page
Cant tell about the gauges as while the log reports this error the
gauge-data.txt file does not generate.
Loading your new gauge-data file now
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
>
Hi Phil,
Now I am confused. I can see the mechanism that is causing the failure. The
following code in the template:
#set $hourlyrainTH = 0
#set $ThourlyrainTH = ''
#for $hour in $day.hours
#if $hour.rain.sum.raw > $hourlyrainTH
#set $hourlyrainTH = $hour.rain.sum.raw
#set $ThourlyrainTH =
Hi Gary
Returned gauge template to normal and restored rainrate in ss/skin.conf.
Its still failing at the moment
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil Owers wrote:
>
> Hi Guys
>
> First of all I hope everybody is staying safe and well
>
> Before I go into to many details
Ok, thinking some more the error could also occur if the current day has a
one hour period (from the top of the hour) where there is no rain data (as
distinct from rain data that is zero). The issue is definitely tied to the
current days rain data, that is confirmed by your modifications. Give it
If I take out the rainrate in ss/skin.conf that gets rid of the rainrate
error in the log
If I ## all the lines with rain in them in gauge.date.txt file in SS then
all the other errors in the log then go and the gauge.data.txt is formed
correctly(all be it without the rain info)
Phil
On
Gary
It downloaded all the records from the console which was about 3 weeks
records but the last 24 hrs did have some gaps so I downloaded my full
working copy of weewx.sdb
but im afraid the result was the same with the same errors
Phil
On Saturday, April 4, 2020 at 10:40:41 AM UTC+1, Phil
Phil,
You wouldn’t happen to have less than 24 hours of data in your database would
you? Looking at the gauge-data.txt.tmpl template I suspect the problem is that
the template cannot handle the case where there is less than 24 hours of data
in the database. The template needs to be fixed but I
Thanks Gary
Changed it run automatically from start up and it worked fine overnight
So decided the next step was to load steelguages 2.7.4 via wee_extension.
It loaded ok but the next download I got the following errors
Apr 5 13:00:19 raspberrypi weewx[604] INFO weewx.reportengine: Copied 5
30 matches
Mail list logo
