When integrating my intercom device into OpenHAB, I encounter the problem to toggle a switch item managed by OpenHAB, upon sending an HTTP GET Request from the intercom device.
The OpenHAB REST API is set up, and upon creating an appropriate POST request, I can successfully toggle the switch item. Unfortunately, my intercom device is not capable of generating a HTTP POST Request, but only a HTTP GET Request.
Now I wonder what I can do in my OpenHAB setup such that OpenHAB is capable of accepting a GET request and causing an associated switch item to enter either the ON state or the OFF state, depending on the content of the HTTP GET request.
Does anybody have a hint as how solve this issue? I searched the forum and only found ways either to accept POST requests or to use the http binding for sending GET requests. Unfortunately, I did not find a hint as how to receive GET requests in OpenHAB and to link this to a particular item.
Unfortunately that’s not directly supported by OH, so it’s not going to be all that straight forward.
You may use something like a get2post proxy: Purism / get2post · GitLab
Allthough some people do not like to read this, just send this to OH:
It’s not that they don’t like to read it. It’s that that approach:
- requires BasicUi to be install
- is not officially supported so may be removed from any future version of OH at any time without announcement
Recommending that approach pretty much guarantees that at some unknown point in the future, the OP will have their system break again without warning.
true. no offense from my side.
tbh, there are a lot of users out there who appreciate the easyness of this undocumented feature.
Me, personally, I have a few Mobotix cameras from where I send some information to openhab (some infos via SNMP, triggers via http/get as they do not support http/post).
sure, there are a lot of “decent” solutions out there like the ones explained above, but that requires adding a lot of other tools. me, as a semi-experienced user, I am happy not having to walk the painful route.
do you think it is worth starting today the discussion to prevent that some day that feature will be dropped?
I understand the security concerns behind that, but maybe there can be a kind of compromise like allowing one single item to be triggered via http/get and having a rule behind that to control other virtual items?
No because the way it’s implemented and depending on the installation of a UI which, frankly, is likely to be dropped at some point, there is no way to preserve this forever.
It might be worth creating an issue to create an official REST API end point that works like this, but one of the problems is that OH implements a REST API, and using GET in this way violates the way REST APIs are supposed to work. So it might be rejected to add something like this to the official REST API.
It’s not a security concern as much as it is the havoc that occurs when you deviate from a standard, especially when one is using third party tools to implement a big chunk of it.
Maybe an add-on could be written. There are more than one add-on that provide their own HTTP endpoints (IPCamera, GPSTracker, etc.).
But basicui/CMD is not something that will be around forever.
Thanks for this @Oliver2 and also to @rlkoshak for pointing out the dangers … its pretty much exactly what I wanted for now … but obviously I need to get the POST to work with Authentication … I am just playing around still (My SmartThings / Webcore works fine but I really want to move away from it) …
Anyway, appreciate the response and I’ll keep Rich’s warnings in mind.