Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

['Michael Waldor' via weewx-user]

I've pulled your change and waited for some days: Now the temperatures 
shown look much better. No longer constant values. And the values match 
with our weather😊

Thanks for your support, 

Michael 

jo...@johnkline.com schrieb am Dienstag, 1. Dezember 2020 um 15:47:50 UTC+1:

> This is now released as 3.4.0b11:
> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b11
>
> On Nov 30, 2020, at 3:23 PM, John Kline  wrote:
>
> 
>
> Thanks, I was just looking for you to confirm that you were seeing the 
> issue in the forecast skin itself.
>
> I looked at forecast_compact.inc.  It is looking for temperatureMin and 
> temperatureMax (which are in the beginning section of the WU forecast). 
>  Furthermore, when I looked at the tempMin and tempMax columns in the 
> database, they were wrong.  There was a bug in parsing for these values. 
>  I’ve fixed that now.
>
> Please pull forecast.py at head and give it a try.  Copy it to 
> /bin/user.
>
> You’ll need to wait for a new WU forecast to download and then for a 
> report to generate.  This download may take some time.  If you’re 
> comfortable mucking with the database, you could delete the latest WU 
> forecast.  If you’re not comfortable doing that, and you don’t want to 
> wait, you could simply delete the forecast.db file and then restart weewx 
> (which you have to restart anyway after you copy over the new forecast.py 
> file).
>
> On Nov 30, 2020, at 8:20 AM, 'Michael Waldor' via weewx-user <
> weewx...@googlegroups.com> wrote:
>
> Regarding missing icon... I already copied it from your zip, and it's 
> working fine. I just thought that the missing icon might be a hint that 
> some important code might be missing, too. But probably not. 
>
> I did use the original forcast skin creating the subfolder forecast within 
> HTML area. And it, too, contains the "wrong" temperature values. Identical 
> to those values as been shown within my usecase of forecast_compact. 
>
> Yesterday I've validated that forcast.sdb contains the "correct" forecast 
> temperatures within the SQL database field temperature (there are 12entries 
> per timestamp for 6days). Hopefully my forecast.sdb.txt posted yesterday is 
> still a valid binary SQL database, then you can inspect it e. g. using 
> sqlbrowser. 
>
> Thus I assume that somewhere within weewx/forecast the wrong data are 
> forwarded into HTML output. 
>
> jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 
> UTC+1:
>
>> frzngdrzl.png was added to the repository after the b10 release.  If you 
>> want it, you’ll have to download the repository at head.
>>
>> I cannot decipher from your reply if the compact forecast is correct in 
>> the forecast skin.  Is it?
>>
>> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
>>
>> 
>>
>> Yes, I did diff both - they are identical. But there is a minor issue: 
>> You did update install.py to include frzgrain.png. This is still missing 
>> within your  
>> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10 
>> - the png is include but it will not be installed. Is there any other 
>> important change maybe missing within your last zip release?
>>
>> Of course that does not explain the wrong temperature numbers. I've 
>> checked also the foreground skin. The data are in sync with my change 
>> within Seasons skin. But the data do not contain the values from 
>> temperature field within forecast.sdb.
>>
>> Don't know the internal flow of weewx/forecast. I assume that first you 
>> fetch json contents from WU. Then that data is uploaded into forecast.sdb. 
>> Afterwards during creation of HTML output the data from forecast.sdb is 
>> read and added into the HTML templates by forecast.py. If my assumption is 
>> correct there might be a problem during the step from forecast.sdg into the 
>> HTML output.
>>
>>
>> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 
>> UTC+1:
>>
>>> > Maybe I'm using the wrong forecast_compact.inc (see my included file)? 
>>> And see als my forecast.sdb and 5day.json with the presumably correct temp 
>>> values, but not shown within the rendered window.
>>>
>>> Did you diff forecast_compact.inc with the like named file in the latest 
>>> forecast extension?  Are they identical?  If not, please provide the diff.
>>>
>>> Does the compact forecast in the *forecast skin* have the correct 
>>> values?
>>>
>>> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
>>>
>>> Sorry for posting multiple times - but google did abort any post if 
>>> containing *.json or *.inc files:-(
>>>
>>>
>>>
>>> Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:26:00 UTC+1:
>>>
 Tried to rename forecast.sdb into forecast.sdb.txt 

 Michael Waldor schrieb am Sonntag, 29. November 2020 um 10:23:34 UTC+1:

> Sorry, but google doesn't allow me to append the data. Thus I try 
> again ...
>
> -- 
>>> You received this message because you are subscribed to the Goo

Re: [weewx-user] forcast wunderground for weewx 4.2.x using python 3

[John Kline]

Thanks for getting back to me.

> On Dec 3, 2020, at 5:42 AM, 'Michael Waldor' via weewx-user 
>  wrote:
> 
> I've pulled your change and waited for some days: Now the temperatures shown 
> look much better. No longer constant values. And the values match with our 
> weather😊
> 
> Thanks for your support, 
> 
> Michael 
> 
> jo...@johnkline.com schrieb am Dienstag, 1. Dezember 2020 um 15:47:50 UTC+1:
>> This is now released as 3.4.0b11:
>> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b11
>> 
 On Nov 30, 2020, at 3:23 PM, John Kline  wrote:
 
>>> 
>> 
>>> Thanks, I was just looking for you to confirm that you were seeing the 
>>> issue in the forecast skin itself.
>>> 
>>> I looked at forecast_compact.inc.  It is looking for temperatureMin and 
>>> temperatureMax (which are in the beginning section of the WU forecast).  
>>> Furthermore, when I looked at the tempMin and tempMax columns in the 
>>> database, they were wrong.  There was a bug in parsing for these values.  
>>> I’ve fixed that now.
>>> 
>>> Please pull forecast.py at head and give it a try.  Copy it to 
>>> /bin/user.
>>> 
>>> You’ll need to wait for a new WU forecast to download and then for a report 
>>> to generate.  This download may take some time.  If you’re comfortable 
>>> mucking with the database, you could delete the latest WU forecast.  If 
>>> you’re not comfortable doing that, and you don’t want to wait, you could 
>>> simply delete the forecast.db file and then restart weewx (which you have 
>>> to restart anyway after you copy over the new forecast.py file).
>>> 
> On Nov 30, 2020, at 8:20 AM, 'Michael Waldor' via weewx-user 
>  wrote:
> 
 Regarding missing icon... I already copied it from your zip, and it's 
 working fine. I just thought that the missing icon might be a hint that 
 some important code might be missing, too. But probably not. 
 
 I did use the original forcast skin creating the subfolder forecast within 
 HTML area. And it, too, contains the "wrong" temperature values. Identical 
 to those values as been shown within my usecase of forecast_compact. 
 
 Yesterday I've validated that forcast.sdb contains the "correct" forecast 
 temperatures within the SQL database field temperature (there are 
 12entries per timestamp for 6days). Hopefully my forecast.sdb.txt posted 
 yesterday is still a valid binary SQL database, then you can inspect it e. 
 g. using sqlbrowser. 
 
 Thus I assume that somewhere within weewx/forecast the wrong data are 
 forwarded into HTML output. 
 
 jo...@johnkline.com schrieb am Montag, 30. November 2020 um 16:15:24 UTC+1:
> frzngdrzl.png was added to the repository after the b10 release.  If you 
> want it, you’ll have to download the repository at head.
> 
> I cannot decipher from your reply if the compact forecast is correct in 
> the forecast skin.  Is it?
> 
>>> On Nov 30, 2020, at 12:10 AM, Michael Waldor  wrote:
>>> 
>> 
> 
>> Yes, I did diff both - they are identical. But there is a minor issue: 
>> You did update install.py to include frzgrain.png. This is still missing 
>> within your  
>> https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b10
>>  - the png is include but it will not be installed. Is there any other 
>> important change maybe missing within your last zip release?
>> 
>> Of course that does not explain the wrong temperature numbers. I've 
>> checked also the foreground skin. The data are in sync with my change 
>> within Seasons skin. But the data do not contain the values from 
>> temperature field within forecast.sdb.
>> 
>> Don't know the internal flow of weewx/forecast. I assume that first you 
>> fetch json contents from WU. Then that data is uploaded into 
>> forecast.sdb. Afterwards during creation of HTML output the data from 
>> forecast.sdb is read and added into the HTML templates by forecast.py. 
>> If my assumption is correct there might be a problem during the step 
>> from forecast.sdg into the HTML output.
>> 
>> 
>> jo...@johnkline.com schrieb am Sonntag, 29. November 2020 um 14:36:07 
>> UTC+1:
>>> > Maybe I'm using the wrong forecast_compact.inc (see my included 
>>> > file)? And see als my forecast.sdb and 5day.json with the presumably 
>>> > correct temp values, but not shown within the rendered window.
>>> 
>>> Did you diff forecast_compact.inc with the like named file in the 
>>> latest forecast extension?  Are they identical?  If not, please provide 
>>> the diff.
>>> 
>>> Does the compact forecast in the forecast skin have the correct values?
>>> 
> On Nov 29, 2020, at 1:27 AM, Michael Waldor  wrote:
> 
 Sorry for posting multiple times - but google did abort any post if 
 containing *.json or *.inc files:

