Ideas and Discussion: What Features Do You Want in openHAB 5.0?

Development Features
203

One more things, I would like to see also a more easier experience in editing things inside and / or outside openhab UI. There was already some posts on this, but let’s me explain a little more.

  • The widget editor is quite unasable : let me explain.

    • When you have complex widget, hundred of line, the editor is very slow.
    • There is very limited functionnality support : no code completion.
    • We have an UI preview, which is great, but there are many quirks that made it difficult to use the editor to develop complex widgets.

  • The UI editor : as already said, the was a great addon compare to previous openhab version.
    But editting UI is not so simple :

    • We lake support of drag / dropping items inside the editor. I you need to move up a row inside a layout that contains 10 or more row, it’s just a pain.

    • Understanding the UI in edit mode is not simple : many time I have to ask myself about what is the good buttons to edit a widget settings / edit a row / edit a column /etc. The different buttons are quite the same, the is no clear separation between the different layer.

    • Understanding layout is not easy for new comers. I know by asking many time on forum that there is solution to any thing that we need to be done, and that if searching we can certainly find in documentation / previous user ask. But definitively this is not easy for people not having experience with it. Specially when you come to things like responsive design to adapt your UI ot diffrent form factors.

Let me be clear, this is not about to criticize about the jobs that was been done on the existing UI editor, that was a very good job. But just about my feeling on every use, and some way we perhaps get is better.

  • The items - things - rules, … etc. editors

    • Another things that was great additions was the UI editions of things / items / rules inside openhab UI. But you have to make a choice :

      • Edit them in Openhab UI, and so have it inside the JsonDB database.
      • Or Edit them outside Openhab UI, using the text file configuration. But have limited support on modifying them on Openhab UI.

This is the case I thing for most of the editable :

  • Things create in file can’t not be modified in UI.
  • Script on file system automation/js can be displayed in UI, but not modified.

What I would be happy to see:

  • Some improvement to the UI editor to make it more usable in day to day editing the UI.

  • A more modern text editor inside Openhab UI that would make edit widget more friendly,
    possibly using a thirdparty text web editor.

  • Possibly extend this editor usage so we can edit standard config file inside openhab : items, things, script, etc…

  • Possibly, but more complex : some sort of online dynamic synchronization between textual config files, and JsonDB representation. I things that there is already some tools to do this in offline mode.But if we go to the end of the idea, it will be we can edit configuration on both side without noticing that there is a difference on the underlyning implemenations (I know, this one sound like a little dreaming :slight_smile: ).

Laurent.

204

@rlkoshak,

Interesting, I’ve was not remenbering about this “Add equipment to model” functionnality. I will have to retake a look to this. Have to said that on my side, I’m using mostly the text file configuration has I’m an old user of Openhab since 1.x release.

But it’s about what I was saying in my post;
It’ not that functionnality are not there, or that we need to modify the underlyning model.
It’s more that we need to make thing more visible / evident for new user to find them without have to search about it !

About the UI and default items expose from semantic items : one drawback I can find on it.
You have a dashboard populated from your semantics models, but you can’t modify / personnalize it (stop me if I’m wrong).

Laurent.

205

In my experience, those users who have the hardest time with OH 3/4 and those who usdally know the least about what they provide are not brand new users, it’s old users of OH who jumpped without at least reviewing the Getting Started Tutorial.

“Add equipment to model” has been there since OH 3.0 and it’s discussed in the Getting Started Tutorial. Semantic Model | openHAB But far too fewOH 1/2 users ever bothered to review it.

You absolutely can modify/personalize it. You can hide stuff from different types of users, set background images, change the order, change what badgets get shown, change how the Equipment and Point Item’s widgets are shown in the cards, and define your own widgets for any Item if the default isn’t want you want for whatever reason.

In the screenshots I took above I’ve done the following customizations.

  • Created sections to separate the cards per floor on the locations tab
  • Set the order of the cards
  • Almost all of my Items have a custom widget shown in the cards so I can control the icon colors and in a lot of cases combine several Items into one widget. I think all of the widgets I show above are on the marketplace.
  • Some Items I want to keep in the semantic model (for rules) but not show on the Overview cards.

