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
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
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
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.
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 ) normal condition that should not result in error logging.
Please don’t repeat implementing that behavior in your new version.
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!
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):
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?