Re: [weewx-user] Re: Belchertown Graphs, Reports, Records only show Index with parent directory in text.

[Timothy L]

Thank you for your replies, Ian and Vince. Was out of town for the holiday
and will investigate according to your answers. I appreciate  your help.

On Fri, Nov 27, 2020, 8:42 AM ian...@kinnon.org  wrote:

> I am no expert, but sounds like it might be a web server issue rather than
> weewx/belchertown
>
> Are you see anything in your web server logs?
> I am running weewx with belchertown on a raspberry pi Debian 10.6 and my
> apache logs are in
> /var/log/apache2
> check for access.log and error.log
>
> Ian
>
> On Tuesday, 24 November 2020 at 15:06:36 UTC lecoqacr...@gmail.com wrote:
>
>> Is there no answer to this issue? Pretty sure that it should be a simple
>> fix if someone can point me in the right direction.
>> the seasons skin shows all graphs but the belchertown only has the output
>> above of the " Parent directory etc." for graphs, records, reports.
>> Tried on weewx 3.9 with same results using debian install.
>> On Saturday, November 21, 2020 at 12:10:58 AM UTC-6 lecoqacr...@gmail.com
>> wrote:
>>
>>> Have weewx installed on Raspberry pi as a new install using the setup.py
>>> method.
>>> Was trying to test the Belchertown skin after an install according to
>>> instructions.
>>> The home screen of Belchertown looks normal but the Reports, Graphs and
>>> Records tabs only bring up the following :
>>> Index of /home/weewx/public_html/graphs/
>>> NameSizeDate Modified
>>> index.html 
>>> 13.5 kB
>>> 11/20/20, 10:45:19 PM
>>>
>>> Weewx.conf is as follows for the StdReport section
>>> [StdReport]
>>>
>>> # Where the skins reside, relative to WEEWX_ROOT
>>> SKIN_ROOT = /home/weewx/skins/
>>>
>>> # Where the generated reports should go, relative to WEEWX_ROOT
>>> HTML_ROOT = /home/weewx/public_html/
>>>
>>> # The database binding indicates which data should be used in
>>> reports.
>>> data_binding = wx_binding
>>>
>>> # Whether to log a successful operation
>>> log_success = True
>>>
>>> # Whether to log an unsuccessful operation
>>> log_failure = False
>>>
>>> # Each of the following subsections defines a report that will be
>>> run.
>>> # See the customizing guide to change the units, plot types and line
>>> # colors, modify the fonts, display additional sensor data, and other
>>> # customizations. Many of those changes can be made here by
>>> overriding
>>> # parameters, or by modifying templates within the skin itself.
>>>
>>> [[SeasonsReport]]
>>> # The SeasonsReport uses the 'Seasons' skin, which contains the
>>> # images, templates and plots for the report.
>>> skin = Seasons
>>> enable = false
>>>
>>> [[SmartphoneReport]]
>>> # The SmartphoneReport uses the 'Smartphone' skin, and the
>>> images and
>>> # files are placed in a dedicated subdirectory.
>>> skin = Smartphone
>>> enable = false
>>> HTML_ROOT = public_html/smartphone
>>>
>>> [[MobileReport]]
>>> # The MobileReport uses the 'Mobile' skin, and the images and
>>> files
>>> # are placed in a dedicated subdirectory.
>>> skin = Mobile
>>> enable = false
>>> HTML_ROOT = public_html/mobile
>>>
>>> [[StandardReport]]
>>> # This is the old "Standard" skin. By default, it is not enabled.
>>> skin = Standard
>>> enable = false
>>> [[Belchertown]]
>>> skin = Belchertown
>>> HTML_ROOT = /home/weewx/public_html/Belchertown
>>> enable = true
>>>
>>> [[FTP]]
>>> # FTP'ing the results to a webserver is treated as just another
>>> report,
>>> # albeit one with an unusual report generator!
>>> skin = Ftp
>>>
>>> # If you wish to use FTP, set "enable" to "true", then
>>> # fill out the next four lines.
>>> # Use quotes around passwords to guard against parsing errors.
>>> enable = false
>>> user = replace_me
>>> password = replace_me
>>> server = replace_me# The ftp server name, e.g,
>>> www.myserver.org
>>> path = replace_me# The destination directory, e.g., /weather
>>>
>>> # Set to True for an FTP over TLS (FTPS) connection. Not all
>>> servers
>>> # support this.
>>> secure_ftp = False
>>>
>>> # To upload files from something other than what HTML_ROOT is set
>>> # to above, specify a different HTML_ROOT here.
>>> #HTML_ROOT = public_html
>>>
>>> # Most FTP servers use port 21
>>> port = 21
>>>
>>> # Set to 1 to use passive mode, zero for active mode
>>> passive = 1
>>>
>>> [[RSYNC]]
>>> # rsync'ing to a webserver is treated as just another report
>>> skin = Rsync
>>>
>>> # If you wish to use rsync, you must configure passwordless ssh
>>> using
>>> # public/private key authentication from the user account that
>>> weewx
>>> # runs to the user acco

