weather forecast inside the weewx standard skin seasons

[Hans Cilker]

Hi together,

is there an easy way to integrate a simple forecast  inside the standart skin? I've tried it with forecasting and my wu id, but i can't manage it and its too much, for me a simple link to my weather forecast pages at WU would be inough. Perhaps a link to the pages where i can find how to manage a extra Link inside the templates.

thanks  fore help

[Vetti52]

Same question to me!

Although, I think, that the forecast extension from https://github.com/chaunceygardiner/weewx-forecast currently is the most promising approach. It should not be that complex, to integrate just one of the graphs into weewx season skin. However, without WU support!!!

I am ready to cooperate!

To me, the main concern is using a reliable forecast for my region, which is not in the US, but in Germany! I would prefer to integrate forecast from "Deutscher Wetterdienst DWD". There is no API available, but they provide data from DWD-GeoWebService https://maps.dwd.de. As I am not familiar with this kind of data handling, I ask for support. More information seems to be available at the Geoserver Manual, which is to my opinion a very universal source of data, so worth to have a look at it for Weewx developers.

Anyway. First of all, I will try to to integrate an openweathermap forecast, which seems to be currently supported by weewx-forecast, and is also available for my region.

[Graham Eddy]

the forecast extension produces html tables not jpgs - i found it easiest to integrate using iframes (i use ‘compact’ and ‘strip’ tables)

On 13 Aug 2020, at 5:21 am, Vetti52 <drv...@gmail.com> wrote:

Although, I think, that the forecast extension from https://github.com/chaunceygardiner/weewx-forecastcurrently is the most promising approach. It should not be that complex, to integrate just one of the graphs into weewx season skin. However, without WU support!!! 

[tarob...@gmail.com]

I am also trying to get forecast with tides into the Seasons Skin but it looks like I'm getting some errors trying to pull this data from the different sources. Here are the errors I'm seeing in my syslog:

Aug 14 07:15:22 raspberrypi weewxd: forecast: OWMThread: OWM: got 40 forecast records

Aug 14 07:15:22 raspberrypi weewxd: forecast: OWMThread: OWM: saving 40 forecast records

Aug 14 07:15:22 raspberrypi weewxd: forecast: OWMThread: OWM: forecast failure: addRecord() got an unexpected keyword argument 'log_level'

Aug 14 07:15:22 raspberrypi weewxd: forecast: OWMThread: OWM: terminating thread

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: units=1 winddir=119.225591908 pressure=29.9887493475 first_p=29.985739413 last_p=29.9854614785

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: pressure=1015.53545688 month=7 winddir=5 trend=-0.00313731418123 north=True

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: code is E

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: generated 1 forecast record

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: saving 1 forecast records

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: forecast failure: addRecord() got an unexpected keyword argument 'log_level'

Aug 14 07:15:22 raspberrypi weewxd: forecast: ZambrettiThread: Zambretti: terminating thread

Aug 14 07:15:22 raspberrypi weewxd: forecast: XTideThread: XTide: got 222 lines of output

Aug 14 07:15:22 raspberrypi weewxd: forecast: XTideThread: XTide: forecast failure: invalid literal for int() with base 10: 'XXXXXXX' 

Aug 14 07:15:22 raspberrypi weewxd: forecast: XTideThread: XTide: terminating thread

Any ideas on the unexpected keyword argument 'log_level' ?

Thanks,

Troy

[John Kline]

I promised I would take a look at supporting the new WU API.

I’ve done that.

See:

https://github.com/chaunceygardiner/weewx-forecast/releases/tag/v3.4.0b6

On Aug 12, 2020, at 12:21 PM, Vetti52 <drv...@gmail.com> wrote:



--
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/3c485927-4004-433c-a6f8-ad9f50e7ddb1o%40googlegroups.com.

[Graham Eddy]

many thanks for resurrecting this extension to python3

i don't use WU but a bug seems to have carried over from previous version (b5): forecast_compact.inc refers to forecast_iconic e.g.

$varExists('Extras.forecast_iconic_settings')

but is documented as using label forecast_compact e.g.

[forecast_compact_settings]

the nett result being incorrect config header required: [Extras] [[forecast_iconic_settings]]

fix needs simple substitutions in half-dozen lines at top and one line at bottom to forecast_compact.inc

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/483B5816-2E64-46C2-966F-3E50EA438E27%40johnkline.com.

[Graham Eddy]

another little bug is that when flag is set to ‘0’ in conf file, it is treated as ‘true’ in forecast_compact.inc.

fix is to convert the flags to int (they are strings when derived from conf file) e.g. around line 60

