Web UIs for openHAB 3 - Contributor perspective


(David Graeff) #21

Ehm. I tried to read both of your rather long posts, but… they are long and not really on the point. But what I have noticed though is, they are not belonging into this topic :slight_smile:

The goal of this topic is to be the complementary topic to “Web UIs for openHAB 3” of the AC. I had the feeling that the AC is deciding there on behalf of everybody (but that fear was taken, thanks to @rlkoshak) without listening to users and especially contributors.

My opinion on this topic is: Two separate UIs are required. And I want to comment on some misunderstandings

A agree. I’m not separating those two parts. For me it is more like one UI for pure Setup&Maintenance: Install/modify bindings and the setup, check the logs, backup/restore, install new devices, create channels and items. Edit rules, do some batch editing in a text view mode.

Another UI for viewing sitemaps, modifying sitemaps, creating widgets, etc, everything that has to do with controlling and manipulating the view for controlling.

Those two UIs share only one piece of software: The backend connection. About 500 lines of javascript maybe. Nothing more.

That’s why I think it should be two independent projects. If a new contributor want to add a fancy widget, he has not to learn anything about the Setup&Maintenance codebase (which is naturally different than the sitemap UI codebase).

Benefits for contributors & users.

My 2ct. – David


(Andrew Rowe) #22

just quoted because this sums up a new user perspective of openHAB so perfect, wtf… Paper UI appears to be the UI interface but… it doesn’t do everything, and when you don’t understand why… you are told it’s not supposed to be a control interface, but basic UI doesn’t work out of the box… neither does habmin… wtf???
At first with zero knowledge, PaperUI is the only one that self populates and appears to work


(Rich Koshak) #23

well there goes an hour I won’t get back. But I figured it was on topic because kim is advocating for doing away with the “user’s” UI entirely because OH should be about automation, not control. If there is a place for a “user’s” UI it is strictly for monitoring with maybe support for a couple of buttons.

So his answer to the topic would be there should be only one UI, the admin UI. I was arguing against that position.

So how much is shared between the Rules page and Things page? Presumably a lot more or else the same argument could be made to split all the different categories into their own app.

Do we need 3 apps? 5 apps?

Are there synergies that are not apparent between the Rules page and the others? From the outside looking in a siremap builder/viewer seems no more different from the rest of the maintenance UI than the Rules builder/editor.


(Tobias) #24

A motion sensor…


(David Graeff) #25

You got me here. I just wanted to mention that there is no technical reason to have the ONE UI.
I think it’s more like different usage patterns for my two UI ideas. One is being used often in the beginning and then more or less only when new hardware is added.

I mentally categorize all functionality if its one of these setup&maintenance tasks or something that the girlfriend need to operate as well. The controlling UI has actually no reason to mention “Rules”, “Things” or “Channels”. It also looks different, bigger touch friendly buttons etc. I’m feeling uncomfortable to have a UI that tries to suit both. The result will be a paper ui 2 - disaster in a second edition.

Cheers


(Nico Bille) #26

I am mostly just reading the topics and don’t have to say much, because the relevant things are said. But sometimes I like to chime in to give my opinion, so…
When I used this other project I mentioned in the other thread one main thing I missed was a native app to control things. I use the openhab-app quite often, because some tasks aren’t good to automate at my site and some tasks I don’t want to automate. But I have my phone most times with me and sometimes the hardwareswitches are out of reach for my lazyness :wink: So at least for controlling things I like to have a native app like now.
If otherwise there are two UIs or one or administrative things can be done in the app or not I don’t care that much. Of couse it’s convenient to set up things on a nice app on the phone but for that many items you can have quickly in OH it can get cluttered very fast and for the most time you don’t have to do administrative tasks on a daily basis so the assumption you can have a PC or tablet for this and this kind of UI seems reasonable to me.
Just my 2 cents, hope it’s on topic enough.


(Simon) #27

What if the parts of the UI are kind of structured as a microservice UI.
In fact we could have 5(x) different Apps (Controlling, Inbox, Things, Items, …).

On top of it all theres the “master view”, which is configurable and shows exactly the parts that the user needs to see. The “Admin” of the OH installation can configure these, so we would have in the end:

  • openhabianpi:8080/master

  • openhabianpi:8080/girlfriend(boyfriend)

  • openhabianpi:8080/guests

Combined with an easy 2 roles RBAC (admin, user) where you just separate the master view from the rest.

As a PWA you could just save the respective links as webapps on the phones / tablets.

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.

I want to mention https://ionicframework.com/ if we are speaking of possible frameworks for the tech stack.


(David Graeff) #28