[weewx-user] Syntax - install.py

[garrya...@gmail.com]

With the usual aplogies if this is documented somewhere and I didn't work 
hard enough to find it. . .

I'm working on getting my RSS/Atom feed extension (to the Belchertown skin) 
ready for release so want to fully utilize install.py.

Is there a description available for the syntax used in install.py?

Regards,

Garry

-- 
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/f76b1da4-72e9-4280-a831-bd47f4e773f0n%40googlegroups.com.

Re: [weewx-user] Syntax - install.py

[Tom Keffer]

Unfortunately, no. You'll have to follow the examples of the existing
installers.

On Thu, Dec 3, 2020 at 7:32 AM garrya...@gmail.com 
wrote:

> With the usual aplogies if this is documented somewhere and I didn't work
> hard enough to find it. . .
>
> I'm working on getting my RSS/Atom feed extension (to the Belchertown
> skin) ready for release so want to fully utilize install.py.
>
> Is there a description available for the syntax used in install.py?
>
> Regards,
>
> Garry
>
> --
> 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/f76b1da4-72e9-4280-a831-bd47f4e773f0n%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/CAPq0zEByPWQ7BQx85o%3D9b%3DudwWq-jvMM5hLLLhinNuhQebLrTQ%40mail.gmail.com.

Re: [weewx-user] Davis WeatherLink Live: Which driver is best?