#set $show_pop = int($local_settings.get('show_pop', $show_pop))

(while this extension was not being updated, i found it easier to hack from a distance and wrap it in iframe. now that it is being updated, i need to integrate it properly so am interested in bug fixes…)

[John Kline]

The bug wasn’t a b5 bug, per se.  It’s carried over from matthewwall/weewx-forecast.  I’m sure there are plenty more.  Never-the-less, these were easy changes.  I’ve submitted them.

I don’t believe the extension has been abandoned.  It is my understanding that Matthew is busy at the moment; but will eventually update the extension.

On Aug 17, 2020, at 4:46 AM, Graham Eddy <graha...@gmail.com> wrote:



--
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/26F9C1B3-DD10-4F9D-9395-D1769357D794%40gmail.com.

[tarob...@gmail.com]

The latest release, v3.4.0b6 has resolved my issue above. Forecasts are now being generated along with tides. Thank you for updating!

-Troy

[Vetti52]

Finally, I managed to install the latest release also. I used WU Api key and it works nicely. I find it much easier to integrate it into the season skin as a wiget than as iframe. I do not get iframes sized correctly for tablet or smartphone displays. The wigeds look much better. And, as the forecasts are produced just like a separate web site, it would be easier to integrate one of the html files into the season skin than to take it from the WU web site. Moreover, as there are ready to use *.inc files, it is pretty easy to introduce these as widgets. I followed the forecasting wiki  forecast data in the Season skin. I am considering to add more than one *.inc file, as soon as I am satisfied with the results. This is only described for the Standard skin, but I hope, it will work in the Season skin as well.

Meanwhile, there are some things I don't understand:

• single table has a toggle on the the date column (onclick toggle_hours), but without any action.
• multiple tables toggles hours as expected, but has an extra column for dewpoint, which has no values (N/A)
• single strip horizontal has not date line, only hours, and three temperature lines, one of them may be dew point? There is an empty windspeed line, maybe for gust data?
• single strip vertical is exactly the same, except that the icons for clouds are double sized and blow up the matrix.
  
• And why isn't there a cloud prediction for all days? In my case, it only occures once, but this may be WU specific.

The rest of the examples look fine to me, besides that there are no tides available for the North Sea. Looking at https://flaterco.com/xtide/faq.html#60 I have learned, that tides are no longer maintained outside of US, since early 2012. Maybe the forecast documentation could need an update, meanwhile...

[John Kline]

As your incorporating this into your Seasons skin, it makes sense to remove (from the .inc files) the data that is not provided by WU (e.g., dew point).

You should have a look at what’s coming back from WU by using the following URL (assuming you are using the default–station’s lat/long–for the forecast).  Do substitute your api key for the XXX.

https://api.weather.com/v3/wx/forecast/daily/5day?geocode=37.431495,-122.110937&format=json&units=e&language=en-US&apiKey=XXXXXXXXXXXXXXXXXXXXXXXXXXXX

Let me know if you think something in the WU forecast returned from the above URL is amiss in the forecast extension.  Note: there is plenty in what WU sends that has no place in the forecast extension schema.

On Aug 21, 2020, at 7:32 AM, Vetti52 <drv...@gmail.com> wrote:



--

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/ffa219fd-0a10-4283-8605-032932e27503o%40googlegroups.com.

[Vetti52]

Well, I took forecast-table.inc for my Weewx site now. There is no dew point column, although it is set to #set $forecast_source = 'WU', and  the inc file includes #set $show_dewpoint = int($local_settings.get('show_dewpoint', $show_dewpoint))

The dew point column shows only in the multiple-tables.inc in the WU section. I have not activated any other forecaster. So, should I delete the global setting for dew point in multiple-tables.html.tmpl, rather than removing it in forecast_table.inc?

Same with windGust, which also does not exist in the WU json file. In contrast, multible tables contains a column for moon phase, but it does not show anything. The two columns to the right are therefore shifted next to moonrise. The header columns are not adjusted correctly, so that the sun icon is slightly left to the sunrise/set column, the moon icon merely above these data, the moon phase icon  slightly left from the moonrise/set data and the moon phase icon POP icon on the right border of these data. So, it is somewhat confusing to coordinate the table.

The URL returns a 5day.json file, which does not show an entry for dewpoint nor windGust, as far as I can configure. Indeed, there are plenty of entries. I could detect 11 entries each in the section daypart:0: temperature:, temperatureHeatIndex: , and temperatureWindChill. There are two sections for moon phase: moonPhase and moonPhaseCode, which contain 5 entries each.

