[weewx-user] Re: weewx generates reports in simulator mode, but not in SDR mode

[seano...@gmail.com]

Just an update, i think i worked it out...

My [[sensor_map] did not have an underscore between sensor and map.

It's working now.

On Friday, December 18, 2020 at 5:24:02 PM UTC+4 seano...@gmail.com wrote:

> Hi,
>
> I have built a few weather stations so i'm familiar with the process but 
> for some reason i can't understand why weewx is not generating reports when 
> set to SDR mode. Because it works as soon as i change it into simulator 
> mode.
>
> In simulator mode i can use a local computer to browse 192.168.1.123/weewx 
> and i see the reports. When i switch to SDR, that same link does not show 
> the reports, just a file structure.
>
> From what i see and understand, the SDR adaptor is receiving the 
> transmission from the sensor correctly. I have already used the correct 
> identifiers in the [[sensor_map]] section of the weewx.conf - to me it only 
> looks like weewx is not generating reports. Would appreciate if anyone can 
> see anything that i am missing?
>
> weewx.conf
>
> https://u.pcloud.link/publink/show?code=XZIEH8XZnNUlXWDEYnj5qJ2HU4pqLQuv91RV
>
> weewx.log
>
> https://u.pcloud.link/publink/show?code=XZiEH8XZD0glneQHykh8633IJuS6Xbc3fyzk
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1f04834a-f8bf-48ad-a3c5-b6cf1de5f4f7n%40googlegroups.com.

[weewx-user] Re: belchertown question

[Neville Davis]

Pat

I am about to go to 1.2, have configured weewx and pwsweather receiving 
data and my station is now considered active and appears on the main map.
I am now attempting to link AerisWeather and pwsweather but the create 
Aerisweather contributor account page will not do the link..it keeps 
reporting "something went wrong please try submitting again". This has been 
happening for several days. Are you aware of any problems with this 
procedure?


Neville

On Tuesday, July 21, 2020 at 11:00:32 AM UTC+10 Pat wrote:

> Yep! Aeris is only working in the development version right now. I'm 
> working on final clean up of the skin and will be publishing the 
> development as a release soon. 
>
>
> On Monday, July 20, 2020 at 8:32:14 PM UTC-4, Jamie Stephens wrote:
>>
>> do i need to be running the development version to use the forecast with 
>> aeris? go easy on me i'm still learning linux and weewx
>>
>>
>> ERROR weewx.reportengine:   Warning: Error downloading 
>> forecast data. Check the URL in your configuration and try again. You are 
>> trying to use URL: 
>> https://api.darksky.net/forecast//35.17491,-81.02416?units=auto=en, 
>> and the error is: HTTP Error 400: Bad Request
>>
>>
>>
>>   enable = false
>> [[Belchertown]]
>> skin = Belchertown
>> HTML_ROOT = /var/www/html
>> [[[Extras]]]
>> forecast_enabled = 1
>> forecast_api_id = "removed"
>> forecast_api_secret = "removed"
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/00a80cc9-4b6d-4174-beda-451ef1ae7e21n%40googlegroups.com.

[weewx-user] Re: yet another question to GW1000 api driver mapping

[vince]

> [[field_map_extension]]
>txBatteryStatus = wh65_batt
>
> and the entry in the stanza [Accumulator] accordingly, wrote back an 
> untouched copy of seasons.inc, uncommented the original label in 
> skins.conf, and voila, after weewx restart, everything looks ok. Although, 
> I would have preferred wh65_battery decribing the field name more 
> precisely, when thinking about adding further sensors in the future.  But, 
> at least, I can now understand a little part of the whole thing more than 
> before.
>
>
That's actually a very typical way to use the many available elements 
creatively and not need to extend or customize the schema.  I used to do 
the same thing notionally when I had three battery-powered WeatherFlow 
sensors at the same time.   Just comment your weewx.conf appropriately so 
you remember which element is used for which sensor.  Works great !

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/aa6c3366-2cf7-4ffa-9622-8561d7fd1ab0n%40googlegroups.com.

Re: [weewx-user] NWS Radar Changes

[John Kline]

The loops in https://radar.weather.gov/ridge/lite/ seem to be up to date today. 
   

For example:
https://radar.weather.gov/ridge/lite/KMUX_loop.gif

As such, that’s also an option, although these gifs are tough to get used to.

> On Dec 18, 2020, at 9:38 AM, John Kline  wrote:
> 
> 
> This thread has a nice solution (see URL below):
> 
> https://www.wxforum.net/index.php?topic=40980.0
> 
> Terms of use:
> https://www.wunderground.com/company/legal
> 
> (In the following URL, substitute your radar station for OAX.  Set 
> weewx.conf’s Seasons radar_img value to this.)
> 
> https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=OAX=wui=18=15=N0R=0=1.000=0=0=1=1=0=0=0
> 
> 
>>> On Dec 17, 2020, at 10:00 PM, John Kline  wrote:
>>> 
>> 
>> Although the directory listing here shows old timestamps:
>> https://radar.weather.gov/ridge/lite/
>> 
>> The loop is being updated (albeit still a few hours old and I’m not a fan of 
>> this radar imagery):
>> https://radar.weather.gov/ridge/lite/KMUX_loop.gif
>> 
>> Although not part of the loop, this image is only about 30m old:
>> https://radar.weather.gov/ridge/lite/KMUX_1.gif
>> 
>> It’s not clear one could determine which file has the latest image.  Maybe 
>> this will improve over time and the _0.gif will have the latest gif (and/or 
>> the loop will be updated regularly).
>> 
 On Dec 17, 2020, at 4:18 PM, John Kline  wrote:
 
>>> 
>>> I’ve been grappling with this.  It is annoying.  The “new site” is 
>>> maddening to interact with: https://radar.weather.gov/
>>> 
>>> There’s a FAQ about the change here:
>>> https://www.weather.gov/radarfaq
>>> 
>>> The FAQ tells one where files can be downloaded.  I’ve started to look at 
>>> them (they are gzipped), but, so far, I haven’t found anything acceptable 
>>> to use.  I’m seeing a single color overlay (with no base map).  Still 
>>> looking, but this is an awful change.
>>> 
>>> John
>>> 
> On Dec 17, 2020, at 4:05 PM, peterq...@gmail.com 
>  wrote:
> 
 I use the old standard skin (modified). The NWS radar site changed today 
 and the optional radar graphic no longer works. Has anyone dug into this 
 and figured out how to get the new site to work?
 
 It's no big deal if not - I'll take a look myself and post something once 
 I find out how to make it work with the new site.
 -- 
 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.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/15c6bd2a-5795-4cf0-9ada-c6527f8d56ddn%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/1C8A4873-D39D-4DE0-966B-A5BFF73F40E0%40johnkline.com.

Re: [weewx-user] NWS Radar Changes

[John Kline]

This thread has a nice solution (see URL below):

https://www.wxforum.net/index.php?topic=40980.0

Terms of use:
https://www.wunderground.com/company/legal

(In the following URL, substitute your radar station for OAX.  Set weewx.conf’s 
Seasons radar_img value to this.)

https://radblast.wunderground.com/cgi-bin/radar/WUNIDS_map?station=OAX=wui=18=15=N0R=0=1.000=0=0=1=1=0=0=0


> On Dec 17, 2020, at 10:00 PM, John Kline  wrote:
> 
> 
> Although the directory listing here shows old timestamps:
> https://radar.weather.gov/ridge/lite/
> 
> The loop is being updated (albeit still a few hours old and I’m not a fan of 
> this radar imagery):
> https://radar.weather.gov/ridge/lite/KMUX_loop.gif
> 
> Although not part of the loop, this image is only about 30m old:
> https://radar.weather.gov/ridge/lite/KMUX_1.gif
> 
> It’s not clear one could determine which file has the latest image.  Maybe 
> this will improve over time and the _0.gif will have the latest gif (and/or 
> the loop will be updated regularly).
> 
>>> On Dec 17, 2020, at 4:18 PM, John Kline  wrote:
>>> 
>> 
>> I’ve been grappling with this.  It is annoying.  The “new site” is maddening 
>> to interact with: https://radar.weather.gov/
>> 
>> There’s a FAQ about the change here:
>> https://www.weather.gov/radarfaq
>> 
>> The FAQ tells one where files can be downloaded.  I’ve started to look at 
>> them (they are gzipped), but, so far, I haven’t found anything acceptable to 
>> use.  I’m seeing a single color overlay (with no base map).  Still looking, 
>> but this is an awful change.
>> 
>> John
>> 
 On Dec 17, 2020, at 4:05 PM, peterq...@gmail.com  
 wrote:
 
>>> I use the old standard skin (modified). The NWS radar site changed today 
>>> and the optional radar graphic no longer works. Has anyone dug into this 
>>> and figured out how to get the new site to work?
>>> 
>>> It's no big deal if not - I'll take a look myself and post something once I 
>>> find out how to make it work with the new site.
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/15c6bd2a-5795-4cf0-9ada-c6527f8d56ddn%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/F4B9BF24-0779-42E8-8D91-B338972E5B7E%40johnkline.com.

Re: [weewx-user] Re: "Grassland Temperature Sum" (or how it is called in English, german "Grünlandtemperatursumme" (GTS))

[Chuck Rhode]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 17 Dec 2020 23:57:40 -0800 (PST)
Karen K  wrote:

> I will try to do some coding.

I can send you *python 3* formulas.  These are new.

I had an extension that worked for v3 of WeeWX.  See my codling moth
tribute site: http://LacusVeris.com/cydia, now obsolete.

I am working on a v4 version.

- -- 
.. Be Seeing You,
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather:  http://LacusVeris.com/WX
.. 29° — Wind S 6 mph

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT+MY/5I/LMPSswTbVg2/xipKOWUgUCX9zizwAKCRBg2/xipKOW
UuewAJ91uIxUTpjtaFnXiFJug/WghmA/dgCbBq0eOdZKLWMUDVYiCQzNuGg0NfY=
=N2CH
-END PGP SIGNATURE-

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2020121843.7581572c%40wealthy.

[weewx-user] [[Calculations]] on archive record not loop packet?

[Graham Eddy]

my reading of the 4.3.0 source is that [[Calculations]] calculates the 
specified xtypes on each loop packet. is there a simple way now, or is it in 
plan, to be able to have them calculated for archive records only?

i do not want to calculate AQI from averaged pollutant values except when the 
averages are updated, which for me is at the end of each archive interval. i 
have written a data service to call the xtypes each archive record, but i would 
prefer StdWXCalculate handled it for me with ‘= software’ declarations

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/D43D0E70-13A6-4B6B-905C-F7597C97DE0A%40gmail.com.

[weewx-user] Re: Problem wiheth Cheetah search_list_extensions?

[gjr80]

Yes, a setting in weewx.conf overrides the equivalent setting in skin.conf, 
that’s where I was going but you figured it out.

Gary

On Friday, 18 December 2020 at 23:08:51 UTC+10 michael...@gmail.com wrote:

> Gary,
>
> I see the problem now.   Apparently the "search_list_extension" directive 
> I added for the forecast extension (in weewx.conf) is overriding the 
> directive I need to add in Seasons/skin.conf.   When I comment that 
> CheetahGenerator section out of the weewx.conf file and include both 
> forecast and metar extension in skin.conf they both run as expected.  The 
> python version 2 issue (with metargenerator.py) I think now rears it's head 
> because I still don't see any data in the report but I think I can work 
> that out.
>
> I probably would have figured this out eventually going back and forth 
> between weewx.conf and skin.conf but my thanks to you for asking for that 
> debug file.  It helped steer me in the right direction.
>
> Mike - AJ9X
>
> On Friday, December 18, 2020 at 7:42:01 AM UTC-5 Michael Bruski wrote:
>
>> Here is the .conf file.   The search_list_extensions directive that I 
>> tried is commented out in the section for [StdReport] [[SeasonsReport]] 
>> [[[CheetahGenerator]]].
>>
>> [FileParse]
>> poll_interval = 10
>> path = /tmp/wxdata
>> driver = user.fileparse
>> # WEEWX CONFIGURATION FILE
>> #
>> # Copyright (c) 2009-2020 Tom Keffer 
>> # See the file LICENSE.txt for your rights.
>>
>>
>> ##
>>
>> # This section is for general configuration information.
>>
>> # Set to 1 for extra debug info, otherwise comment it out or set to zero
>> debug = 1
>>
>> # Root directory of the weewx data file hierarchy for this station
>> WEEWX_ROOT = /
>>
>> # Whether to log successful operations
>> log_success = True
>>
>> # Whether to log unsuccessful operations
>> log_failure = True
>>
>> # How long to wait before timing out a socket (FTP, HTTP) connection
>> socket_timeout = 20
>>
>> # Do not modify this. It is used when installing and updating weewx.
>> version = 4.2.0
>>
>>
>> ##
>>
>> #   This section is for information about the station.
>>
>> [Station]
>> 
>> # Description of the station location
>> location = Fair Lea Hills Neighborhood
>> 
>> # Latitude in decimal degrees. Negative for southern hemisphere
>> latitude = 39.498
>> # Longitude in decimal degrees. Negative for western hemisphere.
>> longitude = -76.97
>> 
>> # Altitude of the station, with unit it is in. This is downloaded from
>> # from the station if the hardware supports it.
>> altitude = 247.65, meter
>> 
>> # Set to type of station hardware. There must be a corresponding 
>> stanza
>> # in this file with a 'driver' parameter indicating the driver to be 
>> used.
>> station_type = FileParse
>> 
>> # If you have a website, you may specify an URL
>> station_url = XXX obfuscated by wee_debug XXX
>> 
>> # The start of the rain year (1=January; 10=October, etc.). This is
>> # downloaded from the station if the hardware supports it.
>> rain_year_start = 1
>> 
>> # Start of week (0=Monday, 6=Sunday)
>> week_start = 6
>>
>>
>> ##
>>
>> [FileParse]
>> poll_interval = 10
>> path = /tmp/wxdata
>> driver = user.fileparse
>>
>>
>> ##
>>
>> [Simulator]
>> # This section is for the weewx weather station simulator
>> 
>> # The time (in seconds) between LOOP packets.
>> loop_interval = 2.5
>> 
>> # The simulator mode can be either 'simulator' or 'generator'.
>> # Real-time simulator. Sleep between each LOOP packet.
>> mode = simulator
>> # Generator.  Emit LOOP packets as fast as possible (useful for 
>> testing).
>> #mode = generator
>> 
>> # The start time. Format is -mm-ddTHH:MM. If not specified, the 
>> default 
>> # is to use the present time.
>> #start = 2011-01-01T00:00
>> 
>> # The driver to use:
>> driver = weewx.drivers.simulator
>>
>>
>> ##
>>
>> #   This section is for uploading data to Internet sites
>>
>> [StdRESTful]
>> 
>> [[StationRegistry]]
>> # To register this weather station with weewx, set this to true
>> register_this_station = true
>> 
>> [[AWEKAS]]
>> # This section is for configuring posts to AWEKAS.
>> 
>> # If you wish to do this, set the option 'enable' to true,
>> # and specify a username and password.
>> # To guard against parsing errors, put the password in quotes.
>> enable = false
>> username = XXX obfuscated by wee_debug XXX
>>