[didier....@gmail.com]

The right value is "altimeter"
See 
specs 
https://www.davisinstruments.com/product_documents/weather/spec_sheets/6100_WL-Live_Spec_Sheet.pdf
Le mercredi 2 décembre 2020 à 14:24:37 UTC+1, kk44...@gmail.com a écrit :

> To my support question to the Davis support I finally received a reply. I 
> asked them why there are differences between console value and 
> WeatherLinkLive value and whether that is an accuracy issue. The first 
> answer was not helpful. So I confronted them with the statement about 
> different calculation. They took a long time to answer. 
>
> And from what I understand what they wrote the Davis support does not know 
> for sure. Who then?
>
> This was their answer:
> *Hello, *
> *That looks like it is the case. They are calculated different. *
> *To tell you the truth I was not aware of this. *
> ** * * *
> *Tom Raymond *
> *Technical Support Davis Instruments*
>
>
>
> didier@gmail.com schrieb am Sonntag, 22. November 2020 um 14:29:48 
> UTC+1:
>
>> thank's Florentin, I've just opened a ticket on Davis support, I will 
>> give you the result next week I hope.
>>
>> Le dim. 22 nov. 2020 à 14:24, flor...@pre-vost.fr  
>> a écrit :
>>
>>> Hi,
>>>
>>> I'm the author of WLLDriver on Github.
>>> Yes, I think that *altimeter *is the good value. But I suggest to 
>>> confirm that by directly ask Davis.
>>>
>>> Regards,
>>>
>>> Le samedi 21 novembre 2020 à 22:31:04 UTC+1, kk44...@gmail.com a écrit :
>>>
 I found that additional information at 
 https://www.manula.com/manuals/pws/davis-kb/1/en/topic/barometric-pressure-issues
 .

 There they say, that Davis uses different calculations in different 
 devices:

- VP2 and envoy consoles: sea-level pressure ("barometer", QFF)
- WeatherLinkLive: altimeter pressure ("altimeter", QNH)
- Vue consoles: user can choose between the two

 So it seems, the author of the "weatherlinkliveudp" driver read the 
 documentation most carefully. 

 And to confuse the user or something, in the LOOP data record, Davis 
 calls the value, what we learnt is altimeter, "bar_sea_level". 

 The archive record contains all the three values barometer, altimeter, 
 and pressure (I checked). Since the "weatherlinkliveudp" driver does not 
 provide a value for barometer, may be, WeeWX calculates it by itself.

 didier@gmail.com schrieb am Samstag, 21. November 2020 um 20:54:45 
 UTC+1:

> Thank's a lot
> I'm learning a lot of things with you
>
> Le sam. 21 nov. 2020 à 18:59, vince  a écrit :
>
>> On Saturday, November 21, 2020 at 9:31:11 AM UTC-8 kk44...@gmail.com 
>> wrote:
>>
>>> didier@gmail.com schrieb am Samstag, 21. November 2020 um 
>>> 16:09:22 UTC+1:
>>>
 Ooops, after 10 mn the 2 values have diverged (only 1 mbar)
 The explanation is that weatherlinkliveudp driver uses "altimeter" 
 and WLLDriver uses "barometer" for the station info