Today forecast-table shows at two places the B1.png icon, depicted as "Mostly cloudy". The entries are for today and next thursday. I can not find the corresponding data in the json file. The most promising entry would be in

narrative:

0	: "Showers possible early. Lows overnight in the mid 50s."
1	: "Cloudy with showers and thunderstorms. Highs in the upper 60s and lows in the mid 50s."
2	: "Showers possible. Highs in the mid 60s and lows in the low 50s."
3	: "Showers possible in the afternoon. Highs in the low 70s and lows in the upper 50s."
4	: "Light rain and windy. Highs in the upper 60s and lows in the mid 50s."
5	: "Partly cloudy. Highs in the upper 60s and lows in the low 50s."

Mostly cloudy, however, does not occure anywhere in the json file.

[John Kline]

Yes, I concluded that WU does not provide a dew point nor wind gust when I wired it up.

I would remove the columns in your copy of these files (since you have copied them to another skin).  I have modified various files when I copied them to another skin at https://www.paloaltoweather.com/ (see the Graphic and Detailed tabs under forecast).  It seems a reasonable thing to do.  I believe Matthew Wall, the author of this extension, meant the skin to be examples that one can copy to another skin and modify.  I’m not inclined to spend a lot of time playing with formatting.  My fork is, presumably, temporary until Matthew gets around to this extension again.

I can’t think of a reason that you would need to delete the $show_dewpoint setting—if that is what you meant by delete the global setting.  Simply don’t use it.

I think your understanding of the json file is fairly on target.  The stuff under daypart will have 11 or 12 entries depending on the time of day that you look (after “apparent” 3PM, at your location, you’ll only have 11 as the first will be None).  These entries are for 7am-7pm and 7pm-7am.  Thus, you’ll have either 5 1/2 or 6 days of 12-hour forecasts.

The entries outside of daypart apply to 24 hours (rather than 12 hours).

The B1.png icon you refer to comes from the following code in forecast.py and corresponds to wxPhraseShort in the json:

WU_SKY_DICT = {

        'Sunny': 'CL',

         'M Sunny': 'FW',

         'P Sunny': 'SC',

        'P Cloudy': 'B1',

         'M Cloudy': 'B2',

         'Cloudy': 'OV'}

You might notice if you go searching that much of what is in this file is not defined anywhere.  If you do find something definitive, please let me know.  You can start here:

https://docs.google.com/document/d/1_Zte7-SdOjnzBttb1-Y9e0Wgl0_3tah9dSwXUyEA3-c/edit

I am very interested in if I’m missing any conversions (for example, if you see anything in wxPhraseShort in the json file that isn’t listed in WU_SKY_DICT above).  Since I can’t find documentation, I can’t for a complete list and reports from you and other can help me find anything that may be missing.

You also allude to the fact that there is much in the json file that is ignored.  That is true.  The way this extension is written, there is a single schema for all forecast types.  If I could not find a place in the schema, I ignored it (as is the same for every other forecast implementation in this extension).

On Aug 22, 2020, at 8:42 AM, Vetti52 <drv...@gmail.com> wrote:



--
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/31491044-d207-4219-9018-4c92f0d40795o%40googlegroups.com.

[Vetti52]

To inactivate dewpoint, I thought to delete (or comment out) the line in forecast-table.inc:

## Now assign the values that will actually be used
..

#set $show_dewpoint = int($local_settings.get('show_dewpoint', $show_dewpoint))

or is it better to inactivate it in multiple-tables.html.tmpl

Example file:

<h1>Forecast Table</h1>
<p>
Display forecast data in multiple tables, one table for each forecast source.
</p>

#set global $forecast_table_settings = dict()
#set global $forecast_table_settings['num_periods'] = 300
#set global $forecast_table_settings['show_legend'] = 1
#set global $forecast_table_settings['show_hourly'] = 1
#set global $forecast_table_settings['show_day'] = 1
#set global $forecast_table_settings['show_date'] = 1
#set global $forecast_table_settings['show_outlook'] = 1
#set global $forecast_table_settings['show_temp'] = 1
#set global $forecast_table_settings['show_dewpoint'] = 1
..

<h2>Weather Underground</h2>
#set global $forecast_table_settings['source'] = 'WU'
#include "forecast_table.inc"

curiously, as my forecast.inc looks like

<link rel='stylesheet' type='text/css' href='forecast_table.css'/>

<div id='forecast_widget' class="widget">
  <div class="widget_title">
    Vorhersage
    <a class="widget_control"
      onclick="toggle_widget('forecast')">&diams;</a>
  </div>
  <div class="widget_contents">