Quite good, but commercial. Look at their price tab. They will probably have a special deal for open source, but then why not use the complete open source, Google supported flutter.io.


(Michael) #29

Zwave sensors

  • you need to enable pairing at the zwave hub and then press a button at the sensor
    Homematic devices
  • you need to start the pairing mode at the CCU or Homegear and then press a button

Some sensors could be paired while at your desk while others (like thermostats) need to be installed first.

Please don‘t limit this view to the openHAB administrators but also to family members.
No sensor or rule can determine if my wife wants the livingroom heated or not.

Never let voice control without voice recognition control something that is security relevant.
And that‘s only the part when leaving the house.

How many cars are able to send this information to a smart home?
My BMW already has some informations that can be used in openHAB but the information is polled and doesn‘t have a parameter for the engine.

And what about the other way?
I‘m coming home and just want to park in front of the garage instead of driving inside because i just hop inside, grab something and leaving again.

It‘s not always black or white and it‘s hard to tell what someone will do with openHAB or not.
Most users want smart controlling instead of home automation.
It‘s easier to have an sitemap with controlling for everything instead of tons of apps to control everything one by one.


(David Graeff) #30

Guys! Seriously! Please stay on topic. @Kim_Andersen did a hypothetical suggestion (on the wrong topic!). But nobody wants to remove UI. And its not part of this topic. If you continue like that the AC will continue to look down all future decision taking threads. And the look down is the pure reason for this topic.

Thanks


(Simon) #31

The pricing is just for some CI / CD additional components or for enterprise level support.

The core framework is open source.


(Kim Andersen) #32

Just to make clear… I´m not speaking for removing Web UI´s.
What I´m trying to say is, that in my opinion there are two major parts.
One for setting up the system, and one for using the system.

The second could be several/different kinds of user-interfaces, (different designs) like we already have today. But I would prefere one powerfull and flexible option to design the front-end user design.

This is basicly how it is today - But they need a facelift, a clean-up, as well as new and more powerfull functionallites in both parts.

Openhab dont need to get rid of any of the UI´s we´re having today. But they could become optional during the installation of openhab. In time, when new or better UI´s have been made, I´m pretty sure the old ones will dissapear.

I made a quick strategy plan to show my idea… Just to make sure everybody get it :slight_smile:

You´ll probably notice, this is not much different from what it is today. But it should be optimized alot.

First of all…
The administrator tools should contain every possible setup options. We can not have an administrator tool, which isn´t capable of handling everything, (like PaperUI cant set taggings for items today). This is very wrong.
The administrator tools (green Web-UI) could be alot better than PaperUI is today. By the use of a better design and drop-down menu, things could be alot better giving a better overview.
I wonder when I enter PaperUI/configuration/Things, all things are listet. Why aren´t they sorted in a sub-menu (fold-out option) from the bindings installed? The same goes for the items. They could be listed and sorted by things (fold-out option). I know there is a filtering options, but why use a design like this. It´s old-school design.
There should be NO control-panel inside the administrator tools. (like PaperUI has today). If the administrator need to control/test/whatever anything, create a front user-design or use frontail log/logfiles.

Second…
The tool for designing the front user-end should be alot more powerfull. (I like the idea of using an scalable vectore graphic design for big screens (tablets etc), like the one in the Habpanel/SVG design.


Unfortunatly habpanel is not powerfull enough to make this fully scalable.
And then a more “simple” BasicUI-like design for mobilephones/small tablets.
This can become a problem where the administrator has to build two different designs). Using scalable vectore graphic design, it could become a plain drag and drop directly from items/functions, if the icons are vector graphic as well.

The Front-user design is the finished design for monitor and/or controlling the system…
My wife and family doesn´t really care about, what I´m dealing, (struggling), with when setting up the system. They care about the end-user interface, the end-user design. This is important to make this a userfriendly and logical as possible.

Please notice - None of the above has anything to do with main installation of openhab!!
Also notice, none of the above interfere with the idea of having control-buttons in the front-user design. Infact, anything should be possible.

My idea is mainly taking from the strategy behind the IHC system, for those of you who are familiar with that commercial “Intelligent House Control” created by LK/Schneider.


(David Graeff) #33

You have seen my Paper UI NG design study, have you? :slight_smile: I agree with almost all of your points.

The day is unfortunately only so and so long, otherwise I would think about the frontend controlling part as well. I hope that Yannick can help out.

HA has more developers and they penetrate more and more projects, and we only have more “users”. That does not scale well for us at the moment. But yeah one step after the other.

Just fyi: There is no free developer slot for “refrehsing” or enhancing habpanel atm.


(Kim Andersen) #34