>>>
>>> That I do not understand. Does the driver only retrieves the 
>>> readings from the hardware, doesn't it? So, which way the driver can 
>>> influence which values is displayed?
>>>  
>>>
>>
>> There are two pressure-related elements provided by the Davis 
>> hardware.One is the pressure as reported by the sensor, the other is 
>> the pressure corrected to sea-level pressure based on your altitude.
>> The 
>> driver code defines which sensor values it uses for what generic weewx 
>> database element
>>
>> Both drivers map 'bar_absolute' from the hardware to weewx 'pressure' 
>> in the database.
>>
>> But...the two drivers map 'bar_sea_level' from the hardware to 
>> different elements in weewx's database.
>>
>>- WLLDriver.py   puts the value into 'barometer' in weewx
>>- weatherlinkliveudp.py  puts the value into 'altimeter' in weewx
>>
>> According to 
>> https://github.com/weewx/weewx/wiki/Barometer,-pressure,-and-altimeter, 
>> the correction math differs slightly, so I'd expect slight differences 
>> perhaps.  A difference of 1 mbar to me isn't something to worry too 
>> much.  
>> You're talking 0.1 percent offset.  The sensor itself isn't that precise 
>> to 
>> begin with.
>>
>>
>> -- 
>> 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/fccfe641-03d1-473f-910a-c1f0d7aa2cabn%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 

Re: [weewx-user] Syntax - install.py

[Garry A Lockyer]

Thanks!

That is what I’m doing.  :^))

Regards,

Garry Lockyer
C: +1.250.689.0686
E: ga...@lockyer.ca


> On Dec 3, 2020, at 07:37, Tom Keffer  wrote:
> 
> 
> Unfortunately, no. You'll have to follow the examples of the existing 
> installers.
> 
>> On Thu, Dec 3, 2020 at 7:32 AM garrya...@gmail.com  
>> wrote:
>> With the usual aplogies if this is documented somewhere and I didn't work 
>> hard enough to find it. . .
>> 
>> I'm working on getting my RSS/Atom feed extension (to the Belchertown skin) 
>> ready for release so want to fully utilize install.py.
>> 
>> Is there a description available for the syntax used in install.py?
>> 
>> Regards,
>> 
>> Garry
>> 
>> -- 
>> 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/f76b1da4-72e9-4280-a831-bd47f4e773f0n%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/CAPq0zEByPWQ7BQx85o%3D9b%3DudwWq-jvMM5hLLLhinNuhQebLrTQ%40mail.gmail.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/CA30B0E4-F910-47C6-9570-69BB394DC426%40gmail.com.

[weewx-user] simple python question, while adopting current.inc

[Vetti52]

After upgrading to Weewx version 4.2.0 I want to replace the deprecated 
type Beaufort by the new unit  $current.windSpeed.beaufort.
First, I replaced the previous evaluation in my accomodated current.inc, 
where I want to express the beaufort value by a literal description:
#if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
  #if $current.windSpeed.beaufort == '0'
#set $word_current_beaufort = 'Calm'
  #elif $current.windSpeed.beaufort == '1'
#set $word_current_beaufort = 'Light Air'
...
  #else
#set $word_current_beaufort = 'N/A'
  #end if
 
This construct does not result in errors, but always ends up displaying 
"N/A".

As gust seems not to be covered by the new unit $current.windSpeed.beaufort, 
I evaluate gust into beaufort still the old way, which is an adoption from 
another contribution in this forum. This works well:

  #if $unit.unit_type.windSpeed == 'mile_per_hour'
#set $current_gust_kts = $current.windGust.raw * 0.8689762
  #elif $unit.unit_type.windSpeed == 'km_per_hour'
#set $current_gust_kts = $current.windGust.raw * 0.539956
  #elif $unit.unit_type.windSpeed == 'meter_per_second'
#set $current_gust_kts = $current.windGust.raw * 1.943844
  #elif $unit.unit_type.windSpeed == 'knot'
#set $current_gust_kts = $current.windGust.raw
  #else
#set $current_gust_kts = 0
  #end if
  #if $current_gust_kts < 1
#set $current_gust_beaufort = 0
  #elif $current_gust_kts < 4
#set $current_gust_beaufort = 1
 ...
  #else
#set $current_gust_beaufort = 12
  #end if
#else
  #set $current_gust_beaufort = 'N/A'
#end if

As I am pretty naive with python, I do not understand, what is wrong with 
my solution. Python experts may lough about it. But, please, explain, how 
to solve my problem.

Thanks!

-- 
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/d84a6194-945c-4754-8ee9-a04421821429n%40googlegroups.com.

Re: [weewx-user] simple python question, while adopting current.inc

[Tom Keffer]

Your main problem is that $current.windSpeed.beaufort returns a number, not
a string. So, you want

#if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
  #if $current.windSpeed.beaufort == 0
#set $word_current_beaufort = 'Calm'
  #elif $current.windSpeed.beaufort == 1
#set $word_current_beaufort = 'Light Air'
...
  #else
#set $word_current_beaufort = 'N/A'
  #end if

You should be able to do $current.windGust.beaufort as well. However,
oceanographically, Beaufort's observations are related to the steady wind
speed, not gusts, so the results cannot be related to sea state through his
table.

-tk