#include "forecast_table.inc"

  </div>
</div>

which is evoked as a widget in the skin. There the dew point is not shown, but only, when the same inc file from multiple-tables.html.tmpl is used. And then, there are those misaligned columns containing the empty moon phases. But, maybe, it is a difference, when the file is invoked from a html.tmpl or as inc file? Sorry, but my view into the Weewx and python philosophy is not very deep. But, moon phases should anyway be shown according to the moonPhaseCode data, which are present in the json file, which is not the case.

So, at least, one "problem" is solved: When retrieving the json file from WU with "language=en-US", I get (the long and short versions do not differ much):

wxPhraseShort
0	"PM Showers"
1	"Shwrs Late"
2	"Rain"
3	"P Cloudy"
4	"PM Showers"
5	"Showers"
6	"Rain/Wind"
7	"Shwrs Early"
8	"P Cloudy"
9	"Shwrs Late"
10	"T-Showers"
11	"Showers"

when language is set to "de-DE", I get

wxPhraseLong
0	"Nachm. Schauer"
1	"Später Schauer"
2	"Regen"
3	"Wolkig"
4	"Nachm. Schauer"
5	"Schauer"
6	"Regen/Wind"
7	"Zunächst Schauer"
8	"Wolkig"
9	"Später Schauer"
10	"Gewitterschauer"
11	"Schauer"
wxPhraseShort
0	""
1	""
2	""
3	""
4	""
5	""
6	""
7	""
8	""
9	""
10	""
11	""

So, there is an issue with WU. The solution would be either to use the wxPhraseLong or to urge the request to use US values.

Maybe there is already a way to set the language somewhere, but I did not find it yet. Moreover, I know, that I've read about the interval for retrieving forecasts at times, e.g. whenever the Weewx site is updated or at defined times, but do not find it again. Same might be with the language settings. In case, the request should be retrieved in en-US, will the data be shown in Weewx still in German? At least temperature and windSpeed seem to be converted into metric values.

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[Vetti52]

Ok, I just copied this part from multiple-ables.html.tmpl into forecast.inc:

#set global $forecast_table_settings = dict()
#set global $forecast_table_settings['num_periods'] = 300
#set global $forecast_table_settings['show_legend'] = 1
#set global $forecast_table_settings['show_hourly'] = 1
#set global $forecast_table_settings['show_day'] = 1
#set global $forecast_table_settings['show_date'] = 1
#set global $forecast_table_settings['show_outlook'] = 1
#set global $forecast_table_settings['show_temp'] = 1

## set global $forecast_table_settings['show_dewpoint'] = 1
#set global $forecast_table_settings['show_wind'] = 1
#set global $forecast_table_settings['show_tides'] = 1
#set global $forecast_table_settings['show_sun'] = 1
#set global $forecast_table_settings['show_moon'] = 1
#set global $forecast_table_settings['show_pop'] = 1
#set global $forecast_table_settings['show_precip'] = 1
#set global $forecast_table_settings['show_obvis'] = 1
#set global $forecast_table_settings['source'] = 'WU'
above the existing
#include "forecast_table.inc"

show_dewpoint is commented out. That works!

Then I aligned the table by modifying

<td class='col-sun'><img src='icons/sunriseset.png' class='legend-img' alt='S' title='Sun' /><br/><span class='units'>Sunrise <br/>Sunset</span></td>

and for the moon accordingly. I did this, because I looked into the generated index.html file and realized, that the headers of the table are in a separate table than the data, which prevents the two tables for common alignment. Thus, I just decided to adjust the column width by adding "some text" to the headers. Old style, I know.....

But this enlighted me, concerning the moon phase, so that I could realize, that the phase are not shown as png replacements such as the clouds are, but as simple percent values of the moon phase. Shame on me.... I could find the code also in forecast-table.inc, which told me, that almanac data are used. I am assuming, that the data are from pyephem and not extracted from the json file. However, the ephemerial data for today differ somewhat. The forecast data read for today 25%, celestial data read 28%. Why?

Anyway, almost everything (except of the clouds) is fine now, even, as I do not understand much of what I did.

[John Kline]

So, there is an issue with WU. The solution would be either to use the wxPhraseLong or to urge the request to use US values.

The extension already does this.  It always requests en-US.  The database stores US values (US being a WeeWX term for the English system).  You see metric because they are converted as appropriate for the report.  This cannot be changed because it would break the logic in the extension.

Moreover, I know, that I've read about the interval for retrieving forecasts at times, e.g. whenever the Weewx site is updated or at defined times, but do not find it again.

