So we’re going for the 2.5, right?
From what I understand, it’s a different subscription for One Call with billing for more than 1,000 API calls per day.
I will add the subscription to run the test
If they ever ask you for a credit card, don’t enter one — we need to find a simple solution that doesn’t require a credit card 
I tested oncall v3 with my API key, and indeed:
{"cod":401, "message": "Invalid API key. Please see http://openweathermap.org/faq#error401 for more info."}
Okay, I created a new account to test, and:
By default the new account doesn’t have access to the hourly API, nor to the daily forecast..
J’ai pareil avec mon vieux compte
Indeed, a false alarm! ^^
Ah! Well, we’ll have to adapt Gladys..
And additional forecast data for the new keys because the weather route doesn’t return it.
https://api.openweathermap.org/data/2.5/weather?lat=47&lon=1&lang=fr&appid=XXXXXXXX
{
"coord": {
"lon": 1,
"lat": 47
},
"weather": [
{
"id": 804,
"main": "Clouds",
"description": "couvert",
"icon": "04d"
}
],
"base": "stations",
"main": {
"temp": 308.27,
"feels_like": 306.21,
"temp_min": 308.27,
"temp_max": 308.27,
"pressure": 1007,
"humidity": 19,
"sea_level": 1007,
"grnd_level": 992
},
"visibility": 10000,
"wind": {
"speed": 2.26,
"deg": 120,
"gust": 4.1
},
"clouds": {
"all": 94
},
"dt": 1662994709,
"sys": {
"country": "FR",
"sunrise": 1662960572,
"sunset": 1663006528
},
"timezone": 7200,
"id": 2987855,
"name": "Perrusson",
"cod": 200
}
Good evening,
Reading the discussion didn’t allow me to find the solution to integrate the weather. There are many offers on the site; which one should I choose?
I get this :
Hello. You have the step-by-step documentation here OpenWeather | Gladys Assistant
Good evening,
I will review the procedure and start over from the beginning. Thank you.
Hello you two!
Indeed, OpenWeather changed its offering, the API call we use (OneCall) is no longer available in the free plan (they changed it on their side..) 
We’ll need to adapt the Gladys integration to use the free API calls, we’ll probably have less information though.
I created a GitHub issue:
Otherwise, on OpenWeather’s side, the endpoint we use is available in « Pay as you go », with 1000 free API calls/day, the only catch is that you have to enter your credit card:
If anyone drops by and wants to propose a PR, I’m interested, I already have a thousand things this month on Gladys and I hadn’t planned this dev at all!
Thanks Pierre-Gilles for your feedback
I did a bit of digging (and tested it in real life).
In the free tier now, we effectively have access to:
- Live weather
- Next 5 days in 3-hour increments
So the things we’ll lose compared to the current development are:
→ No more hour-by-hour, only 3-hour increments
→ Forecasts for 5 days only
For forecasts for the following days, we’ll also have to do a little workaround, because until now we had a « per day » prediction, and now we only have « 3-hourly » forecasts.
But that’s not the same thing! When we see « 26°/27° » in my screenshot, does the number on the left correspond to the day’s lowest temperature and the one on the right to the highest? If so, we need to compute that by iterating over the day’s 8 predictions.
Management of existing users
All users who created their token before this change still have access to the old API.
2 options:
- We code a special mechanism for them to keep the existing code so that users whose key works with the One Call can still use the full API. Need to see how to determine the « old » tokens from the new ones.
- We switch everyone to the new API, which causes a regression in terms of features for existing users.
Option 1 is preferable, but requires more work.
For detecting « old vs new », several approaches:
- Use the creation date of the variable in the DB
- Test both API calls; if one works and the other doesn’t, we can store somewhere (DB or RAM) whether the user is new or old
Hourly (hour-by-hour) via Gladys Plus?
If there’s demand, I could pay for the One Call API via Gladys Plus and offer it to Gladys Plus users. Then again, I’m not sure it’s worth it just to have hour-by-hour on your dashboard, especially since we all have free weather apps on our phones…
We lose the benefit it could have of knowing the weather in advance, for example for controlling roller shutters, awnings, alerts, or weather-based automations. So it’s a real plus!
Maybe consider other APIs, for example 7 Reliable Weather API Solutions for your smart products
Hello @pierre-gilles ,
That’s where the interest lies in being able to connect to your own outdoor station for those who have one like me (cf. my requests a while back… about the Bresser station) but the drawback is these stations now tend to transmit their data via the box to a third‑party client (Weather Underground for me) which obviously must give us access to our own data (via an API)
That’s why you suggested at the time — and which I implemented — to go through Node-RED and MQTT.
And it works very well!
One caveat: some data that I can retrieve via Node-RED cannot be returned (even though useful) in Gladys because the formats are not compatible with the formats offered in the MQTT devices(fake) features, notably the « inconnu » feature, and here I’m talking about things I’ve already raised and for which I recently formalized feature requests (support for a text format that I will supplement with a date format, not having a value-range enforced by default for features) but also the request I made about graph rendering so that views longer than 24 hours can be max, min, … and not averaged values as today.
I’ve been a bit long-winded, I hope this remains understandable and that you can tie it back to my previous posts on the subject.