PWS_Dashboard (WD34) Beta releases

Perhaps an   ? But, IMHO, you could increase the type size in the earthquake block too. . . (I have done it on my July version page).

But maybe change the whole date time string to be either [font=courier]Today at 16:44[/font] or [font=courier] Yesterday at 23:55[/font] The received data spans nowadays only 24 hours. Using Today or Yesterday seems clearer to me.

Sounds logical. Maybe see if you get any other feedback on that?

I enlarged the font-type so that it is better readable also.
The remaining free area in the height is needed for longer region/country area which sometimes wrap on two lines.

Wim

:thumbright:

Also posted on the WX-forum!

Background:
For the next release of PWS_Dashboard I still use canvasJS for the graphs and moment.js but I am testing locale.js for date and time formatting in the graphs.
It works as “advertised”. Change the language to “en-us” and the times are in “1:26 pm” format. Select “de-at” (German in Austria) prints “13:26”

Question(s):
Can you check the languages used in your country and tell me if there are improvements needed for locale.js, it would really help.
You can test your country+languages at the moment.js startpage https://momentjs.com/ , scroll to the bottom.

Example: I thought that the date/time-display for a country was the same for all official languages spoken in that country.
For Belgium, where I live, the three official languages all use 24 hour time format and day-month.
Canada I thought uses always 24 hour but locales.js sets all times for Canada-English to am/pm time and Canada-French to 24 hour format. Is that correct?
And according to locales.js there is one language (English) in Australia and the times are in am/pm. I doubt that.

Why:
I want to use 1 setting only where you select the default locale during setup.
Based on that one setting, the language file the units, the date-time formats, the country flag a.s.o. should be automatically and correctly set.
If you want to use something different on your own website, there is a file one can change for that.

And when selecting another language in the menu, the time/date-formats, units a.s.o. should be the changed identical for the php scripts (server-side) and the javascripts (browser).

If that works, the use of “comma for decimal point” can be included in the October release also.

Wim


Hi Win,
I congratulate you on the program, modern, easy to configure and great future.
I tried to add two Greek and Romanian languages and I work for translating into Danish and Bulgarian.
As a suggestion, it may also be useful for snowfall in precipitation.

http://www.celinmeteo.com/wdisplay/PSWWD09/w34_index2.php

http://www.celinmeteo.com/wdisplay/wxindex.php

Marian

Well thank you for the nice words and the time you spent for those extra languages.
In the next release there will be a very easy way to add an extra language.
For every language 1 line is needed in a separate file, example the Italian language for Italy
The fields contain:
language-country | locale for javascript | the name of the language file | the title in the menu and easyweather | the default units for that language-country

it-it   |it.svg  |it      |lang_it.txt     |Italian (Italy)        | metric |

The scripts will test if there is a language file, if not they will use the English file (as that is used to remove typing errors in my_english.

As a suggestion, it may also be useful for snowfall in precipitation.
If time permits I will add the snow-block as used in the Leuven-template. Before December this year. It will be a pop-up with manual snow height entry. AFAIK there is no snowfall weather-tag as there is for rain in most of the weather-programs. If you have any more ideas about snow-height-melts a.s.o. let me know.
[http://www.celinmeteo.com/wdisplay/PSWWD09/w34_index2.php](http://www.celinmeteo.com/wdisplay/PSWWD09/w34_index2.php)

http://www.celinmeteo.com/wdisplay/wxindex.php
Marian


Again, thanks, Wim

Hi
I am noticing a slight difference in the max temp displayed between the main screen and the history page the main screen is correct and is correct in the wdapi.txt but the history page is 0.1 low see attached image I also see the value is incorrect in the today.txt

http://ballaugh.no-ip.biz:2082/pws09/index.php

some time I notice the min temp is 0.1 higher on history page


today26092019.txt (7.81 KB)

WDapi26092019.txt (354 Bytes)

I will check this when I am back home on Monday
Wim

hello

on my template no discrepancy for the TH on the other hand, it is currently raining on the station and in the page “history” I still have the value “n / a” ?
thanks and have a nice week end
Regards


pwsWD.PNG

so far today its ok just to prove me wrong but will keep an eye on it till you get back

Hi
FYI today the max temp is 0.1 low min temp ok I have also noticed the pressure is wrong max is 0.1 low and min is 0.1 high, have attached WDapi.txt and today.txt files for today


WDapi.txt (357 Bytes)

today.txt (6.98 KB)

The history file is generated using your upload-file current-temperature. In your case the WD-API field “temp [ 2] => 14.2”
Every time the station-cron runs the most recent temp-value is (1) written to the today.txt and (2) used to update the history using the original units from your upload file.
The other temperature fields are NOT used. It is the same for all other weather-values.
The history file highest/lowest values for this day should be the same the same high-lows as in the today-txt file.

Your realtime upload WD-API has a higher frequency (every minute?) then your station-cron which runs every 10 minutes.
During that 10 minute time the increasing/decreasing temp occurring in that period can be missed, in your case you found 0.1 degrees differences.

Wim

            [rain_day_in] => 0.0079
            [rain_month_in] => 2.5276
            [rain_rate_day_high_in_per_hr] => 0.0079
            [rain_rate_day_high_time] => 5:00am
            [rain_rate_hour_high_in_per_hr] => 0.0000
            [rain_rate_in_per_hr] => 0.0000
            [rain_rate_month_high_in_per_hr] => 6.2126
            [rain_rate_year_high_in_per_hr] => 64.7953
            [rain_storm_in] => 0.5669
            [rain_storm_start_date] => 9/13/2019
            [rain_year_in] => 23.4252

When using the weather-data data from weatherlink.com there is no value to use for the “current” rain value.
For the other weather-programs we can use “last-hour” rain as the “current”-value

Wim

I think I got that
WD unfortunately does not have a 5 min option to do the station-cron job which may improve the error

Just noticed that the temp module is the only one where the variable names and values in left and right columns are both in bold: usually the name is in roman (regular) and the value is in bold.

And there’s always an exception: “Wind” at bottom right of the Wind|Gust module is also bold. . . :?

Is there anyone else using wunderground for their graph data? No data is showing after September 3rd. I’ve seen a couple of other stations with a similar issue. I know it’s not the template as another script shows the same, so I wondered if anyone knew what was up?

If WeatherUnderground will restore the access to your data in the “old way” (using .csv) is still uncertain even after nearly a year of conflicting information.

Multiple stations have no access to their stations-CSV-data from different dates. Others still have full access.
My station IVLAAMSG47 was out a few times for a few days bur returned to “normal”. Others have had no problems at all.

So I think we should wait and see. I postponed the roll-out of the October release to the end of the month, just to see if things clear up.

=== _wu_to_mydata.php and _wu_to_mydata.pdf

As you post this question in the beta-discussion, I assume you installed the beta-October version?
This script in the (current) beta release will convert the WU-yearly .CSV to your own year/month-.txt files and retrieves the missing days from WU using the API.
You can then adapt your easy-weather settings to use your own data for the graphs.

But I still “hope” that the WU-programmers will get the old .CSV generating scripts working again for all users.

Wim

:oops:

I’ve been lucky :slight_smile:

I postponed the roll-out of the October release to the end of the month

Still time for a few comments, then? (I don’t run the beta version, I only look at yours.)

  1. Heading not centred

  2. Orphan full stop in Current Conditions

  3. degree symbol for wind direction


heading.png

fullpoint.png

degree.png

And extratemp shows


extratemp.png

extratemp2.png