All of these options are covered in Getting Started: Pages - Overview Page | openHAB for some of the customizations of the Overview page. There are more options available than those, these are just the ones I’ve done.

1 Like
206

So you definitily get me, I’m this old user that have don’t read the doc and tutorial.
Sorry for this :slight_smile:

One more time, i’m not saying that contributers have not made some good job on Openhab.
But my opinion is that the way the interface presents things today make it not so easy to figure out the possibility offer by openhab.

Perhaps the opinion of user that have lesser experience then us would be interesting on this topic. I know, Rich, because of already discussing with you that you know many aspect of openhab and the UI. What is interesting is to see for a newcomer if it’s easy to setup, or need to take a long time reading the documentation.

Laurent.

207

huh… so you get node red but not blockly? I kinda thought both were very similar as far as visual programming

208

This is true, and a concern.

Also if you wondered why these cards outside Locations were so big, it’s because they were always meant to display more than a title and background. But generating stuff automatically like for locations was too difficult and never done.
You can add whatever you want yourself though:

image
image745×923 39.9 KB

      Humidity:
        - component: oh-property-card
          config: {}
          slots:
            header:
              - component: oh-gauge
                config:
                  borderBgColor: rgba(255,255,255,0.4)
                  borderColor: white
                  borderWidth: 20
                  item: ZW074Sensor_Humidity
                  labelText: Humidity (Avg)
                  labelTextColor: white
                  size: 250
                  style:
                    margin-left: 30px
                  type: semicircle
                  value: 60
                  valueTextColor: white
      SoundVolume:
        - component: oh-property-card
          config:
            backgroundColor: black
          slots:
            header:
              - component: f7-link
                config:
                  style:
                    color: white
                    font-size: 14px
                    text-transform: uppercase
                  text: Multiroom Audio Volume
              - component: f7-block
                config:
                  style:
                    color: white
                    display: flex
                    flex-direction: row
                    justify-content: space-around
                    width: 320px
                  title: Multiroom Audio Volume
                slots:
                  default:
                    - component: oh-knob
                      config:
                        class:
                          - card-prevent-open
                        item: MusicCast_Salon_Volume
                        max: 110
                        primaryColor: white
                        secondaryColor: gray
                        size: 75
                        textColor: white
                    - component: oh-knob
                      config:
                        class:
                          - card-prevent-open
                        item: MusicCast_Chambre_Volume
                        max: 50
                        primaryColor: white
                        secondaryColor: gray
                        size: 75
                        textColor: white
                    - component: oh-knob
                      config:
                        class:
                          - card-prevent-open
                        item: MusicCast_Bureau_Volume
                        max: 30
                        primaryColor: white
                        secondaryColor: gray
                        size: 75
                        textColor: white
      Temperature:
        - component: oh-property-card
          config: {}
          slots:
            glance:
              - component: oh-link
                config:
                  color: white
                  iconColor: white
                  iconF7: thermometer
                  style:
                    font-size: 12px
                    margin-top: 8px
                  text: "='Ground Floor: ' + items.GroundFloor_Temperature.state"
              - component: oh-link
                config:
                  color: white
                  iconColor: white
                  iconF7: thermometer
                  style:
                    font-size: 12px
                    margin-top: 3px
                  text: "='First Floor: ' + items.FirstFloor_Temperature.state"
              - component: oh-link
                config:
                  color: white
                  iconColor: white
                  iconF7: thermometer
                  style:
                    fontSize: 12px
                    margin-top: 3px
                  text: "='Outside: ' + items.Outside_Temperature.state"

Use the glance slot to add stuff below the title or the header slot to redesign the entire card.

3 Likes
209

I would like to see the personal widgets sorted when adding to a page.

Currently it is not sorted and sometimes it is hard to find the widget that is wanted to be added.

Maybe add a filter to find the widget easier?

Thanks

210

Search works even for marketplace widgets.

image
image2004×380 44.3 KB

Never mind. You are not talking about installing widgets. Indeed, if you have more than just a few there that list is pretty hard to use. Search, sort, and stuff like that would be nice. I’d like to see that look the same as the Item selection dialog really.

211

