Openhab-addons: [openweathermap] Feature request - support of the new One Call API

[MoritzMK]

Hey guys,

there is a new free route named one call api. Take a look here: https://openweathermap.org/api/one-call-api

It is included in the free api key and provides also daily forecast.
I think the implementation is a great improvement for all users.

I would do it by myself, but I started with OpenHab two days ago and I have too unterstand the mechanic of bindings first.

Regards
Moritz

[TRSx80]

I just started looking into this today. Initially, I had made a forum post about it. Now I think I found my answers. :smile:

I didn't dig into the code yet, but my initial thought is that the URL for the binding to call the API is hard coded, and since the new "one call" API has a different URL (and perhaps different mappings of returned data? not actually sure about that) it's going to be a matter of a code change, and not simply a config option. Or maybe we can add a url="bla_bla_onecall" to the openweathermap Bridge parameters? I have no idea, just spitballing here.

At any rate, I will put a link this issue in my forum thread, so anyone coming along looking into it in the meantime can easily see the status.

Thanks again guys for all your hard work. It is greatly appreciated (at least from me :wink: ) :beers: Hope you are enjoying your weekends!

[TRSx80]

An update. In the meantime some other forum users came up with idea for workaround of using the new URL in a rule and then doing JSONPATH transformation on the results to derive the data from the new format. Working example has been posted, and hopefully soon we should have full copy paste example with all items. All relevant info can be found in my forum thread I linked in post directly above this one.

[MPH80]

Just as a comment in case any one else is reading this - I've got a working (or I think it's working) version of the binding calling the onecallapi locally - I've put it into the forum post above to get some testers. It's been a while since I've done any java and I'm trying to work on some of the old warnings located in the files and tidy it all up before I consider putting a pull request in.

[MPH80]

Hi - so - feedback would be appreciated here. The main API calls have been updated and seem to be working fine in my test version. However, I'm now looking at the UV Forecast. This can now be retrieved as part of the OneCallAPI rather than a separate UV Call.

Me being me - I generally don't like to break people's working systems without warning, which I'd do if I decommission the UVIndexHandler and simply add a new channel to the Weather and Forecast piece - so I see two options:

1) I could (somehow) amend the UVIndexHandler to pick the data up from the WeatherAndForecastHandler (not entirely sure how yet).
or 2) I could add UV Channels to the Weather and Forecast Handler - meaning those who wanted to continue using the old one could, for a time, do that. But those content with how it's working can put up with the old call.

Thoughts - and I'm particularly looking at @cweitkamp here? :-)

Happy to open up a PR if you'd like to see the changes I've done so far!

[Wolfgang1966]

Hi @MPH80 , if there is a working tree to check out I may find time to have a look at it. I already thought about implementing this request also, as one or more new channels to avoid messing up the existing ones.

[MPH80]

Hi @MPH80 , if there is a working tree to check out I may find time to have a look at it. I already thought about implementing this request also, as one or more new channels to avoid messing up the existing ones.

I've created a pull request with the relevant updates in: https://github.com/openhab/openhab-addons/pull/8253

I'm not too upset by the loss of station ID and Name - nor the wind gust (this was always marked as advanced). The UVIndexHandler is tricky though. Removing it breaks existing code, but the way the objects are structured makes it trickier (without causing cross references or using a file cache) to share the data.

[cweitkamp]

I am voting for your approach to merge all existing thing types into one new thing type. For backward compatibility we could introduce a new one and keep the existing ones but hide them now and remove them later - there is a not documentation feature to do so (<listed>false</listed> in thing type definition, https://github.com/openhab/openhab-core/blob/29dfb967c4104b4e8caca72bd4286d72ff5d2413/bundles/org.openhab.core.thing.xml/thing-description-1.0.0.xsd#L40). This will buy some time for users to adopt their environments until OH3 will be available. The OWM binding is a very popular one and you will - to be kind - "annoy" a lot of users by removing something.

[MPH80]

:-) Yes - I'm very conscious of the annoyance factor on this one - I've hesitated for some time before getting up the courage to touch this binding!

Can I ask you take a look at the PR? I've basically done this - but I've left the local weather forecast object intact. I have had to remove the station ID and name - but those are the only major adjustments. Everything else is addition at this point (I was able to add wind gust back in). I've also added UV Index onto the current object and daily forecast - so if I just hide off the UV Index object - that would do it.

The challenge I have is how upset people might be about not knowing which station is providing their data. I have no idea! It doesn't bother me other than a bit of disappointment.

[bwosborne2]

"The challenge I have is how upset people might be about not knowing which station is providing their data. I have no idea! It doesn't bother me other than a bit of disappointment."

I think the key is to emphasize why this part was removed. Perhaps including an explanation (in BOLD if possible) in the Thing description.

[cweitkamp]

Can I ask you take a look at the PR?

I already looked into it. Not very deep but quick. I do not have much time at the moment. Sry.

I have had to remove the station ID and name

