Support for more weather providers in Weather binding

Add-ons Bindings
1

Hi!

I would be interested in get weather forecasts from SMHI open API since I live in Sweden.

Is there any chance of getting support for that provider in the Weather binding?

BR,

/Janne

1 Like
2

If the answer is “no” and in the mean time the API appears to be REST and doesn’t seem to require authentication so the HTTP binding should work. You can see an example of how to parse the results in the Demo which uses Yahoo!'s REST weather API to pull down the data instead of the Weather binding.

3

Hi!

Thanks for the tip of using the HTTP binding, I will definitely check that
one out.

I’ve actually found an old SMHI openhab binding on github that I’ve been
playing around with to learn
the art of binding development but then I realised that there already
exists a Weather binding so the proper
place should be to include support in that binding I assume.

BR,

/Janne

4

Hi Janne. (and all others)

As a Swedish citizen I am curious about this so I got into the technical details of the weather binding.
SMHI is currently rolling out a version 2 of their REST API which unfortunately have an “odd” structure compare to all other weather services supported by the weather binding. The old api would be easy to implement with easy “copy and paste” but it will be dropped.

Version 1 will only be available for a limited time!

The new API is abit more complicated to handle and the current code is not really build for that case in mind.
More precisely the new API transfer all parameters (humidity, pressure and so on) within a generic structure.

"parameters":[
        {
          "name":"msl",
          "levelType":"hmsl",
          "level":0,
          "values":[
            1031
          ]
        },
        ...
        ]

This will need some sort of special handling when being parsed.
It would be great to get in touch with the maintainer of this binding.

An open question to the community.
Who is the maintainer of the weather binding?

5

Hi!

The proper place would be in the Weather binding, FYI I’ve made a private implementation of a SMHI binding supporting version 2 of the REST API based on OH 1.x, if you’re interested I could put in on github.

BR,

/Janne

6

I am interested in this :slight_smile:
/mike

7

Please put the code on Github Janne.
It can serve as a start for integration support in the official binding.

According to the source code @gerrieg looks like the author ( /maintainer? ) for the binding.
Maybe he could give us some direction how to structure the json parsing within the weather binding to support SMHI style api.

8

Hi!

Please note that the code is work in progress:

BR,

/Janne

9

I looked at the SMHI api and the data it returns. So first of all, SMHI returns only data for a specified area. If the lat/lon is outside this area, the error message “FIELD POINT OUT OF BOUNDS” is returned. The provider is only usable for Sweden/Norway and not worldwide.

The data from the API is in timeseries, not daily which is completely different from the other providers in the weather binding. I did not find a parameter in the API to switch to a daily response.

Therefore it’s not possible to implement this provider in the weather binding.

10

What is the long term goal with the weather binding for OpenHab 2 and onwards?

For the community and the frameworks end user experience I think one weather binding would be good because of:

  • Defined parameters between all providers.
    This open up for script and rules which i generic between different weather providers.
    If a user moves, either permanant or temporarly, summer cottage or equivalent.

  • One source of information, openHAB and Eclipse Smarthome is growing fastly. To easy up for the consumer one abstraction would be good especially since all weather web services have so much in common.
    (Same data and similar auth methods)

We are also in the great position to refactor this binding for openHAB 2 API. In that case we could organize all weather services as bridges which enables weather-forecasts having the same dataset and query methods.

For example SMHI binding could have an process layer which converts the timeseries to specific days.
We could also supports XML as well to support YR.no and similar services.

What is your opinion?
As usually a rewrites and addons take time but its good to have a clear goal to work against.

11

I fully agree with you. My previous statement was related to the 1.x binding. For 2.x the binding could be refactored just like you said.

Currently i am still busy with the Homematic binding. When it’s done, i can move to the weather binding. So don’t expect a solution very soon.

If someone else with more free time will do the weather binding, i am not unhappy :wink:

1 Like
12

I must apologize if I let accusatory, not my intention.
I fully agree with you regarding 1.x binding no reason to put effort on it.

Regardless of who will implement and design the binding it would be nice to brainstorm which capabilities and format it shall have.

I am not sufficiently versed in what is good or bad for weather forecasts but a generic timeseries format would be great which supports hours as well as days.