[weewx-user] weewx generates reports in simulator mode, but not in SDR mode

[seano...@gmail.com]

Hi,

I have built a few weather stations so i'm familiar with the process but 
for some reason i can't understand why weewx is not generating reports when 
set to SDR mode. Because it works as soon as i change it into simulator 
mode.

In simulator mode i can use a local computer to browse 192.168.1.123/weewx 
and i see the reports. When i switch to SDR, that same link does not show 
the reports, just a file structure.

>From what i see and understand, the SDR adaptor is receiving the 
transmission from the sensor correctly. I have already used the correct 
identifiers in the [[sensor_map]] section of the weewx.conf - to me it only 
looks like weewx is not generating reports. Would appreciate if anyone can 
see anything that i am missing?

weewx.conf
https://u.pcloud.link/publink/show?code=XZIEH8XZnNUlXWDEYnj5qJ2HU4pqLQuv91RV

weewx.log
https://u.pcloud.link/publink/show?code=XZiEH8XZD0glneQHykh8633IJuS6Xbc3fyzk

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/afe10679-8c51-4b66-87bf-6eb9a4a2399bn%40googlegroups.com.

Re: [weewx-user] Bad graphs

[Tom Keffer]

You do not want the PIL version. It is very out of date. You want Pillow.
What exactly did you try? If you tried to install PIL, then tried to
install Pillow, it's possible you left parts of PIL behind, and now have a
mixture.