You can set interval.  That can be set for all forecast types or for individual forecasts.

The default is 10800 seconds (3 hours).

Try this to get get forecasts twice as often as the default:

[[WU]]

   api_key = XXXXXXXXXXXXX

   interval = 900

On Aug 23, 2020, at 1:24 AM, Vetti52 <drv...@gmail.com> wrote:



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/6ef8dbd8-1fc6-451d-b8a3-c00eec3e628ao%40googlegroups.com.

[Vetti52]

What a pity, so the solution for clouds is not that trivial. hope, you will find it.

And thanks for the hint for setting interval. I was afraid, that WU will stop delivering because of too many requests. 3 hours look ok for me. I don't think, that forecasting is such a capriciously changing business.

[John Kline]

Perhaps I missed something.  What solution for clouds?  Exactly what isn’t working for you?  Please send the entire response you receive (contemporary to the problem) when calling WU directly with the URL I gave you (of course, putting in your lat/long and API key to get the forecast).  Also, please say exactly what you are seeing that is wrong (what is missing and/or what shouldn’t be there) and on what page you are seeing it.

On Aug 23, 2020, at 11:42 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cf46d84e-232a-45e3-823f-94ba12ac0eddn%40googlegroups.com.

[Vetti52]

wxPhraseShort
0	null
1	"Showers"

2	"Rain"
3	"P Cloudy"

4	"PM Lgt Rain"
5	"Light Rain"

6	"Rain/Wind"
7	"Shwrs Early"

8	"M Cloudy"
9	"M Cloudy"
10	"Showers"
11	"Showers"

That is, what the API returns right now.

the forecast shows (just look at the icons)

Mo 24 Aug

19 10

13-14

06:12:54 20:28:16

13:16:00 22:53:04

33%

90% 8,89

07:00		19	14		13:16:00		90% 8,89
19:00		10	13	20:28:16	22:53:04		20%

Di 25 Aug

21 10

14-21

06:14:42 20:25:55

14:41:38 23:17:51

44%

70% 4,06

Mi 26 Aug

18 10

27-32

06:16:30 20:23:34

16:03:24 23:50:02

55%

90% 9,65

Do 27 Aug

19 10

13-21

06:18:17 20:21:12

17:17:11 00:32:33

66%

20%

07:00		19	21		17:17:11		10%
19:00		10	13	20:21:12			20%

Fr 28 Aug

19 10

13-16

06:20:05 20:18:49

18:18:50 00:32:33

76%

60% 6,10

WU forecast for geocode=54.09,10.26 issued on 23-Aug-2020 21:10
report generated in 0.175 s

You can see two entries, first for today at 19:00 "mostly cloudy", and the second one on Thursday "considerable cloudiness" all day. What about showers and rain/wind and all the others? Rain without clouds? I am confused.

Hope, I could demonstrate it.

Am Freitag, 21. August 2020 16:45:38 UTC+2 schrieb John Kline:

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[John Kline]

What do you propose I put in for clouds in the cases you mention?

The choices are:

'CL': 'Clear',

'FW': 'Few Clouds',

'SC': 'Scattered Clouds',

'BK': 'Broken Clouds',

'B1': 'Mostly Cloudy',

'B2': 'Considerable Cloudiness',

'OV': 'Overcast',

On Aug 23, 2020, at 12:45 PM, Vetti52 <drv...@gmail.com> wrote:



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/01173606-c326-4707-ae56-d8d11b3fcdd8o%40googlegroups.com.

[steeple ian]

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/B902B523-1F3D-43BF-8DD0-A2EEE4D2B7EB%40johnkline.com.

[John Kline]

WU does have a cloud cover percentage, so this will work.  Thanks.

On Aug 23, 2020, at 3:44 PM, steeple ian <steep...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CADASSaScMJUyVsTX0eCtb4YB1bQ5m8qLzKFKtVmESaVOnB3Czg%40mail.gmail.com.

[John Kline]

For WU, the cloud icon is now calculated from cloud cover percentage.

You’ll need to pull head.

On Aug 23, 2020, at 3:48 PM, John Kline <jo...@johnkline.com> wrote:



[Vetti52]

I was thinking about a graphic demonstration like that in the wiki:

https://camo.githubusercontent.com/8b5474131edc812687002ab075ec51e1ddb8bd82/687474703a2f2f6c616e6365742e6d69742e6564752f6d77616c6c2f70726f6a656374732f776561746865722f77656577782d666f7265636173742d7461626c652e706e67

where all states are shown. Thus, there is no empty field in the cloud column at all.

Does "pull head" mean just to update to the latest version, 3.4.0b7? Sorry, but I am dumb....

