I’m sure I’m missing something with this so hopefully a quick and easy one.
I’m trying to setup the Open Weather Map integration. Registered with Open Weather Map fine and all setup with the API key.
Configuring the integration on HA (docker install tried on 22.7.5 and 22.8.5) just gives an invalid API key error. Initially I didn’t worry as the HA notes say it can take between 10 minutes and 2 hours.
What I’m seeing though is I get a successful API call with the weather data if doing from a command line (simple wget) but it still fails on the integration setup in HA.
It looks like OpenWeatherMap may be moving further through the process of deprecating the 2.5 API set in favour of the 3.0 set. (At least if this is right.)
And here is what I think is happening now:
OpenWeatherMap website is providing 3.0 access for new API keys generated. No access to 2.5 API set. (If I try a manual call to a 2.5 API I get an authorisation failure but calls to 3.0 APIs work.)
The OpenWeatherMap integeration in HA uses pyowm (3.2.0 although current version 3.3.0 has the same behaviour) which appears to be hardcoded to the 2.5 API set for the onecall APIs.
The HA documentation/links muddy this a bit further with the integration config taking you to a page that refers to 2.5 (but links to the main registration page) while OpenWeatherMap - Home Assistant takes you straight to the sign up that I went through and landed me with 3.0 only access.
I am having the same problem as the OP. I am able to access the API directly from a web browser, but not able to get the integration to accept the API.
So openweathermap have come back and stated that from their perspective, One Call 1 (aka API version 2.5) has in general been replaced by One Call 3 (aka API version 3) and that is the reason the the authorisation failure to the 2.5 endpoint.
Interestingly, pyowm appears to recognise they are using legacy endpoints based on their documentation but don’t appear to have made an move to adopt the 3.0 APIs. My suspicion is the HA plugin may stay broken until pyowm gets fixed.
Provided you’re not after anything more than tinker/hack then maybe. Reading code enough to understand why something is broken and being able to hack it to fix my problem is a whole different ball game to getting something up to the level for a PR that lands in PIP and who knows where else around the globe while not breaking other peoples usage…
The pyowm code structure wraps onecall up inside the broader weather API set. Openweathermap have not deprecated that (so /weather works at 2.5 while /onecall doesn’t) so it’s not even a case of updating the whole weather module to v3 and change it’s parsing code. One-call probably needs to be pulled out to a separate module as things like the pollution and agro APIs have been.
There is a ticket raised directly against pyowm but no response on that yet from the owner. Given they can undoubtably do a better job than me both knowing their code (let’s face it, Github isn’t the best place to find design docs, test approaches etc) and being a better Python user I’d rather give that route a chance.
Who knows though - maybe I’ll get bored next week at the out-laws…
Edit:
Curse you @nickrout ! My curiosity has gotten the better of me and it looks like pyowm may have a reasonable automated test setup so that’s one less excuse I have!