I have no opinions about frontail vs other similar systems, Windows support would be nice of course. But, I think that having it integrated in MainUI would have one huge drawback: It wouldn’t be able to report what’s happening during startup/shutdown of OH. I find that very useful with frontail now, because having to SSH in and use command line tools without (easy) coloring and filtering just makes finding what goes wrong so much harder.

212

I think there’s a more general “problem” with MainUI that hampers adoption. I myself have used OH since OH2, I’m not sure exactly when I started, but I’ve been using it for 6-8 years or so. I still use a combination of Sitemap and HABPanel for my “daily use” (a combination because both have their shortcomings).

Since OH3 I’ve had numerous attempts at “migrating” to MainUI, but each one has stalled. I’m at it again now, and maybe I’ll succeed this time, but: I’m both quite technically inclined and stubborn and persistent. When I get overwhelmed and give up, I suspect that the majority has already given up a long time ago. And, that’s the point I want to make: It’s just too difficult to figure out how to do a lot of things. It’s often not very intuitive, and even the smallest things can require hours of reading forum threads.

Don’t take this the wrong way, I see that there are many good things in MainUI, the structure shows a lot of ambition - but the downside that users must often understand quite a lot of the concepts and structure just to do simple things.

I don’t really have a “fix” for this, but I do think it’s an important issue. Better documentation is an obvious suggestion, but there’s actually quite a lot of relatively good documentation already. The problem is to find the part you need at that time without a huge effort. I think that maybe this could be made somewhat easier by organizing the documentation in a more “hierarchical” way - so that you could read through topics faster to get the overview, and then “drill down” on the parts that really interest you right then. It might not be easy to actually achieve, I don’t have a good suggestion as to how exactly the documentation should be organized to work that way, but I believe that if it was achieved, it would make it easier for people to find the information they need. I often find that the documentation “hides” the bits I “need” at that time at some place that I would never have guessed, and the only way to find it is to read through a lot of stuff that don’t interest me right then. I also don’t think the documentation goes “deep enough” in many instances.

There’s already some “context-sensitive” help available in MainUI using the question mark in the upper right corner, which opens the developer sidebar. Extending such “interactive documentation” might also make it easier to understand how things tie together. That said, I’ve never noticed that “interactive documentation” until now… Personally, I really appreciate tooltips and “similar mechanisms” that focus on the exact thing you need to figure out right there and then.

I also think that a more intuitive design would be helpful in some places. If users understand something without reading the documentation, that’s always better than having the world’s best documentation.

It might be hard for many of you guys to see how this looks “from the outside”, because you already know the things people struggle to figure out. I often feel that the bits of information I need to gather to do something is spread all over the place, and that it can require some significant effort to find what I need. It might be something to think about that I find it much easier to figure out how to write a binding than to get MainUI to “behave”. In the end, if you can’t get things to work like you need them to within some reasonable amount of time, it probably won’t be used - meaning that some other solution will be used instead - whether that is another UI with OH or some other system altogether.

3 Likes
213

Part of the problem here is that, of course, intuitive is a subjective experience. For my part, when I moved from OH2 to OH3, I had little javascript experience, knew less about Vue, had never even heard of Framework-7, and was at least 10 years out-of-date on my css. The moment I went through the posts Yannick was producing about the new OH3 custom widget system, something about the way it was put together made nearly perfect sense to me from the start which, in turn, made it much easier for me to pick up those pieces I was missing.

Now, I’m probably a bad example here (OK, I’m probably a bad example for most things), but the fact is that ‘intuitive’ is not universal. Just a little way up this thread @Pedro_Liberal (no slouch in the technical expertise department) admitted that blockly, an interface specifically developed to be as intuitive as possible to as wide an audience as possible, doesn’t work for him. I’ve got my own series of things everyone else thinks are “intuitive” that I just cannot wrap my head around.

I know that many people do not see the widget system as intuitive the same way I do and that’s certainly one of the reasons I try to put detailed explanations into my forum answers whenever I can. But that kind of support has to be there for everything because, there’s no way to achieve something that’s intuitive for everyone. Note that I am definitely not saying “this is an impossible goal so we shouldn’t try”. I agree completely that there is always room for improvement. But I think you’re closer to the mark with this:

With a complex (and individual system) like home automation, “intuition” is only ever going to get you so far. Understanding is a much better goal. So how do we speed up getting a new user from 0 to understanding? How do we make it easier for new users to learn? How do we make it easier for experienced users to translate their experience from old version to new? There’s obviously RTFM (and the docs for every software platform everywhere can always use some love), but I agree with you that there’s a definite place for learning from the UI as well.

This is a great example. I added that help feature after the last one of these wish list topics and when I did there was some discussion of how intrusive to make it. Because one of the things to remember is that UX is a very complex optimization problem. There is not just the Intuitive ↔ Arcane axis to consider. How about the Helpful to novice ↔ Not irritating to experienced users axis? I don’t know about you, but I despise those startup windows so many programs have with “helpful” tips when I just want to get to my main window, thank you very much. I angrily click the “Never waste my time with this useless nonsense again” option as soon as I have the opportunity (I frequently also later curse the stupid program when I can’t figure out how to do something that “should be obvious”). You just recently noticed the help system because it doesn’t get in the way of an advanced user but that also makes it a little harder for a novice to find. There’s a lot of talk about how OH won’t thrive in the long term if it can’t attract new users, well, alienating your current experienced user-base can be just as problematic (just ask SONOS…).

In the end, I think one of the reasons that a lot of people with technical experience in general and OH experience specifically find MainUI “less intuitive” is that there is a higher expectation of what “just works out of the box” really means. When you have a better idea of what’s possible, what “should be easy” is not always the same thing as “should be easy” for someone just starting out. I do this all the time. “What do you mean I can’t just sum three time series, take the integral over arbitrary periods and graph the histogram with the click of a button?! That’s just basic stuff!” And I have to remind myself that just because it’s my requirement doesn’t mean it’s everyone’s requirement.

7 Likes
214

I agree that “intuitive” is very subjective, because it depends on the person’s previous knowledge, experience, habits and to some extent probably also personality. So, while there is no such thing as “universally intuitive”, I’d say that there is something pretty close to universally unintuitive. So, there is some order in the madness, up to a point at least. For me, intuitive doesn’t mean that I instantly know how to use something, but that there’s consistency and a “red thread” that I understand after having struggled with it for a little bit. If I never “see the system”, never know where I should probably look for this or how I should probably do that, I deem it unintuitive. Consistency is more important than the solution itself, as I see it, but this consistency must be on a “concept level”. By that I mean that if one thing is solved one way, and there’s a somewhat similar thing, it should be solved in a similar way - so that a user can guesstimate how to do a task he/she has never done before.

I don’t think you can ever get to a point where the average user have experience with JavaScript, CSS, HTML or the various frameworks. I know close to nothing about Vue and Framework-7, except that I read that they were abandoning their desktop support and were going to focus exclusively on mobile. Not a good development in my view, and it completely shuts down any interest in learning more about it. When it comes to JavaScript, I dislike it because it’s so messy, because of the missing type system - basically because it’s a mess. CSS is also a mess, with different things supported by different browsers and browser versions. You can’t really keep current with stuff like this without working with it on a more or less daily basis. It’s just too inconsistent. This makes me “unwilling” to learn more than I absolutely need to solve a certain task with these tools. And, as soon as that task is done, I forget it, because I simply “can’t afford” to remember things that probably won’t be correct the next time I need them anyway.

I don’t know how others do similar considerations, but we all have to choose what we want to keep in our head - the storage space is limited. Because of this, I doubt that most people will ever choose to keep enough knowledge about these things to really be able to efficiently navigate it, unless they are involved in this in some other way (work etc.). That doesn’t mean that people can’t learn how to use a CSS property to change color, that doesn’t require “learning CSS”. But, most users will never know enough about CSS layouts, hierarchy etc. to “master” those things. They will probably need examples/samples that they can tweak.

I think the clue is to have a system that “works” for people with different levels of knowledge. If you have to acquire a lot of knowledge before you can do anything, most will give up. If you can do basic things with basic knowledge, and then study whatever parts that you want to be able to do more with further, I think you have a system that “invites people to learn”. But, translating that into an actual implementation might not always be so easy. You can get some way with sane default and the ability to override when needed. But, it is hard to do both, without doubt. At the same time, one thing is certain: Those that are scared away because they can’t acquire enough knowledge to achieve anything, will never learn the system.

