Re: [weewx-user] Display METAR Data in Seasons 4.6.2

[Michael Bruski]

In reviewing the steps provided by MikeQ above, I see an issue with step 
3.  The search_list_extensions under the [[[CheetahGenerator]]] section 
should not be modified in weewx.conf but in skin.conf.  If you don't find 
the search_list_extensions line in that section, just add it.  The original 
author made it clear in his write-up that the METAR data will not be found 
by the skin unless you call the user.metargenerator.MyMetarSearch function 
from within the skin.  Also, the [MetarReport] block is appended at the end 
of the skin.conf file.  Notice single square bracket.  Your list of 
airports will be encapsulated in double square brackets following the 
section heading.  For example:

[MetarReport]
  refresh_interval = 5
  [[KBOI]]
  [[KONO]]
  ...

On Friday, June 2, 2023 at 6:44:12 PM UTC-4 Nate Bargmann wrote:

> * On 2023 02 Jun 15:48 -0500, Michael Bruski wrote:
> > Attached is a diff file for my current changes. Note that this also 
> > disables the request for TAF data as I request that separately using 
> > tafgenerator.py.
>
> I've no need to separate the two so I just modified line 101 in the
> original file as that seemed to be the only substantive change and I
> still get the same failure so I've shelved this idea until such time as
> it is fixed.
>
> - Nate
>
> -- 
> "The optimist proclaims that we live in the best of all
> possible worlds. The pessimist fears this is true."
> Web: https://www.n0nb.us
> Projects: https://github.com/N0NB
> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819
>
>

-- 
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/a5926a98-9810-4c8d-bf6a-cf161fba66ddn%40googlegroups.com.

Re: [weewx-user] Display METAR Data in Seasons 4.6.2

[Michael Bruski]

Attached is a diff file for my current changes.  Note that this also 
disables the request for TAF data as I request that separately using 
tafgenerator.py.
In Seasons/skin.conf just tack another couple lines at the end for example:

[TafReport]
  [[kbwi]]

and append ", user.tafgenerator.MyTafSearch" to the search_list_extensions 
in the same file.

I'll submit another pull request on github to get these changes in.

My taf.inc for the Seasons skin is also attached.
On Friday, June 2, 2023 at 4:07:24 PM UTC-4 Michael Bruski wrote:

> I actually did the python3 rewrite and provided it to the original author 
> to post on github.   I may have changed my local copy sometime later to fix 
> a problem with the URL but can't say for sure.  I have about 7 lines in my 
> generator that are commented out.  I know I didn't post further updates to 
> the author.   I could post my current code block for statsHTMLTable() here 
> but don't know how to go about getting it formatted correctly.
> Either that or send me your email address and I'll send it to you the file.
>
> I also created a tafgenerator based on the metargenerator so that I can 
> post that separately from the METAR blocks.
>
>
> On Friday, June 2, 2023 at 3:15:14 PM UTC-4 MikeQ wrote:
>
>> I'm running the same thing.  I don't think you will find anything in 
>> debug mode since metargenerator.py seems to be running and it logs to 
>> syslog directly.  I am not a python programmer, but I think you will need 
>> to add some additional "syslog.syslog(syslog.LOG_INFO,..." code to find 
>> out exactly what is happening in def statsHTMLTable(self, airport): when it 
>> tries to get the metar.
>>
>> On Friday, June 2, 2023 at 12:58:21 PM UTC-6 Nate Bargmann wrote:
>>
>>> * On 2023 02 Jun 13:31 -0500, MikeQ wrote: 
>>> > One more thought - what version of Python are you running? The 
>>> original 
>>> > weewx-metar code was written in 2018 for Python2 and was re-written 2 
>>> years 
>>> > ago for Python3. The current version in master on github is the 
>>> Python3 
>>> > version. 
>>>
>>> I am running on Amrbian (Debian) Bullseye which has Python 3.9.2. Would 
>>> the extension benefit from running Weewx with debug mode enabled? 
>>>
>>> - Nate 
>>>
>>> -- 
>>> "The optimist proclaims that we live in the best of all 
>>> possible worlds. The pessimist fears this is true." 
>>> Web: https://www.n0nb.us 
>>> Projects: https://github.com/N0NB 
>>> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 
>>>
>>>

-- 
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/76bc97d5-ccd5-4163-9e48-f683509b82fbn%40googlegroups.com.
# -*- coding: UTF-8 -*-
#
# Copyright (c) 2017-2018  Daniel Macías Perea 
#
# Distributed under the terms of the GNU GENERAL PUBLIC LICENSE
#
# Derived metargenerator.py by Michael Bruski (AJ9X)
# Runs under Python3 and WeeWx version 4
#
# None of the local airports in my immediate vacinity provide TAFs.
# This extension allows me to display a TAF(s) for larger Airport(s) around
# me that do provide them.  The results in this table are display separately
# from the metar table.  I have also modified the URL in my copy of
# my copy of metargenerator.py to turn off the check for TAFs.  Likewise,
# the URL in this generator turns off the check for METARs.
#
# To distinguish TAF backup files from METAR backup files, this generator
# will produce filenames in the form "icao.taf".  Use the data tag
# $iaco_taf to include them in your report just as you would use
# $iaco_metar to display a METAR.
#
"""Extends the Cheetah generator search list to add TAF data tables.
To use it, add this generator to search_list_extensions in skin.conf:

[CheetahGenerator]
search_list_extensions = user.tafgenerator.MyTafSearch


#
# HTML TAF obtained from aviationweather.gov
#
[TafReport]

# Taf Airports to generate
refresh_interval = 5

[[kbwi]]   # Create a new Cheetah tag which will have a _taf suffix: $kbwi_taf
[[kmdt]] 

"""

from weewx.cheetahgenerator import SearchList
from weewx.tags import TimespanBinder
from datetime import datetime
import time
import os.path
import weeutil.weeutil
import syslog
import random
import requests
import re

cl

Re: [weewx-user] Display METAR Data in Seasons 4.6.2

[Michael Bruski]

I actually did the python3 rewrite and provided it to the original author 
to post on github.   I may have changed my local copy sometime later to fix 
a problem with the URL but can't say for sure.  I have about 7 lines in my 
generator that are commented out.  I know I didn't post further updates to 
the author.   I could post my current code block for statsHTMLTable() here 
but don't know how to go about getting it formatted correctly.
Either that or send me your email address and I'll send it to you the file.

I also created a tafgenerator based on the metargenerator so that I can 
post that separately from the METAR blocks.


On Friday, June 2, 2023 at 3:15:14 PM UTC-4 MikeQ wrote:

> I'm running the same thing.  I don't think you will find anything in debug 
> mode since metargenerator.py seems to be running and it logs to syslog 
> directly.  I am not a python programmer, but I think you will need to add 
> some additional "syslog.syslog(syslog.LOG_INFO,..." code to find out 
> exactly what is happening in def statsHTMLTable(self, airport): when it 
> tries to get the metar.
>
> On Friday, June 2, 2023 at 12:58:21 PM UTC-6 Nate Bargmann wrote:
>
>> * On 2023 02 Jun 13:31 -0500, MikeQ wrote: 
>> > One more thought - what version of Python are you running? The original 
>> > weewx-metar code was written in 2018 for Python2 and was re-written 2 
>> years 
>> > ago for Python3. The current version in master on github is the Python3 
>> > version. 
>>
>> I am running on Amrbian (Debian) Bullseye which has Python 3.9.2. Would 
>> the extension benefit from running Weewx with debug mode enabled? 
>>
>> - Nate 
>>
>> -- 
>> "The optimist proclaims that we live in the best of all 
>> possible worlds. The pessimist fears this is true." 
>> Web: https://www.n0nb.us 
>> Projects: https://github.com/N0NB 
>> GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 
>>
>>

-- 
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/c2cbf0b9-8ab7-45cd-90f6-e49a1616f2dbn%40googlegroups.com.

Re: [weewx-user] Abridged summary of weewx-user@googlegroups.com - 5 updates in 1 topic