[Vetti52]

I found this link for assigning the iconCode entries from the WU json file to the meaning, along with some icons:

https://www.weather-watch.com/smf/index.php/topic,67656.msg543684.html?PHPSESSID=9cntj0deu62o4c9q6jasslpqph#msg543684

After update to version b7, there is still only one icon visible, which is on thursday. I guess, this corresponds to number 6 (Considerable Cloudiness). No matter, which of the forecast sampler files I look at.

Here my actual request:

cloudCover
0	85
1	64
2	76
3	84
4	96
5	64
6	60
7	76
8	84
9	65
10	72
11	77

iconCode
0	11
1	29
2	11
3	12
4	12
5	11
6	30
7	45
8	11
9	11
10	11
11	11
wxPhraseShort 0 "Showers" 1 "P Cloudy" 2 "PM Lgt Rain" 3 "Rain" 4 "Rain" 5 "Rain Early" 6 "P Cloudy" 7 "Shwrs Late" 8 "Showers" 9 "Showers" 10 "Showers" 11 "Showers"

[Vetti52]

I hate the new google forum surface!

The link should read:

https://www.weather-watch.com/smf/index.php/topic,67656.msg543684.html#msg543684

and for clarification of the missing entries, it is much better to look at the Forecast Sampler: Periods

Periods from Selected Forecast Sources

Display specific portions of a forecast, from various forecast sources. This illustrates the use of the forecast search list extension.

Weather Underground

24-Aug-2020 19:00 11,7°C
25-Aug-2020 07:00 20,6°C
25-Aug-2020 19:00 14,4°C
26-Aug-2020 07:00 17,8°C
26-Aug-2020 19:00 12,8°C
27-Aug-2020 07:00 18,9°C Considerable Cloudiness

Issued at 24-Aug-2020 09:20 for geocode=54.09,10.26

To my intension, every line should end with a description, such as 'Mostly cloudy'. Well, actually I miss 'Clear', but this is, due to the current weather situtation, not an option.

[John Kline]

Send the contents of forecast/single-table.html and forecast/forecast-periods.html that are generated.  Also send the contents of a contemporaneous WU API call.  Don’t send excerpts of either.

Are you sure you installed and restarted weewx?  I ask because I get icons for every day in single-table.html and descriptions for every period in forecast-periods.html.  Please verify that you see 3.4.0b7 in the log.

As for the extra icons you would like to see on the right, I would need a way to generate them.  Probably, over time I could do it from the English descriptions.  I could also do it by looking at the icons they provide and map them (as was done by the author of the post you provided).  I note that these extra icons were not generated for the prior WU daily forecast.  Let me think about whether or not I want to add that functionality.

On Aug 24, 2020, at 3:36 AM, Vetti52 <drv...@gmail.com> wrote:



--

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/5e5f50cb-19fe-42e7-a558-9c12da34ea85n%40googlegroups.com.

[John Kline]

Actually, the most likely problem is that you didn’t wait for a new WU forecast to be downloaded after installing and restarting.  That won’t happen until at least three hours after the last forecast.  Before you do what I asked below, please check these reports again.  Do they not look correct?

On Aug 24, 2020, at 7:08 AM, John Kline <jo...@johnkline.com> wrote:



[Vetti52]

You are right! I assumed, that the forecast would be downloaded immediately after installing and restarting. Now, three hours later, the cloud column is completely filled and all is correct. Great job!

So, what about the idea to use the complete set of icons, including day/night versions? Well, it is pure luxury. But to me mapping iconCode versus PNG icons seems the most simple adoption.

I have already written down the WU codelist with descriptions provided from the weather-watch forum, just for better understanding and may be for future use. And, if I can help drawing the png icons, I could support.

[John Kline]

That’s good news.

The forecast extension relies on coercing the various forecast to a standard representations that is stored in a common schema.

As such, supporting arbitrary icons would not fit in with the scheme.

WU does provide precipType and precipChance.  precipType can be rain, snow or precip.

For cases where precipType is rain, or snow, I have now added the appropriate icon (based on precipChance).

Please give 3.4.0b8 a spin; and do wait for a new forecast to be downloaded.  That will be no sooner then 3 hours after the previous forecast.

On Aug 24, 2020, at 9:25 AM, Vetti52 <drv...@gmail.com> wrote:

You are right! I assumed, that the forecast would be downloaded immediately after installing and restarting. Now, three hours later, the cloud column is completely filled and all is correct. Great job!

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/e80b093b-2357-47b2-9e87-b0846febe3can%40googlegroups.com.