I must accept a considerable part of the “blame” for not discovering this. The reason I never saw it was that I never looked for it. The reason for this is that I didn’t expect that anything had changed since I first saw OH3 - because the UI looks similar. When you “think you know what you’re looking at”, you often won’t notice the details. It’s one of those things we do to save time and effort.

But I agree that it can be a difficult balance. Forced wizards are definitely not the answer, they should be banned globally. Ideally the information should be available, at your fingertips, when you need it - but not get in the way when you don’t need it. This is why I love mouseover tooltips - except that it’s annoying that the often disappear after a certain time. Eclipse has gotten that right - if you click the tooltip, it will stay until you close it. But, tooltips doesn’t work with touch, which is probably why it’s been in so much decline. I still think it’s the best way I’ve found. That said, one could probably place small buttons/symbols “everywhere” that you could click to get a similar popup. But, it would be a lot of work, and it would have to “integrate” with the “larger documentation” so that concepts and structure weren’t explain in the “tooltips”, but were refereced/linked to.

Whatever technical/practical solution is used, I think the “ideal documentation” is easily accessible when and where you need it, but doesn’t get in your way.

2 Likes
215

Energy logging and visualization out of the box would be great. Yes, it is also possible with the current OH4, but only if you are very experienced, because you need to write rules, unterstand persistence, develop some nice widgets.
I think the user only wants to add its energy meter thing, that’s it; graphing, logging, everything is done automatically.

1 Like
216

To be honest, I think this is really difficult to achieve, as there are many different ways to connect a energy meter (smartmeter).
I have already published rule templates for doing calculations based on a meter Item value and a widget to show those.
But a said, there is no general meter thing.
You can have meters delivering the correct value, sometimes you just get pulse counters and have to build the meter value from that.
But feel free to open a new topic, describe a bit more detailed what you would like to see (have) and we csn check, what‘s feasable.

217

Lets keep semantic in another thread, cause I really dont get it, while I need to ask some specific questions :slight_smile:

The issue is, the widgets tends to get on top of eachother.

In the code section of the page, there the resolution can be set.

Thats not fair.
Yes I dont get the sematic model. So I gave up on that. But I can still create pages by hand. And thats the thing I adressed to become more automatic. I see this as two differenf ways of creating a dashboard.
Perhaps you´re right, that Semantic model can do much of what I ask. But it doesnt help much since I dont get.

I never said anything about throwing something out. I suggested to focus on how users can easy create a good and modern looking dashboard from a few examples (templates), without having to deal with html, css etc..

218

Someone sometime finally made ‘Latest Post’ the default in the search page instead of ‘Relevance’ which I had be asking for… forever

I now feel openHAB is perfect in ever way and we no longer ever need to have any of these type discussions or work on the code. :upside_down_face:

I just checked my own discourse server and relevance is the default still so somebody actually changed this in our forum

Who ever you are… THANK YOU!!!

219

No. That generally put, that’s an application and not OH’s intention nor vision to provide you with.
You have been requesting this a number of times already, I remember hearing you say that back in the OH4’s equivalent of this thread.
But OH is not Home Assistant or any other home automation software that attempts to provide out-of-the-box application level functionality, and it never will become a system to attempt this.

So let’s put it straight: this will not happen.
It is and will remain the user that has to combine available OH elements (widgets, rules etc) to create an application that matches his needs.

If your wish is to have energy monitoring (a vague buzzword on a very wide playing field BTW), then go create your application for your devices. Most if not all the ingredients are there.
Checking the marketplace for templates may help you in achieving this faster.

But it’s still your job as the user, and it will remain to be.
Please stop asking over and over for someone else to build it for you.

1 Like
220

I have everything already in OH, so I don’t need it any more. It was just an idea to bring more users to OH as in my opinion it is very complex to do this with OH.

1 Like
221

51 posts were split to a new topic: On openHAB documentation and some more

230

Suggestion:

On the overview page the only way to see the side menu is to pin it.
Can there be a pinned option and also have an option to show the side menu if you move the mouse to the left. That way I can have the overview page as full screen but if I need the side menu I don’t have to click the 3 bars then click the pin then click the side menu option I just need to move to the left and select the menu option.

(I don’t want to wear out my muse button :slightly_smiling_face: )