migrate to new api for weather.py
Closed this issue · 9 comments
With the demise of the free Wunderground API weather.py is broken. Opensprinkler has moved to openweathermap.org, perhaps this would work for OSPy as well?
I got some mail long time ago, but stuff kept on working so far.
Did the service go down today or something?
I'm short on time, but will need to address it for sure before the summer ;)
If you have any suggested implementation, feel free to make a PR :)
Free api access ended Dec 31, 2018. Already playing with the openweathermap api. Offers 1 to 16 day forecasts. I'll take a look at code changes. Something interesting is the availability of the wrapper library PyOWM. I'm using this project to learn so I might be done by summer. :-)
My (developer) API key still seems to work, but OSPy is giving some error regarding the weather.
At the same time my other automation that uses the same key does still work, weird...
As a learning exercise I went through and commented the heck out of the code in weather.py.
How did you decide on the mappings in cloud_coverage{ } and the modifications used in _calc_coverage() in weather.py? Since every service uses it's own nomenclature those mappings and adjustments will have to be retooled.
Or I could buy a little weather station and contribute data to wunderground to maintain api access ...
I just started looking at the work needed to migrate the API and using this site I concluded that Dark Sky API is most likely providing the best free data. Also because it provides 7 days forecasts, historical data and allows 1000 calls per day.
Any objections?
That is interesting because as of last week I was thinking the same thing. Their 'time machine' looks like it may make things easier since you can get data forward and backward within the same query.
I've seen concerns over the accuracy of various services but I don't think that is so important here since the code is already doing estimates over an extended interval.
The API is indeed nice and simple and it also includes cloud coverage as number, so no need to guess that value based on text any more.
The time machine is indeed easy to use for all dates, but I will use the forecast to get future data. This single API call can return me hourly data for the upcoming 7 days, while with the time machine I need to query each day separately.
I started implementing the API yesterday and I think I'm halfway. I now do the geolocation lookup using OpenStreetMap (no API key needed) and I can retrieve both from time machine and forecast already. Just need to update all dependencies to use the new data format.
Wow, fantastic. I'm still stumbling. Learning, but still stumbling. Got any other stuff you'd like someone to look into but otherwise don't care if/when it actually gets done? Perhaps a smaller bite than this.
I program for my work on a daily basis, so don't be surprised in case you're still learning ;)
I think right know the most valuable might still be to add i18n support (#90). I'm perfectly fine using only English, but I can imagine that some people would like use their native language.
Not sure if it's small, but Martin already made it in his fork, so you could try to use that as source of information. And if you get stuck, let me know and I will see if I can find some time to help out.