Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[mwall]

On Tuesday, February 5, 2019 at 8:23:21 PM UTC-5, Thomas Keffer wrote:
>
> So, why did cmon work before? 
>

in my installations i specify paths in weewx.conf.  so i never tested this 
configuration.

here is the fix.  in genplot.py, change this:

@staticmethod

def normalize_path(skin_dir, path):

if os.path.isabs(path):

return path
return os.path.join(skin_dir, path) 

to this:

@staticmethod

def normalize_path(skin_dir, path):

if path is None or os.path.isabs(path):

return path

return os.path.join(skin_dir, path)

m

-- 
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.

Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[Thomas Keffer]

So, why did cmon work before?

On Tue, Feb 5, 2019 at 5:02 PM mwall  wrote:

> tom,
>
> i think we missed this case.  the function
> weeplot.utilities.get_font_handle deals with no font specified, but the
> path normalization in genplot.py does not do the right thing.  it tries to
> normalize even when path is None.
>
> m
>
> --
> 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.
>

-- 
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.

Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[mwall]

tom,

i think we missed this case.  the function 
weeplot.utilities.get_font_handle deals with no font specified, but the 
path normalization in genplot.py does not do the right thing.  it tries to 
normalize even when path is None.

m

-- 
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.

Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[mwall]

this is because the cmon skin.conf does not specify any fonts

the change to defaults.py did not include fonts - only strings

as a workaround, add these to the cmon skin.conf:

[ImageGenerator]

top_label_font_path = 
/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

unit_label_font_path = 
/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

bottom_label_font_path = 
/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

axis_label_font_path = 
/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

rose_label_font_path = 
/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf

...



-- 
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.

Re: [weewx-user] Vantage through serial to Ethernet device and lost connections

[Thomas Keffer]

Not completely following the scenario.

If the vantage driver loses communication with the station, it will try up
to max_retries time, then the program *starts over* from the top. It does
not exit, so it is never in an "exiting state." It should keep trying
forever.

As always, it is helpful to have a log, preferably with debug=1.

-tk

On Tue, Feb 5, 2019 at 2:18 PM chriswilkes33 
wrote:

> Hi,
> I have a Redhat system set up with two different Vantage Pro 2 systems
> going. These are using the Weatherlink Serial devices that I run through
> either a Wiznet SR110 serial to ethernet or a StarTech serial over IP. They
> both work fine, I have no issues running two instances of weewx. My issue
> is that I have these stations set up in a place where network connectivity
> can be troublesome.
>
> When network connections are lost, the Vantage driver seems to try to
> reconnect three (actually 4 but the code doesnt see the counter hits 3
> until it tries the 4th time) times, then wait 60 seconds to try again and
> then fail if no connection is detected. Naturally, the outages we see are
> usually more than the couple minutes that this whole process takes. When
> the weewx service exits, it never fully exits, it seems to remain in active
> (exiting) state. In that state my CM software (puppet) doesnt detect the
> service down and try to restart it.
>
> Im wondering if someone could point me in the code where I can change the
> service to either not die after losing the connection and keep trying
> forever or if there is a way to make the service actually fully exit when
> it decides it wants to? The program I use to fake a tcp port into thinking
> it is a serial port (remserial) cannot handle the service choking very well.
>
> Thanks,
> Chris
>
> --
> 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.
>

-- 
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.

Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[Thomas Keffer]

Hello, Sef

Take a look under [ImageGenerator] in the skin.conf configuration file for
your 'BigReport', and make sure there are entries for

top_label_font_path
bottom_label_font_path
unit_label_font_path
axis_label_font_path
rose_label_font_path


-tk



On Tue, Feb 5, 2019 at 4:04 PM Sef Konings 
wrote:

>
> Hi, weewx users.
>
> I have just upgraded my weewx weatherstation, from weewx 3.8.2 to the
> latest version 3.9.0. I have done this with the apt-get update and upgrade
> tool  The weatherstation starts again in 3.9.0, new graphs are being
> produced, but after a few minutes, I can see this error message when the
> system is producing the html pages:
>
> 2019 Feb  6 00:53:09 localhost reportengine: Caught unrecoverable
> exception in generator 'weewx.imagegenerator.ImageGenerator'
> 2019 Feb  6 00:53:09 localhost   'NoneType' object has no
> attribute 'startswith'
> 2019 Feb  6 00:53:09 localhost   Generator terminated
> Feb  6 00:53:09 localhost weewx[537]: imagegenerator: Generated 19 images
> for BigReport in 5.01 seconds
> Feb  6 00:53:09 localhost weewx[537]: cheetahgenerator: Generated 1 files
> for report lastrain in 0.04 seconds
> Feb  6 00:53:09 localhost weewx[537]: cheetahgenerator: Generated 1 files
> for report cmon in 0.04 seconds
> Feb  6 00:53:09 localhost weewx[537]: reportengine: Caught unrecoverable
> exception in generator 'weewx.imagegenerator.ImageGenerator'
> Feb  6 00:53:09 localhost weewx[537]:   'NoneType' object has
> no attribute 'startswith'
> Feb  6 00:53:09 localhost weewx[537]:   Traceback (most recent
> call last):
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weewx/reportengine.py", line 204, in run
> Feb  6 00:53:09 localhost weewx[537]:   obj.start()
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weewx/reportengine.py", line 300, in start
> Feb  6 00:53:09 localhost weewx[537]:   self.run()
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weewx/imagegenerator.py", line 32, in run
> Feb  6 00:53:09 localhost weewx[537]: 
> self.genImages(self.gen_ts)
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weewx/imagegenerator.py", line 112, in genImages
> Feb  6 00:53:09 localhost weewx[537]:   plot =
> weeplot.genplot.TimePlot(plot_options)
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weeplot/genplot.py", line 122, in __init__
> Feb  6 00:53:09 localhost weewx[537]:   skin_dir,
> self.top_label_font_path)
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/share/weewx/weeplot/genplot.py", line 134, in normalize_path
> Feb  6 00:53:09 localhost weewx[537]:   if
> os.path.isabs(path):
> Feb  6 00:53:09 localhost weewx[537]: File
> "/usr/lib/python2.7/posixpath.py", line 54, in isabs
> Feb  6 00:53:09 localhost weewx[537]:   return
> s.startswith('/')
> Feb  6 00:53:09 localhost weewx[537]:   AttributeError:
> 'NoneType' object has no attribute 'startswith'
> Feb  6 00:53:09 localhost weewx[537]:   Generator terminated
>
> After this, weewx keeps active. I already have been searching in this
> group for other people with the same errormessage, but until now nobody
> seems to have got this problem.
> Can you please give me a clue ?   (You can find my weewx page on :
> https://sekoni.nl/weewx)
>
> Thanks !
> many regards,
>
> Sef
>
>
> --
> 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.
>

-- 
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.

Re: [weewx-user] Re: Is more than one station_type possible in a single instance of WeeWX?

[Robert Anthony Pitera]

Thanks all for the info!  I have a few more things I need to feel more
comfortable with in basic configuration, but I'll look at all of the links
and info provided.  Struggled with getting cmon in my exfoliation skin for
days only to find out that the instructions say to use cmon_binding when it
was actually wx_binding, at least in my case.  So I need to keep working
the learning curve, but the input helps.

Thanks very much!

On Tue, Feb 5, 2019 at 12:30 PM mwall  wrote:

>
>
> On Monday, February 4, 2019 at 12:25:22 PM UTC-5, Robert Anthony Pitera
> wrote:
>>
>> I have WeeWX up and running with my Acurite 5in1 but I also have a
>> Bloomsky Sky1.  I discovered there was a driver for the Bloomsky and was
>> wondering if there was a way to add it into my existing WeeWX instance.  I
>> saw that in 2017 someone asked and it wasn't possible to use two drivers
>> simultaneously but I was wondering if that limitation still existed?  If
>> so, has anyone found a work around for this like running two instances of
>> WeeWX and somehow combing the info in the skins?
>>
>
> it is easy to run multiple instances, but as tom notes, only one driver
> per instance.
>
> using a service to augment data works well in some cases, such as adding
> data from some one-wire sensors to the database that has data from your
> weather station.
>
> but for multiple weather stations, or for power monitoring, tide
> monitoring, water consumption, fuel consumption, air quality, or other
> types of data collection, it is often better to run multiple instances of
> weewx.
>
> https://github.com/weewx/weewx/wiki/weewx-multi
>
> you can always combine data into a single report with a separate,
> dedicated skin and wee_reports.  or you can aggregate by feeding into
> influx or emoncms or something that feeds off of mqtt.
>
> this is how i typically configure a system that will have multiple
> instances of weewx on it:
>
> /opt/weewx-x.y.z   - weewx is installed here
> /opt/weewx-skins   - skins go here
> /etc/weewx/- configurations go here, one per instance
> /var/lib/weewx/- database files go here, one per instance
> /etc/init.d/weewx-multi  - script that starts/stops them
> /etc/default/weewx-multi - list of which instances should run
>
> that way i can test new releases of weewx without disturbing what is
> already running.  i can test/update one instance without disturbing the
> others.  i can update/test skins without disturbing whatever is already
> running.  i can update skins independently of weewx itself.
>
> on most systems i run only two or three weewx instances, but i have a
> couple of systems with 6 or 8 instances.
>
> m
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/BbOOM3sAtK0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

Re: [weewx-user] Re: Beta testers for v3.9.0 needed

[Sef Konings]

Hi, weewx users.

I have just upgraded my weewx weatherstation, from weewx 3.8.2 to the 
latest version 3.9.0. I have done this with the apt-get update and upgrade 
tool  The weatherstation starts again in 3.9.0, new graphs are being 
produced, but after a few minutes, I can see this error message when the 
system is producing the html pages:

2019 Feb  6 00:53:09 localhost reportengine: Caught unrecoverable exception 
in generator 'weewx.imagegenerator.ImageGenerator'
2019 Feb  6 00:53:09 localhost   'NoneType' object has no 
attribute 'startswith'
2019 Feb  6 00:53:09 localhost   Generator terminated
Feb  6 00:53:09 localhost weewx[537]: imagegenerator: Generated 19 images 
for BigReport in 5.01 seconds
Feb  6 00:53:09 localhost weewx[537]: cheetahgenerator: Generated 1 files 
for report lastrain in 0.04 seconds
Feb  6 00:53:09 localhost weewx[537]: cheetahgenerator: Generated 1 files 
for report cmon in 0.04 seconds
Feb  6 00:53:09 localhost weewx[537]: reportengine: Caught unrecoverable 
exception in generator 'weewx.imagegenerator.ImageGenerator'
Feb  6 00:53:09 localhost weewx[537]:   'NoneType' object has 
no attribute 'startswith'
Feb  6 00:53:09 localhost weewx[537]:   Traceback (most recent 
call last):
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weewx/reportengine.py", line 204, in run
Feb  6 00:53:09 localhost weewx[537]:   obj.start()
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weewx/reportengine.py", line 300, in start
Feb  6 00:53:09 localhost weewx[537]:   self.run()
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weewx/imagegenerator.py", line 32, in run
Feb  6 00:53:09 localhost weewx[537]:   
self.genImages(self.gen_ts)
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weewx/imagegenerator.py", line 112, in genImages
Feb  6 00:53:09 localhost weewx[537]:   plot = 
weeplot.genplot.TimePlot(plot_options)
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weeplot/genplot.py", line 122, in __init__
Feb  6 00:53:09 localhost weewx[537]:   skin_dir, 
self.top_label_font_path)
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/share/weewx/weeplot/genplot.py", line 134, in normalize_path
Feb  6 00:53:09 localhost weewx[537]:   if 
os.path.isabs(path):
Feb  6 00:53:09 localhost weewx[537]: File 
"/usr/lib/python2.7/posixpath.py", line 54, in isabs
Feb  6 00:53:09 localhost weewx[537]:   return 
s.startswith('/')
Feb  6 00:53:09 localhost weewx[537]:   AttributeError: 
'NoneType' object has no attribute 'startswith'
Feb  6 00:53:09 localhost weewx[537]:   Generator terminated

