Please test attached script
(But I haven’t worked out why max wind time was still showing 14.20.)Around midnight there is a lot of housekeeping for a weather-program: min/max today, yesterday values, optional min/max month/year a.s.o.
All OK this morning
Wim
wind_c_small.php.zip (2.31 KB)
Sorry, it’s not right when I really look at it: the depth is always reported and shown in km, so the depth units have to stay in km whether the distance is shown in miles or km.
Done and thank you for the solution Wim
Seems to work OK, at least the gust does not disappear altogether. Screenshot wind.png taken at 0001.
Around midnight there is a lot of housekeeping for a weather-program: min/max today, yesterday values, optional min/max month/year a.s.o. So it is often that until some time ( 1/2 hour) not all values are initialized. The times will be correct after the first non-zero measurements.
I guessed as much when I said
It seems that neither %maxavgspdt% - "maximum average wind speed time" - nor clientraw [135] - "max gust today time" - is reset at midnight.
Waited until 0015 - wind15.png - but no change to times. It’s past my bedtime 
Hi Wim
Under the Current conditions This Hour it has the temp at 30c but the actual temp is 10.7c, I am not sure where that temp is coming from.
http://www.mangawhaiweather.co.nz/pwsWD/index.php
Thanks
Tony
There are two parts: The top part is, in your case, the current conditions from WeatherDisplay.
The bottom part (with the 30C) is the current “this” hour forecast, from DarkSky.
Add a DarkSky key and that information will also be current,
Wim
There are two parts: The top part is, in your case, the current conditions from WeatherDisplay. The bottom part (with the 30C) is the current "this" hour forecast, from DarkSky. Add a DarkSky key and that information will also be current,Wim
Thanks Wim.
Today I have sent the following to WU.
Exciting if there is a solution.
Hello
I have a weather station
IDKFREDE2
which sends data to WU.
I have found some mystifications.
When I want to get data for this year here
https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IDKFREDE2&graphspan=year&format=1
stops data by July 25.
If I want to get data for August here
https://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IDKFREDE2&graphspan=month&format=1
I get a file with no data.
Data for July 25 as here
https://www.wunderground.com/dashboard/pws/IDKFREDE2/graph/2019-07-25/2019-07-25/daily
says there is no data. This is mysterious as both maximum and minimum values are present.
Year and month data should be used in this template
http://weather.inaogmogens.dk
Can you fix it so I can retrieve my data again?
(I know I have problems with correct temperature display, but shouldn’t that be the cause of these problems?)
Kind regards
Mogens
normally re uploading the data to WU would sort it
you do not say what weather station you have or what software you use
Data is present at WU - except for July 25.
See
https://www.wunderground.com/dashboard/pws/IDKFREDE2/graph/2019-08-4/2019-08-4/daily
Scroll down and click “Previous”
WU simply does not send data on request.
WU knows both weather station and software.
Click the round “i” next to “IDKFREDE2” at the top of the same page.
This is not a HWS or script problem on our side.
This is a problem on the WU/TWC site where the two databases, old-WU and new-TWC are not always correctly synchronised.
Check these and other discussions on the wx-forum:
and on the WU forum:
https://apicommunity.wunderground.com/weatherapi/topics/huge-amount-of-data-is-missing-on-pws-dashboard
I am 100% sure that they will solve the missing data for the API-json scripts corrected as they need that to populate the dashboard.
If hope they have time and resources enough to get the old .csv fully operational again.
But if we have to abandon the .csv, it is not a big deal for the HWS-template type scripts.
The .csv files are only used for the graphs and we should then use the 7 day API-json history and cache the data to obtain longer periods.
For now WU is slowly improving, we even have the decimals for our data back!
Wim
@ ONLY for WU - uploaders!
There were no problems during testing and WU itself is still using that “&numericPrecision=decimal” in their API-calls for the dashboard.
So I attach a folder, with the old version (just for safe keeping) and the current version of w34_load_files.php
Wim
wu_daily2.zip (18.6 KB)
I was looking at an American site today and could not help noticing that am/pm was treated differently in small temp and wind blocks?
Wim, does WD34 interpret the barometer setting that comes from the Weewx Cumulus realtime.txt file. It always appears high compared to the reading on WU and on my Acurite display. I realize this is probably a Weewx problem, but wanted to see if anyone has experienced the same problem.
My weewx site is https://klephtic-math.000webhostapp.com/index.php and my WU site is https://pendulous-here.000webhostapp.com/
Do you still have the url to the site?
Those times are coming from the uploaded realtime file and are processed in the same way.
I added extra code to the wind script end of July, but that has no effect for that site.
I have to check the upload file and see what the exact uploaded time strings are. And copy that file to adjust the code.
Wim
The scripts just display the values received. They recalculate if another unit is requested than the one in the upload-file
WU => upload file 1010.84 hPa / 29.85 inHg => displayed correctly on the dashboard for hPa and inHg
Weewx => upload file [10] => 29.89 inHg => displayed correctly on the dashboard for hPa and inHg
Maybe you are uploading station-pressure to the dashboard and the correct sea-level pressure to WU?
I see there is another discussion about this at Weewx and Acurite 02032C Barometer Reading
Wim
Owner is a regular visitor to the forum
Caused by a leftover from the “2017” version, adapted script attached,
@all only for WD-clientraw users who use this small block.
Wim
w34_livedata.php.zip (8.68 KB)
I went into the Weewx config file and had it subtract 26 from the pressure being sent via the realtime.txt. I’m not sure if that’s the correct way to do it, but it’s close.