And that is a crucial point. I do not care about those values a lot but others do and they will not like it.

Beside the documentation the best and recommended way to inform users about breaking changes is to add a small hint to the update.lst in OH distro.

[bwosborne2]

Sorry, I am not a Java programmer & have not used this binding. I thought it might be of future interest for me though.

[MPH80]

Can I ask you take a look at the PR?

I already looked into it. Not very deep but quick. I do not have much time at the moment. Sry.

I have had to remove the station ID and name

And that is a crucial point. I do not care about those values a lot but others do and they will not like it.

Beside the documentation the best and recommended way to inform users about breaking changes is to add a small hint to the update.lst in OH distro.

No problem. I'll leave the PR where it is as it needs your review anyway and I'll remove the WIP notice on it as I think (other than the 'update.lst' update) it's done. It'll get merged when you're ready.

[Wolfgang1966]

Dear all, I started implementing the one call API access as two additional things, one for current data and forecast, one for historical data. As soon as I have a working beta (hopefully within the next days), I will update this thread.

This update should be backward compatible, so existing configurations will continue to work. On the other hand, to make use of the one call API config changes will be needed. Also, as @MPH80 already found out, not all channels of the existing things are supported in the one call API (e.g. stations).

[Wolfgang1966]

Update: A first version is now available for testing. Find the JAR and test configs here: https://home.klimt.de/owncloud/index.php/s/BgnsYtxAAYFcZ7f
Please update the thing definition with your API key and the location you want to test.

I did not yet test the minutely data or the history access, so expect problems there 😄

The current source is here:
https://github.com/Wolfgang1966/openhab-addons/tree/2.5.x/bundles/org.openhab.binding.openweathermap

I already updated a part of the README, but documentation of the history thing and extended example files are missing. I hope to be able to complete the work within the next days. Every feedback is appreciated!

Have fun!

[Wolfgang1966]

Tested (hopefully) all other aspects of the new things, especially history and minutely data. Found and corrected a few bugs. An updated jar and extended example config is available at
https://home.klimt.de/owncloud/index.php/s/BgnsYtxAAYFcZ7f

README is now also updated and contains examples for one call API configuration. Please test and give feedback.

I would like to open a pull requests latest one week from now, depending on the test results.

[bwosborne2]

Is it worth doing a PR for openHAB2? The next release may be the last for OH2.

[Wolfgang1966]

I would think so. It can always be ported to OH3 later on, but I think many users will stay with OH2 for longer as OH3 AFAIK will drop support for OH1 bindings.

I do not closely follow all discussions, but is a release of OH3 planned within the next several weeks?

[bwosborne2]

Latest schedule is mentioned here. Likely Milestone in September.

https://community.openhab.org/t/openhab-2-5-x-patch-releases/90248/260

[Wolfgang1966]

Hi @MPH80 , if there is a working tree to check out I may find time to have a look at it. I already thought about implementing this request also, as one or more new channels to avoid messing up the existing ones.

I've created a pull request with the relevant updates in: #8253

I'm not too upset by the loss of station ID and Name - nor the wind gust (this was always marked as advanced). The UVIndexHandler is tricky though. Removing it breaks existing code, but the way the objects are structured makes it trickier (without causing cross references or using a file cache) to share the data.

@MPH80 Before I started with my extension to the code I checked your PR in the hope I could modify it to provide both the old things (for compatibility) and the new things. Finally I decided to do it from scratch because to me this seemed easier. I am really sorry that I could not make use of your work! I Hope you are not too upset!

[MPH80]

Hi @MPH80 , if there is a working tree to check out I may find time to have a look at it. I already thought about implementing this request also, as one or more new channels to avoid messing up the existing ones.

I've created a pull request with the relevant updates in: #8253
I'm not too upset by the loss of station ID and Name - nor the wind gust (this was always marked as advanced). The UVIndexHandler is tricky though. Removing it breaks existing code, but the way the objects are structured makes it trickier (without causing cross references or using a file cache) to share the data.

@MPH80 Before I started with my extension to the code I checked your PR in the hope I could modify it to provide both the old things (for compatibility) and the new things. Finally I decided to do it from scratch because to me this seemed easier. I am really sorry that I could not make use of your work! I Hope you are not too upset!

Not at all - in truth - once I saw your 'I'll look at it' post - I thought "heh - maybe I'll rework it and get there first" as a bit of competition. But I'm lazy and it seemed like a lot of work. So I didn't. :-)

As long as the work gets done - I don't mind who does it - and, honestly, I did it for myself so I could get the hourly forecasts. So I've been enjoying my upgraded JAR for sometime and I'm ok with that. I'll happily switch over to your version once it's in 2.5.9 or whatever.

So thank you for taking it off my hands!

[Wolfgang1966]

As I will be off for one week starting 12th of September, I filed a PR now:

https://github.com/openhab/openhab-addons/pull/8395

I hope it will make it into the 2.5.9 release.