PiClock: Weather Underground no longer provides free API Keys
Weather Underground no longer provides API Keys for free, and I have tried replacing the config URL with a separate free API service and put in a key to the ApiKey.py file, but no weather data appears. I also get a Json decoding error -
raise ValueError ("No JSON object could be decoded")
Value Error: No JSON object could be decoded
The Clock and Map data work, but no radar or forecast data appears. Any solutions?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 73 (24 by maintainers)
My fork works within the US. I use open weather and weather.gov as providers (both free). It is based on node.js though, and is a significant deviation that may require a “reflash” of the pi.
https://github.com/merky1/PiClock
I would pull into this repo, but the python vs. node difference is pretty significant.
I used nodejs in my fork. I figured better to fork than to rationalize python vs js. I guess I should have done Perl, but everyone calls me old for using that.
I’ve updated the instructions. I’m close to closing out this Issue. I’m going to create a couple more for some future changes.
@merky1 7 above, 11 below
@merky1 - looks like I’m going to have to cut over to your implementation before that date!
Do you have a list of stuff that isn’t working yet (areas where it deviates from original PiClock)?
Weather Underground’s API’s end of service was announced here: https://apicommunity.wunderground.com/weatherapi/topics/end-of-service-for-the-weather-underground-api
Additional information for personal weather station (PWS) owners will be forthcoming.
Feel free to direct questions about the API to me via private email or on the WU Forum.
Victoria Gardner victoria.gardner@ibm.com
Easy first - mesonet is a us government grant that takes the NEXRAD data and cleans it up. Otherwise, the raw radars return too much “noise”. US only though…
X,y is part of the google maps get tile function based on the map display. Basically does the math for me so I don’t have to figure out bounding boxes. I’m sure similar functionality exists in python. The only “work” I put in was a way to cycle 5 minute increments over 20 mins.
Ok - no warranty, may cause universe implosion. Use at your own risk. standard GPL.
Here is my extremely early work. You will need to adjust the lat / lon in both the .js and index.html. piclock.js will need your openweather api key. index.html will need your google maps api. Eventually I will clean up all the js in the index.html, but I only spent part of the weekend on it thanks to a sprained ankle.
install instructions (wholly untested): 1 - install chromium-broswer 2 - install node.js 3 - npm install request cron 4 - node piclock.js 5 - nohup chromium-browser --kiosk http://localhost:8081 &
“should work” radar images are CONUS only as far as I can tell. Direct pulls from weather.gov included way too much radar noise. Resolution is less than optimal. Animation is not implemented yet. I just refresh current every 5 minutes.
Sorry, hate to spam. I pulled together a few things, and wrote an example using node.js as the backend and HTML / JS as the frontend. Mainly because that’s what I work on all day. I merged openweather and weather.gov data, so it is definitely not ready for prime-time. I am also trying to work out the map / radar layers, but there is no weather today, so the test is invalid.
I’m not sure if this approach is maintainable, but it does validate that the datapoints exist. I’m also not sure of the etiquette (fork project/generate a new one/etc) to share this out.
Latest screenshot taken off of a RaspberryPI LCD (800x480) :
After running temp grabs over night, it feels like openweather may be the best replacement. Aeris limits to 750 calls per day, and seems laggy. It felt that Aeris was really just pulling from weather.gov, where as openweather had additional sources to pull from.
My vote has switched over to openweather, at least for current observations. temps.zip
temps.zip
weather.gov - pros - least likely to change over time (gotta love USG) cons - CONUS only.
aerisweather.com - pros - seems to be a drop in replacement?
cons - could be back in the same situation in a year.
openweather.com - pros - the price is free!!! still referenced by google?(not sure if this + or -) cons - sketchy / delayed weather
I like the weather.gov approach, but then I’m a greedy fat 'Merican 😃. Not sure how much time I have to parse the code, but I remember going through it 6-8 months ago when wunderground radar API lost reliability. That and as a native PERL coder python gives me a rash 😃
EDIT: weather.gov is highly unreliable for current observations. I just polled weather station KJYO for 1 hour, and got results that were “stale” | null | or just plain wrong based on every other API provider I use including the thermometer outside. Frustrating, since I would have thought weather.gov would be more likely to keep things accurate.
OpenWeathermap.org’s free API says that it updates weather api information “< 2 hours” so… If the radar image is 2 hours old this is simply not workable. Even the current temperature being 2 hours hold is pretty useless.
Looks like current API keys still work.
It’ll take a bit of time but I’ll need to pick out another provider and make it work with their api.
The forecast is easy to find a replacement provider. Good radar providers is harder.