HTTP binding - openHAB 3 version

As some of you might know the http binding is still an openHAB 1-addon and will not be supported in the upcoming openHAB3. Therefore I developed a new openHAB 3-version. This is still work-in-progress, but I would like to here your thoughts (especially on missing or unclear features), bugs and everything related.

The documentation can be found on Github: (edited: binding included in distribution).http and the latest and greatest JAR is available at (edited; binding included in distribution).

You should be able to use the old http binding and the new one side-by-side, so no risk in trying out what is coming.

Edit: Updated link to 3.0.0. Newer version will not be compiled for 2.5.x

23 Likes

@J-N-K Thank you for all the hard work you do for OH and the community. :+1: Just wanted to let you know it does not go un-noticed. :smiley: Thanks again.

6 Likes

Well done, and thanks. Been wondering about the http1 binding.

Some things and items files examples would be great.
I use the http binding a bit, it’s great for when there’s no binding or mqtt bridge available.

It’s a pity with the move to openhab 2 that what used to be just configured as an item, now needs a thing then an item referencing the thing (mqttv2 is quite a pain for this). No fault of yours of course

2 Likes

great, Thanks. I’m only using the http binding in my rules as an action. Is it possible to use this one also in a rule? The extension feature looks very interesting, because this is one feature I miss in the v1 binding

As mentioned in OP this version should work side-by-side with version 1 so give it a try and post back the results. If there’s an issue it would be good for @J-N-K to know so he can look into it.

no what I meant was that e.g. I want to make a get request with some authorization, headers etc. In this v2 version I see that you can define them in the things file. However I see no option to use this in a rule as an action. The v1 version can be used as an action in the rule, however there are the limitations with the header, atuh etc.
That’s why I asked if this v2 version can be used within a rule with the additionals extensions listed in the markdown

Ah, I see what you mean now. :upside_down_face:

Give it a try and see if it works as expected. If not maybe a change or feature can be added. :wink:

Can you give an example how that looks? I can’t find documentation in the http binding about actions.

I think @NoneWhereTo refers to this:

I think the “Actions” are actually part of the OH basis and not of the Binding, which can lead to some confusion.

OH2 bindings can offer Actions for use in rules, these are “got hold of” by using a getActions(http, some params) method. I suspect this is not yet existing for the new binding.

@J-N-K how can you get a value from a json array?
In http1 I had: [0].name
I have tried it this way in the new binding: JSONPATH:$[0].name

But I get an exception…

Thanks for your engagement. Upfront, I haven’t validated that yet, but the old binding had a nuisance that if the target was unreachable, it was spitting errors with an error level log. That was very annoying when it’s every n seconds and it was not a (binding) error in fact but server unreachable is a perfectly (well :wink:) normal condition that should not result in error logging.
Please don’t repeat implementing that behavior in your new version.

2 Likes

Can you please show the server response and the exception?

The question is how this should be handled. UNDEF or just ignore the error?

1 Like

Sure. Here is the exception:

2020-07-09 21:40:09.798 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.lang.IllegalArgumentException: Illegal character in scheme name at index 0: "https://api.github.com/repos/arendst/Tasmota/tags"

	at java.net.URI.create(URI.java:852) ~[?:1.8.0_222]

	at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:442) ~[?:?]

	at org.openhab.binding.http.internal.http.RefreshingUrlCache.refresh(RefreshingUrlCache.java:79) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_222]

	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:1.8.0_222]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_222]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:1.8.0_222]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]

	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

Caused by: java.net.URISyntaxException: Illegal character in scheme name at index 0: "https://api.github.com/repos/arendst/Tasmota/tags"

	at java.net.URI$Parser.fail(URI.java:2848) ~[?:1.8.0_222]

	at java.net.URI$Parser.checkChars(URI.java:3021) ~[?:1.8.0_222]

	at java.net.URI$Parser.checkChar(URI.java:3031) ~[?:1.8.0_222]

	at java.net.URI$Parser.parse(URI.java:3047) ~[?:1.8.0_222]

	at java.net.URI.<init>(URI.java:588) ~[?:1.8.0_222]

	at java.net.URI.create(URI.java:850) ~[?:1.8.0_222]

	... 9 more

Ps.: My bad, I had a look at the exception again and the problem was in the base url, I forgot to delete the quotation marks, it works now!

1 Like

Would you post your example (in case you use text file definition)?

INFO level logging ?
Ideally on state changes only (server gone between last and current request + when server came back)

I’m using PaperUI. Anyway the config is really straightforward.
Define the BaseURL at thing level and add state transform for a channel as you would do in MQTT2 binding.
So state transform should look like this (assuming a json input):

JSONPATH:$[0].name

Thanks for bringing that up!
Yes it was really annoying and it not even showed these errors between the specified poll intervals but every few seconds…
@J-N-K
I think an UNDEF state for channels on a Thing is great for showing unreachable hosts. Maybe also use ThingStatus to represent availability on a Thing level?

For anyone who wants to start off using/migrating textual config, here is a very simple example that works for me:


Thing http:url:exchangerate "USD-EUR Exchange Rate" [ baseURL="https://api.exchangeratesapi.io/latest?symbols=USD", refresh=3600] {
    Channels:
        Type number : USDEUR "Exchange Rate" [ stateTransformation="JSONPATH:$.rates.USD" ]
}

Item:
Number ExchangeRateEURUSD  "EUR - USD [%.3f]"                  <exchangerate>          (gAll)  {channel="http:url:exchangerate:USDEUR"}
2 Likes