Open Weather Map (OWM) API 2.5 closing, switch to 3.0 API

Log into OWM. If, under “Services” it doesn’t say “One Call API 3.0” and next to “Basic plan” it doesn’t say “Activated” you are not using the 3.0 API and what ever is possibly working now will stop working when the 2.5 API is shut down.

There is no way around it. If you want to continue to use OWM, you must subscribe to the 3.0 API and to do that you must enter your payment information, even for the free plan.

thx Rich…

sounds like I will replace another binding with some python scripts and some public API calls (which provide the same data, without registration etc. :slight_smile: :smiley: )

did that already with petrol prices, public transportation, severe weather warnings…
so I will do it with the ‘normal’ weather also…
found already some api endpoints :slight_smile: :smiley:

edit:
these sound really great …:

{
                        "dateTime": "2024-05-01T13:00:00Z",
                        "temp": 22.9,
                        "tApparent": 27.4,
                        "symbol": "2",
                        "precipitation": 0,
                        "precipitationChance": 0,
                        "windSpeed": 17.5,
                        "windGusts": 28.2,
                        "windDirection": 114.6,
                        "pressure": 1005,
                        "humidity": 44.9,
                        "sunMinutes": 60,
                        "sunElevation": 49.1,
                        "uvIndex": 5,
                        "snowCover": 0,
                        "snowFresh": 0,
                        "snowChance": 0
                    },
                    {
                        "dateTime": "2024-05-01T14:00:00Z",
                        "temp": 23.1,
                        "tApparent": 26.6,
                        "symbol": "2",
                        "precipitation": 0,
                        "precipitationChance": 0,
                        "windSpeed": 17,
                        "windGusts": 28.2,
                        "windDirection": 113,
                        "pressure": 1004,
                        "humidity": 43.3,
                        "sunMinutes": 60,
                        "sunElevation": 41.2,
                        "uvIndex": 4,
                        "snowCover": 0,
                        "snowFresh": 0,
                        "snowChance": 0
                    },
                    {
                        "dateTime": "2024-05-01T15:00:00Z",
                        "temp": 23.1,
                        "tApparent": 25.4,
                        "symbol": "2",
                        "precipitation": 0,
                        "precipitationChance": 0,
                        "windSpeed": 16.7,
                        "windGusts": 28.7,
                        "windDirection": 111.9,
                        "pressure": 1003,
                        "humidity": 43,
                        "sunMinutes": 60,
                        "sunElevation": 32,
                        "uvIndex": 3,
                        "snowCover": 0,
                        "snowFresh": 0,
                        "snowChance": 0
                    },

hourly forecasts, even also with elevation (which for me currenlty is comming from astro binding), uvIndex, sunMinutes (for each hour!!!), wind etc. etc…

edit 2:
where my next question comes in…
I have now 336 (14 days * 24 hours) json objects… how to get them effectively into things / items?
Http thing with 336 * 17 channels sounds a little bit weired to me…
any tips / hints / suggestions from your end Rich? how you would do things like that?
Maybe each day in a string channel and do the jsonpath extraction then in the items?

That’s kind of why bindings exist in the first place. They implement all that stuff for you so you just need to worry about linking to Items.

If you are rolling your own implementation, you’re going to have to do that work too. You will see that the weather bindings all have orders of magnitude more Channels than any other binding type, and that’s because they have so many values.

If that’s what it takes, that’s what it takes. To have a one-to-one relationship between Channels and Items you’ll need one Channel per value. You can have fewer String Items with JSON and use transformation profiles or rules to further split up the JSON and put the values into Items but all that’s doing is moving where the work is done, not reducing the amount of work.

OpenWeatherMap OneCall current and forecast Thing has support for sending TimeSeries, once I find the time to implement a way to access persisted states from widgets, you should be fine without the dozen of channels.
The persistence extensions are currently extended (core PR is already approved) to better support working with future states in rules, and since a few days, it’s possible to create have future charts in Main UI (before, you could always click to the future, but not have the chart default to a future period).


I will probably post a short tutorial how to create those weather forecast charts (requires some reading of Echarts docs).

@maDDin1338 I really recommend to just subscribe to One Call version 3.0, just set the daily API call limit to 1000 and you’ll never have to pay anything. And if you are still on openHAB 2.x, please consider migrating to 4.x — it is worth the effort.

2 Likes

@florian-h05 yep, but for a free service, I do not like or want to put my payment info there… that’s just the pure “for what” or data privacy question … same is for the petrol binding or the public transportation…
creating ton’s of accounts for (at the end) a api, which is mostly totally public and does not require an api key?.. :smiley: or at least, other providers do not require an key, but they deliver the same data…
I’m currently running on v4.1.1 … the chart stuff would be my next topic, after it would work… so if you put a tutorial, also I would be already very thankful :slight_smile:
found some 10 min’s today, currently now struggling with the JSONPATH query…
Would like to put a full day into a channel, but

Type string : forecast0 [
			mode = "READONLY",
			stateTransformation = "JSONPATH:$.data[0].attributes.hourly[:2]"
		]

results in:

20:55:31.633 [WARN ] [nternal.JSonPathTransformationService] - JsonPath expressions with more than one result are only supported for Boolean, Number and String data types, please adapt your selector. Result: [{"dateTime":"2024-04-30T22:00:00Z","temp":17.1,"tApparent":14.1,"symbol":"101","precipitation":0,"precipitationChance":0,"windSpeed":11.1,"windGusts":28.1,"windDirection":120.8,"pressure":1011,"humidity":46.5,"sunMinutes":0,"sunElevation":-24.5,"uvIndex":0,"snowCover":0,"snowFresh":0,"snowChance":0},{"dateTime":"2024-04-30T23:00:00Z","temp":17,"tApparent":13.7,"symbol":"101","precipitation":0,"precipitationChance":0,"windSpeed":14.8,"windGusts":21.5,"windDirection":124.1,"pressure":1011,"humidity":50.7,"sunMinutes":0,"sunElevation":-26.1,"uvIndex":0,"snowCover":0,"snowFresh":0,"snowChance":0}]

I do not rlly understand the error message… i’m selecting a array into a string… for string it should be supported… so…

edit:
just found some post from rich…:

maybe I should also put each single value into an own channel in the thing already…
hmm…

I did this with a virtual prepaid credit card (free of any charge)

yep, also thought on that “solution” already…

I think things got a little confused, because your comment followed someone else saying that they’re still on OH 2.4. Thanks for clarifying.

1 Like

I think I already hijacked this post completely… :frowning: I might create a separate post

1 Like

Given this is really off topic for this thread I request you open a new thread for help working through any technical issues you encounter working with this third party service.

Everyone puts values on things like privacy and their own time differently. But TANSTAAFL applies. If you are unwilling to use the service provided, you’re going to have to trade that increase in privacy or whatever for your time implementing the alternative approach. Personally, I value my time way more than any privacy lost by registering for an OWM account.

Note, registering for an account is not new. OWM has always required registering to get an API key. So it’s not like this is a new requirement.

3 Likes