After this, weewx keeps active. I already have been searching in this group 
for other people with the same errormessage, but until now nobody seems to 
have got this problem.
Can you please give me a clue ?   (You can find my weewx page on : 
https://sekoni.nl/weewx)

Thanks !
many regards, 

Sef


-- 
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.

Re: [weewx-user] Re: At last! Version 3.9.0 released

[gjr80]

This post is for users of the WeeWX-WD extension who upgrade to WeeWX 
v3.9.0 or later.

The introduction of the new [StdReport]/[[Defaults]] stanza 
 and the flow on effect 
to overrides may cause problems for some users of WeeWX-WD. The issue is to 
do with WeeWX-WD defaulting to Metric units for some report generated files 
but the 3.9.0 upgrade may install a US customary [StdReport]/[[Defaults]] 
stanza in weewx.conf. The effect of this is that the default units set in 
some WeeWX-WD skins are overridden by the [[Defaults]] stanza. The affected 
(generated) files appear to be limited to testtags.php, weewx_pws.xml and 
any image files created by the StackedWindRose generators (eg 
daywindrose.png)

It is likely that this issue will only affect those users who use Metric 
units in any of the affected files. WeeWX-WD users who use US customary 
units in the affected files should not need to make any changes.

The fix is simply to place appropriate overrides under each WeeWX-WD report 
stanza under [StdReport] in weewx.conf. To place these overrides:

1. edit weewx.conf and locate the [StdReport] stanza
2. add the following under [[wdTesttags]] choosing appropriate settings 
from the available options:

[[wdTesttags]]
...
[[[Units]]]
TimeFormats
date_time_f = %d/%m/%Y %H:%M# options are %d/%m/%Y 
%H:%M or %m/%d/%Y %H:%M
date_f = %m/%d/%Y   # options are %d/%m/%Y or 
%m/%d/%Y
Groups
group_altitude = meter  # options are 'meter' or 
'foot'
group_speed2 = km_per_hour2 # options are 
'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
group_pressure = hPa# options are 'inHg', 
'mbar', or 'hPa'
group_rain = mm # options are 'mm' or 'inch'
group_rainrate = mm_per_hour# options are 'mm_per_hour' 
or 'inch_per_hour'
group_temperature = degree_C# options are 'degree_C' or 
'degree_F' 
group_degree_day = degree_C_day # options are 
'degree_C_day' or 'degree_F_day'
group_speed = km_per_hour   # options are 
'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'
group_distance = km # options are 'km' or 'mile'

3. add the following under [[wdPWS]] choosing appropriate settings from the 
available options:

[[wdPWS]]
...
[[[Units]]]
Groups
group_speed2 = km_per_hour2 # options are 
'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
group_temperature = degree_C# options are 'degree_C' or 
'degree_F' 
group_pressure = hPa# options are 'inHg', 
'mmHg', 'mbar', or 'hPa'
group_rain = mm # options are 'mm' or 'inch'
group_rainrate = mm_per_hour# options are 'mm_per_hour' 
or 'inch_per_hour'
group_speed = km_per_hour   # options are 
'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'

4. add the following under [[wdStackedWindRose]] choosing appropriate 
settings from the available options:

[[wdStackedWindRose]]
...
[[[Units]]]
TimeFormats
date_time_f = %d/%m/%Y %H:%M# may be any format 
supported by python strftime
date_f = %d/%m/%Y   # may be any format 
supported by python strftime
Groups
group_speed2 = km_per_hour2 # options are 
'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2'
group_speed = km_per_hour   # options are 
'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second'

5. save weewx.conf and do a WeeWX config reload or restart WeeWX
6. monitor the WeeWX log for errors and confirm that any pages/apps using 
the WeeWX-WD generated files still display the correct units and date and 
time formats.

If any issues are noted please raise a separate thread.

The next WeeWX-WD release will address these issues.

Gary

-- 
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.

[weewx-user] Vantage through serial to Ethernet device and lost connections

[chriswilkes33]

Hi,
I have a Redhat system set up with two different Vantage Pro 2 systems 
going. These are using the Weatherlink Serial devices that I run through 
either a Wiznet SR110 serial to ethernet or a StarTech serial over IP. They 
both work fine, I have no issues running two instances of weewx. My issue 
is that I have these stations set up in a place where network connectivity 
can be troublesome.

When network connections are lost, the Vantage driver seems to try to 
reconnect three (actually 4 but the code doesnt see the counter hits 3 
until it tries the 4th time) times, then wait 60 seconds to try again and 
then fail if no connection is detected. Naturally, the outages we see are 
usually more than the couple minutes that this whole process takes. When 
the weewx service exits, it never fully exits, it seems to remain in active 
(exiting) state. In that state my CM software (puppet) doesnt detect the 
service down and try to restart it.

Im wondering if someone could point me in the code where I can change the 
service to either not die after losing the connection and keep trying 
forever or if there is a way to make the service actually fully exit when 
it decides it wants to? The program I use to fake a tcp port into thinking 
it is a serial port (remserial) cannot handle the service choking very well.

Thanks,
Chris

-- 
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.

Re: [weewx-user] Re: Second crash after 11 days

[Steve2Q]

Tom: Here is the screenshot of Top showing both instances running. 
Obviously, the simulator is using far less memory. I will check tomorrow AM 
and send an updated screen capture.


-- 
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.

Re: [weewx-user] Re: Second crash after 11 days

[Steve2Q]

On Tuesday, February 5, 2019 at 10:38:36 AM UTC-5, Thomas Keffer wrote:
>
> I really only need the 'top' results for the instance running the 
> simulator: is it growing in its memory use?
>
> On Tue, Feb 5, 2019 at 7:11 AM Steve2Q > 
> wrote:
>
>> Tom: After I run my system for a few more days, let me know which file(s) 
>> you would like to see. 
>>
>> -- 
>> 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+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.

Re: [weewx-user] Re: NOAA reports not available

[Glenn McKechnie]

Indeed! That looks better, the menu is now populated and working.
It appears that removing the "search_list_extensions =
user.forecast.ForecastVariables"  entry has made all the difference.

That line is still in the copy I have here but I don't have the
forecast extension installed so it had nothing to call. Maybe I should
install it here and see if it breaks it here to. Maybe, I'll hold fire
unless it helps further. chores are calling.
(You're using forecast v3.2.4  by the looks of it)

Looking at the wiki page for forecasting, it mentions adding it to
that location.
https://github.com/weewx/weewx/wiki/forecasting

With hindsight in full, a search on weewx-user returns  a couple of
hits, 2 of interest are...
https://groups.google.com/d/topic/weewx-user/k3yy2IK__Ow/discussion
https://groups.google.com/d/topic/weewx-user/p1AYCf0KkxI/discussion

It appears that it's cropped up before and Mathew may still want to
know about this?
The wiki page for forecast shows there is a version 3.3.0 available.
It may pay to install that version and see if the issue is still
present.

For the record. The [[SummaryByMonth]] and [[SummaryByYear]] do come
before the [[ToDate]] section in Bobs skin.conf.

Great that it's working now.
A side affect is I have a better understanding of the mechanics of the
NOAA templates !  ;-)

I'm with you regarding the plane trip, you'd only work up more of a
thirst too, although the 40 deg C days appear to be behind us for a
while, back to the 20's for a while.  (Good!)

On 06/02/2019, bgrat...@umw.edu  wrote:
> Glenn,
>
> *I've got it!!!* I checked the original skin.conf under 3.8.2 and noticed
> that "search_list_extensions = user.forecast.ForecastVariables" didn't
> exist under [CheetahGenerator]. I commented it out in mine and the
> summaries worked from drop down lists.
> I'll have to go back and figure out what that was doing but, anyway, the
> problem seems to be solved for now.
> Thank you again for the much appreciated help! I'm sorry for all the
> complications! I would like to treat you to a pint but don't think I could
> stand the plane ride...
> Cheers,
> Bob
>
> On Monday, February 4, 2019 at 9:56:28 PM UTC-5, Glenn McKechnie wrote:
>


-- 


Cheers
 Glenn

rorpi - read only raspberry pi & various weewx addons
https://github.com/glennmckechnie

-- 
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.

Re: [weewx-user] Re: At last! Version 3.9.0 released

[Thomas Keffer]

On Tue, Feb 5, 2019 at 12:08 PM Ruben Navarro Huedo 
wrote:

> Updated here.
> Not using Standard Skin.
>
> All fine except: It is not using correctly time format.
> %H:%M is what i want to use and it is creating %H:%M:%S
>
>
Were you able to fix this? This was probably changed because of the change
in override hierarchy. You may have to directly edit in skin.conf.

-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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: At last! Version 3.9.0 released

[Scott Grayban]

Thanks !!

On Tuesday, February 5, 2019 at 12:52:18 PM UTC-8, Thomas Keffer wrote:
>
> On Tue, Feb 5, 2019 at 12:47 PM Scott Grayban  > wrote:
>
>> Are there any changes to the conf from the beta ?
>>
>
> No, there shouldn't be.
>

-- 
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.

Re: [weewx-user] Re: At last! Version 3.9.0 released

[Thomas Keffer]

On Tue, Feb 5, 2019 at 12:47 PM Scott Grayban  wrote:

> Are there any changes to the conf from the beta ?
>

No, there shouldn't be.

-- 
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.

[weewx-user] Re: At last! Version 3.9.0 released

[Scott Grayban]

Are there any changes to the conf from the beta ?

On Tuesday, February 5, 2019 at 11:22:13 AM UTC-8, Thomas Keffer wrote:
>
> Find it in the usual place . 
>
> Be sure to read the Upgrading Guide .  
> If you chose the unit system your reports will be in by selecting US or 
> METRIC during installation of your old skin, you will have no problems. 
> This includes most users. OTOH, if you directly modified skin.conf, 
> specifying metric units, you may find that your report suddenly comes out 
> in US. The fix is easy and covered in the Upgrading Guide.
>
> Changes:
>
> 3.9.0 02/05/2019
>
>
> New skin called Seasons. For new users, it will be installed and enabled.
> For old users, it will be installed, but not enabled. Fixes issue #75.
>
> There are also two new skins for mobile phones: Mobile and Smartphone.
> These are installed, but not enabled, for all users.
>
> Reworked how options get applied for reports. Backstop default values
> are supplied by a new file weewx/defaults.py. These can get overridden
> by skin.conf, or in a new section [StdReports] / [[Defaults]] in weewx.conf.
> See the Customizing Guide, section "How options work", for details.
> Fixes issue #248.
>
> The skin.conf is optional.  It is possible to specify the entire skin
> configuration in the configuration file weewx.conf.
>
> Dropped support of Python 2.5. You must now use either Python 2.6 or 2.7. This
> is in anticipation of porting to Python 3.
>
> The image generator now supports the use of a 'stale_age' option. Thanks to
> user John Smith. Fixes issue #290.
>
> Rose line width can now be specified with option rose_line_width.
>
> The Felsius unit of temperature (see https://xkcd.com/1923/) is now supported.
>
> New tag $almanac.sidereal_time for calculating current sidereal time
>
> New tag $almanac.separation() for calculating planet separations.
>
> Can now use ephem.readdb() to load arbitrary bodies into the almanac.
>
> StdQC now includes an entry for rain again (inexplicably removed in v3.1.0).
>
> If software record generation is used, the archive interval is now what is
> specified in weewx.conf, even if the station supports hardware generation.
>
> Fixed problem where records were downloaded on startup, even if software
> record generation was specified.
>
> The tag formatting taxonomy has been simplified. Just use suffix ".format()"
> now. Documentation updated to reflect changes. Backwards compatibility with 
> old
> suffixes is supported. Fixes issue #328.
>
> Can now set Rapidfire parameter rtfreq. Thanks to user 'whorfin'. PR #304.
>
> Template names can now include the week number. Thanks to user 'stimpy23'.
> PR #319.
>
> New aggregation type for plots: 'cumulative'. Thanks to user 'henrikost'.
> PR #302.
>
> Fixed problem where MySQL error 2013 could crash WeeWX. Fixes issue #327.
>
> Posts to the Weather Underground will be skipped if an observation type that
> is listed in the [[[Essentials]]] subsection is missing. Fixes issue #329.
>
> Upgrade process now explicity upgrades version-to-version, instead of
> doing a merge to the new config file. Fixes issue #217.
>
> Example xstats now includes tags for last_year and last_year_todate.
> Thanks to user evilbunny2008. PR #325.
>
> Guard against a negative value for 'interval' in WMR200 stations.
>
> Check for missing or negative values for the record field 'interval'.
>
> Changed the formula used to calculate percentage illumination of the moon to
> something more accurate around 2018. This formula is only used if pyephem is
> not installed. Fixes issue #342.
>
> Fixed bug that caused older, "type A" Vantage Pro2, to crash. Fixes issue 
> #343.
>
> Fixed a bug that caused a divide-by-zero error if a plot range was the same as
> a specified min or max scale. Fixes issue #344.
>
> Fixed bug that prevented an optional data_binding from being used in tags
> when iterating over records. Fixes issue #345.
>
> Examples lowBattery and alarm now try SMTP_SSL connections, then degrade if
> that's not available. Fixes issue #351.
>
> Fixed problem with Brazilian locations at the start of DST. It manifested
> itself with the error "NoColumnError: no such column: wind". Fixes issue #356.
>
> Fixed problem that caused sunrise/sunset to be calculated improperly in 
> Sun.py.
>
> Improved coverage of test suites. Fixes issue #337.
>
> wee_device, when used with the Vantage series, now honors the "no prompt" (-y)
> option. Fixes issue #361.
>
> Log watch now correctly logs garbage collection events. Thanks to user 
> buster-one. PR #340.
>
>
>

-- 
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.

[weewx-user] Re: At last! Version 3.9.0 released

[Ruben Navarro Huedo]

Updated here. 
Not using Standard Skin.

All fine except: It is not using correctly time format.
%H:%M is what i want to use and it is creating %H:%M:%S

It is all OK on skin.conf and weewx.conf

http://meteoelche.es

El martes, 5 de febrero de 2019, 20:22:13 (UTC+1), Thomas Keffer escribió:
>
> Find it in the usual place . 
>
> Be sure to read the Upgrading Guide .  
> If you chose the unit system your reports will be in by selecting US or 
> METRIC during installation of your old skin, you will have no problems. 
> This includes most users. OTOH, if you directly modified skin.conf, 
> specifying metric units, you may find that your report suddenly comes out 
> in US. The fix is easy and covered in the Upgrading Guide.
>
> Changes:
>
> 3.9.0 02/05/2019
>
>
> New skin called Seasons. For new users, it will be installed and enabled.
> For old users, it will be installed, but not enabled. Fixes issue #75.
>
> There are also two new skins for mobile phones: Mobile and Smartphone.
> These are installed, but not enabled, for all users.
>
> Reworked how options get applied for reports. Backstop default values
> are supplied by a new file weewx/defaults.py. These can get overridden
> by skin.conf, or in a new section [StdReports] / [[Defaults]] in weewx.conf.
> See the Customizing Guide, section "How options work", for details.
> Fixes issue #248.
>
> The skin.conf is optional.  It is possible to specify the entire skin
> configuration in the configuration file weewx.conf.
>
> Dropped support of Python 2.5. You must now use either Python 2.6 or 2.7. This
> is in anticipation of porting to Python 3.
>
> The image generator now supports the use of a 'stale_age' option. Thanks to
> user John Smith. Fixes issue #290.
>
> Rose line width can now be specified with option rose_line_width.
>
> The Felsius unit of temperature (see https://xkcd.com/1923/) is now supported.
>
> New tag $almanac.sidereal_time for calculating current sidereal time
>
> New tag $almanac.separation() for calculating planet separations.
>
> Can now use ephem.readdb() to load arbitrary bodies into the almanac.
>
> StdQC now includes an entry for rain again (inexplicably removed in v3.1.0).
>
> If software record generation is used, the archive interval is now what is
> specified in weewx.conf, even if the station supports hardware generation.
>
> Fixed problem where records were downloaded on startup, even if software
> record generation was specified.
>
> The tag formatting taxonomy has been simplified. Just use suffix ".format()"
> now. Documentation updated to reflect changes. Backwards compatibility with 
> old
> suffixes is supported. Fixes issue #328.
>
> Can now set Rapidfire parameter rtfreq. Thanks to user 'whorfin'. PR #304.
>
> Template names can now include the week number. Thanks to user 'stimpy23'.
> PR #319.
>
> New aggregation type for plots: 'cumulative'. Thanks to user 'henrikost'.
> PR #302.
>
> Fixed problem where MySQL error 2013 could crash WeeWX. Fixes issue #327.
>
> Posts to the Weather Underground will be skipped if an observation type that
> is listed in the [[[Essentials]]] subsection is missing. Fixes issue #329.
>
> Upgrade process now explicity upgrades version-to-version, instead of
> doing a merge to the new config file. Fixes issue #217.
>
> Example xstats now includes tags for last_year and last_year_todate.
> Thanks to user evilbunny2008. PR #325.
>
> Guard against a negative value for 'interval' in WMR200 stations.
>
> Check for missing or negative values for the record field 'interval'.
>
> Changed the formula used to calculate percentage illumination of the moon to
> something more accurate around 2018. This formula is only used if pyephem is
> not installed. Fixes issue #342.
>
> Fixed bug that caused older, "type A" Vantage Pro2, to crash. Fixes issue 
> #343.
>
> Fixed a bug that caused a divide-by-zero error if a plot range was the same as
> a specified min or max scale. Fixes issue #344.
>
> Fixed bug that prevented an optional data_binding from being used in tags
> when iterating over records. Fixes issue #345.
>
> Examples lowBattery and alarm now try SMTP_SSL connections, then degrade if
> that's not available. Fixes issue #351.
>
> Fixed problem with Brazilian locations at the start of DST. It manifested
> itself with the error "NoColumnError: no such column: wind". Fixes issue #356.
>
> Fixed problem that caused sunrise/sunset to be calculated improperly in 
> Sun.py.
>
> Improved coverage of test suites. Fixes issue #337.
>
> wee_device, when used with the Vantage series, now honors the "no prompt" (-y)
> option. Fixes issue #361.
>
> Log watch now correctly logs garbage collection events. Thanks to user 
> buster-one. PR #340.
>
>
>

-- 
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] At last! Version 3.9.0 released

[Thomas Keffer]

Find it in the usual place .

Be sure to read the Upgrading Guide .
If you chose the unit system your reports will be in by selecting US or
METRIC during installation of your old skin, you will have no problems.
This includes most users. OTOH, if you directly modified skin.conf,
specifying metric units, you may find that your report suddenly comes out
in US. The fix is easy and covered in the Upgrading Guide.

Changes:

3.9.0 02/05/2019


New skin called Seasons. For new users, it will be installed and enabled.
For old users, it will be installed, but not enabled. Fixes issue #75.

There are also two new skins for mobile phones: Mobile and Smartphone.
These are installed, but not enabled, for all users.

Reworked how options get applied for reports. Backstop default values
are supplied by a new file weewx/defaults.py. These can get overridden
by skin.conf, or in a new section [StdReports] / [[Defaults]] in weewx.conf.
See the Customizing Guide, section "How options work", for details.
Fixes issue #248.

The skin.conf is optional.  It is possible to specify the entire skin
configuration in the configuration file weewx.conf.

Dropped support of Python 2.5. You must now use either Python 2.6 or 2.7. This
is in anticipation of porting to Python 3.

The image generator now supports the use of a 'stale_age' option. Thanks to
user John Smith. Fixes issue #290.

Rose line width can now be specified with option rose_line_width.

The Felsius unit of temperature (see https://xkcd.com/1923/) is now supported.

New tag $almanac.sidereal_time for calculating current sidereal time

New tag $almanac.separation() for calculating planet separations.

Can now use ephem.readdb() to load arbitrary bodies into the almanac.

StdQC now includes an entry for rain again (inexplicably removed in v3.1.0).

If software record generation is used, the archive interval is now what is
specified in weewx.conf, even if the station supports hardware generation.

Fixed problem where records were downloaded on startup, even if software
record generation was specified.

The tag formatting taxonomy has been simplified. Just use suffix ".format()"
now. Documentation updated to reflect changes. Backwards compatibility with old
suffixes is supported. Fixes issue #328.

Can now set Rapidfire parameter rtfreq. Thanks to user 'whorfin'. PR #304.

Template names can now include the week number. Thanks to user 'stimpy23'.
PR #319.

New aggregation type for plots: 'cumulative'. Thanks to user 'henrikost'.
PR #302.

Fixed problem where MySQL error 2013 could crash WeeWX. Fixes issue #327.

Posts to the Weather Underground will be skipped if an observation type that
is listed in the [[[Essentials]]] subsection is missing. Fixes issue #329.

Upgrade process now explicity upgrades version-to-version, instead of
doing a merge to the new config file. Fixes issue #217.

Example xstats now includes tags for last_year and last_year_todate.
Thanks to user evilbunny2008. PR #325.

Guard against a negative value for 'interval' in WMR200 stations.

Check for missing or negative values for the record field 'interval'.

Changed the formula used to calculate percentage illumination of the moon to
something more accurate around 2018. This formula is only used if pyephem is
not installed. Fixes issue #342.

Fixed bug that caused older, "type A" Vantage Pro2, to crash. Fixes issue #343.

Fixed a bug that caused a divide-by-zero error if a plot range was the same as
a specified min or max scale. Fixes issue #344.

Fixed bug that prevented an optional data_binding from being used in tags
when iterating over records. Fixes issue #345.

Examples lowBattery and alarm now try SMTP_SSL connections, then degrade if
that's not available. Fixes issue #351.

Fixed problem with Brazilian locations at the start of DST. It manifested
itself with the error "NoColumnError: no such column: wind". Fixes issue #356.

Fixed problem that caused sunrise/sunset to be calculated improperly in Sun.py.

Improved coverage of test suites. Fixes issue #337.

wee_device, when used with the Vantage series, now honors the "no prompt" (-y)
option. Fixes issue #361.

Log watch now correctly logs garbage collection events. Thanks to user
buster-one. PR #340.

-- 
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.

[weewx-user] Re: Is more than one station_type possible in a single instance of WeeWX?

[mwall]

On Monday, February 4, 2019 at 12:25:22 PM UTC-5, Robert Anthony Pitera 
wrote:
>
> I have WeeWX up and running with my Acurite 5in1 but I also have a 
> Bloomsky Sky1.  I discovered there was a driver for the Bloomsky and was 
> wondering if there was a way to add it into my existing WeeWX instance.  I 
> saw that in 2017 someone asked and it wasn't possible to use two drivers 
> simultaneously but I was wondering if that limitation still existed?  If 
> so, has anyone found a work around for this like running two instances of 
> WeeWX and somehow combing the info in the skins?
>

it is easy to run multiple instances, but as tom notes, only one driver per 
instance.

using a service to augment data works well in some cases, such as adding 
data from some one-wire sensors to the database that has data from your 
weather station.

but for multiple weather stations, or for power monitoring, tide 
monitoring, water consumption, fuel consumption, air quality, or other 
types of data collection, it is often better to run multiple instances of 
weewx.

https://github.com/weewx/weewx/wiki/weewx-multi

you can always combine data into a single report with a separate, dedicated 
skin and wee_reports.  or you can aggregate by feeding into influx or 
emoncms or something that feeds off of mqtt.

this is how i typically configure a system that will have multiple 
instances of weewx on it:

/opt/weewx-x.y.z   - weewx is installed here
/opt/weewx-skins   - skins go here
/etc/weewx/- configurations go here, one per instance
/var/lib/weewx/- database files go here, one per instance
/etc/init.d/weewx-multi  - script that starts/stops them
/etc/default/weewx-multi - list of which instances should run

that way i can test new releases of weewx without disturbing what is 
already running.  i can test/update one instance without disturbing the 
others.  i can update/test skins without disturbing whatever is already 
running.  i can update skins independently of weewx itself.

on most systems i run only two or three weewx instances, but i have a 
couple of systems with 6 or 8 instances.

m

-- 
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.

Re: [weewx-user] Is more than one station_type possible in a single instance of WeeWX?

[tomnykds]

For a while, I was running two instances of weewx on a machine with the 
same installation, but
separate trees for the db_archive, output web files, skins, and separate 
config files.  I didn't have any
problem with it, just changed hardware and needed to move the one close to 
the console (VP2 in the kitchen),
which is now on an RPi model B+.  Actually, I might have had all 3 
instances in that one install.

Chris

-- 
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.

Re: [weewx-user] Re: NOAA reports not available

[bgrattan]

Glenn,

*I've got it!!!* I checked the original skin.conf under 3.8.2 and noticed 
that "search_list_extensions = user.forecast.ForecastVariables" didn't 
exist under [CheetahGenerator]. I commented it out in mine and the 
summaries worked from drop down lists.
I'll have to go back and figure out what that was doing but, anyway, the 
problem seems to be solved for now.
Thank you again for the much appreciated help! I'm sorry for all the 
complications! I would like to treat you to a pint but don't think I could 
stand the plane ride...
Cheers,
Bob

On Monday, February 4, 2019 at 9:56:28 PM UTC-5, Glenn McKechnie wrote:
>
> No insights (to me ) from the files you provided. 
>
> What's in no.htaccess? I wouldn't have thought there could be anything 
> in there that would prevent weewx from using the contents of NOAA. 
> It's more a webserver control point  - but then...? 
>
> Ownership and permissions seem okay. root.www-data is typical for a 
> debian install, 775 is liberal. 
>
> It's nice to see someone else that uses 'tree' It's a great little 
> program  and perfect for this case! 
> it shows the files where they should be. 
>
> I guess you could move them (the ones in public_html/NOAA ) aside, 
> then restart weewx to allow weewx to regenerate them. Then see if 
> excitement or disappointment wins that coin toss. 
>
>
> If it wasn't for the fact that your tmpl and skin.conf works here... 
> flawlessly even... Phttt. 
>
>
>
>
>
> On 05/02/2019, bgra...@umw.edu   > wrote: 
> > Hi Glenn, 
> > 
> > Sorry to put you through all of this. I have attached two files. One 
> from 
> > wee_debug and one of a "tree" from /home/weewx (a bit long but may have 
> a 
> > clue). I have a symlink in /var/www/html to /home/weewx/public_html 
> which 
> > has been working ok with apache2. A "diff" on cheetahgenerator.py and 
> 382 
> > source came out equal. The same thing on 370 showed a small difference 
> so I 
> > 
> > used that file but nothing changed so I put the original back. I'll work 
> on 
> > 
> > blocking the WX-HWS code I added to see if that changes anything.  In 
> > trying to get things going earlier, I changed some ownership to 
> > root:www-data and permissions to 775. I wouldn't think this would matter 
> > with this problem (?). 
> > Thanks again. 
> > Bob 
> > 
> > On Monday, February 4, 2019 at 5:01:17 PM UTC-5, Glenn McKechnie wrote: 
> >> 
> >> Hey Bob, 
> >> 
> >> There is no change, but it confirms that 
> >> 1.) we are working on the same page (the change has propagated to 
> godaddy) 
> >> 
> >> 2.) The [[SummaryByMonth]] and [[SummaryByYear]] sections aren't being 
> >> picked up and filled. If weewx couldn't find them, it would complain 
> >> with an error - at least it does here. It's odd that they aren't being 
> >> substituted as I believe your locations are correct - see below. 
> >> 
> >> I assume you are running as root, in which case it doesn't matter what 
> >> the permissions on the NOAA directories are. FWIW The Directory is 
> >> 0744, the files are 0644 
> >> 
> >> Regarding your syslog output. I'm not familiar with public_html as the 
> >> web directory. I assume it gets remapped by apache2(?) and that's when 
> >> it becomes /weewx/ as ftpuploads refers to it. 
> >> eg:- ftpupload: Uploaded file /weewx/NOAA/NOAA-2019-02.txt 
> >> Are you using apache? Are you rewriting the Directory? 
> >> 
> >> It might pay to use wee_debug to sanitise your weewx.conf file. Double 
> >> check the output is cleaned of anything private, then post the 
> >> contents here. 
> >> http://weewx.com/docs/utilities.htm#wee_debug_utility 
> >> 
> >> Regarding weewx.conf values... 
> >> 
> >> Mine runs with 
> >> WEEWX_ROOT = / 
> >> SKIN_ROOT = /home/weewx/skins 
> >> HTML_ROOT = /var/www/html/weewx 
> >> 
> >> Yours is 
> >> WEEWX_ROOT = /home/weewx  (I assume this otherwise the following 
> >> values won't expand out) 
> >> and you supplied these previously 
> >> SKIN_ROOT = skins 
> >> HTML_ROOT = public_html 
> >> and that's pretty much a setup.py install 
> >> 
> >> Which means that your NOAA files should reside in 
> >> /home/weewx/public_html/NOAA 
> >> eg:- /home/weewx/public_html/NOAA/NOAA-2019-02.txt 
> >> 
> >> From there CheetahGenerator should be able to find them and use them 
> >> in the index template. 
> >> 
> >> Nope, I'm out of ideas. 
> >> 
> >> Regarding WX-HWS. I'm running your template with that section 
> >> basically commented out (sort of, I have stubs in place) 
> >> You could try commenting out that whole section, or at least the 
> >> HTML_ROOT = /home/weewx/public_html/hws entries for a couple of runs. 
> >> Not sure if it will make any difference but we're at that stage. 
> >> 
> >> 
> >> Replace cheetah the application or weewx/cheetahgenerator.py ? 
> >> You could try reinstalling cheetah, It shouldn't mess with anything. 
> >> You could replace the  weewx/cheetahgenerator.py file with a fresh 
> >> copy from the source package without any issue.  As an aside, I'm 
> 

Re: [weewx-user] Re: NOAA reports not available

[Thomas Keffer]

To get the entries for the dropdown list, the report generator does not
scan the NOAA subdirectory. Instead, it watches what goes by in the
[[SummaryByMonth]] and [[SummaryByYear]] sections, then saves that result.

So, for the dropdown list to populate properly, the [[SummaryByMonth]] and
[[SummaryByYear]] sections must come *before* the [[ToDate]] section in
your skin configuration file skin.conf.

Double check that this is the case.



On Tue, Feb 5, 2019 at 6:52 AM  wrote:

> Glenn,
>
> Had a thought that might not mean anything but here it goes. The page is
> not finding the summaries in /NOAA because I am unable to select a month or
> year. The box fails to display a drop down list of months or years from
> which I would select. It seems that it's the actual drop down list that is
> missing here because, until I select a year/month, the software has no need
> to go to /NOAA to display a date.txt file. Maybe it's the code/mechanism
> that creates the drop down list is missing (?) or not functioning (?) The
> list of months/years is not in /NOAA so maybe there is some script that
> produces it and creates links to /NOAA...  I really don't know how these
> drop down lists function so I'm out of my element at this point.  Any
> thoughts on this idea?  Thanks.
> Bob
>
>
> On Monday, February 4, 2019 at 9:56:28 PM UTC-5, Glenn McKechnie wrote:
>>
>> No insights (to me ) from the files you provided.
>>
>> What's in no.htaccess? I wouldn't have thought there could be anything
>> in there that would prevent weewx from using the contents of NOAA.
>> It's more a webserver control point  - but then...?
>>
>> Ownership and permissions seem okay. root.www-data is typical for a
>> debian install, 775 is liberal.
>>
>> It's nice to see someone else that uses 'tree' It's a great little
>> program  and perfect for this case!
>> it shows the files where they should be.
>>
>> I guess you could move them (the ones in public_html/NOAA ) aside,
>> then restart weewx to allow weewx to regenerate them. Then see if
>> excitement or disappointment wins that coin toss.
>>
>>
>> If it wasn't for the fact that your tmpl and skin.conf works here...
>> flawlessly even... Phttt.
>>
>>
>>
>>
>>
>> On 05/02/2019, bgra...@umw.edu  wrote:
>> > Hi Glenn,
>> >
>> > Sorry to put you through all of this. I have attached two files. One
>> from
>> > wee_debug and one of a "tree" from /home/weewx (a bit long but may have
>> a
>> > clue). I have a symlink in /var/www/html to /home/weewx/public_html
>> which
>> > has been working ok with apache2. A "diff" on cheetahgenerator.py and
>> 382
>> > source came out equal. The same thing on 370 showed a small difference
>> so I
>> >
>> > used that file but nothing changed so I put the original back. I'll
>> work on
>> >
>> > blocking the WX-HWS code I added to see if that changes anything.  In
>> > trying to get things going earlier, I changed some ownership to
>> > root:www-data and permissions to 775. I wouldn't think this would
>> matter
>> > with this problem (?).
>> > Thanks again.
>> > Bob
>> >
>> > On Monday, February 4, 2019 at 5:01:17 PM UTC-5, Glenn McKechnie wrote:
>> >>
>> >> Hey Bob,
>> >>
>> >> There is no change, but it confirms that
>> >> 1.) we are working on the same page (the change has propagated to
>> godaddy)
>> >>
>> >> 2.) The [[SummaryByMonth]] and [[SummaryByYear]] sections aren't being
>> >> picked up and filled. If weewx couldn't find them, it would complain
>> >> with an error - at least it does here. It's odd that they aren't being
>> >> substituted as I believe your locations are correct - see below.
>> >>
>> >> I assume you are running as root, in which case it doesn't matter what
>> >> the permissions on the NOAA directories are. FWIW The Directory is
>> >> 0744, the files are 0644
>> >>
>> >> Regarding your syslog output. I'm not familiar with public_html as the
>> >> web directory. I assume it gets remapped by apache2(?) and that's when
>> >> it becomes /weewx/ as ftpuploads refers to it.
>> >> eg:- ftpupload: Uploaded file /weewx/NOAA/NOAA-2019-02.txt
>> >> Are you using apache? Are you rewriting the Directory?
>> >>
>> >> It might pay to use wee_debug to sanitise your weewx.conf file. Double
>> >> check the output is cleaned of anything private, then post the
>> >> contents here.
>> >> http://weewx.com/docs/utilities.htm#wee_debug_utility
>> >>
>> >> Regarding weewx.conf values...
>> >>
>> >> Mine runs with
>> >> WEEWX_ROOT = /
>> >> SKIN_ROOT = /home/weewx/skins
>> >> HTML_ROOT = /var/www/html/weewx
>> >>
>> >> Yours is
>> >> WEEWX_ROOT = /home/weewx  (I assume this otherwise the following
>> >> values won't expand out)
>> >> and you supplied these previously
>> >> SKIN_ROOT = skins
>> >> HTML_ROOT = public_html
>> >> and that's pretty much a setup.py install
>> >>
>> >> Which means that your NOAA files should reside in
>> >> /home/weewx/public_html/NOAA
>> >> eg:- /home/weewx/public_html/NOAA/NOAA-2019-02.txt
>> >>
>> >> From there CheetahGenerator should be able 

Re: [weewx-user] Re: Second crash after 11 days

[Thomas Keffer]

I really only need the 'top' results for the instance running the
simulator: is it growing in its memory use?

On Tue, Feb 5, 2019 at 7:11 AM Steve2Q  wrote:

> Tom: After I run my system for a few more days, let me know which file(s)
> you would like to see.
>
> --
> 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.
>

-- 
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.

Re: [weewx-user] Re: Second crash after 11 days

[Steve2Q]

Tom: After I run my system for a few more days, let me know which file(s) you 
would like to see. 

-- 
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.

Re: [weewx-user] Re: NOAA reports not available

[bgrattan]

Glenn,

Had a thought that might not mean anything but here it goes. The page is 
not finding the summaries in /NOAA because I am unable to select a month or 
year. The box fails to display a drop down list of months or years from 
which I would select. It seems that it's the actual drop down list that is 
missing here because, until I select a year/month, the software has no need 
to go to /NOAA to display a date.txt file. Maybe it's the code/mechanism 
that creates the drop down list is missing (?) or not functioning (?) The 
list of months/years is not in /NOAA so maybe there is some script that 
produces it and creates links to /NOAA...  I really don't know how these 
drop down lists function so I'm out of my element at this point.  Any 
thoughts on this idea?  Thanks.
Bob


On Monday, February 4, 2019 at 9:56:28 PM UTC-5, Glenn McKechnie wrote:
>
> No insights (to me ) from the files you provided. 
>
> What's in no.htaccess? I wouldn't have thought there could be anything 
> in there that would prevent weewx from using the contents of NOAA. 
> It's more a webserver control point  - but then...? 
>
> Ownership and permissions seem okay. root.www-data is typical for a 
> debian install, 775 is liberal. 
>
> It's nice to see someone else that uses 'tree' It's a great little 
> program  and perfect for this case! 
> it shows the files where they should be. 
>
> I guess you could move them (the ones in public_html/NOAA ) aside, 
> then restart weewx to allow weewx to regenerate them. Then see if 
> excitement or disappointment wins that coin toss. 
>
>
> If it wasn't for the fact that your tmpl and skin.conf works here... 
> flawlessly even... Phttt. 
>
>
>
>
>
> On 05/02/2019, bgra...@umw.edu   > wrote: 
> > Hi Glenn, 
> > 
> > Sorry to put you through all of this. I have attached two files. One 
> from 
> > wee_debug and one of a "tree" from /home/weewx (a bit long but may have 
> a 
> > clue). I have a symlink in /var/www/html to /home/weewx/public_html 
> which 
> > has been working ok with apache2. A "diff" on cheetahgenerator.py and 
> 382 
> > source came out equal. The same thing on 370 showed a small difference 
> so I 
> > 
> > used that file but nothing changed so I put the original back. I'll work 
> on 
> > 
> > blocking the WX-HWS code I added to see if that changes anything.  In 
> > trying to get things going earlier, I changed some ownership to 
> > root:www-data and permissions to 775. I wouldn't think this would matter 
> > with this problem (?). 
> > Thanks again. 
> > Bob 
> > 
> > On Monday, February 4, 2019 at 5:01:17 PM UTC-5, Glenn McKechnie wrote: 
> >> 
> >> Hey Bob, 
> >> 
> >> There is no change, but it confirms that 
> >> 1.) we are working on the same page (the change has propagated to 
> godaddy) 
> >> 
> >> 2.) The [[SummaryByMonth]] and [[SummaryByYear]] sections aren't being 
> >> picked up and filled. If weewx couldn't find them, it would complain 
> >> with an error - at least it does here. It's odd that they aren't being 
> >> substituted as I believe your locations are correct - see below. 
> >> 
> >> I assume you are running as root, in which case it doesn't matter what 
> >> the permissions on the NOAA directories are. FWIW The Directory is 
> >> 0744, the files are 0644 
> >> 
> >> Regarding your syslog output. I'm not familiar with public_html as the 
> >> web directory. I assume it gets remapped by apache2(?) and that's when 
> >> it becomes /weewx/ as ftpuploads refers to it. 
> >> eg:- ftpupload: Uploaded file /weewx/NOAA/NOAA-2019-02.txt 
> >> Are you using apache? Are you rewriting the Directory? 
> >> 
> >> It might pay to use wee_debug to sanitise your weewx.conf file. Double 
> >> check the output is cleaned of anything private, then post the 
> >> contents here. 
> >> http://weewx.com/docs/utilities.htm#wee_debug_utility 
> >> 
> >> Regarding weewx.conf values... 
> >> 
> >> Mine runs with 
> >> WEEWX_ROOT = / 
> >> SKIN_ROOT = /home/weewx/skins 
> >> HTML_ROOT = /var/www/html/weewx 
> >> 
> >> Yours is 
> >> WEEWX_ROOT = /home/weewx  (I assume this otherwise the following 
> >> values won't expand out) 
> >> and you supplied these previously 
> >> SKIN_ROOT = skins 
> >> HTML_ROOT = public_html 
> >> and that's pretty much a setup.py install 
> >> 
> >> Which means that your NOAA files should reside in 
> >> /home/weewx/public_html/NOAA 
> >> eg:- /home/weewx/public_html/NOAA/NOAA-2019-02.txt 
> >> 
> >> From there CheetahGenerator should be able to find them and use them 
> >> in the index template. 
> >> 
> >> Nope, I'm out of ideas. 
> >> 
> >> Regarding WX-HWS. I'm running your template with that section 
> >> basically commented out (sort of, I have stubs in place) 
> >> You could try commenting out that whole section, or at least the 
> >> HTML_ROOT = /home/weewx/public_html/hws entries for a couple of runs. 
> >> Not sure if it will make any difference but we're at that stage. 
> >> 
> >> 
> >> Replace cheetah the application or 

Re: [weewx-user] Re: NEW!!! --- OutOfSpan: Attempt to merge an accumulator whose timespan is not a subset

[Thomas Keffer]

On Tue, Feb 5, 2019 at 6:22 AM mwall  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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: NEW!!! --- OutOfSpan: Attempt to merge an accumulator whose timespan is not a subset

[mwall]

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.  however, tom and gary know the 
accumulator code better than i do, so they could say whether OutOfSpan 
should be a fatal failure, versus a just "restart the report engine" 
failure.  but first we need to know the root cause of OutOfSpan.

a few observations:

- here is the analysis of report generation times from the syslog.2 file.  
nothing unusual here.

report cycle for record 2019-02-01 06:28:00
StdReport - 14 files in 18.82s + 36 images in 18.89s
cmon - 1 file in 0.7s + 32 images in 82.48s
exfoliation - 9 files in 100.62s + 62 images in 38.07s
forecast - 12 files in 110.11s
ftp - 353 files in 110.13s

report cycle for record 2019-02-01 03:35:00
skipped because report generator still running previous record

report cycle for record 2019-02-01 06:42:00
StdReport - 14 files in 5.53s + 12 images in 3.07s
cmon - 1 file in 0.15s + 32 images in 81.32s
exfoliation - 8 files in 9.64s + 48 images in 27.97s
forecast - 12 files in 82.3s
ftp - 127 files in 35.62s

report cycle for record 2019-02-01 06:49:00
StdReport - 14 files in 2.89s + 12 images in 2.89s
cmon - 1 file in 0.15s + 32 images in 81.12s
exfoliation - 8 files in 9.63s + 28 images in 9.37s
forecast 12 files in 83.02s
ftp - 107 files in 33.38s

so the first run is longer, as expected.  you should see longer report 
generation times whenever the monthly/yearly plots are updated as well.

you could eliminate LOTS of overhead by removing the forecast skin.  the 
exfoliation skin has forecast reporting built in, so you don't need the 
forecast skin too.  the forecast skin is designed to illustrate how 
forecasting works and to provide lots of examples of how to use it.  you 
probably don't want to run it in 'production'.

- what are wx_ftp_upload and wx_cp_index?

- you are getting stale data from the acurite sensor cluster (see circa 
07:13:47 in syslog.2). this is not unusual, but if it happens a lot then 
you should look at way of making your connection stronger (eliminate 
interference, re-orient the console, put console closer to sensors, dance 
naked around a fire at the next full moon, etc).

- you might want to plot the 'ignoring stale data' messages over time.  
that is a good way to see if there is a pattern to the interference timing.

- don't generate forecasts any more often than you must.  once every 4 
hours is typically sufficient.  i think exfoliation is set up to do this - 
it only generates forecast.html every 4 hours.  and the forecast download 
services are set up to download the data based on when the sources update.  
once again, get rid of forecast skin, because i think it regenerates every 
report cycle, even though that frequency is pointless.

- be sure that you have a sane max_age in the [Forecast] section in 
weewx.conf.  something like 604800 is reasonable.  you should only use 
max_age=none if you intend to retain forecasts indefinitely, e.g., for 
doing forecast comparisons over extended periods.

-- 
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.

Re: [weewx-user] Re: Second crash after 11 days

[Thomas Keffer]

Another data point: I installed the stretch 4.14.94 kernel that Steve is
using, then ran weewxd using my VPro2. No memory growth.

I'll be interested to see the results of running the simulator.

-tk

On Mon, Feb 4, 2019 at 12:12 PM Thomas Keffer  wrote:

> It is helpful for figuring out which services WeeWX is loading. Not
> essential, but useful for when you post a log.
>
> -tk
>
> On Mon, Feb 4, 2019 at 11:04 AM Steve2Q  wrote:
>
>> Tom..now that I have a better understanding of the process, I will
>> implement the change. Before I do that, I note that you have debug = 1 in
>> weewx_mem.conf, while in my weewx.conf debug is not set. Should I set it to
>> 1 in my weewx.conf?
>>
>>
>> --
>> 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.
>>
>

-- 
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.

[weewx-user] Re: Checking versions, configurations

[Kevin Tarr]

Thank you, back to 5 minute intervals.

On Saturday, February 2, 2019 at 5:13:08 PM UTC-5, mwall wrote:
>
> On Saturday, February 2, 2019 at 5:07:56 PM UTC-5, Kevin Tarr wrote:
>>
>>
>> Trying to change to wee_device /etc/weewx/weewx.conf --set-interval=5
>>
>> weewx.WeeWxIOError: could not claim interface 0: Operation not permitted
>>
>> I have weewx stopped.
>>
>
> try 'sudo wee_device ...'
>
> unless you modified the permissions on the usb device (using udev rules), 
> you must have root privileges to write to the device.
>
> m
>

-- 
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.

[weewx-user] Re: Weewx stopped running after 4 days

[Andrew Milner]

Gary - the point I was really trying to make was that - especially where an 
RPi is involved - it is likely that one cannot necessarily do all that one 
wishes - but compromising does not necessarily mean a significant loss of 
information.  What people often forget is that midnight in particular 
results in more load for reports as the yearly plots and pages are 
regenerated together with the monthly, weekly, current etc also and this 
can result in more issues when small archive intervals are being used. 

I think we are really on the same page Gary, even if I may appear a luddite 
and a pedant at times.

Andrew


On Tuesday, 5 February 2019 07:49:34 UTC+2, gjr80 wrote:
>
> I beg to disagree. I learnt a long time ago to not impose my views on a 
> user's requirements; maybe the user needs to generate a report every 
> minute, maybe they need to record the number of widgets every minute, maybe 
> they just like lots of dots in their plots. At the end of the day it does 
> not matter, WeeWX supports a 1 minute archive interval. Now if a user 
> chooses to use a 1 minute archive interval that may impose some limits on 
> the user, but that is a different matter. I know the old chestnut about 
> wind speeds and directions gets dragged out every now and then. I think we 
> need to keep in mind that the period over which an observation is made does 
> not necessarily bear any relationship to how often you may wish to record 
> the value.
>
> Gary
>
> On Tuesday, 5 February 2019 14:22:12 UTC+10, Andrew Milner wrote:
>>
>> I continue to find it almost impossible to conceive a situation where an 
>> archive interval of under 5 minutes serves any useful purpose.  As long as 
>> a gust value is recorded for the 5 minute period the average speed 
>> value/direction over the period is more than sufficient - even for an 
>> airfield - and the other readings are unlikely to alter over 5 minutes 
>> anyway.  So with a Pi a 5 minute interval is more than sufficient.
>>
>> I found the following whilst googling wind gust which I thought useful 
>> since the implication is that wind measurements over short periods of time 
>> (if the rest of the world is right) are error prone anyway:
>>
>> "Wind gusts (which last only a few seconds) make it hard to determine the 
>> overall wind speed of storms whose winds don't always blow at constant 
>> speeds. This is especially the case for tropical cyclones and hurricanes. 
>> To estimate the overall wind speed, the wind and wind gusts are measured 
>> over some period of time (typically 1 minute) and are then averaged 
>> together. The result is the highest average wind observed within the 
>> weather event, also called the *maximum sustained wind speed*. 
>>
>> Here in the U.S., maximum sustained winds are always measured by 
>> anemometers at a standard height of 33 feet (10 m) above ground for a 
>> duration of 1 minute. The rest of the world averages their winds over a 
>> period of 10 minutes. This difference is significant because measurements 
>> averaged over just one minute are about 14% higher than those averaged over 
>> the course of ten minutes."
>>
>>
>> On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote:
>>>
>>> Yes the NoneType error is certainly due to the realtime clientraw 
>>> extension not handling a None value correctly, by the looks of it a wind 
>>> related field so quite possibly brought on by your battery/connectivity 
>>> issue. That extension was written over 2 years ago and never formally 
>>> released (and judging by the lack of user questions I assume not used by 
>>> too many). So that means it is probably not too robust. It maybe easiest to 
>>> just disable it until I can get to have a look at it in the next 2-3 weeks 
>>> (as per other thread).
>>>
>>> Some good advice above about getting a machine to work reliably, the 
>>> only thing I would add is chose your archive interval carefully as that 
>>> also has an impact on stability when you start to add in a number of 
>>> extensions. A 5 minute archive period means there is 5 minutes between 
>>> report cycles so arguably WeeWX has around 5 minutes to get all of its 
>>> report processing completed, cut that down to 1 minute and WeeWX now only 
>>> has 1/5 the time. You don't want your reports taking longer to run than 
>>> your archive interval, that would be bad on many fronts. Some folks think 
>>> that having the shortest possible archive interval is essential, that may 
>>> be the case in some circumstances but there are other secondary effects 
>>> that need to be kept in mind. Basically, to run a 1 minute archive WeeWX 
>>> needs to be fairly lean extension wise.
>>>
>>> Gary
>>>
>>> On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote:

 On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith 
 wrote:
>
> Noted the use of skins and mqtt on a pi, i kind of assumed it was up 
> to the job, i do like the weewx system so may well move up to a more