What do you get for this:


*python3 -c "from PIL import ImageDraw; print(dir(ImageDraw))"*
*python3 -c "import PIL; print(PIL.__version__)"*
*python3 -m pip list*

-tk


On Thu, Dec 17, 2020 at 11:04 PM Meteo Ballino 
wrote:

> I can't get the PIL version, but I've updatet Pillow.
> Now I obtain this result.
>
> Il giorno venerdì 18 dicembre 2020 alle 00:49:52 UTC+1 tke...@gmail.com
> ha scritto:
>
>> Not sure, but you can try pip:
>>
>> sudo python3 -m pip install Pillow
>>
>> Then, again,
>>
>> python3 -c "import PIL; print(PIL.__version__)"
>>
>> to see if it's any different.
>>
>> On Thu, Dec 17, 2020 at 2:04 PM Meteo Ballino 
>> wrote:
>>
>>> how can I do?
>>> thanks
>>>
>>> Il giorno giovedì 17 dicembre 2020 alle 22:41:30 UTC+1 tke...@gmail.com
>>> ha scritto:
>>>
 Can you upgrade PIL?

 On Thu, Dec 17, 2020 at 1:03 PM Meteo Ballino 
 wrote:

> Yes, the anti_alias is set to 1. I also think that the problem is the
> PIL.
>
> Python version 3
> PIL version is the 5.4.1
>
> Il giorno giovedì 17 dicembre 2020 alle 21:58:38 UTC+1
> tke...@gmail.com ha scritto:
>
>> Very odd. I have not seen this before. This is with anti_alias = 1,
>> correct?
>>
>> I'm suspecting something is wrong with your installation of the
>> Python Imaging Library (PIL). What version do you have? I can't tell 
>> which
>> version of Python you are running because you did not post the log from 
>> the
>> restart of WeeWX.
>>
>> But, this should work:
>>
>> *cat /etc/default/weewx*
>>
>> *source /etc/default/weewx*
>> *$WEEWX_PYTHON -c "import PIL; print(PIL.__version__)"*
>>
>>
>>
>> -tk
>>
>> On Thu, Dec 17, 2020 at 12:27 PM Meteo Ballino 
>> wrote:
>>
>>> Hello and thanks for your answers.
>>> I set the standard skin and these are the results
>>> The graphs are generated but they are all buggy
>>>
>>> [image: screen.png][image: graph.png]
>>>
>>> Il giorno giovedì 17 dicembre 2020 alle 20:32:39 UTC+1 vince ha
>>> scritto:
>>>
 On Thursday, December 17, 2020 at 6:43:21 AM UTC-8
 meteo@gmail.com wrote:

> Could it be that the hardware is limited and can't handle plotting?
> weewx is running on a sheevaplug with debian10
>
>
 I run weewx in debian 8 on a Seagate Dockstar which is a Sheevaplug
 with only 128 MB RAM.  Everything runs just fine on that tiny system,
 although it periodically swaps a bit.   I run many extensions and skins
 including forecast and Belchertown without issues there, other than it
 being slow to process the skins.

 --
>>> 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.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/ed4b3ded-032c-44e6-b6f1-60a900b358a7n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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.
>
 To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/fa34fc43-c2ca-4bb8-bef3-9c7ec08ab681n%40googlegroups.com
> 
> .
>
 --
>>> 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.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/1b6beb62-55d1-4395-a986-c80d5559b94bn%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> 

[weewx-user] Re: Problem wiheth Cheetah search_list_extensions?

[Michael Bruski]

Gary,

I see the problem now.   Apparently the "search_list_extension" directive I 
added for the forecast extension (in weewx.conf) is overriding the 
directive I need to add in Seasons/skin.conf.   When I comment that 
CheetahGenerator section out of the weewx.conf file and include both 
forecast and metar extension in skin.conf they both run as expected.  The 
python version 2 issue (with metargenerator.py) I think now rears it's head 
because I still don't see any data in the report but I think I can work 
that out.

I probably would have figured this out eventually going back and forth 
between weewx.conf and skin.conf but my thanks to you for asking for that 
debug file.  It helped steer me in the right direction.

Mike - AJ9X

On Friday, December 18, 2020 at 7:42:01 AM UTC-5 Michael Bruski wrote:

