'Unauthorized'. That means OWM is not accepting your API Key. There are two possible API Keys that this driver can use. The older 'Legacy' OneCall 2.5 API Key (that is no longer issued) and the new (current) OneCall 3.0 API Key. You must set the API Key switch to the Key type you have (2.5 or 3.0) A 2.5 API Key will not work on the 3.0 endpoint and a 3.0 API Key will not work on the 2.5 API endpoint. I am told that you may have key new 3.0 API Key, however if you did not input payment information that API key will not work.
You will need to correct this before any data will be received.
For some reason I thought using the OpenWeather Call API 3.0 was free for limited calls, at least that's what it states on its website 1,000 API calls per day for free. I guess I misunderstood the usage?
Hi @Matthew or @thebearmay I must be missing something on the OWM site. I have registered, got my API key but I can't figure out how to add to my account my credit card, "so that they can bill me if I exceed that amount." that is1,000 API calls per day for free .
All I can find is " Please fill you billing information for subscription — "One Call by Call" subscription, Base plan, 0.15 USD per 100 calls (VAT is not included)" which any way does not let me change the Country from the United States (I am in Canada). I see other plans Startup, Developer, etc. don't think that is what I am looking for...?
I am NOT an expert on the setting up the new 3.0 API. If I go to their website and click on the link to subscribe to OneCall 3.0 it takes me here. If that doesn't get you what you need then you may need to contact OWM and ask for their assistance. Good luck.
Thanks @Matthew, I did get to that page but could not change the country. My hope was I was missing something obvious, maybe a different page for the free registration that someone had come across. I will reach out directly.
No. Each poll, regardless of the number of attributes you use from that poll, is a 'call' to the API. The number of polls done is based on what you set in these parameters:
I have used a daytime polling intervals of two (2) minutes and a nighttime polling interval of 15 minutes. Conservatively, that should be approximately 18 daytime hours x 30 polls per hour = 540 polls plus 6 nighttime hours x 4 polls per hour = 24 polls, or a grand total of 564 polls per day. A little more than half (56%) of the of the '1,000 calls per day free' limit. I chose to do this so the Lux is quickly updated during daylight hours, and the frequency is reduced when Lux is not as important (nighttime).
Thanks for the good reference from the OWM site. I agree that polling more often than the site has updated data is not meaningful. Different locations do appear to have different update internals (how often OWM refreshes their data). The location I poll does appear to update more frequently than 10 minutes (however, it has been several years since I have validated that). Since I am staying well below the 1,000 polls per day I have not checked it recently.
I wonder if your issue is the night schedule is not kicking in as there are issues with sunset time. Check the logs. That would explain you exceeding the 1000 per day.
No one has reported any issue on this. There were issues with the Sunrise-Sunset.org poll in general failing, but that has been removed from the driver. No issues reported since that happened.
I have mine set for 2mins daytime and 2 minutes night time.
So really, it should be 30 polls per hour x 24 hours = 720 polls per day/24hr period. Still below the 1000 call Limit
I've been using the OpenWeatherMap driver since switching to Humitat from SmartThings. I have my latitude/longitude set correctly, and for the most part, the weather is generally reliable and matches other sources of weather that I can retrieve for my location. However, I have several variables that randomly seem to report incorrect during some data refreshes. For example, my Ecobee thermostat was announcing to open all the windows at home since it thought the weather was favorable, but it was not. This was followed soon after by a message to close all the windows. In looking at the weather device event log, I can see that the dewpoint was hovering in the upper sixties all day, but for two isolated moments this morning, it got reported in the low fifties which triggered some of my automations. Any knowledge about what causes this or how to fix it?
Same thing happened yesterday too where several data refreshes pulled inconsistent data, and then it returned to normal again.
