[SOLVED] Web UIs for openHAB 3 - Contributor perspective

Hm. I’m not sure I like how the AC want to vote on topics without letting other contributors say a word or two on the topic.

Because I can’t post on the other topic I’m just saying it here in a very concise form:

  • The dashboard can’t be removed if the replacing single UI is not rendering further options that the old dashboard listed. Including node-red, grafana, habPanel and other solutions.
  • I think we need two UIs, not one, with specific functionality each.

I have thought about it intensively and will probably share a video to go over all my thoughts, but my drawn conclusion is: You will not setup your openHab system on a phone. So we can expect a big screen device (tablet, pc) with screen estate that can be used to show a text editor with syntax highlighting, a rule editor and so on. This first app is what I call “Setup & Maintenance”.

A second app is all about controlling:

  • Creating sitemaps, rendering sitemaps, rendering a dynamically created sitemap that just maps all Things/Channels on it (like Paper UI is doing it atm), rearranging items on a sitemap
  • showing notifications
  • habot like “smart” interaction.
  • Managing scheduled tasks,
  • Creating/Renaming/Removing scenes.

Basically like the Philips Hue app and Habot combined. No configuration. And I really mean no configuration. Not even inbox approvals. A user will understand the concept of each app so much better if it sticks to an area of expertise.

I’m not convinced yet that it makes sense to have this in one app, I mean that failed for Paper UI. I hope this will lead to a fruitful interesting discussion.

I agree though that the mobile apps don’t receive enough love. And if the OH REST API changes for OH3, those apps will barely catch up is my assumption. One (web) app would solve this. I just want to throw in another thought: https://flutter.io/ Just as an example for a technology stack for united iOS/Android native development.

Cheers, David


I agree with that.
I don‘t understand why openHAB should be reduced to one UI that offers the configuration and sitemap part!
One part is to build everything and the other is for daily use.
I know that a smart home is about automation and not controlling, but that‘s what alot of users do.

Many openHAB installations are used by someone who is doing the administration and normal users.
A single UI would need a pretty good access control to manage all of this.
And still the administrator is also a user when he isn‘t working on openHAB.

As said by Rich in the AC, the Android app get‘s enough love but the iOS app is far behind.
I‘m happy to see that new developers stepped up to migrate the iOS app to Swift and actively maintain the app.
I‘ve to admit that i‘m not a fan of web UIs compared to native apps.
Just when the iOS app gets more attention there are plans to stop this…

Kind regards

1 Like

For getting that single sensor in my hallway running, I wished I could have done this. Now I ran back and forth between my PC and the hallway…

Use a laptop, a tablet, or a Chinese 7 inch smartphone :joy:

@David_Graeff Or a properly scaling web engine. I am not from the business, but there are these nice web engines ( like the one for the forum) that adapt perfectly to the screen size.

The request for two UI sounds a bit like having one app for reading the forum, and another one for user registration, and post writing, formatting and editing :wink:

Still, the one forum app does a pretty good job on both my PC and my phone.

Seriously: I am just a bloody freshman and you did this awesome Next-Gen PaperUI, so I should not pretend to know the internals. But the idea I liked most on your work is the perspective to join all functionalities that now are spread over several programs that have to be maintained and used separately.

A forum engine is a much simpler thing then a whole house automation with so many functions in it… So you can’t compare this to OH.


Not comparable on a functionality and logics level. But maybe on a UI level, I think. Still, I am not a programmer, and thus no expert…

I’m just a learning Software Engineer (and I don’t have much experience on UI/UX), what you want is achieveable, and yes you will only have one UI, but that one UI would be that complex that it would be harder to use and understand as a newbie than the current status…

which I opened an hour before this post.

I think it’s important to bring up the other part of the proposal which is role based access (RBAC). This would be required to achieve on UI because we all agree, you don’t want to give access to administration stuff to normal users.

So when you log in as a “user” you see “sitemaps” just as now.

The phone apps continue to render sitemaps.

But if you log in as an admin role, you also gain access to the Setup & Maintenance parts of the UI.