[Vetti52]

ok, I was thinking of keep it simple. So the correlation of iconCode to one icon each looked straight forward to me. Probably you can see, what I mean in the attached ZIP. There should be no need to have separate icons for each forecaster, but the idea was, that there is a simple one to one relation of WU iconCode to PNG file. So, there should be a complete set for all of the 47 iconCodes. The icon files could nevertheless be replaced, matching a common schema.

I will give b8 a spin tonight. You may know, that I replaced the Zambretti narratives with German translations. So, I need some extra seconds for spinning.

[John Kline]



WU_SKY_DICT is for cloud cover.  What you are proposing is simply not a good fit for this extension.  I won’t be creating these new icons.

Having said that, there is definitely information to be gathered from the iconCode.  Using that code, I can get many more precipitation types which can be combined with precipitation chance to derive which icon to add.

As such, I’ve pushed v3.4.0b9.  It adds support for the following icons in the WU forecast: tstms, hail, dirzzle, sleet, frzngdrzl, frzngrain, flurries.

On Aug 25, 2020, at 4:03 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a5fbeeac-0357-4303-852f-1eba383709b2n%40googlegroups.com.

<WU_Code.zip>

[Vetti52]

Ok, I understand (hopefully). Meanwhile I have an update to v3.4.0b8, where I could see, that precipitation is in a separate column next to POP. So, you divide the WU icon set into two separate sets, one for cloud cover, and one for precipitation. That is a little bit more complex and needs more intelligence than just reading the iconCode and display, whatever it means, in one single row (or column). So you can gain simultaneous information from different json entries and display the results separately, right?

Actually, the next forecasts are full of "rain". But it would be nicer, if the icons would differ, when the precipitation chance is <20% or 80%. Actually, all of the week forecast looks the same for rain, although there are days with POP 100% and <20%.

Forecast for next Sunday is displaying the SC icon, presumably due to WU cloudCover=42, WU iconCode would show icon 45, which is scattered showers. I think, that different icons, as WU provides here, would reduce irritation.

Just to let you reproduce, what I am trying to explain, I attach another ZIP with the actual index.html and json files.

And, again, I will give v3.4.0b9a spin.

[John Kline]

Can you state with certainty that you waited for a new WU forecast to be downloaded?

On Aug 25, 2020, at 8:32 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/6e2d2064-655c-4ba2-b944-8d4b76ef9845n%40googlegroups.com.

<5day.zip>

[Vetti52]

Well, I am not pretty sure about the syncronization of json and html file. I append the most recent data as a ZIP file again. The latest WU forecast seems to be from 25-Aug-2020 19:05. And the json file is retrieved from just now, which should be in the same 3h period.

May be, there are differences in time, but the forecast seems to be the same.

And, there is some rain outside....

[John Kline]

Please point me to a exactly one specific thing you think is not correct.  I’m not suggesting you are wrong, but I’m very busy (I have a real job) and that will help me quickly find the issue.  Also, please send your lat long.

On Aug 25, 2020, at 11:57 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/6b7e5e2c-d1c0-41a6-8e84-1de1fe3695ecn%40googlegroups.com.

<5day.zip>

[John Kline]

I see your latlong, let me run it.

On Aug 25, 2020, at 12:01 PM, John Kline <jo...@johnkline.com> wrote:



[John Kline]

I had a look at single-strip.html and it looks good when I plug in youR latlong.

Please concentrate on single-strip.html.  And look at the logic in forecast_table.inc.

Do you see anything that is wrong?  I’m looking for exactly one thing to start with.  Don’t say something like, I see the same icon for 10% chance of rain vs. 100% chance of rain unless you think the logic in forecast_table.inc is differentiating them and presenting different icons.

My goal is not to change the logic and the icons, it is for the forecast to be working as intended.

On Aug 25, 2020, at 12:03 PM, John Kline <jo...@johnkline.com> wrote:



[Vetti52]

When looking at single-strip.html from the sampler, there are only the cloud icons, but no precipitation icons. So it is not completely comparable with forecast_table.

Besides, an there is an empty line below the wind (km/h) line, which I guess to be for gust data. But WU does not provide gust. How to disable this line for WU? I don't get into the concept of selecting the data appriopriate to the forecaster. Although, there should be an overall directive of which data are provided, e.g. driven by #set $forecast_source = 'WU'

Your question about, what is wrong in single-strip.html?

The date line is missing.The table starts with hours. Next, there are three temp lines. The three temp icons have no descriptions. I interpret them as temp-max, temp, and temp-min. The data from day values are shown in temp-max and temp, those from night values in temp and temp-min. Is this the intention?

