Hi,
I have a Openhab3 installation and tried to integrate the OpenWeatherMap Binding to read information using the OneCall API.
I Subscribed to the OneCall Plan on their website and I am also able to receive data using the API call with a created key:
Unfortunately, when I create the Bridge and the OneCall Thing in Openhab, the bridge as well as the OneCall thing states change to âOFFLINEâ.
In addition to that, I can find the following text in the openhab log (Invalid API-KEy, Error 401):
2022-08-21 10:59:38.823 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'openweathermap:onecall:api:local' changed from UNKNOWN to OFFLINE (CONFIGURATION_ERROR): UngĂŒltiger API SchlĂŒssel. Mehr Infos unter https://openweathermap.org/faq#error401.
Is someone familiar with this problem and can help me out? I would really love to use the OpenWeatherMap binding and weather data.
If you need any more data or logs to invastigate, just let me know.
Ensure you have access to the service from your Raspberry (e.g. âping openweathermap.orgâ on a shell). That should eliminate network issues.
Create the openweathermap bridge via UI. Creating things that way is far less error prone than doing it in a textual file. (Saying that although I have everything else in files )
It should look like this:
Waited for the new Bridge to be online, only took around a minute
Added needed things again
The strange thing is, when I create the âweather-and-forecastâ as thing, everything works normal, bridge and thing are ONLINE afterwards.
When I add the âonecallâ thing in addition, the new added thing is first UNKNOWN and then changes to OFFLINE (CONFIGURATION_ERROR).
The bridge and the regular âweather-and-forecastâ-thing stay online.
After doing these tests, the situation looks to me like summarized below:
API-Key in general is working for OneCall API-Requests from the same raspberry (I can also see the number of received requests in my OWM-Account)
Bridge and Thing are correctly configured inside Openhab
Regular Requests are working just fine, only the ones using the OneCall App are returned with an error
Is it possible, that inside the Binding there is an error when creating the API-Request?
I donât really have another idea anymore why the normal API request is working and the OneCall request not, knowing that my API-Key is subscribed to the OneCall API.
Has anyone ideas how I could test the behaviour of the binding or where I could take a look into the code?
Iâve never looked that deep into âsystem behaviourâ until now tbh.
Yeah, this was also something I played around with quite a long time.
Just did another test to be certain, it does not matter what I put in there.
Below a screenshot with Number of hours and Number of Days set to â1â.
Hm, I am out of ideas âŠ
Itâs very long ago since I installed OWM.
If I remember right I did not add any thing manually.
I think they came up automatically:
As you can see my things having âlocalâ at the end, yours has just digits.
I donât know if this makes any difference.
I picked my weather and forecast thing from the inbox, the same as Christian mentioned. If that does not lead to a functional situation, my next suggestion is to enable DEBUG log level for this binding. There is a chance that the issue can be narrowed down further that way.
Changing the log level for the binding to TRACE, I could see the actual request.
When I enter this link in a browser (with the actual AppId of course) I get the same message like shown in Openhab (âInvalid API key âŠâ )
After further testing in a web browser I found out that the number â2.5â in the bindings API Request seems not to be correct anymore (at least in my case with a brand new subscription). When I change it to 3.0 like shown in the OpenWeatherMap template, I receive the complete list of Items in my browser.
Is there a way to change this in the binding somehow or is it possible the binding needs an update?
At the moment Iâm just glad I found out what is wrong, it was my second open problem I diagnosed today
Congratulations Although you donât have a solution or a workaround yet, you found the root cause.
If you canât find an configuration to work around the issue, my advise is to check the existing issues at openhab-addons if there is already an issue matching your finding. If not, open one.