> Here is the .conf file.   The search_list_extensions directive that I 
> tried is commented out in the section for [StdReport] [[SeasonsReport]] 
> [[[CheetahGenerator]]].
>
> [FileParse]
> poll_interval = 10
> path = /tmp/wxdata
> driver = user.fileparse
> # WEEWX CONFIGURATION FILE
> #
> # Copyright (c) 2009-2020 Tom Keffer 
> # See the file LICENSE.txt for your rights.
>
>
> ##
>
> # This section is for general configuration information.
>
> # Set to 1 for extra debug info, otherwise comment it out or set to zero
> debug = 1
>
> # Root directory of the weewx data file hierarchy for this station
> WEEWX_ROOT = /
>
> # Whether to log successful operations
> log_success = True
>
> # Whether to log unsuccessful operations
> log_failure = True
>
> # How long to wait before timing out a socket (FTP, HTTP) connection
> socket_timeout = 20
>
> # Do not modify this. It is used when installing and updating weewx.
> version = 4.2.0
>
>
> ##
>
> #   This section is for information about the station.
>
> [Station]
> 
> # Description of the station location
> location = Fair Lea Hills Neighborhood
> 
> # Latitude in decimal degrees. Negative for southern hemisphere
> latitude = 39.498
> # Longitude in decimal degrees. Negative for western hemisphere.
> longitude = -76.97
> 
> # Altitude of the station, with unit it is in. This is downloaded from
> # from the station if the hardware supports it.
> altitude = 247.65, meter
> 
> # Set to type of station hardware. There must be a corresponding stanza
> # in this file with a 'driver' parameter indicating the driver to be 
> used.
> station_type = FileParse
> 
> # If you have a website, you may specify an URL
> station_url = XXX obfuscated by wee_debug XXX
> 
> # The start of the rain year (1=January; 10=October, etc.). This is
> # downloaded from the station if the hardware supports it.
> rain_year_start = 1
> 
> # Start of week (0=Monday, 6=Sunday)
> week_start = 6
>
>
> ##
>
> [FileParse]
> poll_interval = 10
> path = /tmp/wxdata
> driver = user.fileparse
>
>
> ##
>
> [Simulator]
> # This section is for the weewx weather station simulator
> 
> # The time (in seconds) between LOOP packets.
> loop_interval = 2.5
> 
> # The simulator mode can be either 'simulator' or 'generator'.
> # Real-time simulator. Sleep between each LOOP packet.
> mode = simulator
> # Generator.  Emit LOOP packets as fast as possible (useful for 
> testing).
> #mode = generator
> 
> # The start time. Format is -mm-ddTHH:MM. If not specified, the 
> default 
> # is to use the present time.
> #start = 2011-01-01T00:00
> 
> # The driver to use:
> driver = weewx.drivers.simulator
>
>
> ##
>
> #   This section is for uploading data to Internet sites
>
> [StdRESTful]
> 
> [[StationRegistry]]
> # To register this weather station with weewx, set this to true
> register_this_station = true
> 
> [[AWEKAS]]
> # This section is for configuring posts to AWEKAS.
> 
> # If you wish to do this, set the option 'enable' to true,
> # and specify a username and password.
> # To guard against parsing errors, put the password in quotes.
> enable = false
> username = XXX obfuscated by wee_debug XXX
> password = XXX obfuscated by wee_debug XXX
> 
> [[CWOP]]
> # This section is for configuring posts to CWOP.
> 
> # If you wish to do this, set the option 'enable' to true,
> # and specify the station ID (e.g., CW1234).
> enable = false
> station = XXX obfuscated by wee_debug XXX
> 
> # If this is 

[weewx-user] Re: Problem wiheth Cheetah search_list_extensions?

[Michael Bruski]

Here is the .conf file.   The search_list_extensions directive that I tried 
is commented out in the section for [StdReport] [[SeasonsReport]] 
[[[CheetahGenerator]]].

[FileParse]
poll_interval = 10
path = /tmp/wxdata
driver = user.fileparse
# WEEWX CONFIGURATION FILE
#
# Copyright (c) 2009-2020 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 1

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 4.2.0

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = Fair Lea Hills Neighborhood

# Latitude in decimal degrees. Negative for southern hemisphere
latitude = 39.498
# Longitude in decimal degrees. Negative for western hemisphere.
longitude = -76.97

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 247.65, meter

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be 
used.
station_type = FileParse

# If you have a website, you may specify an URL
station_url = XXX obfuscated by wee_debug XXX

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##

[FileParse]
poll_interval = 10
path = /tmp/wxdata
driver = user.fileparse

##

[Simulator]
# This section is for the weewx weather station simulator

# The time (in seconds) between LOOP packets.
loop_interval = 2.5

# The simulator mode can be either 'simulator' or 'generator'.
# Real-time simulator. Sleep between each LOOP packet.
mode = simulator
# Generator.  Emit LOOP packets as fast as possible (useful for 
testing).
#mode = generator

# The start time. Format is -mm-ddTHH:MM. If not specified, the 
default 
# is to use the present time.
#start = 2011-01-01T00:00

# The driver to use:
driver = weewx.drivers.simulator

##

#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = true

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
# To guard against parsing errors, put the password in quotes.
enable = false
username = XXX obfuscated by wee_debug XXX
password = XXX obfuscated by wee_debug XXX

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = false
station = XXX obfuscated by wee_debug XXX

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = XXX obfuscated by wee_debug XXX
password = XXX obfuscated by wee_debug XXX

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = XXX obfuscated by wee_debug XXX
password = XXX obfuscated by wee_debug XXX

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