On Thu, Dec 3, 2020 at 8:49 AM Vetti52  wrote:

> After upgrading to Weewx version 4.2.0 I want to replace the deprecated
> type Beaufort by the new unit  $current.windSpeed.beaufort.
> First, I replaced the previous evaluation in my accomodated current.inc,
> where I want to express the beaufort value by a literal description:
> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>   #if $current.windSpeed.beaufort == '0'
> #set $word_current_beaufort = 'Calm'
>   #elif $current.windSpeed.beaufort == '1'
> #set $word_current_beaufort = 'Light Air'
> ...
>   #else
> #set $word_current_beaufort = 'N/A'
>   #end if
>
> This construct does not result in errors, but always ends up displaying
> "N/A".
>
> As gust seems not to be covered by the new unit
> $current.windSpeed.beaufort, I evaluate gust into beaufort still the old
> way, which is an adoption from another contribution in this forum. This
> works well:
>
>   #if $unit.unit_type.windSpeed == 'mile_per_hour'
> #set $current_gust_kts = $current.windGust.raw * 0.8689762
>   #elif $unit.unit_type.windSpeed == 'km_per_hour'
> #set $current_gust_kts = $current.windGust.raw * 0.539956
>   #elif $unit.unit_type.windSpeed == 'meter_per_second'
> #set $current_gust_kts = $current.windGust.raw * 1.943844
>   #elif $unit.unit_type.windSpeed == 'knot'
> #set $current_gust_kts = $current.windGust.raw
>   #else
> #set $current_gust_kts = 0
>   #end if
>   #if $current_gust_kts < 1
> #set $current_gust_beaufort = 0
>   #elif $current_gust_kts < 4
> #set $current_gust_beaufort = 1
>  ...
>   #else
> #set $current_gust_beaufort = 12
>   #end if
> #else
>   #set $current_gust_beaufort = 'N/A'
> #end if
>
> As I am pretty naive with python, I do not understand, what is wrong with
> my solution. Python experts may lough about it. But, please, explain, how
> to solve my problem.
>
> Thanks!
>
> --
> 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/d84a6194-945c-4754-8ee9-a04421821429n%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/CAPq0zEAwYhkEnmZoYZN2Op6hbLVu5AV-V18rO8b72Cx9Htfeaw%40mail.gmail.com.

Re: [weewx-user] simple python question, while adopting current.inc

[Vetti52]

I tried the integer version already, with the same result. So, I assumed, 
that Beaufort is a string. Still no success.
At least current.windGust.beaufort works fine!
Thanks for the hint. 
Showing wind gust is just to compare the values to the red line in the 
windspeed/gust graph. When sailing, I am accustomed to trust on the waves, 
not on the wind meter.

tke...@gmail.com schrieb am Donnerstag, 3. Dezember 2020 um 17:59:37 UTC+1:

> Your main problem is that $current.windSpeed.beaufort returns a number, 
> not a string. So, you want
>
> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>   #if $current.windSpeed.beaufort == 0
> #set $word_current_beaufort = 'Calm'
>   #elif $current.windSpeed.beaufort == 1
> #set $word_current_beaufort = 'Light Air'
> ...
>   #else
> #set $word_current_beaufort = 'N/A'
>   #end if
>
> You should be able to do $current.windGust.beaufort as well. However, 
> oceanographically, Beaufort's observations are related to the steady wind 
> speed, not gusts, so the results cannot be related to sea state through his 
> table.
>
> -tk
>
>
> On Thu, Dec 3, 2020 at 8:49 AM Vetti52  wrote:
>
>> After upgrading to Weewx version 4.2.0 I want to replace the deprecated 
>> type Beaufort by the new unit  $current.windSpeed.beaufort.
>> First, I replaced the previous evaluation in my accomodated current.inc, 
>> where I want to express the beaufort value by a literal description:
>> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>>   #if $current.windSpeed.beaufort == '0'
>> #set $word_current_beaufort = 'Calm'
>>   #elif $current.windSpeed.beaufort == '1'
>> #set $word_current_beaufort = 'Light Air'
>> ...
>>   #else
>> #set $word_current_beaufort = 'N/A'
>>   #end if
>>  
>> This construct does not result in errors, but always ends up displaying 
>> "N/A".
>>
>> As gust seems not to be covered by the new unit 
>> $current.windSpeed.beaufort, I evaluate gust into beaufort still the old 
>> way, which is an adoption from another contribution in this forum. This 
>> works well:
>>
>>   #if $unit.unit_type.windSpeed == 'mile_per_hour'
>> #set $current_gust_kts = $current.windGust.raw * 0.8689762
>>   #elif $unit.unit_type.windSpeed == 'km_per_hour'
>> #set $current_gust_kts = $current.windGust.raw * 0.539956
>>   #elif $unit.unit_type.windSpeed == 'meter_per_second'
>> #set $current_gust_kts = $current.windGust.raw * 1.943844
>>   #elif $unit.unit_type.windSpeed == 'knot'
>> #set $current_gust_kts = $current.windGust.raw
>>   #else
>> #set $current_gust_kts = 0
>>   #end if
>>   #if $current_gust_kts < 1
>> #set $current_gust_beaufort = 0
>>   #elif $current_gust_kts < 4
>> #set $current_gust_beaufort = 1
>>  ...
>>   #else
>> #set $current_gust_beaufort = 12
>>   #end if
>> #else
>>   #set $current_gust_beaufort = 'N/A'
>> #end if
>>
>> As I am pretty naive with python, I do not understand, what is wrong with 
>> my solution. Python experts may lough about it. But, please, explain, how 
>> to solve my problem.
>>
>> Thanks!
>>
>> -- 
>> 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/d84a6194-945c-4754-8ee9-a04421821429n%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/819b6e9b-11d1-4b0e-aee6-e4f3726412f9n%40googlegroups.com.