I’m not trying to argue one way or the other, but this detail seems to be lost in the discussion. The proposal is not “everyone uses PaperUI all the time”, its that what a user sees depends on their role. If they are a user, they see just sitemaps. If an admin they get the whole enchilada.

That is not part of the proposal.

And if you check the AC thread you will see that Kai put a stop to Yannick and my discussion as out of scope. The AC’s job is to say “we should merge the UIs”. It’s the developer’s job to figure out the how and most of that discussion Yannick and I had was regarding the how, and therefore outside the purview of the AC.

Like I said on the other thread, we’ve been at this for two days. We are all trying to figure out how this is going to work.

But let me say this clearly. There are no plans. No decisions have been made. There are just some proposals that have been offered. And discussions like what is happening here and in the other threads are exactly what needs to happen. If there is a consensus out of this thread, that will become the “decision.” If it’s contentious, the AC can become the arbiter of last resort (if I understand Kai’s vision correctly).

Tomorrow I am tasked with adding this process we are currently engaged in to the Governance policy. This is how it was always meant to work. A thread opens for general discussion and the AC records the consensus or breaks the impasses.

1 Like

I’m not against a shared code base. It is actually very reasonable to have one code base. I always tried to think about the newby user while making the design study. I’m already feeling like the main menu at the top provides too much options for someone new. (At the same time openHAB is just very powerful and you can’t break it down much more). But if sitemap creation, controling, interactive habot controling and whatnot is also part of the very first interface a newby sees: how do you present that in a reasonable way.

I’m not sold on the paper UI concept (that Yannick picked up to a certain degree) in which setup& maintenance is hidden in a single menu option called “configuration”. So everything that I have multiple main pages for in the design study is ONE single option in a control centered app. How is that user friendly, especially if you are in the setup phase and don’t want to see all the control parts.

So that is basically my concern. Two UIs make sense. It addresses two use cases. The only other way I see is that you present two totally different interfaces based on the logged in user role. Which is two apps again though.

Cheers David

1 Like

Complexity is a good point. I guess I was envisioning something like the following:

When the the user role logs in (or no login) all they get is the configured default sitemap and there is a menu somewhere that make sense to select other sitemaps. So this part is simple enough whether it is included in the one UI or not.

For the admin UI I figured when the admin role logs in they would be presented with the Setup & Maintenance UI, either something like yours or Yannick’s “Welcome to openHAB”, or configurable like in your study so it comes up immediately on the maintenance page with the charts and such.

I don’t particularly like hiding the UI under a two entry menu either and I don’t think we need to.

As for the complexity of the admin UI itself, no matter how we break it down we have the following X concepts to deal with:

  • Generic setup
  • Monitoring
  • Bindings (install and configure)
  • Things
  • Items
  • Rules (install and create)
  • Persistence
  • User’s UI creation / configuration / sitemaps / test (i.e. access to the working sitemaps)

I don’t really see how splitting the last part into two separate UIs helps. I would not like it if we had to split the last bullet in its entirety into a separate UI because then we are back in the “Why can’t I do it in PaperUI” problem we have now.

I don’t know if I’m totally sold on HABot being included either, though support for adding the semantic tagging to the Items will need to be supported in the Items UI portion regardless.

You are right, perhaps listing the categories across the top may not be the best option but I don’t really see how adding one more category, one that probably needs to be there anyway, would be the straw that broke the camel’s back. Is the difference between seven options and eight options at the top level really so disruptive that we are forced to provide one UI to allow users to configure everything but the sitemaps and force them to go to some other app to build those? Or even worse, allow them to configure their sitemaps but not actually look at them unless they go to some other app?

My 2cents. I dont see why HabPanel should be kept seperate from a user perspective - it’s not like the UIs other than HabPanel allow you to do much, HabPanel is what makes it sexy to have it seperate seems odd to me.

I’d like to see more intergration and features in it.

Let‘s not forget how complex RBAC is.
The software i‘m daily working with and selling to customers has RBAC.
Sometimes it‘s very hard to setup the correct RBAC in terms of allow/deny and i‘m not sure if this fits the proposal to make things easier for new oH users.
An easy implementation would only allow pre-defined roles like administrator and user.
But this wouldn‘t fit for power users of oH, so there needs to be a basic and expert setup for RBAC.