[weewx-user] Re: yet another question to GW1000 api driver mapping

[Vetti52]

Ok, this is the missing point. Actually, I hesitate because of this 
highlight in the Customization Guide:

*Warning!*
Make a backup of the data before doing any of the next steps! 

 

As I am actually not physically close to the Raspi running with Weewx (the 
actual connection is with ssh from outside), so I prefer the lazy way:

I replaced wh65_battery with

[[field_map_extension]]
   txBatteryStatus = wh65_batt

and the entry in the stanza [Accumulator] accordingly, wrote back an 
untouched copy of seasons.inc, uncommented the original label in 
skins.conf, and voila, after weewx restart, everything looks ok. Although, 
I would have preferred wh65_battery decribing the field name more 
precisely, when thinking about adding further sensors in the future.  But, 
at least, I can now understand a little part of the whole thing more than 
before.

Thanks!
Peter
gjr80 schrieb am Freitag, 18. Dezember 2020 um 10:58:43 UTC+1:

> The penny drops. Have you added wh65_battery to your database schema? 
> $current.wh65_battery will work without wh65_battery being in your schema 
> but $day.wh65_battery requires wh65_battery be in your schema.
>
> Refer to Adding a new type to the database 
>  in the 
> Customization Guide.
>
> Gary
>
> On Friday, 18 December 2020 at 19:30:22 UTC+10 Vetti52 wrote:
>
>> Thanks, Gary. The typo was here, not in seasons.inc. But I had another 
>> assumption: When displaying the values $current.txBatteryStatus.raw and 
>> $current.wh65_battery.raw , I could see, that the first one was empty, 
>> and only the second value was existent. My assumption was, that  $
>> day.txBatteryStatus had data from time of this day before switching from 
>> interceptor to gw1000 driver, but $day.wh65_battery did not (yet). 
>> So I tried this modification:
>>
>> #set $have_battery_status = 0
>> #for $x in [$day.txBatteryStatus, $day.wh65_battery, 
>> $day.windBatteryStatus, $day.rainBatteryStatus, $day.outTempBatteryStatus, 
>> $day.inTempBatteryStatus]
>>
>>   #if $x.has_data
>> #set $have_battery_status = 1
>>   #end if
>> #end for
>>
>>
>> If this was true, I expected, that the sensor section would be present 
>> today, because 
>>
>> #if $have_battery_status
>> Batterie Status
>> #if $day.txBatteryStatus.has_data
>> 
>>   $obs.label.wh65_batteryStatus
>>   $get_battery_status($current.wh65_battery.raw)
>> 
>>
>> #end if
>>
>> should result in the header line but no "Transmitter" data, because 
>> $have_battery_status being true, but no content, because 
>> $day.txBatteryStatus.has_data was supposed to be wrong since today. 
>> However, unfortunately, the complete section disappeared. So, my assumption 
>> is true only partially: Today there is no more $day.txBatteryStatus, 
>> but, surprise,  there isn't  $day.wh65_battery either.
>> What is wrong with it?
>>  
>> gjr80 schrieb am Donnerstag, 17. Dezember 2020 um 21:21:10 UTC+1:
>>
>>> Peter,
>>>
>>> Your understanding is correct. The logic in the code now appears correct 
>>> but I think you are using the incorrect field name. Earlier you posted an 
>>> archive record:
>>>
>>> REC:2020-12-16 13:30:00 CET (1608121800) altimeter: 
>>> 30.09246486970751, appTemp: 46.07291271146897, barometer: 
>>> 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, 
>>> daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 
>>> 0.00012174671890853505, extraTemp1: 124.894399, heatindex: 
>>> 47.4030006, humidex: 48.934644083871206, inDewpoint: 
>>> 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, 
>>> luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 
>>> 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 
>>> 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 
>>> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, 
>>> UV: 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, 
>>> windchill: 48.74, windDir: 187.0, windGust: 3.3554127779089566, 
>>> windGustDir: 187, windrun: 0.22369418519393044, windSpeed: 
>>> 2.6843302223271652, yearRain: 29.17716535433071
>>>
>>> The field name is wh65_battery not wh_65battery. Anywhere you use $day 
>>> or $current to access the WH65 battery state you need to be using 
>>> $day.wh65_battery or $current.wh65_battery.
>>>
>>> Gary
>>>
>>> On Thursday, 17 December 2020 at 22:38:50 UTC+10 Vetti52 wrote:
>>>
 Aaah, now I start to understand! The first part is just a definition. 
 Got it! Thanks

 In skin.conf stanza [Labels] [Generic] I found

 txBatteryStatus  = Transmitter

 I replaced the left side with wh65_batteryStatus

 In Seasons.inc I found:

 #set 

[weewx-user] Re: yet another question to GW1000 api driver mapping

[gjr80]

The penny drops. Have you added wh65_battery to your database schema? 
$current.wh65_battery will work without wh65_battery being in your schema 
but $day.wh65_battery requires wh65_battery be in your schema.

Refer to Adding a new type to the database 
 in the 
Customization Guide.

Gary

On Friday, 18 December 2020 at 19:30:22 UTC+10 Vetti52 wrote:

> Thanks, Gary. The typo was here, not in seasons.inc. But I had another 
> assumption: When displaying the values $current.txBatteryStatus.raw and 
> $current.wh65_battery.raw , I could see, that the first one was empty, 
> and only the second value was existent. My assumption was, that  $
> day.txBatteryStatus had data from time of this day before switching from 
> interceptor to gw1000 driver, but $day.wh65_battery did not (yet). 
> So I tried this modification:
>
> #set $have_battery_status = 0
> #for $x in [$day.txBatteryStatus, $day.wh65_battery, 
> $day.windBatteryStatus, $day.rainBatteryStatus, $day.outTempBatteryStatus, 
> $day.inTempBatteryStatus]
>
>   #if $x.has_data
> #set $have_battery_status = 1
>   #end if
> #end for
>
>
> If this was true, I expected, that the sensor section would be present 
> today, because 
>
> #if $have_battery_status
> Batterie Status
> #if $day.txBatteryStatus.has_data
> 
>   $obs.label.wh65_batteryStatus
>   $get_battery_status($current.wh65_battery.raw)
> 
>
> #end if
>
> should result in the header line but no "Transmitter" data, because 
> $have_battery_status being true, but no content, because 
> $day.txBatteryStatus.has_data was supposed to be wrong since today. 
> However, unfortunately, the complete section disappeared. So, my assumption 
> is true only partially: Today there is no more $day.txBatteryStatus, but, 
> surprise,  there isn't  $day.wh65_battery either.
> What is wrong with it?
>  
> gjr80 schrieb am Donnerstag, 17. Dezember 2020 um 21:21:10 UTC+1:
>
>> Peter,
>>
>> Your understanding is correct. The logic in the code now appears correct 
>> but I think you are using the incorrect field name. Earlier you posted an 
>> archive record:
>>
>> REC:2020-12-16 13:30:00 CET (1608121800) altimeter: 
>> 30.09246486970751, appTemp: 46.07291271146897, barometer: 
>> 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, 
>> daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 
>> 0.00012174671890853505, extraTemp1: 124.894399, heatindex: 
>> 47.4030006, humidex: 48.934644083871206, inDewpoint: 
>> 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, 
>> luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 
>> 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 
>> 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 
>> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 
>> 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill: 
>> 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187, 
>> windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain: 
>> 29.17716535433071
>>
>> The field name is wh65_battery not wh_65battery. Anywhere you use $day 
>> or $current to access the WH65 battery state you need to be using 
>> $day.wh65_battery or $current.wh65_battery.
>>
>> Gary
>>
>> On Thursday, 17 December 2020 at 22:38:50 UTC+10 Vetti52 wrote:
>>
>>> Aaah, now I start to understand! The first part is just a definition. 
>>> Got it! Thanks
>>>
>>> In skin.conf stanza [Labels] [Generic] I found
>>>
>>> txBatteryStatus  = Transmitter
>>>
>>> I replaced the left side with wh65_batteryStatus
>>>
>>> In Seasons.inc I found:
>>>
>>> #set $have_battery_status = 0
>>> #for $x in [$day.txBatteryStatus, $day.windBatteryStatus, 
>>> $day.rainBatteryStatus, $day.outTempBatteryStatus, $day.inTempBatteryStatus]
>>>   #if $x.has_data
>>> #set $have_battery_status = 1
>>>   #end if
>>> #end for
>>>
>>> and later on:
>>>
>>> #if $have_battery_status
>>> Batterie Status
>>> #if $day.txBatteryStatus.has_data
>>> 
>>>   $obs.label.txBatteryStatus
>>>   $get_battery_status($current.txBatteryStatus
>>> .raw)
>>> 
>>> #end if
>>>
>>> I replaced all txBatteryStatus entries by wh65_battery  except 
>>> $obs.label.wh65_batteryStatus according to the label in skin.conf. 
>>>
>>> First, all this looks simply logic. However, now the sensors data were 
>>> no longer displayed at all. Checked for typos. Nope. So, my logic failed 
>>> again.
>>>
>>> I then tried to replace all entries step by step. So, at first, it was 
>>> evident, that the expression #for $x in [$day.txBatteryStatus, ...  
>>> still results in status = 1, but not, when replaced with 
>>> $day.wh_65battery,. 
>>>
>>> Ok, next step. Then I have to keep the original condition also here:
>>>
>>> #if $have_battery_status
>>> Batterie Status
>>> #if $day.txBatteryStatus.has_data
>>> 
>>>
>>> but 

[weewx-user] Re: yet another question to GW1000 api driver mapping

[Vetti52]

Thanks, Gary. The typo was here, not in seasons.inc. But I had another 
assumption: When displaying the values $current.txBatteryStatus.raw and 
$current.wh65_battery.raw , I could see, that the first one was empty, and 
only the second value was existent. My assumption was, that  $
day.txBatteryStatus had data from time of this day before switching from 
interceptor to gw1000 driver, but $day.wh65_battery did not (yet). 
So I tried this modification:

#set $have_battery_status = 0
#for $x in [$day.txBatteryStatus, $day.wh65_battery, 
$day.windBatteryStatus, $day.rainBatteryStatus, $day.outTempBatteryStatus, 
$day.inTempBatteryStatus]
  #if $x.has_data
#set $have_battery_status = 1
  #end if
#end for

If this was true, I expected, that the sensor section would be present 
today, because 

#if $have_battery_status
Batterie Status
#if $day.txBatteryStatus.has_data

  $obs.label.wh65_batteryStatus
  $get_battery_status($current.wh65_battery.raw)

