Did you read and understand what the problem is? I tried to describe it in my first post in this thread. The official App as well as Paper UI and Basic UI show a similar (and faulty) behaviour in my configuration, while Classic UI works as expected.
So it should not matter if someone tries it out with the App, Paper UI or Basic UI. If one of those does not show the faulty behaviour this would be a valuable hint in the right direction.
No, I mean a web server as both, nginx and apache, are web servers with reverse proxy capability. And the first problem is that two web servers cannot listen on the same port on the same physical server. Second I have to open at least one non-standard port in my Router and in my firewall to gain access to a parallel nginx server instance from outside my LAN. All this with the risk of temporarily breaking access to the services running.
Third problem is “openHABian is restricted to Debian/Ubuntu based systems”. As stated above I have an openSuSE Leap based system. Porting to openSuSE would not be helpful in matters of time and result.
A simple “works as expected” or “same issues” from someone who has a working system up and running would still be much simpler. I understand that openHABian is very good if you setup a new system on a supported platform but it’s not the answer for my question.
I admit I had forgotten about when replying to the other post, but you were adding to the confusion by talking about PaperUI only in your next post, and PaperUI is wrong in the first place thus misleading anyway. You mustn’t use PaperUI for any user action such as to switch items. It’s an admin UI.
No, both are software. Apache is capable of providing both functions, to be a server and a proxy, but its server capabilities are NOT used in this context. The server is a jetty which is part of OH.
Meanwhile nginx can even not be setup to serve (AFAIK - I admit I haven’t checked lately).
So you meant to say a proxy then.
So what, use a different port then or bind them to a virtual IP.
So what ? Just do.
nginx is available as a SuSE package, too, and the config you can get to look up on openHABian repo on GitHub. Again, so what ?
The point is that if it had been a known problem unrelated to your specific proxying setup, this would have shown up much earlier for many users. It didn’t so it’s related to your setup.
And who do you expect to also have an Apache to have the same very specific configuration to do the URL proxy rewriting ?
Another misunderstanding… I’m talking about a working openHABian/nginx based installation with SSL access. Maybe others don’t care if the change does not show up in UI as long as the changes are transmitted to the items. Maybe it’s a problem related to my special setup.
To find out I am asking if my problem does not show in a setup you recommend.
As there is a difference in behaviour in my special configuration concerning Classic UI vs. Basic/Paper UI the problem might as well be UI specific.
Maybe I’ll find the time to setup and test everything against nginx. Should be faster than asking anyone with an already configured system to tap on a light switch and observe the behaviour.
This is something you can explore without extra setting up efforts. BasicUI and ClassicUI use very similar REST calls, unsurprising as they do essentially the same job. Can’t be much different.
I already know the difference. Accessing my SSL secured webserver, which proxies the request to my 127.0.0.1 openhab instance:
Classic UI - Heating Control - Button up
New temperature is immediately shown in UI, command (according to events.log) is sent to item
Basic UI - Heating Control - Button up
Command (according to events.log) is sent to item, temperature in UI unchanged, after timeout (configured for the proxy) message on the bottom of the UI “Offline: waiting for connection”
Message disappears (Basic UI online again), new temperature is shown (first change like this: “19,00 °C”, every other change correct)
Classic UI shows physically changed items immediately, Basic UI comes up with the bottom message every 30 seconds and then, after being online again, shows actual values.
Same there, no matter if BasicUI or app.
I have seen the browser failing to refresh at times, but that’s browser dependent and a page reload always does.
More surprisingly, when using a VPN connection and using the local webserver on port 80, which proxies to the same openhab instance at 127.0.0.1, Basic UI works as expected (as well as Paper UI and the App). No “Offline” messages at the bottom of the page, no “strange” characters in the values.
I’m not using client certs nor am I using apache or nginx (I use HAProxy as that’s what’s on pfSense) but…
I frequently see this when I use BasicUI through the proxy.
And I can confirm that if I modify an element (e.g. a setpoint) that the commands are received but the UI does not update immediately. It will update eventually though.
I’ve only set this up to learn so I don’t really use it and will likely shut it down soon so I never really paid attention to this. But I can confirm the behavior at least with HAProxy.
NOTE: this is through Chrome on a Windows machine. I access OH through VPN on my Android so can’t say what the app behavior would be.
So this looks like it is not a proxy problem with apache but, as confirmed when setting the log level for the REST API to debug, a different way of subscribing to events in Basic and Classic UI.
But … both these methods work for other people. Both these methods work for you locally. The BasicUI (and I expect likely other UIs) give you a problem with remote access. I wouldn’t know if its proxy or firewall or whatever, but the problem lies in your setup somewhere.
I’m experiencing the same problem with basic UI with my PC when from outside I access through apache as reverse proxy.
I thought was related to my apache misconfigured and I postpone it to further investigations.
I think could be related to the SSE protocol (or whatever the basic UI is using to receive messages without reloading the page) not passing the reverse proxy…maybe some missing module/directive in apache for that protocol…or maybe the basic authentication I have in place blocking some anonymous calls made by that protocol…just guessing.
I cannot tell for the Android app because I use myopenhab.org as external url.
I’m going to dig deeper soon.
There are differences in the way, the UIs and the App subscribe for event notification.
There is a difference in using the local reverse port 80 with user/password auth from a local PC compared to a local access over a VPN tunnel.
There is a difference in using port 80 or port 443, but not for all UIs.
I think it will take some time to analyze all the different debug logs.
Please do. Thanks. I didn’t mean to say the reason for the faulty behavior is in your Apache setup alone. Just that it’s not there all the time. But of course it can be in the page contents, browser, server, …
SSE is a prime candidate IMHO.
Checking the default openHABian nginx config, I saw this mentioned: # proxy_buffering off; # openHAB supports non-buffering specifically for SSEs now
So please try nginx to see if that works.
If no check out these to see if that helps.
Not sure how to make OH/jetty set headers, though but there’s nginx-only variants, too.