From my point of view it‘s easier to work in two browser tabs instead of one and switching between options.
It‘s the question what users oH wants to address.
Power users that are working with software on a daily base or users that are new and want to build a smart home.

Some of the discussions sounds like making it easier and simplier for new users but forget about the power users.
The main reason why i switched from the Telekom Qivicon system to openHAB was the ability to control/automate my home like i want it to. And not what Telekom thinks a user would like to do.
I don‘t want to see myself confronted with this again.
Yes, a simple UI that makes the start easier is great and will bring openHAB to a bigger base of users. But i‘m concerned that some power user functions (like working with text/code instead of UIs) will be lost or reduced.

As you said, no decision was made.
I just want to bring this part on for discussion.

Agreed and I said so on the AC thread where this was brought up.

I believe the consensus is that the GUIs address “users that are new and want to build a smart home”. “Power users that are working with software on a daily basis” have already made it quite clear they don’t want no stinking GUI in the first place so those users will be supported through text based configs.

This is going to be a rant. But why why why does everyone seem to think that if we are talking about new users and GUIs and making things easier in one thread where that is the topic it means we plan on breaking everything for the power users. And then you go and talk about how to support the power users and everyone starts to shout “what about the new users?!”

Just because we want to make the GUIs easier to use does not mean we are taking away from power users.


There are two needs:

A user need for controlling the house
An administrator need for configuration, creating sitemaps (or the replacement)

Even new users needs that administrator part.

Combining both needs into one UI, will be very confusing for all other users of that are using the same house/building.

With RABC, some tabs /parts of the UI could be turned off/grey so they can’t accidently use that.

I agree that RBAC can quickly turn ugly. That could be simplified if we stick to just 2 (or a limited number of roles) (My propose two roles: controlling, admin)

When I work on a system where I do know the administrator password, I still prefer to work as a normal user, only using administrator rights when I need to, which I consider safer.
F ex when I’m openhab on my phone, I’m only interested in the controlling part.

I can imagine that for new users, it might be strange to have a mode to be able to do more and a mode just for controlling, yet I can imagine that especially for a new users, it’s good to have to consciously swap between controlling and administrating.

But why? What kind of sensor needs you to run back and forward between anything? Thats sounds more like some design problems you´re suffering.

And this is actually the first thing to think of… What IS openhab? And whats is it suppose to be in the future. Do we need a user interface at all, except for setting up the smarthome system (openhab)?
Where is the need. Is it because everyone else is having nice looking apps for mobilephones/tablets, where the user can click a button, and then the light turns on? It doesn´t make sense (to me). Why even bother with all these buttons and stuff. Its a nice to have feature, specially when testing and setting things up. But in daily use, it´s not a need to have. Not unless something else is missing, like physical buttons and/or voice commands. I have yet to see a home build without physical buttons.

What we do need is a good and easy way to provide a monitor for our smarthome. A monitor which main purpose is to monitor, and when automatic things not working, then the use can overrule the monitor and have a functionality, like buttons etc.
I feel the main reason why we dont see smarthomes like this are:

  1. You´re used to have something to push/click/switch and then something happens.
  2. We do not trust our smarthome, at least not fully, yet.

But what if we fully put our trust fully in the smarthome?
This is where the monitors become important. We need to be convinced somehow. And the monitor is the one to tell us things are working, so we can calm down not running back/forward between anything.

1 Like

Why do you need to controle anything? And why do you need to controle it from your phone? Do you have your phone in your pocket all the time when at home?

As I just mentioned… This sound more like a basic missing act somewhere. What if you could control whatever you need to controle, without the need of the phone?
Voice commands, sensors etc is doing a hell of a job simulating a human act. Why not use that? Thats one of the huge idea behind a smarthome. Let the smarthome learn your way of living, and when you need to “help” it, (you step out of your daily habbits) interfer with it, by the use of sensores and commands, and as a last option, physical buttons. Using a phone for control is even more stupid than using physical switches/buttons.
Phones should be monitors. This is where you look at your smarthome, getting convinced things (your home) are working just the way you have told (programmed/coded) it to be.