Re: [weewx-user] simple python question, while adopting current.inc

[Tom Keffer]

Silly me. You need a .raw suffix:

#if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
  #if $current.windSpeed.beaufort.raw == 0
#set $word_current_beaufort = 'Calm'
  #elif $current.windSpeed.beaufort.raw == 1
#set $word_current_beaufort = 'Light Air'
...
  #else
#set $word_current_beaufort = 'N/A'
  #end if

On Thu, Dec 3, 2020 at 9:35 AM Vetti52  wrote:

> I tried the integer version already, with the same result. So, I assumed,
> that Beaufort is a string. Still no success.
> At least current.windGust.beaufort works fine!
> Thanks for the hint.
> Showing wind gust is just to compare the values to the red line in the
> windspeed/gust graph. When sailing, I am accustomed to trust on the waves,
> not on the wind meter.
>
> tke...@gmail.com schrieb am Donnerstag, 3. Dezember 2020 um 17:59:37
> UTC+1:
>
>> Your main problem is that $current.windSpeed.beaufort returns a number,
>> not a string. So, you want
>>
>> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>>   #if $current.windSpeed.beaufort == 0
>> #set $word_current_beaufort = 'Calm'
>>   #elif $current.windSpeed.beaufort == 1
>> #set $word_current_beaufort = 'Light Air'
>> ...
>>   #else
>> #set $word_current_beaufort = 'N/A'
>>   #end if
>>
>> You should be able to do $current.windGust.beaufort as well. However,
>> oceanographically, Beaufort's observations are related to the steady wind
>> speed, not gusts, so the results cannot be related to sea state through his
>> table.
>>
>> -tk
>>
>>
>> On Thu, Dec 3, 2020 at 8:49 AM Vetti52  wrote:
>>
>>> After upgrading to Weewx version 4.2.0 I want to replace the deprecated
>>> type Beaufort by the new unit  $current.windSpeed.beaufort.
>>> First, I replaced the previous evaluation in my accomodated current.inc,
>>> where I want to express the beaufort value by a literal description:
>>> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>>>   #if $current.windSpeed.beaufort == '0'
>>> #set $word_current_beaufort = 'Calm'
>>>   #elif $current.windSpeed.beaufort == '1'
>>> #set $word_current_beaufort = 'Light Air'
>>> ...
>>>   #else
>>> #set $word_current_beaufort = 'N/A'
>>>   #end if
>>>
>>> This construct does not result in errors, but always ends up displaying
>>> "N/A".
>>>
>>> As gust seems not to be covered by the new unit
>>> $current.windSpeed.beaufort, I evaluate gust into beaufort still the
>>> old way, which is an adoption from another contribution in this forum. This
>>> works well:
>>>
>>>   #if $unit.unit_type.windSpeed == 'mile_per_hour'
>>> #set $current_gust_kts = $current.windGust.raw * 0.8689762
>>>   #elif $unit.unit_type.windSpeed == 'km_per_hour'
>>> #set $current_gust_kts = $current.windGust.raw * 0.539956
>>>   #elif $unit.unit_type.windSpeed == 'meter_per_second'
>>> #set $current_gust_kts = $current.windGust.raw * 1.943844
>>>   #elif $unit.unit_type.windSpeed == 'knot'
>>> #set $current_gust_kts = $current.windGust.raw
>>>   #else
>>> #set $current_gust_kts = 0
>>>   #end if
>>>   #if $current_gust_kts < 1
>>> #set $current_gust_beaufort = 0
>>>   #elif $current_gust_kts < 4
>>> #set $current_gust_beaufort = 1
>>>  ...
>>>   #else
>>> #set $current_gust_beaufort = 12
>>>   #end if
>>> #else
>>>   #set $current_gust_beaufort = 'N/A'
>>> #end if
>>>
>>> As I am pretty naive with python, I do not understand, what is wrong
>>> with my solution. Python experts may lough about it. But, please, explain,
>>> how to solve my problem.
>>>
>>> Thanks!
>>>
>>> --
>>> 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/d84a6194-945c-4754-8ee9-a04421821429n%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/819b6e9b-11d1-4b0e-aee6-e4f3726412f9n%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/CAPq0zEA0k-%3DQ2FMnUW0Yj2r4DD8XisBmEV4qCVnENNw_GxpD3A%40ma

