Creating a UI APP for your Smart Home / openHab

Tags: #<Tag:0x00007f61704f3840> #<Tag:0x00007f61704f3278> #<Tag:0x00007f61704f30c0>

Hi everyone, I am a Developer currently working on a new UI Tool App for openHab.
The App will be available on Android, iOS and Web maybe as DockerContainer. It will be free to use and there wont be any advertising so don’t worry.

With the App you will be able to build a UI as multiple Widgets in a ListView. You’ll have to connect your openHab REST Api to the App and after that, every Item you’ve configured in oH will be available in the app. Main Goal is, to make building an UI as simple as possible but still keeping the costumization.

My Question is, if you could wish something for an UI Tool like this, what would it be ?
What are the biggest Issues you run into currrently when it comes to an UI ?
Remember, the App is not for people who want a lot of costumization or are good at building UI from scratch because of coding experiance. It supose to take all the UI stuff away from you so you can concentrate on managing your openhab items, rules and so on but still have a beatiful UI by just some simple config.

Greetings
Mitch

2 Likes
  • Not being able to use the value of one item as a label and one value as a value
  • Not being able to split the gui configuration into multiple files.
  • Desktop view it’s two columns, Mobile view is one column.
    More control how the columns get filled would be nice. e.g.
    Mobile:
1
2
3
4

Desktop

1   3
2   4
1 Like

Is it going to be like the new UI in OH3 that will be released soon?

Backup of the configuration, means even if I delete the app and install it again at a later point in time I should be able to restore the UI with minimal fuss.

1 Like

@MitchMcKean Just as something to contemplate over: We had in the past many people building new UIs for specific reasons, many of them were indeed helpful and thus made their way into the official distro. We hence ended up with a pile of UIs in openHAB 2.5, which caused a lot of confusion and it actually raised the entry barrier for newbies instead of lowering it (what seems to be your intention). We thus decided to merge those efforts into a single UI in openHAB 3, which guides the user and reduces the complexity for everyone.

So when asking what are people currently missing, the best action is to contribute those missing features to the existing UI and make it even better. :slight_smile:

7 Likes

It should be extendable to permit other programs such as frontail to be displayed within the UI.

nice to hear that 'cause I already have that accomplished in my alpha version =)

What changed?

Or will it be a fee in the future?

But seriously if you want to contribute anything for openHAB consider helping with the new ui instead building your own ui as kai says. One of the reasons we are lacking in the ui part is because front end developers seem to be bad at cooperation. And I get that, because building a ui is a lot of work and having a good ui is a way to monetize your work. But to monetize you need to develop something yourself. So that seem to be the direction people tend to make. And that’s a shame, because if we could just cooperate together to build a consistent great ui for openHAB that would benefit everyone.

8 Likes
  1. Lock current UI in a specific interface

  2. Locked UI is isolated with the reboot or reopen the App. (I mean that the APP will not go back to the login interface for the next activation.)

  3. (I am still thinking of a way to unlock it without too much effort like reinstall it or clean up settings in the App. If there is any good method please inform me of it. Thank you very much in advance.)

The reason why I need these features is that most users in my circumstance have no idea which interfaces to choose and some of them will mess up the interface setting.

Yea, I understand that but still the point is, as I know even in oH 3 the UI is Web based. No native performance and still not possible to take advantage of the full screen of Mobile Devices because of that. I dont wanne be rude and I really love oH but all the current UIs and specially the current available oH App have a big lack of design in my opinion and really this is a hard problem to solve because often it comes with taking away customization from the user and need much more time to develop.

And I dont want to say here that thats something I will solve but its something I want to solve. Its not that I dont want to contribute something but I want to build something useful for oH wich is not locked in to oH if you understand what I mean…

It will be completely free! There will only be an option to donate and additional themes in the future maybe.

Here is my point. I am coming from full-stack web development currently learning App development and needed a project to start with. So here I am trying to create a UI Tool App. Its not the point that I dont want to cooperate and not that I dont want to contribute anything. Its not my goal to make as much money as possible out of this, just to make that clear.

