Sorry I’ve been editing my post as I do research.
No problem!
But the correspondence above led me to look at the Gelderland beta site too, where I found the column headings “Temperature” and “Feels” in WU Forecast Details to be quite confusing. They seem to be alternating max-min/min-max temps?
Think this is one for Wim!
The rain% went up to 23% at the hour change, which matches the forecast. At any rate this is a bug because the current conditions box should not be showing any forecast data.
Yea, mine is way off too.
Darksky seems OK for temp, but is missing precip in daily, and feels & precip in the hourly
The Current Conditions are only the icon and the text beside it. Below that your block says “This hour:” and mine says “Hourly Forecast”.
Not just because the moon sets twice but also because it sets at the same time (00:00) in Edinburgh and Gelderland.
This has always been so, “by design”
I could add a horizontal line or similar.
And one can use the language file to translate it to “1 hour forecast” or “This hour expected”
Wim
I currently (2019-04-07 21:15 CEST) see no problems
The problem is that I can not filter on a 00:00 value as that can be a real value also.
I will put it on the TO-SOLVE list.
Wim
Thanks, but the problem is that I have to find a better solution then adding every language.
This problem and a few others are the reason that i am not releasing the April version yet.
As a stop-gap I want to add 1 extra language in the settings which replaces the 1st one.
Still have to do some testing to make it smooth.
Wim
Yes, there is sometimes/often “weird” data in the WU .json file.
Debug console http://wd34.weather-template.com/pwsTEST/w34_module_test.php
=> contents of “./jsondata/wufct_en_m.txt”, processed as filetype “.json encoded file”
[temperature] => Array
(
[0] =>
[1] => 6
[2] => 20
[3] => 5
[4] => 15
[5] => 2
[6] => 12
[7] => 1
[8] => 11
[9] => 1
[10] => 11
[11] => 2
)
[temperatureHeatIndex] => Array
(
[0] =>
[1] => 20
[2] => 19
[3] => 17
[4] => 14
[5] => 13
[6] => 11
[7] => 10
[8] => 10
[9] => 9
[10] => 10
[11] => 9
)
[temperatureWindChill] => Array
(
[0] =>
[1] => 6
[2] => 6
[3] => 2
[4] => 2
[5] => -1
[6] => -1
[7] => -2
[8] => -2
[9] => -2
[10] => -2
[11] => -1
)
I expect it to get solved by the WU-programmers
But as long as it is beta I leave those strange values in, to check if it is improving (probably) and if the language/UOM selection makes a difference (no ?)
Bear with me and a “beer” for the solution
Wim
It was, here, the day before that! Or very recently, anyway.
But presumably not in Gelderland?
The last version tried to catch the 00:00 extra lines with the minimal difference between rise and set.
That did not work today. The site I always check the generated rise/set times is Moonrise, Moonset, and Moon Phase in Brussels
I updated the script and tested the attached version with:
WU (= latest test version) https://www.weerstation-herent.be/pwsWU/
pwsWD version Leuven Home Weather Station (wf version)
pwsTEST version http://wd34.weather-template.com/pwsTEST/
The next date we have to check is April 21 → 24
Wim
moon_popup.php.zip (5.92 KB)
Just an idea…might help with the time problem…
The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds (in ISO 8601: 1970-01-01T00:00:00Z)./code]
The script does not return a real zero, as for 1970-01-01 T 00:00:00
It returns the unix timestamp for “this-day 00:00:00”
The problem is that there is no way to check if the “this-day 00:00:00” is a real moonrise/moonset or not.
So for now all 00:00:00 moonrise/sets are skipped.
There are 246060 seconds in a day.
There are about 20 active users of this template.
Once every (246060 / 20) moonrises/sets, it will happen that a correct moonrise/set at 00:00 will not be printed.
It will not happen in April/May/June.
Conclusion: ample time to find a better solution. 
Wim
Good luck!
Released the beta version April 9. => http://wd34.weather-template.com/beta.php
It has the selection of your own language file, see attached screenshot.
I will shortly write the readme, but for now
- You have to create your own language text-file and give it the name lang_xx.txt
- In easyweather setup select as template language “Your language”
- Set the locale for your language, it is only used by one script, implementation in webservers is not reliable, if in doubt use en_EN
- Set the name to be used for your language
Wim
Wim,
One small thing I found was in the barometer block. Using clientraw file baro trend wasn’t being converted.
I changed w34_livedata.php line 508 from
$weather["barometer_trend"] = $wd[50];
to
$weather["barometer_trend"] = convert_baro ($wd[50],$from,$to);
Tom
In production version, too: I’m getting trend 2 hPa and 2 inHg.