Re: [weewx-user] simple python question, while adopting current.inc

[Vetti52]

Right! That works nicely.

Well, I could have realized it. But perfect, that there is somone, that 
understands, what I have written.
Thanks a lot!

tke...@gmail.com schrieb am Donnerstag, 3. Dezember 2020 um 18:47:33 UTC+1:

> Silly me. You need a .raw suffix:
>
> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>   #if $current.windSpeed.beaufort.raw == 0
> #set $word_current_beaufort = 'Calm'
>   #elif $current.windSpeed.beaufort.raw == 1
>
> #set $word_current_beaufort = 'Light Air
> '
> ...
>   #else
> #set $word_current_beaufort = 'N/A'
>   #end if
> On Thu, Dec 3, 2020 at 9:35 AM Vetti52  wrote:
>
>> I tried the integer version already, with the same result. So, I assumed, 
>> that Beaufort is a string. Still no success.
>> At least current.windGust.beaufort works fine!
>> Thanks for the hint. 
>> Showing wind gust is just to compare the values to the red line in the 
>> windspeed/gust graph. When sailing, I am accustomed to trust on the waves, 
>> not on the wind meter.
>>
>> tke...@gmail.com schrieb am Donnerstag, 3. Dezember 2020 um 17:59:37 
>> UTC+1:
>>
>>> Your main problem is that $current.windSpeed.beaufort returns a number, 
>>> not a string. So, you want
>>>
>>> #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
>>>   #if $current.windSpeed.beaufort == 0
>>> #set $word_current_beaufort = 'Calm'
>>>   #elif $current.windSpeed.beaufort == 1
>>> #set $word_current_beaufort = 'Light Air'
>>> ...
>>>   #else
>>> #set $word_current_beaufort = 'N/A'
>>>   #end if
>>>
>>> You should be able to do $current.windGust.beaufort as well. However, 
>>> oceanographically, Beaufort's observations are related to the steady wind 
>>> speed, not gusts, so the results cannot be related to sea state through his 
>>> table.
>>>
>>> -tk
>>>
>>>
>>> On Thu, Dec 3, 2020 at 8:49 AM Vetti52  wrote:
>>>
 After upgrading to Weewx version 4.2.0 I want to replace the deprecated 
 type Beaufort by the new unit  $current.windSpeed.beaufort.
 First, I replaced the previous evaluation in my accomodated 
 current.inc, where I want to express the beaufort value by a literal 
 description:
 #if $varExists('day.windSpeed') and $current.windSpeed.raw is not None
   #if $current.windSpeed.beaufort == '0'
 #set $word_current_beaufort = 'Calm'
   #elif $current.windSpeed.beaufort == '1'
 #set $word_current_beaufort = 'Light Air'
 ...
   #else
 #set $word_current_beaufort = 'N/A'
   #end if
  
 This construct does not result in errors, but always ends up 
 displaying "N/A".

 As gust seems not to be covered by the new unit 
 $current.windSpeed.beaufort, I evaluate gust into beaufort still the 
 old way, which is an adoption from another contribution in this forum. 
 This 
 works well:

   #if $unit.unit_type.windSpeed == 'mile_per_hour'
 #set $current_gust_kts = $current.windGust.raw * 0.8689762
   #elif $unit.unit_type.windSpeed == 'km_per_hour'
 #set $current_gust_kts = $current.windGust.raw * 0.539956
   #elif $unit.unit_type.windSpeed == 'meter_per_second'
 #set $current_gust_kts = $current.windGust.raw * 1.943844
   #elif $unit.unit_type.windSpeed == 'knot'
 #set $current_gust_kts = $current.windGust.raw
   #else
 #set $current_gust_kts = 0
   #end if
   #if $current_gust_kts < 1
 #set $current_gust_beaufort = 0
   #elif $current_gust_kts < 4
 #set $current_gust_beaufort = 1
  ...
   #else
 #set $current_gust_beaufort = 12
   #end if
 #else
   #set $current_gust_beaufort = 'N/A'
 #end if

 As I am pretty naive with python, I do not understand, what is wrong 
 with my solution. Python experts may lough about it. But, please, explain, 
 how to solve my problem.

 Thanks!

 -- 
 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/d84a6194-945c-4754-8ee9-a04421821429n%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/819b6e9b-11d1-4b0e-aee6-e4f3726412f9n%40googlegroups.com
>>  
>>