[Michael Bruski]

I posted a simple mod on here about two years ago that allows you to pull
the AFM vice the PFM which will give you a more accurate forecast for your
local area than a PFM will provide in most cases.


On Sun, Jul 10, 2022, 07:47  wrote:

> weewx-user@googlegroups.com
> 
>  Google
> Groups
> 
> 
> Today's topic summary
> View all topics
> 
>
>- National Weather Service location IDs
><#m_-5317155678677738781_group_thread_0> - 5 Updates
>
> National Weather Service location IDs
> 
> "wfs...@gmail.com" : Jul 09 11:22AM -0700
>
> Yes, Mike I think you're right. The weewx forecasting extension looks to
> be scraping those PFM reports for its data, so you can only choose from
> those zones where a PFM is generated. ...more
> 
> John Kline : Jul 09 12:08PM -0700
>
> > The newer api.weather.gov can return a lot of detailed forecast
> information for quite specific locations using gridpoints, but that's not
> integrated into weewx AFAIK.
>
> ...more
> 
> MikeQ : Jul 09 12:31PM -0700
>
> I dug through the NWS forecast page generated by lat/lon and there is an
> option to generate a tabular output, but that is not in PFM format. So, it
> looks like your are stuck with the classic PFM ...more
> 
> "wfs...@gmail.com" : Jul 09 01:26PM -0700
>
> Very neat, John/Chauncey! I think I was aware of your extension at some
> point, I have your website bookmarked as a really good model.
> But I don't see your extension listed in the wiki.
>
> Walt ...more
> 
> MIchael Cumbee : Jul 09 03:53PM -0700
>
> I finally found one that works but same as another user pointed out the
> only one I can get the extension to pull a forecast from is the Airport,
> there are actually about 12 point forecasts ...more
> 
> Back to top <#m_-5317155678677738781_digest_top>
> You received this digest because you're subscribed to updates for this
> group. You can change your settings on the group membership page
> 
> .
> To unsubscribe from this group and stop receiving emails from it send an
> email to weewx-user+unsubscr...@googlegroups.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/CALYY9-tY2o1xWfEeydvja2mE%3D%2BgUhEDDxhXiBLmK8Z0Dvbw_YA%40mail.gmail.com.

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

[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] Problem with Cheetah search_list_extensions?

[Michael Bruski]

Hi all,

I've been trying for a few weeks now (on-off) to get Daniel Macias's METAR 
extension working on my WeeWX setup but not having any success.  I'm 
running WeeWX v4.2.0 on an RPi0W with RaspIOS Buster.  I did a full system 
install so WeeWx configs and skins are in /etc/weewx.

Dec 17 20:31:24 server systemd[1]: Starting LSB: weewx weather system...
Dec 17 20:31:26 server weewx[15115] INFO __main__: Initializing weewx 
version 4.2.0
Dec 17 20:31:26 server weewx[15115] INFO __main__: Using Python 3.7.3 
(default, Jul 25 2020, 13:03:44) #012[GCC 8.3.0]
Dec 17 20:31:26 server weewx[15115] INFO __main__: Platform 
Linux-5.4.79+-armv6l-with-debian-10.7
Dec 17 20:31:26 server weewx[15115] INFO __main__: Locale is 'en_US.UTF-8'
Dec 17 20:31:26 server weewx[15115] INFO __main__: PID file is 
/var/run/weewx.pid
Dec 17 20:31:27 server weewx[15104]: Starting weewx weather system: weewx.