I have, and I like it alot… It´s a major step in the right direction of my idea. (I dont like the design though, but thats a matter of taste :slight_smile: ).

I know, this is open source and rely on free an volunteer programmers… I do respect that, ofcouse. But to archive this goal, there is a need for more or things will be getting along slowly.
I wish I could provide some more help, but I cant code anything. It has been a few decades since I did, as well as web designs and havnt done since. So I would be of no use today.

What I can do is to provide my idea of the way I see things, just as well as I believe anyone else should provide their idea. Then it´s up to the AC/coders/whoever to pick what may seem to suit openhab best, and work on that part. AC/coders should not be locked onto their own ideas only.


(YvesHanoulle) #35

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).

Eh you say exactly the same as I am.
controlling ==> your 2
and administrating ==> your 1


(YvesHanoulle) #36

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?

I can see value for sensors etc
yet I know that i’m using my phone/tablet or website a lot for controlling

what I tried to say, was I never use my phone, or tablet for administrating/setting up the system.
I 'm a text person, so I will not use anything else for setting up, yet the new users that I know, usually prefer to not use their phone for administrating stuff, because it’s damn hard to get a good admin site on a small UI like a phone.
that was what I was trying to say in that part

Using a phone for control is even more stupid than using physical switches/buttons.

You might not like it
yet I do, so you just called me stupid. Probably not your intention, yet that is what you did.

Many users have different needs. a sensor and a physical button is the same for every users.

with sitemaps I can offer more different options for different users.
that works for us.


(YvesHanoulle) #37

Or even better hidden and not shown at all.

many UI specialist think that is a very confusing for new users.
when they see a greyed option they know faster they need different rights
if they don’t see the button, they thing they look at the wrong place.

==> less questions on the forums

  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.

the confusion here seems to be lacking of the features

  1. 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.

here it seems to many options. not two clear different interfaces with different intentions.

But if we keep the user’s ui and admin uis completely separated doesn’t address the apparent
I was not talking about two different interfaces. One interface with different parts

one part for controlling and one for admin /setup
I think we actually say the same, with me more in detail on how to combine them

I agree, controling the lights from a phone app is suboptimal

I’m thinking more about settings scenes. TV/ romantic/breakfast etc
I don’t have enough buttons in my (new) house for all the options I can already now think of.

Many users do not have voice command either, because it isn’t available in their country,

We are also a long time away from having good enough voice control in all languages.

some things end up being more convenient to control from my phone

  • A phone is location independent.
    I work at home from a walking desk. with a tablet/phone website I can contor my whole house, without the need to leave my walking desk.

And when my family is a sleep, I don’t want to talk to alexa to turn of the television my son forgot to turn off (and I don’t want automatic turn off the TV when someone has just left the living to go to the toilet)


(Kim Andersen) #38

[quote=“yves, post:36, topic:67453”]

Using a phone for control is even more stupid than using physical switches/buttons.

No, my intention was not to call you stupid, as a person… It´s the act itself which doesnt make much sense. Like I wrote to Rich…
Standing in my garage right next to the physical pushbutton to controle the garagedoor, or should I go for the phone in my pocket?
We shouldn´t be arguing which option requires less handling (= beeing smart). But we can have different opinions about, which option is “smart”. I know my opinion in that specific situation. I would feel rather stupid going for my phone :slight_smile:

This is basically what I´m trying to advocate for, in general! As well as the UI´s for openhab (trying to get back to topic). Think smart, be smart. This is what smarthomes is all about, in my opinion though!


(YvesHanoulle) #39

like I said , not your intention, yet when you say “using … is stupid” and I like to do that, you are telling me that I’m stupid.

I would much rather prefer you asky what is my intention in doing it that way, you will lget the same answers without making me feel insulted.

Standing in my garage right next to the physical pushbutton to controle the garagedoor, or should I go for the phone in my pocket?

yes when I’m close to a button that is configured to do exactly as I want, I will use that.
yet most of the time:

  • I’m not close to the button:
  1. On the couch
  2. on the toilet
  3. in my car trying to get into the garage
  4. I left the garage with my hands full of groceries and It’s raining cats and dogs and I want to close the garage from my house.
  • I want more sphere’s then I have buttons.

about smart homes:

There is a training facility that I used some time ago, not had buttons that activated sphere’s, like presentation mode, video mode etc.
all great if you know what switch does what and works when.

when you only hire it for an afternoon, they don’t bother to explain the buttons they give you a tablet where every button has the name of the mode, much easier for newbies

I want the same for visitors like babysitters…


(Kim Andersen) #40

Sorry, it´s never my intention to insult anyone.

The rest of you message I will reply in a new thread later, as it´s getting off topic in this one.