You seem to using a API 2.5 key with the API 3.0. That will not work. Only a API 3.0 key will work with the API 3.0 URL. Turn on 'Extended Logging' to get more meaningful logs.
If you would like assistance, please turn on 'Extended Logging' to get more meaningful logs and provide the errors you get. Thanks.
i can work the code myself and have.. thats not the issue.. just trying to point out to you that the 3.0 find call DOES NOT work as someone else also mentioned above and the new call is /geo.. if you dont want to look into that fine.. i have modified my code to work around it and was just trying to be helpfull.
Sorry. I really didn't understand what you were attempting to communicate. I re-read the thread and looked at the Extended Logging ..... and know I understand what you are saying.
I have updated the code to correct for this BUT I DID NOT CHANGE THE VERSION NUMBER.
If you updated within the five hours ..... If using HPM do a Repair. Otherwise open the driver code and re-import the code.
Thank you for your patience.
1 Like
Looks like my timing was terrible asking for something new, but thanks. Although I see these attributes
when looking at the device page, they are not offered when adding a dashboard tile.
It doesn't seem to matter if Display All Optional Attributes is on (and preferences saved) or not.
Apparently I forgot to declare the new attributes 
I just added that.
If using HPM do a Repair. Otherwise open the driver code and re-import the code.
3 Likes
Yep. That did it! Thanks a bunch!
NOTE TO USERS SWITCHING TO API 3.0
With the basic plan on OpenWeatherMap I did not get any updates after switching and saving to use the API3.0. Went to the OpenWeatherMap site and found out I had to upgrade to get access to API 3.0. Since I'm in Canada, this could not be done directly, had to contact support so they change my account in as being in Canada, after this I could finally upgrade my account to be able to make API3.0 calls. (note that you will need to give a credit card number to upgrade but you get 1000 calls per day free, so make sure you limit your refresh accordingly).
After upgrading, all started to work again using the API3.0, no need to change your API key.
@Matthew maybe you should have some logging when calls to the API3.0 don't get anything back or something. Since I was not getting any errors in my logs, this went unnoticed for 2 days before we checked the weather on the dashboard and saw that it was 2 days late.
3 Likes
The main OWM API call in this driver is to the OneCall API. That is the one where the 2.5 OneCall API key will stop working in June and you must use the 3.0 OneCall API key after that.
In addition to the OneCall API, there is one section of the code that is NOT using the OneCall API. It is using a different OWM API described here. The only thing this API call does is obtain the OWM location code based on your LAT/LON. That API does have "2.5" in the URL, but it is NOT referencing the OneCall 2.5 API.
There is no indication that the URL for the API the code is using to obtain the OWM location code is changing in the future.
Thanks.
1 Like
@Matthew I'm having an issue getting a 400 Bad Request during the weather poll. I tried creating a new API same results, any ideas on what I should be troubleshooting. I'm subscribed to the 0necall 3.0 package. Installed using HPM, and already attempted a repair.
I cannot replicate. I get no errors. Only thing different is the API key. Suggest you reboot hub. If error continues then confirm with OWM customer support that API key is valid.
I created a new virtual driver and now it's pulling data without the error, but I'm seeing results that don't match the current conditions showing on their website, odd. Humidity and Temperature specifically.
Could be a browser cache issue? Clear your cache and refresh. Hit Poll Data in the driver to refresh that data.
Tried that, same results. Almost seems like it's pulling data from a wrong location? I tried overriding the hub location, but the results are the same.
I noticed one thing in your logs that looked odd. Your LAT looks like it has two decimal places (61.132.457)? It should only have one decimal (61.132457). I have no idea how that happened or what that may do to the results returned???
I just tried overriding the lat/long in driver and now the 400 bad request error is back. just rebooted to see if that helps
Check your 'Hub Details' under settings and make sure your LAT is correct there.
it is, also tried the built in driver same results so it seems something is wonky with the API not driver related.