Following the directions on his web page 
(https://domoticproject.com/including-metar-reports-weewx/) I have done the 
following:

Downloaded and installed the metargenerator.py file to 
/usr/share/weewx/user.  I added a line to log (in syslog) when a metar is 
successfully retrieved from the web site.  Failures are already being 
logged.


Next I modified /etc/weewx/skins/Seasons/skin.conf in two places.  The 
first modification extends the CheetahGenerator search_list

# The CheetahGenerator creates files from templates.  This section
# specifies which files will be generated from which template.

[CheetahGenerator]

# Possible encodings are 'html_entities', 'utf8', or 'strict_ascii'
encoding = html_entitiese
*search_list_extensions = user.metargenerator.MyMetarSearch*

At the end the file I added this (I also copied this to the end of the 
weewx.conf file).






*# The list of airports to include in the METAR 
report:[MetarReport]refresh_interval = 5[[kdmw]][[kosh]]*


Finally, I added the following lines to 
/etc/weewx/skins/Seasons/index.html.tmpl to display results in the report:

'''
  

  METAR (Meteorological Aerodrome Report)



  

   KDMW - Carroll County Regional Airport
   $kdmw_metar
 
  
   KOSH - Wittman Regional Airport
   $kosh_metar

  



'''


After I restart and wait for the first report to be generated I get this in 
my syslog.  There is no indication that the search_list_extension 
user.metargenerator.MyMetarSearch was ever run and no METAR data is found 
in the report, just the tags for the individual airports ($kdmw_metar and 
$kosh_metar).

Dec 17 20:17:51 server weewx[14851] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx.sdb'
Dec 17 20:17:51 server weewx[14851] INFO weewx.manager: Starting backfill 
of daily summaries
Dec 17 20:17:51 server weewx[14851] INFO weewx.engine: Starting main packet 
loop.
Dec 17 20:17:51 server weewx[14851] INFO weewx.wxxtypes: Type beaufort has 
been deprecated. Use unit beaufort instead.
Dec 17 20:20:22 server weewx[14851] INFO weewx.manager: Added record 
2020-12-17 20:20:00 EST (1608254400) to database 'weewx.sdb'
Dec 17 20:20:23 server weewx[14851] INFO weewx.manager: Added record 
2020-12-17 20:20:00 EST (1608254400) to daily summary in 'weewx.sdb'
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: MainThread: 
Zambretti: starting thread
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: generating forecast for 2020-12-17 09:00:00 EST (1608213600)
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: MainThread: NWS: 
not yet time to do the forecast
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: using winddir from 2020-12-17 08:30:00 EST (1608211800) to 
2020-12-17 09:00:00 EST (1608213600)
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: using pressure from 2020-12-17 06:00:00 EST (1608202800) to 
2020-12-17 09:00:00 EST (1608213600)
Dec 17 20:20:23 server weewx[14851] DEBUG weewx.reportengine: Running 
reports for latest time in the database.
Dec 17 20:20:23 server weewx[14851] DEBUG weewx.reportengine: Running 
report 'SeasonsReport'
Dec 17 20:20:23 server weewx[14851] DEBUG weewx.manager: Daily summary 
version is 2
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: units=1 winddir=None pressure=30.07961402744 
first_p=30.04029032258066 last_p=30.1118675
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: pressure=1018.6124876429427 month=11 winddir=None 
trend=0.807950946880851 north=True
Dec 17 20:20:23 server weewx[14851] DEBUG user.forecast: ZambrettiThread: 
Zambretti: code is B
Dec 17 20:20:23 server weewx[14851] INFO user.forecast: ZambrettiThread: 
Zambretti: generated 1 forecast record
Dec 17 20:20:23 server weewx[14851] DEBUG weewx.reportengi

Re: [weewx-user] No PFM found for MEZ025

[Michael Bruski]

The URL you provided yields a number of duplicated LIDs each with different 
LAT/LONs and Elevations.  I see MEZ008, MEZ021, NHZ002, NHZ005, NHZ012 and 
NHZ015 listed twice.  NHZ011 is listed three times.  I didn't see any 
duplicates in the AFM from the same forecast office and MEZ025 is reported 
there.  If that is the location you want a forecast for, you may need to 
make a mod to your forecast.py in order to get that.  See my previous post 
about that mod.

On Monday, November 2, 2020 at 7:09:36 AM UTC-5 Michael Bruski wrote:

>
> MEZ024 is in that page twice with two different locations and elevations 
> posted?   Perhaps the forecast office made a mistake and one is a typo.  
> You can go to very bottom of the page and send an e-mail to the NWS 
> Internet Services Team to report that.
>
> On Monday, November 2, 2020 at 12:45:13 AM UTC-5 Greg from Oz wrote:
>
>>  lid = MEZ025
>>
>> should be 
>>
>>  lid = MEZ024
>>
>> as there is no MEZ025 just like the error messages says.just guessing.
>>
>>
>> On Monday, 2 November 2020 14:42:15 UTC+11, John Kline wrote:
>>
>>> NWS: no PFM found for MEZ025 in forecast from GYX
>>>
>>>
>>> Seems like a good error message to me.  MEZ025 is not where to be found 
>>> on the page.
>>>
>>> Did you mean MEZ024?
>>>
>>
>>> On Nov 1, 2020, at 7:15 PM, weather list  wrote:
>>>
>>> I have fthe forecast extension installed, with NWS set up as:
>>>
>>> [[NWS]]
>>> lid = MEZ025
>>> foid = GYX
>>>
>>> WeeWx log reports:
>>>
>>>
>>> Nov  1 22:04:27 raspberry-NUC62 weewx[27447] ERROR user.forecast: 
>>> NWSThread: NWS: no PFM found for MEZ025 in forecast from GYX
>>> Nov  1 22:05:18 raspberry-NUC62 weewx[27447] ERROR user.forecast: 
>>> NWSThread: NWS: no PFM found for MEZ025 in forecast from GYX
>>>
>>> And yet, this URL 
>>> <https://forecast.weather.gov/product.php?site=NWS&product=PFM&issuedby=GYX>
>>>  seems 
>>> to return PFM data. Am I making an obvious (not to me) error here?
>>>
>>> Point Forecast Matrices 
>>> Issued by NWS Portland, ME
>>>
>>> Current Version | Previous Version | Text Only | Print | Product List | 
>>> Glossary On
>>> Versions: 1 2 3 4 5 6 7 8 9 10 11 12
>>> 000
>>> FOUS51 KGYX 020103
>>> PFMGYX
>>>
>>> Point Forecast Matrices
>>> National Weather Service Gray ME
>>> 802 PM EST Sun Nov 1 2020
>>>
>>> *MEZ024*-020900-
>>> Portland-Cumberland ME
>>> 43.65N  70.32W Elev. 75 ft
>>> 802 PM EST Sun Nov 1 2020
>>>
>>> Date   11/01/20  Mon 11/02/20Tue 11/03/20   
>>>  Wed
>>> EST 3hrly 16 19 22 01 04 07 10 13 16 19 22 01 04 07 10 13 16 19 22 
>>> 01 04 07
>>> UTC 3hrly 21 00 03 06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 
>>> 06 09 12
>>>
>>> Min/Max  39  41  29  42 
>>>  26
>>> Temp50 48 42 39 40 40 35 32 31 31 30 30 37 41 39 33 31 
>>> 30 28 28
>>> Dewpt   47 45 39 34 29 25 21 18 20 21 22 23 21 18 18 18 18 
>>> 17 17 20
>>> RH  89 89 89 82 64 55 56 56 63 66 72 75 52 39 42 53 58 
>>> 58 63 71
>>> Wind dir S  W NW  W  W  W  W  W  W SW  W  W NW NW NW NW NW 
>>>  N NW  S
>>> Wind spd 8 10 10 12 20 27 26 19 12  9  6 10 14 14 12  6  5 
>>>  2  2  2
>>> Wind gust   35 40 44 32
>>> Clouds  OV OV B2 B1 B2 SC SC FW SC B2 B1 B1 SC SC FW FW FW 
>>> FW SC SC
>>> PoP 12hr 90  20  40  30 
>>>   5
>>> QPF 12hr   0.24   00.02   0 
>>>   0
>>> Snow 12hr 00-00   00-00   T
>>> Rain D  L
>>> Rain shwrs SS
>>> SnowshwrsS  C  C  C
>>> Wind chill   31 31 30 23 19 20 21 23 21 2831 27 25
>>> Min chill31301920212327   
>>>  2526
>>> Wind Y  Y  Y
>>>
>>>
>>> Date   11/04  Thu 11/05/20  Fri 11/06/20  Sat 11/07/20  Sun 
>>> 11/08/20
>>> EST 6hrly 13 19   01 07 13 19   01 07 13 19   

Re: [weewx-user] No PFM found for MEZ025

[Michael Bruski]

MEZ024 is in that page twice with two different locations and elevations 
posted?   Perhaps the forecast office made a mistake and one is a typo.  
You can go to very bottom of the page and send an e-mail to the NWS 
Internet Services Team to report that.

On Monday, November 2, 2020 at 12:45:13 AM UTC-5 Greg from Oz wrote:

>  lid = MEZ025
>
> should be 
>
>  lid = MEZ024
>
> as there is no MEZ025 just like the error messages says.just guessing.
>
>
> On Monday, 2 November 2020 14:42:15 UTC+11, John Kline wrote:
>
>> NWS: no PFM found for MEZ025 in forecast from GYX
>>
>>
>> Seems like a good error message to me.  MEZ025 is not where to be found 
>> on the page.
>>
>> Did you mean MEZ024?
>>
>
>> On Nov 1, 2020, at 7:15 PM, weather list  wrote:
>>
>> I have fthe forecast extension installed, with NWS set up as:
>>
>> [[NWS]]
>> lid = MEZ025
>> foid = GYX
>>
>> WeeWx log reports:
>>
>>
>> Nov  1 22:04:27 raspberry-NUC62 weewx[27447] ERROR user.forecast: 
>> NWSThread: NWS: no PFM found for MEZ025 in forecast from GYX
>> Nov  1 22:05:18 raspberry-NUC62 weewx[27447] ERROR user.forecast: 
>> NWSThread: NWS: no PFM found for MEZ025 in forecast from GYX
>>
>> And yet, this URL 
>>  
>> seems 
>> to return PFM data. Am I making an obvious (not to me) error here?
>>
>> Point Forecast Matrices 
>> Issued by NWS Portland, ME
>>
>> Current Version | Previous Version | Text Only | Print | Product List | 
>> Glossary On
>> Versions: 1 2 3 4 5 6 7 8 9 10 11 12
>> 000
>> FOUS51 KGYX 020103
>> PFMGYX
>>
>> Point Forecast Matrices
>> National Weather Service Gray ME
>> 802 PM EST Sun Nov 1 2020
>>
>> *MEZ024*-020900-
>> Portland-Cumberland ME
>> 43.65N  70.32W Elev. 75 ft
>> 802 PM EST Sun Nov 1 2020
>>
>> Date   11/01/20  Mon 11/02/20Tue 11/03/20 
>>Wed
>> EST 3hrly 16 19 22 01 04 07 10 13 16 19 22 01 04 07 10 13 16 19 22 01 
>> 04 07
>> UTC 3hrly 21 00 03 06 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 
>> 09 12
>>
>> Min/Max  39  41  29  42   
>>26
>> Temp50 48 42 39 40 40 35 32 31 31 30 30 37 41 39 33 31 30 
>> 28 28
>> Dewpt   47 45 39 34 29 25 21 18 20 21 22 23 21 18 18 18 18 17 
>> 17 20
>> RH  89 89 89 82 64 55 56 56 63 66 72 75 52 39 42 53 58 58 
>> 63 71
>> Wind dir S  W NW  W  W  W  W  W  W SW  W  W NW NW NW NW NW  N 
>> NW  S
>> Wind spd 8 10 10 12 20 27 26 19 12  9  6 10 14 14 12  6  5  2 
>>  2  2
>> Wind gust   35 40 44 32
>> Clouds  OV OV B2 B1 B2 SC SC FW SC B2 B1 B1 SC SC FW FW FW FW 
>> SC SC
>> PoP 12hr 90  20  40  30   
>> 5
>> QPF 12hr   0.24   00.02   0   
>> 0
>> Snow 12hr 00-00   00-00   T
>> Rain D  L
>> Rain shwrs SS
>> SnowshwrsS  C  C  C
>> Wind chill   31 31 30 23 19 20 21 23 21 2831 27 25
>> Min chill3130192021232725 
>>26
>> Wind Y  Y  Y
>>
>>
>> Date   11/04  Thu 11/05/20  Fri 11/06/20  Sat 11/07/20  Sun 
>> 11/08/20
>> EST 6hrly 13 19   01 07 13 19   01 07 13 19   01 07 13 19   01 07 13 
>> 19
>> UTC 6hrly 18 00   06 12 18 00   06 12 18 00   06 12 18 00   06 12 18 
>> 00
>>
>> Max/Min  48  3960  4562  4461  44   
>>  62
>> Temp  46 43   41 41 58 52   48 46 60 52   48 45 60 52   48 45 60 
>> 53
>> Dewpt 27 34   36 38 44 45   44 44 46 46   44 42 45 45   43 43 46 
>> 47
>> PWind dir S  SWSW  SWSW   W W   W   
>>  SW
>> Wind charLT  LTGN  LTLT  LTLT  LT   
>>  LT
>> Avg cloudsSC FW   FW FW FW SC   B1 B2 B1 SC   SC SC SC FW   SC SC SC 
>> SC
>> PoP 12hr  0   0 0   0 0   0 0   0 
>> 5
>>
>> $$
>>
>> -- 
>> 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...@googlegroups.com.
>>
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/20D9FD93-D7F6-4A14-9BD9-4228FC98EEE2%40gmail.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/e39111

[weewx-user] Re: Solution to some AFM forecast matrices fail to parse

[Michael Bruski]

My bad...

In the modified date2ts() function, the except line has a syntax error (I 
pulled the code snippet from the wrong forecast.py file, sorry).  It should 
read:

except ValueError:

not

   except ValueError, e:

Mike/AJ9X

On Friday, October 9, 2020 at 12:24:39 PM UTC-4 Michael Bruski wrote:

> Okay all.  Here is a working solution to the problem I encountered trying 
> to
> exploit Area Forecast Matrices for generating a forecast_table in WeeWX.
>
> Background.  If you live in an area served by a moderately sized or larger
> airport, the NWS most likely generates a Point Forecast Matrix (PFM) that
> fairly accurately predicts your future weather up to 7 days out.  If, on
> the other hand, you live in a rural/agri-business area like I do, where the
> PFMs are only published for airports more than an hours drive away you
> probably want to make use of an Area Forecast Matrix (AFM) for your 
> immediate
> area.  The actual data content of the PFM and AFM are identical with the
> exception of a few lines of header information.  In the PFM, this is lines
> two and three of the report which provide the Description (airport name) 
> and
> Location information (lat/lon/elev).  In the AFM, line two provides a zone 
> or
> county name and line three(/four/five?) lists cities or towns within the
> zone/county that are covered by the report.
>
> A problem existed with finding the DTG in some (not all) of the AFMs.  Here
> I'll present a solution to this issue that is rather trivial.  I won't bore
> you with the logic of the solution.  I assume you already have installed 
> the
> forecast extension.  You will need v3.4.0b10 if you are running WeeWX v4.
> Make sure it is producing a forecast panel in WeeWX using any valid 
> PFM/FOID
> combination.  Before proceeding, you will want to download the AFM dataset
> from your local NWS forecast office and make a note of the location ID 
> (LID)
> for your immediate area.
>
> The code for this extension is installed in /usr/share/weewx/user/.  The
> filename is forecast.py.  You need to edit this file using your favorite
> editor (mine happens to be nedit):
>
> shell prompt> cd /usr/share/weewx/user/
> shell prompt> sudo cp -p forecast.py forecast.py-dist
> shell prompt> sudo nedit forecast.py
>
> Somewhere around line 1900 is a function named 'date2ts'.  You will need to
> replace or modify that function so that it looks like this when you are 
> done:
>  
> def date2ts(tstr):
> """Convert NWS date string to timestamp in seconds.
> sample format: 418 PM EDT SAT MAY 11 2013
> """
>
> parts = tstr.split(' ')
> s = '%s %s %s %s %s' % (parts[0], parts[1], parts[4], parts[5], 
> parts[6])
> try:
> time_struct = time.strptime(s, "%I%M %p %b %d %Y")
> except ValueError, err:
> logerr('%s: %s is not a valid DTG' % (NWS_KEY, s))
> return None
> ts = time.mktime(time_struct)
> return int(ts)
>
>
> With the above changes made save your file.  Next you need to modify your
> existing options for the forecast extension in /etc/weewx/weewx.conf.
>
>
> [Forecast]
>⁞ 
> [[NWS]]
> lid = 'Your location ID'
> foid = 'Forecast Office ID'
> url = 
> http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby='Forecast
>  
> Office ID'
> interval = 3600
>
> Note that I opt to capture an update every hour vice the default of 3 hour 
> so
> don't include the interval parameter if you're happy with the default.  
> Save
> your file when the changes are complete.  Now simply run the following 
> commands:
>
>
> shell prompt> sudo /etc/init.d/weewx stop
> shell prompt> sudo rm /var/lib/weewx/forecast.sdb
> shell prompt> sudo /etc/init.d/weewx start
> shell prompt> sudo tail -n 100 -f /var/log/syslog
>
> Check the output from syslog to see that it picked up your changes and that
> the forecast thread is running (no python error messages).  At this point,
> you will need to wait for the next report cycle to see that the AFM dataset
> is downloaded and that forecast records are written to the database. This
> typically happens 2 to 3 minutes after the beginning of the report cycle on
> my RPi4.  The forecast panel in WeeWX will not propagate until the 
> following
> report cycle completes (about 5 minutes after the forecast records are
> written).
>
> That's all there is to it.  With this change you can exploit either PFM or 
> AFM
> products from the NWS.
>
> Mike/AJ9X
>
>

-- 
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/0ea0559a-e216-410a-8a5d-1dd9267511e1n%40googlegroups.com.

[weewx-user] Solution to some AFM forecast matrices fail to parse

[Michael Bruski]

Okay all.  Here is a working solution to the problem I encountered trying to
exploit Area Forecast Matrices for generating a forecast_table in WeeWX.

Background.  If you live in an area served by a moderately sized or larger
airport, the NWS most likely generates a Point Forecast Matrix (PFM) that
fairly accurately predicts your future weather up to 7 days out.  If, on
the other hand, you live in a rural/agri-business area like I do, where the
PFMs are only published for airports more than an hours drive away you
probably want to make use of an Area Forecast Matrix (AFM) for your 
immediate
area.  The actual data content of the PFM and AFM are identical with the
exception of a few lines of header information.  In the PFM, this is lines
two and three of the report which provide the Description (airport name) and
Location information (lat/lon/elev).  In the AFM, line two provides a zone 
or
county name and line three(/four/five?) lists cities or towns within the
zone/county that are covered by the report.

A problem existed with finding the DTG in some (not all) of the AFMs.  Here
I'll present a solution to this issue that is rather trivial.  I won't bore
you with the logic of the solution.  I assume you already have installed the
forecast extension.  You will need v3.4.0b10 if you are running WeeWX v4.
Make sure it is producing a forecast panel in WeeWX using any valid PFM/FOID
combination.  Before proceeding, you will want to download the AFM dataset
from your local NWS forecast office and make a note of the location ID (LID)
for your immediate area.

The code for this extension is installed in /usr/share/weewx/user/.  The
filename is forecast.py.  You need to edit this file using your favorite
editor (mine happens to be nedit):

shell prompt> cd /usr/share/weewx/user/
shell prompt> sudo cp -p forecast.py forecast.py-dist
shell prompt> sudo nedit forecast.py

Somewhere around line 1900 is a function named 'date2ts'.  You will need to
replace or modify that function so that it looks like this when you are 
done:
 
def date2ts(tstr):
"""Convert NWS date string to timestamp in seconds.
sample format: 418 PM EDT SAT MAY 11 2013
"""

parts = tstr.split(' ')
s = '%s %s %s %s %s' % (parts[0], parts[1], parts[4], parts[5], 
parts[6])
try:
time_struct = time.strptime(s, "%I%M %p %b %d %Y")
except ValueError, err:
logerr('%s: %s is not a valid DTG' % (NWS_KEY, s))
return None
ts = time.mktime(time_struct)
return int(ts)


With the above changes made save your file.  Next you need to modify your
existing options for the forecast extension in /etc/weewx/weewx.conf.


[Forecast]
   ⁞ 
[[NWS]]
lid = 'Your location ID'
foid = 'Forecast Office ID'
url = 
http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby='Forecast
 
Office ID'
interval = 3600

Note that I opt to capture an update every hour vice the default of 3 hour 
so
don't include the interval parameter if you're happy with the default.  Save
your file when the changes are complete.  Now simply run the following 
commands:


shell prompt> sudo /etc/init.d/weewx stop
shell prompt> sudo rm /var/lib/weewx/forecast.sdb
shell prompt> sudo /etc/init.d/weewx start
shell prompt> sudo tail -n 100 -f /var/log/syslog

Check the output from syslog to see that it picked up your changes and that
the forecast thread is running (no python error messages).  At this point,
you will need to wait for the next report cycle to see that the AFM dataset
is downloaded and that forecast records are written to the database. This
typically happens 2 to 3 minutes after the beginning of the report cycle on
my RPi4.  The forecast panel in WeeWX will not propagate until the following
report cycle completes (about 5 minutes after the forecast records are
written).

That's all there is to it.  With this change you can exploit either PFM or 
AFM
products from the NWS.

Mike/AJ9X

-- 
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/8152f127-0c97-4602-b1ca-213ca36543d2n%40googlegroups.com.

Re: [weewx-user] Parsing some NWS Area Forecast Matrices fails

[Michael Bruski]

I forgot to mention that the AFM format is correct and the extension will 
handle it (in this particular case for MDZ005 and for MDZ006) if I force 
the scanner/parser to ignore the 'Including' line.  I'm pretty sure that 
'cheat' will fail though on MDZ013 and MDZ014 in that same dataset.  
Perhaps need to check the line splits to 7 tokens and the first token is a 
numeric value or a numeric value less than 1300 before passing it to 
date2ts() and not worry about first token is 'Including'?

Mike/AJ9X

On Thursday, October 8, 2020 at 1:49:03 PM UTC-4 Michael Bruski wrote:

>
> I attached a text file containing one of the latest results from URL 
> https://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX
> .
>
> These are the options I have configured in my weewx.conf file:
>
> # Options for extension 'forecast'
> [Forecast]
> data_binding = forecast_binding
> [[XTide]]
> location = "INSERT_LOCATION_HERE (e.g., Boston)"
> [[Zambretti]]
> hemisphere = NORTH
> [[NWS]]
> lid = "MDZ005"
> foid = "LWX"
> url = 
> http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX
> [[WU]]
> api_key = INSERT_WU_API_KEY_HERE
> [[OWM]]
> api_key = INSERT_OWM_API_KEY_HERE
> [[UKMO]]
> api_key = INSERT_UKMO_API_KEY_HERE
> location = INSERT_UK_LOCATION_HERE
> [[Aeris]]
> client_id = INSERT_AERIS_CLIENT_ID_HERE
> client_secret = INSERT_AERIS_CLIENT_SECRET_HERE
> [[WWO]]
> api_key = INSERT_WWO_API_KEY_HERE
> [[DS]]
> api_key = INSERT_DS_API_KEY_HERE
>
> I appreciate any effort you put into resolving this.  It will be nice to 
> see the extension handle these instead of silently failing.
>
> Also, a thank you to the other group member who supplied a link to the 
> AFM_format.pdf document.  I mentioned to Chris at NWS Balt/Wash this 
> morning that it is difficult to find any specifications for the AFM/PFM on 
> the NWS web site.  Perhaps that will get addressed in the future as well.
>
> Mike/AJ9X
>
> On Thursday, October 8, 2020 at 11:24:50 AM UTC-4 jo...@johnkline.com 
> wrote:
>
>> This is all very helpful.
>>
>> Would you please send your NWS configuration for the problem AFM report 
>> as well as sample output from the URL you specified that the extension 
>> chokes on?
>>
>> Have you determined if the output is valid as specified by the AFM format 
>> doc?
>>
>> I’ll add proper support for AFM in the coming week or so.
>>
>> Cheers,
>> John
>>
>> On Oct 8, 2020, at 6:08 AM, Michael Bruski  wrote:
>>
>> 
>>
>> I queried the NWS Baltimore/Washington D.D. forecast office about the 
>> differences between AFM and PFM and received this reply:
>>
>>  Hello, 
>>
>>  Thanks for writing.  The AFMs and PFMs are set to a national 
>> standard. So they should be the same across all the forecast offices. 
>>
>>  Our Directive that talks about these products, as well as links to 
>> format decoding, are in this NWS Directive 
>> <https://www.nws.noaa.gov/directives/sym/pd01005003curr.pdf> between 
>> pages 10-12. 
>>
>>  Hope that helps. 
>>
>>  Chris Strong 
>>  NWS Baltimore/Washington 
>>
>> The reference Chris sites contains links to AFM/PFM format PDFs and the 
>> element specifications PDF for both reports.  The only difference between 
>> the two that I could detect was in lines 2 and 3 of the report (Description 
>> and Location in the PFM;  zone and included cities in the AFM).
>>
>> On Wednesday, October 7, 2020 at 8:28:01 PM UTC-4 etji...@gmail.com 
>> wrote:
>>
>>> Here is the spec on AFMs from the NWS:
>>> https://www.weather.gov/media/notification/dir/AFM_Format.pdf
>>>
>>>
>>> On Wed, Oct 7, 2020 at 5:57 PM John Kline  wrote:
>>>
>>>> Absent a spec on area forecast matrices, and absent any problem reports 
>>>> on point forecast matrices, there isn’t much to go on here.
>>>>
>>>> On Oct 7, 2020, at 2:35 PM, Michael Bruski  
>>>> wrote:
>>>>
>>>> 
>>>> Hi John,
>>>>
>>>> I've looked at several forecast matrices from my local and surrounding 
>>>> NWS forecast offices and haven't seen anything format wise that would lead 
>>>> me to think they would cause a problem for the forecast extension.

Re: [weewx-user] Parsing some NWS Area Forecast Matrices fails

[Michael Bruski]

I attached a text file containing one of the latest results from URL 
https://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX.

These are the options I have configured in my weewx.conf file:

# Options for extension 'forecast'
[Forecast]
data_binding = forecast_binding
[[XTide]]
location = "INSERT_LOCATION_HERE (e.g., Boston)"
[[Zambretti]]
hemisphere = NORTH
[[NWS]]
lid = "MDZ005"
foid = "LWX"
url = 
http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX
[[WU]]
api_key = INSERT_WU_API_KEY_HERE
[[OWM]]
api_key = INSERT_OWM_API_KEY_HERE
[[UKMO]]
api_key = INSERT_UKMO_API_KEY_HERE
location = INSERT_UK_LOCATION_HERE
[[Aeris]]
client_id = INSERT_AERIS_CLIENT_ID_HERE
client_secret = INSERT_AERIS_CLIENT_SECRET_HERE
[[WWO]]
api_key = INSERT_WWO_API_KEY_HERE
[[DS]]
api_key = INSERT_DS_API_KEY_HERE

I appreciate any effort you put into resolving this.  It will be nice to 
see the extension handle these instead of silently failing.

Also, a thank you to the other group member who supplied a link to the 
AFM_format.pdf document.  I mentioned to Chris at NWS Balt/Wash this 
morning that it is difficult to find any specifications for the AFM/PFM on 
the NWS web site.  Perhaps that will get addressed in the future as well.

Mike/AJ9X

On Thursday, October 8, 2020 at 11:24:50 AM UTC-4 jo...@johnkline.com wrote:

> This is all very helpful.
>
> Would you please send your NWS configuration for the problem AFM report as 
> well as sample output from the URL you specified that the extension chokes 
> on?
>
> Have you determined if the output is valid as specified by the AFM format 
> doc?
>
> I’ll add proper support for AFM in the coming week or so.
>
> Cheers,
> John
>
> On Oct 8, 2020, at 6:08 AM, Michael Bruski  wrote:
>
> 
>
> I queried the NWS Baltimore/Washington D.D. forecast office about the 
> differences between AFM and PFM and received this reply:
>
>  Hello, 
>
>  Thanks for writing.  The AFMs and PFMs are set to a national 
> standard. So they should be the same across all the forecast offices. 
>
>  Our Directive that talks about these products, as well as links to 
> format decoding, are in this NWS Directive 
> <https://www.nws.noaa.gov/directives/sym/pd01005003curr.pdf> between 
> pages 10-12. 
>
>  Hope that helps. 
>
>  Chris Strong 
>  NWS Baltimore/Washington 
>
> The reference Chris sites contains links to AFM/PFM format PDFs and the 
> element specifications PDF for both reports.  The only difference between 
> the two that I could detect was in lines 2 and 3 of the report (Description 
> and Location in the PFM;  zone and included cities in the AFM).
>
> On Wednesday, October 7, 2020 at 8:28:01 PM UTC-4 etji...@gmail.com wrote:
>
>> Here is the spec on AFMs from the NWS:
>> https://www.weather.gov/media/notification/dir/AFM_Format.pdf
>>
>>
>> On Wed, Oct 7, 2020 at 5:57 PM John Kline  wrote:
>>
>>> Absent a spec on area forecast matrices, and absent any problem reports 
>>> on point forecast matrices, there isn’t much to go on here.
>>>
>>> On Oct 7, 2020, at 2:35 PM, Michael Bruski  wrote:
>>>
>>> 
>>> Hi John,
>>>
>>> I've looked at several forecast matrices from my local and surrounding 
>>> NWS forecast offices and haven't seen anything format wise that would lead 
>>> me to think they would cause a problem for the forecast extension.  I have 
>>> selected several different AFMs and see they parse fine.  But I ran into 
>>> this issue with my local AFM and spent several hours trying to track down 
>>> the cause.   The issue is not with the matrix itself but with text 
>>> preceeding the DTG.   To test further, I put a cheap hack into the parse 
>>> loop so that date2ts() isn't called if the first word in 'line' is 
>>> 'Including'.  This actually works (in this specific instance) and a valid 
>>> forecast is produced.  What other lines of text might NWS put in the header 
>>> preceeding the DTG, I just don't know.The URLs mentioned in forecast.py 
>>> are dead links so I couldn't find any specifics on decoding the reports.
>>>
>>> I'm not terribly comfortable programming in python so I'm not sure the 
>>> best approach to work this issue but sending bad data to time.mktime() via 
>>> date2ts() is probably bad unless there is a way to trap the error.  Not 
>>&

Re: [weewx-user] Parsing some NWS Area Forecast Matrices fails

[Michael Bruski]

I queried the NWS Baltimore/Washington D.D. forecast office about the 
differences between AFM and PFM and received this reply:

 Hello, 

 Thanks for writing.  The AFMs and PFMs are set to a national standard. 
So they should be the same across all the forecast offices. 

 Our Directive that talks about these products, as well as links to 
format decoding, are in this NWS Directive 
<https://www.nws.noaa.gov/directives/sym/pd01005003curr.pdf> between pages 
10-12. 

 Hope that helps. 

 Chris Strong 
 NWS Baltimore/Washington 

The reference Chris sites contains links to AFM/PFM format PDFs and the 
element specifications PDF for both reports.  The only difference between 
the two that I could detect was in lines 2 and 3 of the report (Description 
and Location in the PFM;  zone and included cities in the AFM).

On Wednesday, October 7, 2020 at 8:28:01 PM UTC-4 etji...@gmail.com wrote:

> Here is the spec on AFMs from the NWS:
> https://www.weather.gov/media/notification/dir/AFM_Format.pdf
>
>
> On Wed, Oct 7, 2020 at 5:57 PM John Kline  wrote:
>
>> Absent a spec on area forecast matrices, and absent any problem reports 
>> on point forecast matrices, there isn’t much to go on here.
>>
>> On Oct 7, 2020, at 2:35 PM, Michael Bruski  wrote:
>>
>> 
>> Hi John,
>>
>> I've looked at several forecast matrices from my local and surrounding 
>> NWS forecast offices and haven't seen anything format wise that would lead 
>> me to think they would cause a problem for the forecast extension.  I have 
>> selected several different AFMs and see they parse fine.  But I ran into 
>> this issue with my local AFM and spent several hours trying to track down 
>> the cause.   The issue is not with the matrix itself but with text 
>> preceeding the DTG.   To test further, I put a cheap hack into the parse 
>> loop so that date2ts() isn't called if the first word in 'line' is 
>> 'Including'.  This actually works (in this specific instance) and a valid 
>> forecast is produced.  What other lines of text might NWS put in the header 
>> preceeding the DTG, I just don't know.The URLs mentioned in forecast.py 
>> are dead links so I couldn't find any specifics on decoding the reports.
>>
>> I'm not terribly comfortable programming in python so I'm not sure the 
>> best approach to work this issue but sending bad data to time.mktime() via 
>> date2ts() is probably bad unless there is a way to trap the error.  Not 
>> meant to criticize...  just my thoughts on how to make it better.
>>
>> Mike/AJ9X
>>
>> On Wednesday, October 7, 2020 at 4:24:56 PM UTC-4 jo...@johnkline.com 
>> wrote:
>>
>>> Perhaps Area Forecast Matrix responses can’t be treated just like Point 
>>> Forecast Matrix responses.  AFMs are only supported to the extent that they 
>>> provide an identically formatted response as the PFM response.
>>>
>>> What do you know about AFMs and the differences between them and PFMs?
>>>
>>> On Oct 7, 2020, at 12:18 PM, Michael Bruski  
>>> wrote:
>>>
>>> 
>>>
>>>
>>> Hi all,
>>>
>>> First of all, I am running WeeWX 4.1.1 with forecast extension 3.4.0b10.
>>>
>>> I had recently managed to use a Area Forecast Matrix for one location 
>>> and that is working fine.   Recently I tried to setup a second location to 
>>> use the AFM (different LID and FOID) and it fails to get a forecast even 
>>> though I see it in the web browser using the URL that forecast.py uses.  
>>> After careful application of some trace print statements, I see the 
>>> forecast is succesfully download from the FOID and that the forecast for 
>>> the specified LID is also located and extracted but nothing gets parsed.  
>>> Below is a copy of my trace output from the log:
>>>
>>> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
>>> forecast downloaded successfully from '
>>> http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX
>>> '
>>> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
>>> 'MDZ005-072100-'
>>> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
>>> 'Carroll-'
>>> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
>>> 'Including the cities of Eldersburg and Westminster'
>>> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
>>> '137 PM

Re: [weewx-user] Parsing some NWS Area Forecast Matrices fails

[Michael Bruski]

Hi John,

I've looked at several forecast matrices from my local and surrounding NWS 
forecast offices and haven't seen anything format wise that would lead me 
to think they would cause a problem for the forecast extension.  I have 
selected several different AFMs and see they parse fine.  But I ran into 
this issue with my local AFM and spent several hours trying to track down 
the cause.   The issue is not with the matrix itself but with text 
preceeding the DTG.   To test further, I put a cheap hack into the parse 
loop so that date2ts() isn't called if the first word in 'line' is 
'Including'.  This actually works (in this specific instance) and a valid 
forecast is produced.  What other lines of text might NWS put in the header 
preceeding the DTG, I just don't know.The URLs mentioned in forecast.py 
are dead links so I couldn't find any specifics on decoding the reports.

I'm not terribly comfortable programming in python so I'm not sure the best 
approach to work this issue but sending bad data to time.mktime() via 
date2ts() is probably bad unless there is a way to trap the error.  Not 
meant to criticize...  just my thoughts on how to make it better.

Mike/AJ9X

On Wednesday, October 7, 2020 at 4:24:56 PM UTC-4 jo...@johnkline.com wrote:

> Perhaps Area Forecast Matrix responses can’t be treated just like Point 
> Forecast Matrix responses.  AFMs are only supported to the extent that they 
> provide an identically formatted response as the PFM response.
>
> What do you know about AFMs and the differences between them and PFMs?
>
> On Oct 7, 2020, at 12:18 PM, Michael Bruski  wrote:
>
> 
>
>
> Hi all,
>
> First of all, I am running WeeWX 4.1.1 with forecast extension 3.4.0b10.
>
> I had recently managed to use a Area Forecast Matrix for one location and 
> that is working fine.   Recently I tried to setup a second location to use 
> the AFM (different LID and FOID) and it fails to get a forecast even though 
> I see it in the web browser using the URL that forecast.py uses.  After 
> careful application of some trace print statements, I see the forecast is 
> succesfully download from the FOID and that the forecast for the specified 
> LID is also located and extracted but nothing gets parsed.  Below is a copy 
> of my trace output from the log:
>
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> forecast downloaded successfully from '
> http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX
> '
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'MDZ005-072100-'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Carroll-'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Including the cities of Eldersburg and Westminster'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> '137 PM EDT Wed Oct 7 2020'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Date Wed 10/07/20Thu 10/08/20Fri 
> 10/09/20'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'EDT 3hrly 05 08 11 14 17 20 23 02 05 08 11 14 17 20 23 02 05 08 11 14 
> 17 20'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'UTC 3hrly 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 15 18 
> 21 00'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Max/Min75 77 8047 48 5265 67 7042 44 4868 
> 70 73'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Temp   76 76 68 61 56 51 50 60 65 64 55 50 47 45 45 61 68 
> 67 59'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Dewpt  52 52 53 50 48 46 45 45 43 42 43 42 41 40 41 45 45 
> 46 47'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'RH 43 43 59 67 74 83 83 58 45 45 64 74 79 82 86 56 43 
> 47 64'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Wind dirW  W NW NW NW NW NW NW NW NW NW NW  W  W  W SW SW 
> SW  S'
> Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
> 'Wind spd   19 17 10  6  5  5  6 11 12 10  5  3  1  2  1  4  6  
> 8  4'
> Oct  7 14:36:45 server weewx[3014] INFO use

[weewx-user] Parsing some NWS Area Forecast Matrices fails

[Michael Bruski]

Hi all,

First of all, I am running WeeWX 4.1.1 with forecast extension 3.4.0b10.

I had recently managed to use a Area Forecast Matrix for one location and 
that is working fine.   Recently I tried to setup a second location to use 
the AFM (different LID and FOID) and it fails to get a forecast even though 
I see it in the web browser using the URL that forecast.py uses.  After 
careful application of some trace print statements, I see the forecast is 
succesfully download from the FOID and that the forecast for the specified 
LID is also located and extracted but nothing gets parsed.  Below is a copy 
of my trace output from the log:

Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
forecast downloaded successfully from 
'http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt&issuedby=LWX'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'MDZ005-072100-'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Carroll-'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Including the cities of Eldersburg and Westminster'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: '137 
PM EDT Wed Oct 7 2020'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Date Wed 10/07/20Thu 10/08/20Fri 
10/09/20'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'EDT 
3hrly 05 08 11 14 17 20 23 02 05 08 11 14 17 20 23 02 05 08 11 14 17 20'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'UTC 
3hrly 09 12 15 18 21 00 03 06 09 12 15 18 21 00 03 06 09 12 15 18 21 00'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Max/Min75 77 8047 48 5265 67 7042 44 4868 
70 73'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Temp   76 76 68 61 56 51 50 60 65 64 55 50 47 45 45 61 68 
67 59'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Dewpt  52 52 53 50 48 46 45 45 43 42 43 42 41 40 41 45 45 
46 47'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'RH 43 43 59 67 74 83 83 58 45 45 64 74 79 82 86 56 43 
47 64'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Wind dirW  W NW NW NW NW NW NW NW NW NW NW  W  W  W SW SW 
SW  S'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Wind spd   19 17 10  6  5  5  6 11 12 10  5  3  1  2  1  4  6  
8  4'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Wind gust  33 31'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Clouds CL CL SC FW FW CL CL FW CL CL CL CL FW FW FW FW FW 
FW SC'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'PoP 
12hr 20  20   0   0   0'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'QPF 
12hr  0   0   0   0   0'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Rain shwrs S  S'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Date  Sat 10/10/20  Sun 10/11/20  Mon 10/12/20  Tue 10/13/20'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'EDT 
6hrly 02 08 14 20   02 08 14 20   02 08 14 20   02 08 14 20'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'UTC 
6hrly 06 12 18 00   06 12 18 00   06 12 18 00   06 12 18 00'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: ''
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Min/Max  5475  5669  5366  5468'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Temp  55 56 73 66   61 58 66 60   56 55 63 59   56 56 65 61'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Dewpt 50 54 59 60   59 56 55 54   54 53 56 56   56 56 58 57'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'PWind dir SSW  SWSE   E E   ESE'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 
'Wind charLTGN  LTLT  GNGN  LTLT'
Oct  7 14:36:45 server weewx[3014] INFO user.forecast: NWSThread: NWS: 'Avg 
cloudsSC B1 B1 B1   B1 B1 B1 B1   B2 B2 B2 B2   B2 B2 B2 B1'
Oct  7 14:36:45 server weewx[3014] INFO user.

Re: [weewx-user] Feature request for forecast extension

[Michael Bruski]

Thanks for that hint John.  It does the trick.  I guess I should have taken
a second look at the docs.

Mike

On Sat, Sep 26, 2020, 23:24 John Kline  wrote:

> 
> I don’t mind adding it; but have you tried specifying the URL in
> weewx.conf:
>
> lid=XX
> foid=XXX
> url =
> http://forecast.weather.gov/product.php?site=NWS&product=AFM&format=txt
> <http://forecast.weather.gov/product.php?site=NWS&product=PFM&format=txt>
>
> If you only changed PFM to AFM, the above should work.
>
> Let me know.
>
> Cheers,
> John
>
> On Sep 26, 2020, at 4:40 PM, Michael Bruski 
> wrote:
>
> 
> Hi John,
>
> I'm trying to run my remote on a RPi4B near Galena, MD 21635.   The MDZ012
> LID covers Kent county, MD where Galena is located.
>
> I'm running WeeWX v4.1.1 and weewx-forecast-3.4.0b10.zip (after
> discovering that 3.4.0B1 wouldn't work).
>
> As a work around, I tweaked the default URLs for NWS in
> /usr/share/weewx/user/forecast.py to substitute 'AFM' for 'PFM' to get the
> Area Forecast Matrix and that is working fine.  My LID is found
> and I get the local forecast I'm looking for.   However, I may do a couple
> more deploys and it would be nice to have the ability to make this
> selection via the weewx.conf file instead of tweaking the source code.
>
> I'm considering doing the same for my home location in Carroll county MD
> because I sometimes see some not so insignificant differences between the
> MDZ005 Area Forecast Matrix and the MDZ013 Point Forecast Matrix possibly
> due to 850 ft difference in elevation.  In Maryland it seems the Area
> Forecast Matrix provides a better granularity (and better forecast) than
> the Point Forecast Matrix which has fewer locations and covers larger areas.
>
> Mike/AJ9X
>
> On Saturday, September 26, 2020 at 5:48:36 PM UTC-4 jo...@johnkline.com
> wrote:
>
>> What town are you in?  Zip code?
>>
>> From where did you get the forecast extension?
>>
>> What version of WeeWX are you running?
>>
>> On Sep 26, 2020, at 8:34 AM, Michael Bruski  wrote:
>>
>> 
>>
>> I'm a newbie to weewx and have recently added the forecast extension to
>> two weewx systems I am operating at two different locations.   The initial
>> setup and test was done at my home location.   I changed the LID/FOID for
>> location 2 after deploying it.  While checking the syslog for the remote
>> system, I found the following messages from the forecast extension:
>>
>> Sep 26 11:10:18 wstn weewx[18561] INFO user.forecast: NWSThread: NWS:
>> downloading forecast from '
>> http://forecast.weather.gov/product.php?site=NWS&product=PFM&format=txt&issuedby=PHI
>> '
>> Sep 26 11:11:58 wstn weewx[18561] ERROR user.forecast: NWSThread: NWS: no
>> PFM found for MDZ012 in forecast from PHI
>>
>> I did some checking through the NWS EMWIN messages on GOES16 to see what
>> was what and see that MDZ012 is not included in the Holy Springs PFM, but,
>> it is provided in the AFM.  Would it be possible to add a key/tag to
>> weewx.conf to specify the product where my LID can be found or maybe change
>> user.forecast to check both PFM/AFM products for the specified LID?
>>
>> Thanks for this great extension and weewx!
>>
>> Mike/AJ9X
>>
>> --
>> 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/b6b535da-6144-4a81-8a20-a2ac930e68adn%40googlegroups.com
>> <https://groups.google.com/d/msgid/weewx-user/b6b535da-6144-4a81-8a20-a2ac930e68adn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
> 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/24573746-8249-4f99-8d31-b53ac909d784n%40googlegroups.com
> <https://groups.google.com/d/msgid/weewx-user/24573746-8249-4f99-8d31-b53ac909d784n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> 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.co

Re: [weewx-user] Feature request for forecast extension

[Michael Bruski]

Hi John,
 
I'm trying to run my remote on a RPi4B near Galena, MD 21635.   The MDZ012 
LID covers Kent county, MD where Galena is located.

I'm running WeeWX v4.1.1 and weewx-forecast-3.4.0b10.zip (after discovering 
that 3.4.0B1 wouldn't work).

As a work around, I tweaked the default URLs for NWS in 
/usr/share/weewx/user/forecast.py to substitute 'AFM' for 'PFM' to get the 
Area Forecast Matrix and that is working fine.  My LID is found
and I get the local forecast I'm looking for.   However, I may do a couple 
more deploys and it would be nice to have the ability to make this 
selection via the weewx.conf file instead of tweaking the source code.

I'm considering doing the same for my home location in Carroll county MD 
because I sometimes see some not so insignificant differences between the 
MDZ005 Area Forecast Matrix and the MDZ013 Point Forecast Matrix possibly 
due to 850 ft difference in elevation.  In Maryland it seems the Area 
Forecast Matrix provides a better granularity (and better forecast) than 
the Point Forecast Matrix which has fewer locations and covers larger areas.

Mike/AJ9X

On Saturday, September 26, 2020 at 5:48:36 PM UTC-4 jo...@johnkline.com 
wrote:

> What town are you in?  Zip code?
>
> From where did you get the forecast extension?
>
> What version of WeeWX are you running?
>
> On Sep 26, 2020, at 8:34 AM, Michael Bruski  wrote:
>
> 
>
> I'm a newbie to weewx and have recently added the forecast extension to 
> two weewx systems I am operating at two different locations.   The initial 
> setup and test was done at my home location.   I changed the LID/FOID for 
> location 2 after deploying it.  While checking the syslog for the remote 
> system, I found the following messages from the forecast extension:
>
> Sep 26 11:10:18 wstn weewx[18561] INFO user.forecast: NWSThread: NWS: 
> downloading forecast from '
> http://forecast.weather.gov/product.php?site=NWS&product=PFM&format=txt&issuedby=PHI
> '
> Sep 26 11:11:58 wstn weewx[18561] ERROR user.forecast: NWSThread: NWS: no 
> PFM found for MDZ012 in forecast from PHI 
>
> I did some checking through the NWS EMWIN messages on GOES16 to see what 
> was what and see that MDZ012 is not included in the Holy Springs PFM, but, 
> it is provided in the AFM.  Would it be possible to add a key/tag to 
> weewx.conf to specify the product where my LID can be found or maybe change 
> user.forecast to check both PFM/AFM products for the specified LID?
>
> Thanks for this great extension and weewx!
>
> Mike/AJ9X
>
> -- 
> 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/b6b535da-6144-4a81-8a20-a2ac930e68adn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/b6b535da-6144-4a81-8a20-a2ac930e68adn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>

-- 
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/24573746-8249-4f99-8d31-b53ac909d784n%40googlegroups.com.

[weewx-user] Feature request for forecast extension

[Michael Bruski]

I'm a newbie to weewx and have recently added the forecast extension to two 
weewx systems I am operating at two different locations.   The initial 
setup and test was done at my home location.   I changed the LID/FOID for 
location 2 after deploying it.  While checking the syslog for the remote 
system, I found the following messages from the forecast extension:

Sep 26 11:10:18 wstn weewx[18561] INFO user.forecast: NWSThread: NWS: 
downloading forecast from 
'http://forecast.weather.gov/product.php?site=NWS&product=PFM&format=txt&issuedby=PHI'
Sep 26 11:11:58 wstn weewx[18561] ERROR user.forecast: NWSThread: NWS: no 
PFM found for MDZ012 in forecast from PHI 

I did some checking through the NWS EMWIN messages on GOES16 to see what 
was what and see that MDZ012 is not included in the Holy Springs PFM, but, 
it is provided in the AFM.  Would it be possible to add a key/tag to 
weewx.conf to specify the product where my LID can be found or maybe change 
user.forecast to check both PFM/AFM products for the specified LID?

Thanks for this great extension and weewx!

Mike/AJ9X

-- 
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/b6b535da-6144-4a81-8a20-a2ac930e68adn%40googlegroups.com.

[weewx-user] Re: DIY weather station + Weewx on Raspberry Pi - how to join them?

[Michael Bruski]

First of all you need to write some code on the Raspberry to get your 
sensor data from the Thingspeak channel they are written to.   This link 

  
will give you an idea how to do that on the pi.  Once you are able to read 
all of your channels, you can write them to a temporary file and use the 
WeeWX extension fileParser to pick it up.   Check out this link 

 
for details.   I used it to setup a fileParser to collect my sensor info so 
that WeeWX could reap it and found the method works well.   My setup is 
somewhat different than yours in that I have my sensors connected directly 
to the RPi so I simply use my sensor program to read the data and then 
write it to a file.   WeeWX knows where to find that file and grabs it at 
the interval specified.  The author gives you a sample python program to 
create a data file containing your sensor data.

Hope that helps.

On Friday, July 24, 2020 at 4:03:15 AM UTC-4, Tomasz Lewicki wrote:
>
> Dear Weewx users.
> It's my first post. I looked into wiki and docs but still are stuck so I 
> ask here.
>
> My configuration is as follows:
>
> 1. DIY solar powered WiFi weather station (built from here: 
> https://www.instructables.com/id/Solar-Powered-WiFi-Weather-Station-V20/ 
> 
>  
> - the project known to some of you, I suppose), based on Wemos D1 Mini Pro 
> (ESP8266) with own IP address in local network
>
> 2. Raspberry Pi 3 used as cheap airplane tracking station (ADS-B stick).
>
> Now I want to extend RPi with Weewx fed and weather station data.
>
> Because my station is hand-made, I can't use any of standard hardware 
> drivers. As far I installed Weewx with Simulator driver and it works - 
> http://stationIP/weewx shows many plots and data. I was even able to send 
> it periodically to my other, public available, webserver by FTP.
>
> But of course I don't need fake, static data. I want to RPi with Weewx to 
> communicate periodically with weather station, grab the data (or weather 
> station push it periodically to RPi, which is the same, I suppose) and view 
> it live via the webserver.
>
> So finally I come to the important question: is such connection possible? 
> I suppose yes, but my experience with such hardware is very poor and I 
> don't know where should I go. I'm experienced Linux user so it is no 
> problem in this field. I only expect that someone will point me in the 
> right direction, some keyword to look for. Maybe someone has similar 
> configuration and could help?
>

-- 
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/a72d2d1d-7852-4be0-a8a7-71cd6b8a7722o%40googlegroups.com.