After the empty gust line, I see wind direction icons followed by the cloud icons. That's perfect.

Then, the table ends with three text lines: POP %, precipitation in mm and snow in mm. Actually, the last line should only show, when needed, at least not now, here in August.

Curiously, in the vertical strip the date is present. But the cloud icons are double in size, so that the table gets huge. The rest of the content is identical to the horizontal strip. Both forecasts looks the same with Firefox, Safari, and Edge. I have no idea, why the date line is not shown in horizontal mode, but in vertical mode, and the cloud icon size differs, although both are absolutely identical, except of the orientation setting.

Concerning the rain icons, I think, that there should be no rain icon, when POP is <=20% and/or the amount of precipitation is (close to) zero. This would be logically, or not?

[John Kline]

I did make a change to better align the header icons on the single strip.  That’s something I did a long time ago for my copy when I integrated it into my skin.  You’ll have to download it by choosing Code -> Download ZIP from the main page as I didn’t do a release for it.

For your  requests, such as not seeing a row in the summer months, or not seeing a rain icon if POP is under 20%, it’s best if you copied these examples and customized in a way that’s best for you.

The request to not see a row for wind gust when the forecast has no wind gust information seems reasonable.  I might make that change sometime when I am not so busy, but I do worry that all of these changes are going to disappear when Matthew Wall updates his forecast extension.  Remember, my fork is planned to go out of existence once Matthew updates his code for WeeWX 4.

On Aug 26, 2020, at 3:37 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/65bc4520-5b6d-4391-bf24-28fb3231b154n%40googlegroups.com.

[Vetti52]

Thanks for your copy of the skin.

I visited Matthew's wiki today, because I was wondering, that the link to an image there did not work anymore. Indeed, most of the images there are broken. Bad news, because I found the table presentation very impressive. But then I followed his link to http://sailing.mit.edu/weather/forecast.html as an example. And there you can see an example of the forecast_table, when choosing NWS, which currently seems to be the only one, that is working. There are currently icons for rain showers and thunderstorm, but only at lines with more than 30% POP. The legend tells weewx 3.9.0b2, so I guess, this is an early forecast version as well. This design looks pretty nice. So, I doubt, that Matthew would change this kind of data evaluation, if you would reproduce it the same way. Whenever you can spend some time....

[Vetti52]

And, I just modified forecast.py at line 2563, and changed "0" to "20":

if precip_chance > 20 and (precip_type == 'rain' or precip_type == 'snow'): 

Now, only rain icons are shown, when precipitation chance is above 20%. It looks like the example at sailing.mit.edu, as linked above. I am happy with that result for forecast_table.inc now. We could let Matthews work on the rest, for my opinion. And there is more time for hard real time jobs... And I have learned a little bit about python. Just a tiny little bit....

[John Kline]

I’ll continue to look for what that number should be.  There does not appear to be an equivalent for NWS.  Either a rain line appears or not in the NWS forecast downloaded.

Having said that, I’m OK with changing 0 to 20, as you have done.  I’ll push that.

 

On Aug 26, 2020, at 11:38 AM, Vetti52 <drv...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cc859425-625c-4ee4-a8c8-e322f1fd20b7n%40googlegroups.com.

[Vetti52]

Well, at least it looks pretty same with WU forecasts now.

And, yes, there are still some cosmetic corrections, such as the different views on the same html file, when nothing else is changed but the orientation from horizontal to vertical.

Today I detected another (cosmetic) misbehavior in multiple_tables. When toggling hours in the first day (see the appended html file), the alignment is not correct. It looks like, if there is no 07:00 line and the moon rise should be displayed within this line, in the 19:00 line the table cells <td class='col-moon'></td> and <td class='col-moonphase'></td> are empty and thus the following table cells shift to the left. This might be the same problem as with the alignment of <div class='legend'> and the following <div class='summary'> table, where there is col width defined in the css being not appropriate for the data. So, the cell width depends on the content.  This may be not so obvious, when the set/rise data are displayed without seconds. But I don't know, where the format is defined. In my case, showing the format hh:mm:ss needs more space than provided with the min col width defined in the css file. So, at what point should this cosmetic problem be taylored?

[Vetti52]

I have seen, that you adjusted forecast_table.css col-sun and col-moon to 95px. in version v3.4.0b10. My own test showed, that 65px would be enough. Anyway, still 65px broadens the table in a way, that the complete web site does not fit onto a mobile screen. Thus, the graphs are cut at the right border. I would therefore prefer to omit the seconds in sun and moon columns. Or create a separate mobile skin.....