I really understand what you are saying, specially font-end developers are mostly bad at cooperation but thats not why I started this project.

Currently a got my App working at Alpha. I am on my way to beta and as soon I got something to show and learned enough, maybe even released the app and got some more feedback, then I would say I am in a position where I could really offer something and maybe cooperate. Like ok, now I know what I am talking about, done that, been there. Hope you understand what I am trying to say here.

So I need a special UI for my home, so I need to finish my App anyway.

1 Like

The only way for a mobile device to have native performance og OH would be to run OH on that device. That is the definition of native performance. Otherwise there needs to be some mechanism to transfer data from the server to the device. A web interface is one such mechanism.

talking about native performance when it come to state based animation and actions inside the UI

1 Like

I understand some of your points and also see the need for a native App with a good UX and native OS support - but why not putting your much appreciated efforts in creating a native App in cooperation with the new UI of OH3?

I´m not a developer so maybe there are limitations that Im not aware of, porting elements of the current only web-based UI into a native App… but this would solve the issue that @Kai mentioned (and I definitely share that opinion as a long-time OH user) as well as your purpose to learn more in terms of app development.

But nevertheless, I appreciate your work for the community!

You might be interested in this OH3 issue.

I’ll thumb up the commends from Kai and Hilbrand.

We already have fully supported apps for openHAB on both Android and iOS. We already have too many UIs and while OH 3 helps, we still have too many IMHO. And if you do build a brand new, not officially part of the project UI, I suspect your user base and therefore overall impact to OH and the world at large will be greatly reduced.

And your building a brand new UI solves this how? If everyone who saw a problem with OH and instead of going off and building something on their own instead focused their attention on making those improvements to OH itself imagine how much better off OH overall would be.

But as was mentioned, cooperation is hard. And as a collaborative project, not everyone gets to have their own way. And so we all suffer.

5 Likes

Here Here totally agree.

Its like standards if their is 15 standards to follow then why don’t we make 1 global standard. Now there is 16 standards.

@MitchMcKean you have decided to make your own APP to learn which is the only way to learn. Just build something that’s excellent.

Once you have figured it all out see what is lacking in the OH3 app and add it in. It can be daunting task adding stuff when you are new to any group. Just know if you make a mistake around here others have you back. There is nothing that you can break that you and others can’t fix.

4 Likes

While this might be me on a soapbox…

I migrated with reluctance from OH1 to OH2 solely due to the UI mess (as I perceived it) at the time. One UI did half of this, the other another third, and not one did all, other than textual config, which seemingly got buggered up when using whatever UI. So I, for one, stayed away from all UIs.

I second the denominator (Creating a UI APP for your Smart Home / openHab), build your own, then you know what is involved, then you can collaborate. I am not a programmer, but write code in C/C++ … but wouldn’t be good with collaboration, as I do not have the proficiency to be of real help to others.

… off the soapbox :slight_smile:

One thing I can say, after that v1 to v2 UI experience, it will take me a while to adopt any UI …

2 Likes

This exactly! If it’s good (enough), people will use it and then the existing UIs can benefit from concepts and from code.

@MitchMcKean
My understanding is that you want to build an UI for displaying items and while we already have enough administrational UIs we lack UIs that display items nicely.
Please don’t get discuraged, just build something. Worst case is you learn something, best case is you make lots of people happy.

4 Likes

If I were to design a new UI for interacting with openHAB on mobile devices, I’d probably use “panels” as basic UI elements representing the controls and items to display, and place them in “cards”. In this context, it could be useful to have a fluid layout which allows rearranging the panels on a card, depending on available screen space.

Navigation between “cards” should be intuitive. For instance, swiping up could mean “up 1 level in the hierarchy” while swiping left/right could mean “switch to previous/next sibling card”.

Cards should be assigned weights to enable ordering them. An option to have a card carousel could be useful as well: when you reach the last “card” in a level, you could go to the 1st card in that level by swiping past that card. And the other way round, of course.

Ideally, you should also have a shortcut to quickly select a card on a card map.