#end if

should result in the header line but no "Transmitter" data, because 
$have_battery_status being true, but no content, because 
$day.txBatteryStatus.has_data was supposed to be wrong since today. 
However, unfortunately, the complete section disappeared. So, my assumption 
is true only partially: Today there is no more $day.txBatteryStatus, but, 
surprise,  there isn't  $day.wh65_battery either.
What is wrong with it?
 
gjr80 schrieb am Donnerstag, 17. Dezember 2020 um 21:21:10 UTC+1:

> Peter,
>
> Your understanding is correct. The logic in the code now appears correct 
> but I think you are using the incorrect field name. Earlier you posted an 
> archive record:
>
> REC:2020-12-16 13:30:00 CET (1608121800) altimeter: 
> 30.09246486970751, appTemp: 46.07291271146897, barometer: 
> 30.092169667712717, cloudbase: 944.6426189788297, dateTime: 1608121800, 
> daymaxwind: 3.6, dayRain: 0.0, dewpoint: 45.0455158818643, ET: 
> 0.00012174671890853505, extraTemp1: 124.894399, heatindex: 
> 47.4030006, humidex: 48.934644083871206, inDewpoint: 
> 50.88299985988465, inHumidity: 60.0, inTemp: 65.12, interval: 5.0, 
> luminosity: 8184.0, maxSolarRad: 86.02828823732644, monthRain: 
> 0.6653543307086613, outHumidity: 87.0, outTemp: 48.74, pressure: 
> 29.97589031125, radiation: 64.59352801894238, rain: 0.0, rainEvent: 
> 0.4015748031496063, rainRate: 0.0, relbarometer: 1019.2, usUnits: 1, UV: 
> 0.0, uvradiation: 6.5, weekRain: 10.9, wh65_battery: 0.0, windchill: 
> 48.74, windDir: 187.0, windGust: 3.3554127779089566, windGustDir: 187, 
> windrun: 0.22369418519393044, windSpeed: 2.6843302223271652, yearRain: 
> 29.17716535433071
>
> The field name is wh65_battery not wh_65battery. Anywhere you use $day or 
> $current to access the WH65 battery state you need to be using 
> $day.wh65_battery or $current.wh65_battery.
>
> Gary
>
> On Thursday, 17 December 2020 at 22:38:50 UTC+10 Vetti52 wrote:
>
>> Aaah, now I start to understand! The first part is just a definition. Got 
>> it! Thanks
>>
>> In skin.conf stanza [Labels] [Generic] I found
>>
>> txBatteryStatus  = Transmitter
>>
>> I replaced the left side with wh65_batteryStatus
>>
>> In Seasons.inc I found:
>>
>> #set $have_battery_status = 0
>> #for $x in [$day.txBatteryStatus, $day.windBatteryStatus, 
>> $day.rainBatteryStatus, $day.outTempBatteryStatus, $day.inTempBatteryStatus]
>>   #if $x.has_data
>> #set $have_battery_status = 1
>>   #end if
>> #end for
>>
>> and later on:
>>
>> #if $have_battery_status
>> Batterie Status
>> #if $day.txBatteryStatus.has_data
>> 
>>   $obs.label.txBatteryStatus
>>   $get_battery_status($current.txBatteryStatus
>> .raw)
>> 
>> #end if
>>
>> I replaced all txBatteryStatus entries by wh65_battery  except 
>> $obs.label.wh65_batteryStatus according to the label in skin.conf. 
>>
>> First, all this looks simply logic. However, now the sensors data were no 
>> longer displayed at all. Checked for typos. Nope. So, my logic failed again.
>>
>> I then tried to replace all entries step by step. So, at first, it was 
>> evident, that the expression #for $x in [$day.txBatteryStatus, ...  
>> still results in status = 1, but not, when replaced with 
>> $day.wh_65battery,. 
>>
>> Ok, next step. Then I have to keep the original condition also here:
>>
>> #if $have_battery_status
>> Batterie Status
>> #if $day.txBatteryStatus.has_data
>> 
>>
>> but still use the new values in the next two lines here:
>>
>>   $obs.label.wh65_batteryStatus
>>
>>   $get_battery_status($current.wh65_battery.raw)
>> 
>> 
>> #end if
>>
>>
>> So, finally everything looks fine, same like the results from 
>> interceptor.py. But why do I still need txBatteryStatus? Where does this 
>> value come from? Obviously $current.wh65_battery returns a valid result, 
>> thus providing data. But it is not suitable for evaluating $x. This is 
>> still not logical to me...
>>
>> Actually to me it looks like txBatteryStatus is not the 

[weewx-user] Re: Installation of version 4.2.0

[Ton vanN]

'Problem' for adding usb-capability solved by using a command-string 
linking to another usb-module
sudo pip3 install pyusb
After running that string at least the configuration-menu has no complaints 
anymore and shows all devices with usb-interface.

Op woensdag 16 december 2020 om 17:35:08 UTC+1 schreef vince:

> I would simply symlink 'from' the existing tree 'to' the weewx directory:
>ln -s /home/weewx/public_html /home/pi/domoticz/www/weewx
>
> Then you should see the web pages from weewx in your web if you use 
> http://hostname/weewx 
>
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d61e40c2-c58e-45f6-927c-94014d9878f4n%40googlegroups.com.