Transforming HTTP calls from external systems to OH Rest API

Hi there,

I came across this issue multiple times already and want to know if there is an official extension point from the OH Architecture point of view for this.

Use Case
External Device has the feature to provide information via HTTP Push. So the device would call HTTP GET on http://configurable-url/fix-api/?somegetparameters=value&anydevicespecificthing.

Often device can be configured which endpoint to call with the IP/hostname, but usually not how the url looks.

One example is:

where the current binding is using HTTP Polling. But using the mowers push mechanism would be nicer as there is no need for an extra polling thread in the binding. Also the timing of the event of change is triggered most likely more accuratly at the event, whereas the polling always depends on an interval.

Another post I found where the concept might be required is here:

Also for the lametric binding it would be interesting to support user feedback via push buttons. The very old conversation about the topic can be found here:

The answer of @Kai at this point in time was

Having to access HTTP requests is not really ideal and should be avoided. If there is no other way of getting hold of this information, though, you could register a servlet that processes these requests (and sends according updates for a trigger channel of your Thing).

How this questions goes to the OH Architecture Team.

  1. If a device provides both possibilities, Push or Get, is it really preferable to have a polling thread versus exposing a servlet?
  2. Is there plans for any kind of transformation servlet in front of the REST API?

And of course to everybody of the community,

  1. do you have similar requirements?
  2. How did you solve it?

last but not least there is another likely question non http related but going cross binding communication.

  • If my device supports mqtt for reporting status but not for triggering actions on the device, which is just supported via http. Is it a good idea to use the MQTT binding for updating the status channels and map the items also to my bindings channels to react on status updates?

Before I start any efforts in this direction I would like to know which approaches exists and what are the recommended ways to tackle such cases.

Thank you all for your input.

2 Likes

That’s is a good idea

I didn’t need to do that, but I would implement a python servlet to listen to your device and then publish updates to OH via MQTT, or use node-red to achieve the same result.

I don’t really see much difference between the polling versus a servlet except for the fact that non-coders can manage the HTTP polling with what OH provides out of the box whereas it would require a Java coder to build a servlet to receive the HTTP push request.

What is surprising to me is that services like these support Push but only with a limited set of URLs or REST commands. That makes it challenging to integrate with much of anything. It’s not just an OH problem. If you are going to go as far as providing an HTTP push/callback, why not provide the full range of REST API commands?

From a technical perspective, push is almost always better than pull.

I highly doubt there are any current plans for a transformation in front of the REST API. I’m not even sure how that would look. Though I imagine if you wrote a custom servlet you could access the transformation services from it. Though you can’t always guarantee that the transformation service you want to use will be installed.

I do not have any similar requirements. But if I did I would probably just implement the polling. If the polling was not feasible then I would spin up something in Python or Node.js to receive the HTTP Push and forward that to OH over MQTT or OH’s REST API.

That seems a pretty odd configuration. MQTT is by far lighter weight and easier to implement. I would almost expect the reverse or you could do everything via MQTT. Anyway, the devil is in the details to answer whether what you propose with using the HTTP and MQTT together is a good idea or not. The challenge is avoiding feedback loops sometimes. But I see nothing fundamentally different from the standard MQTT approach where you have one or two outgoing MQTT configs to send the commands and one incoming MQTT config to receive updates.

That’s about what I have done in the example that @reyem is referring to. Some lines of PHP that takes the call from Robonect and simply makes an appropriate call to OH REST using the information. Works very well but it isn’t a solution for anyone.

Problem with this specific situation is that this is something that might happen twice a month, but when it happens you want to know. Polling every 30 seconds for something that so rarely happens really doesn’t feel like a good thing :face_with_monocle:

On the other hand, if it is really important it might be worth the polling so if something goes wrong you don’t miss the push. For example, if OH is down or your PHP is down when the push happens you will miss the event entirely. But if you are polling, you will pick the event up just as soon as OH comes back online.

A lot of this stuff depends on perspective and what you are trying to optimize for.