Incorrect forecast in customclientrawlocal [RESOLVED]

Software Weather Display for Windows
21

i have tested %5dayforecastday1% and it works OK here
what shows when you click on the main screen icon

22

Unfortunately still not here.

Sorry, but am currently in dumb mode. Have clicked on everything I can on the local WD screen and nothing brings up a forecast. My console and steel gauges pages are also showing the — for the forecast and no longer the incorrect “Today Mostly sunny. highs 78 to 81. northwest wind 5 to 15 mph.” that it was originally.

Thanks.

23

if you had the original method of downloading a NOAA5 day forecast file working then clicking on the main screen icon should have brought up the 5 day forcast screen

what do you have set for the lat/long point in the new nws api setup
(try setting that to the default test, which works here:
38.96,-94.62)

24

Still don’t know exactly which icon that is.

I scaled back my input to 2 decimal places (which is why I asked specifically about decimal places in Incorrect forecast in customclientrawlocal [RESOLVED] - #12 by jgillett - Weather Display for Windows - Weather-Watch Forum) - that has fixed the problem and the correct forecast is appearing where it should. Please note that using the proper weather.gov method, which you have correctly added with your setup link, results in the following snip from the URL…

lat=33.448377164000476&lon=-112.07403634999969

I’m NOT saying take yours out to 12 places, but I think at least 4 decimal places would be more accurate.

Thank you for your patience and fix.

25

The conditions icon above the clock (I think)

26

You win the prize, Martyn! Prior to the fix I did try that icon. The window that now has the forecast was just a blue background and, of course, nothing to indicate ‘forecast’ should be there. It has the wrong city, Guadalupe instead of Phoenix, which is why I was asking for a few more decimal places. Will try messing with the settings.

Thank you.

27

there is no restriction from WD on how many decimal places to use in the api url
using that many obviously then does not work …that is a NOAA API problem and not a WD problem

I had the example default one at only 2 decimal places as a guide to what to enter
I did not realise you were entering that many (which is why I started to suspect where the problem is)

28

If it were a NOAA problem then Ken’s forecast script would fail. As mentioned, what I showed is what is returned from weather.gov in their URL, not used in your API.

Again as mentioned I initially used only 4 decimal places in the WD API. It was not until I did nothing else but change that to 2 decimal places that it started working.

Simply to try and straighten things out, not to start a ruckus… :smiley:

Thanks.

29

John: I assume you are referring to Ken’s latest json forecast code, version 5. As I read that code it has a function that converts the user entered lat/long to 4 decimal places to send to the API. I won’t post the whole code section but you can search for the comment;

“NOTE: the lat,long must be decimal numbers with up-to 4 decimal places and no trailing zeroes
that’s why the funky code”

30

Thanks, niko. The “fine print”. Interesting that weather.gov puts out 12 decimal places.

31

Yup, I was installing the latest version today and noticed that the example new style url “https://forecast.weather.gov/point/37.2639,-122.022” in the code gave a 404 in a browser so there had to be something “funky” happening later in the script. :lol:

32

You’ve probably seen http://discourse.weather-watch.com/p/504369 but just in case. I had to redo my entire $SITE[‘NWSforecasts’] section yesterday. Result was a completely different URL than I previously had.