I dont agree.
I believe a system like this should be build in two pieces.

  1. For setting up the system.
  2. For controling the system (when its fully automtic, there is no need to control anything, just monitor).

I believe this is/was the main purpose with openhab as well. PaperUI to set up the system, and UI´s like BasicUI, ClassicUI, Habpanel for using the system.
Problem today is, PaperUI cant handle all whats needed. And second, the UI´s (basic/classic/habpanel) are stupid to setup, and limited as well.

This should be changed.

1 Like

Or even better hidden and not shown at all.

In my experience on the forum so far I’m not sure that would be the case. The main source of the confusion so far stem from two “feaures” of the current UIs.

  1. PaperUI has that damn Control tab that looks like it is useful for controlling the home automation but it’s incomplete and doesn’t show everything. But the number of folks who try to use it for control clearly, in my mind, shows a demand for some new users to want to do it all in one UI.

  2. There are so many UIs to choose from which creates a burden of choice on the new users. And there is no “official default” UI except for PaperUI. This is addressed a little bit in the Beginner’s Tutorial where this is explained but clearly users are not reading that tutorial.

When we replace PaperUI with something more complete, problem 1 may go away or at least reduce. But if we keep the user’s ui and admin uis completely separated doesn’t address the apparent expectation that the current admin UI should also be used for controlling else why would so many keep asking “why is my Item x not on the Control tab?”, “how do I get my MQTT 1 Item to appear on the Control tab?”, “Missing Items on the Control tab”, and so on.

When I think about it, having one tool to build the UI and a separate tool to view the UI is really counter intuitive. But if we extract the “user’s” UI in total from the admin UI so you have to both build and view the “sitemap” in a separate tool, I feel like we are right back in the same place. Only this time I’ll start getting complaints about wanting to change the organization of the Items page because users will be wanting to control their home automation through that UI (assuming the idea of being able to sendCommand or update an Item from the Items page which I think was part of the study becomes reality).

When I look at software services of similar complexity to OH (OpenMediaVault, pfSense) I find a similar approach, so it is not unheard of. When an admin user logs in they get the full UI with all the bells and whistles. When a non-admin logs in, they have a greatly reduced UI where they can only have UI elements that let them do the things they are allowed to do. It is not a unique paradigm and I don’t think new users will find it all that confusing.

Also, keep in mind that I am certain that David’s plan to embed a new and improved Beginner’s Tutorial where this can be explained in a couple of sentences would address the confusion for a number of users. We can’t solve all confusion for all users but I do think a unified UI as the default would be an improvement over the status quo.

While 100% automated is a great goal, and one I push users to stretch towards, there will always be a need for control as well. For example, I want positive control over my garage door openers. I don’t want it to automatically open or close, ever. So I need a control for that. And control will require some sort of UI. These can be physical buttons but for many use cases a screen on a phone is going to be most convenient.

I agree, controling the lights from a phone app is suboptimal. But that ignores a whole host of other home automation use cases where the behaviors must be controlled and monitored.

Yes, a controlling UI is a requirement. We cannot just skip it.

Physical buttons for everything one would want to control are almost always missing in most user’s home automation. Many users do not have voice command either, because it isn’t available in their country, a desire not to be reliant on cloud services, privacy fears, etc.

Why should I have to fully trust my smarthome in order to have anything at all? Why should I have to automate absolutely EVERYTHING or nothing at all?

I understand the philosophy presented and have even advocated it on this forum in the past. However, it is not a philosophy adopted by all nor even adopted completely like users like me who subscribe to this philosophy. And whether or not there is a UI, we can still adopt this philosophy. But if we allow this philosophy to rule the day, those who don’t subscribe to is are s%!^ out of luck. They have no recourse.

From a technical perspective, there is no difference from a UI that lets you primarily monitor with some ability to control and a UI that lets you primarily control with some ability to monitor. The only difference is the intent of the person who puts together the UI. You still need the same UI elements to do either job.

Because there are some cases where a device has health and safety concerns like a garage door opener. Because sometimes there is no way to automate the action because there is no event to OH to tell it to do something except for one manually submitted by a user.

