Cannot connect remotely to iOS application


I have openHAB set-up in my local network and behind a Nginx ssl proxy. When connecting locally, everything works like a charm. When connecting remotely, I get a “Request failed: unacceptable content-type: application/xml”. I have thoroughly checked the URL I am using in the app, as well as my Nginx configuration and everything seems ok.

The URL I use: (of course a different host name for security reasons)
which is reverse proxied as

In the Nginx log I can see the GET /rest/sitemaps on the proxy, which by the way works very well if connecting through a browser (ie I get the xml sitemaps).

If I use also …/ in Safari everything works as well.

Unfortunately the iOS app is not very “talkative” and I don’t understand where the problem is coming from.

I am on openHAB 1.8.1, using the iOS app 1.7.1 (the one on the App store, I suppose this is not an issue as everything works in local).

Any help highly appreciated.


What is your iOS config?

One thing that trips a lot of people up is that you need to omit the “/” part in your URLs in the app.

Already checked that, this is not the issue. My iOS is 9.1, checked both from my iPad Air and my iPhone 5S.


Am still working on the issue but with no joy. Is there any way to get a more understandable error from the App?

Thanks in advance.


I’m having the same issues with an iPhone6s with Openhab 1.8.1 Windows running behind an IIS reverse proxy. When I configure one or both local/remote URLs with, I get a red banner error stating “A server with the specified hostname could not be found”

On the same phone using a web browser browsing to works without issues.

Brian, quick question, are you using a self signed certificate for your proxy? I encountered issues in the past with this (solution is to install the certificate on your idevice).


No, I’m using a wildcard cert signed by Digicert.

Digging through the IIS logs show 404 errors for GET requests to /rest/bindings but no issues (200) for /rest/sitemaps.

Did you check the outcome of the same request through Safari (I mean the
one on /rest/bindings)?

I get a blank page with /rest/bindings through a browser. With /rest/sitemaps, I get a XML showing the sitemaps configurations.

I’m getting the same 404 error browsing to /rest/bindings with a machine on the same network as my openhab instance. So the issue is definitely not caused by the IIS reverse proxy.

Question, do I need to install any addons in order to use the iOS app remotely? I’m fairly new at Openhab (started last week). :slight_smile:

Here is a snippet from the request log in \openhab\logs

I made requests to /rest/bindings and /rest/sitemaps from a browser on the same machine the Openhab instance is running on and then a 2nd machine on the same network.


The IOS app doesn’t require any special addon, as long as you are able to access the site directly (which sounds like you could). Otherwise it uses the myopenhab service which must be configured in your system.

But one think you should keep in mind: The App does not display the website but uses the rest interface of the server to display the data. This interface might have a different URL or port as the website. So just to be able to display the web frontend in a browser doesn’t help, you must be able to call the rest api from your browser to get the information you want…


Hi Brian and Dieter,

Brian’s issue looks similar to mine. For some reason the iOS app is calling a non existing url (rest/bindings in that case which I double checked and is non existent). The point is that the openhab app seems to fail silently on such wrong url, whilst of course the proxy fails with a 404 error and the iOS app reacts differently to such failure. Again the lack of detail on the error in the app makes the debug a bit difficult…

I will try to test a bit more this week-end. For the time being I have just created an icon from the web site on my home screen and it works quite well as the openhab web app reacts as a “native” app, ie it opens in its own window without showing Safari in the back. It is less efficient than the app as it conveys the full html instead of just the rest data, but it is good enough until I get the iOS app issue sorted out.