Hosting UIs on different machine

Add-ons UIs
1

Hello,

I am thinking of the possibility of hosting UIs on a different machine than the one Openhab runs on. Some benefits that came to my mind when using this approach are:
1- Fewer resources are needed on the device running Openhab (RPi3 B+ will be happier with this)
2- When accessing the devices remotely, it will be faster to serve the UIs from the remote server. Usually, the home internet has limited upload bandwidth, so serving the UIs from the server while only connecting to the devices using Rest or Websocket will use much less bandwidth.

I’ve been trying to figure out how the UIs communicate with Openhab instance to try to implement this idea, but I still can’t figure out. I am not good at frontend stuff.

Please let me know what you think about this idea,
Thanks.

2

My understanding is that the UIs just use the REST API to interface with OpenHAB so it should be theoretically possible.

3

All the UIs installed are available from openhabURL:8080
openHAB is designed to run headless

4

The question is, which component handles the communication to and from the UIs?
Is it implemented in the java code, or in the web app?

The answer will help in deciding whether running the UIs in a standalone environment is possible without much re-implementation.

5

The REST api

6

I do not understand the question. I thought you were referring to arperUI, Basic UI, HABmin, & HABPanel which are likely implemented in Java to perform web calls. They are features of OpenHAB, but not “apps”

I think the mobile apps make their own web calls to OpenHAB and are never hosted on the OenHAB server

7

Yes you understand right, I am talking about the web UIs (Paper UI, Basic UI, etc)
By web app I mean the (html, js) part.

If you take a look at the source code of any UI, you will find a similar implementation. There are some java classes, and there is a web directory which contains the html, css, and js

I am trying to trace where the actual communication happen.

8

This is on Openhab side, but I am talking about the UIs side.

9

Those run on the browser of whatever machine you are using and communicate with openHAB over the REST API.

10

Not really because all the UI rendering is running in your web browser. All the actions you take are converted to REST API web calls to your OH server and the browser page subscribes to a websocket to receive events. Your UI will have to work identically to this so you would be saving exactly zero resources.

Again, not really because the slow down happens in the REST API calls that the web page initially makes to populate the various displays. Adding a layer of redirection is only going to exacerbate the problem because now you will have to go through some third party relay to get all the data back.

This idea is going to be complicated to build and save you nothing in terms of resources on the RPi.

tl;dr all the work that can be moved off of the RPi in terms of UI is already moved off of the RPi and into the browser.

1 Like
11

After spending sometime looking at the source code, it looks like it’s not worth the effort. Since, as you explained, the performance gain won’t be big if any, but the needed effort to implement this is high.

Thanks all.