Because when want to open the garage, whether I’m driving my car or home from a walk with the family, my phone is what I’m most likely to have with me.

Yes as a matter of fact. But like you advocate, most of my home automations do not require my use of my phone to control them. But there are some things in my home automation that I will not completely automation and those require some way to control them which requires a controlling UI.

Some things end up being more convenient to control from my phone like adjusting the thermostat on the main floor when I’m in bed on the upper floor.

Sometimes voice commands are awkward or disruptive. It can be REALLY hard to develop sensors that tell you everything you need to know. For example, how many people are in the living room? Sensors can become expensive too.

That’s one option. Another options is to deterministically determine how the home should behave and program it to do that. I don’t particularly want my house to “learn” what to do. I want to know what it will do and why. That is one thing AI really sucks at, telling you why it made a decision.

Except when it isn’t. And should you chose to live without a controlling interface, you’re good and well supported. OH has your back and can meet your needs. But why should your preference trump the preference of those who want to have more direct control?

And like I said, the elements necessary to build a UI that is a monitor with a few controls or a UI that is a controller with a few monitors is the same.


I respect your opinion of not having an automatic garagedoor. But honestly, using a phone for closing/open it? I have a switch in my garage to do the same, my phone is in my pocket. Why they heck should I:

  1. take the phone form the pocket
  2. open/unlock it
  3. find the app
  4. push the button

When standing right next to the physical button doing exactly the same?
Or even better, just tell Google to open/close the garagedoor?

Next step is to connect the garagedoor to the car. When you start the car, the garagedoor opens.
Ofcouse there will be situation where you start the car, but dont drive. These situations are minimals, and this is where you may have a need for a button in someway, to stop the garagedoor from opening.

I agree, some may not trust the voice commands from google home, Alexa, Siri etc… and specially not when they´re cloud connected. But I have to admit, this is a task we cant win, not unless we remove any kind of connection to our homes, which means getting informations from our smarthome when we´re out, will be removed as well…
And thing of it… Lots of “smart devices” comes with apps and beeing cloud connected as well. And things are just getting “worse”.

You dont have to. The question is, whats the reason for not doing so.
I know there may be reason where a button could be more optimal, (like the garagedoor you mention). But think of it, the main reason is, you dont fully trust the automatic way… Questions like, what if it fails… It´s moving/closing just when your car is under it etc, or even worse, a child/pet…
I understand and respect this, truely… But again, think about it… Do you feel the same, when you enter an elevator etc? You probably dont, because, you trust the elevator.

I know, Rich… And I was provoking, trying to move openhab towards another way of thinking, insted of beeing focused on controlling all the time, then look at the perspective where controlling is secondary.
My main opinion is not to avoid any kind of controlling. I do have buttons, both physicals and virtuals (sitemaps). But the virtuals I hardly ever use. The physical I still use, mainly because my smarthome isnt quite finished yet, still lacking some sensors as well as the voice control in all rooms… But my main goal is to move away from buttons and let the home beeing controle another way programmed from the family needs.

Why do you need to controle the thermostat on the main floor, when you´re at the upper floor? (this is back to the questions of, why). I believe you have a sensor measuring the temperature in the main floor, right? Why do you need anything else? Alernative, a motion sensor could come in hand, maybe even combined with a present detection in the upper floor. When there are no movement in the main floor, set the thermostats to xx degrees, otherweise, yy degrees… Isn´t this the way smarthomes are suppose to be?

But for most basic controls, I would say things are going from okay to alot better. I know language is still a problem somewhere.

Ofcouse… Smarthomes are not easy tasks. And it´s surely not inexpencive.

Well, “learning” is not the right word. I dont want my home to “learn” either. I want it to know and to react from it, including what I have programmed/told it to do from a set of rules I decide.

I understand what you´re getting at, but I dont fully agree. “a few monitors” is the part I dislike. I cant think of any situation where I could accept " a few monitors". Unless you´re speaking in a physical amount? I need a full monitor, and then, as you said, some controles. The controles would not be at the front screen, cause it simply dont make any sense to me. They would be kept somewhere behind the main monitor and only beeing used if something goes wrong/doesnt work as it´s suppose to.