openHAB 4.0 wishlist

[Spaceman_Spiff (Sebastian)]

@rlkoshak

It’s a pretty miserable format to work in though, especially for rules. That’s why the MainUI code tabs convert it to YAML which isn’t great, but way better to read and understand and work in than raw JSON.

JSON also doesn’t support comments which is a significant limitation I think.

I fully agree. Json is a machine to machine data format and not suited for human editing.

@J-N-K

I don’t think that’s a good idea as it would add a third way of configuring the same object.

I agree. There is no benefit for a second textual way.

If we want to switch formats it should be yaml because it’s much more user friendly and a valid json is always a valid yaml which allows users to effectively write in both formats.

Another way would be to replace xText with e.g. a PEG Parser.

But at some point we have to really think about the textual future.
If there is nobody to maintain the legacy file formats maybe it is time we switch to e.g. yaml because it’ll be much easier to maintain.

[Cplant]

Sorry to jump in late on this topic:

@mstormi

Making existing openHABian functionality available through UI clicking will add ZERO new benefit and will not enable any more users to operate OH or ease their life in any other way.

@mstormi

That’s just a pseudo argument, often misused in comparisons or “reviews” done by people that don’t understand how the systems they write about work, probably never even used 'em.

I think there are two different aspects to this topic:

1. What adds value to users.
2. What is perceived to add value to users, or lowers the “entry-threshold” to potential new users. Or alternatively, “what’s reported by people in reviews” (who maybe do or do not understand the system) as their personal subjective perception.

I do not know HA at all (came to OH via a friend without even knowing alternatives), but just read a couple of “reviews” on the general state of mind on the net. What sticks out is that almost all of them consider HA more beginner friendly.

Now one can argue whether that’s true or not, but it’s just what people read online, before they chose a system. And since headlines like “more beginner friendly” or “less command-line configs” (independent from whether they’re true or not) stick, a share of people who’re looking for a system might lean towards HA instead of OH.

Imho there are two consequences out of that:

1. “Ok, fine, that’s the way it is.”
2. “Maybe that’s something that, if put into a backlog, could increase the perceived beginner-friendliness of OH, and thus lower the perceived entry-barrier for new-joiners.”

Both options are fine imo. #1 will basically maintain the status quo (with “reviews” still reporting the same going forward), and #2 could potentially change this (and OH could grow via a higher perceived user-friendliness and a higher share of people who go towards OH instead of HA).

[stamate_viorel]

Reading this post and my conclusion is we all want a Wenger Giant Swiss Army Knife 16999
openhab to be but at the same time just a simple knife.

[mstormi (Markus Storm)]

@Cplant

I think there are two different aspects to this topic:

Oh, there are many more.
Wishlists always are also about capabilities and willingness of people to contribute vs people that (just) raise their voice.
They’re also about feasibility, efforts and, at times, checking back with hard code(d) reality.

For sake of effective communication though, as a moderator may I please ask you to not discuss all of these meta type o’ questions in this development thread, let’s keep it focused on features.
There are better suited categories you can open new threads in.

For the record: this request is more than 2 yrs old. I will not work on this myself but I would happily merge any well done PR.

[Pedro_Liberal]

@mstormi

For the record: this request is more than 2 yrs old.

I’d like to see the pending/open requests page in GitHub being checked first, before seeing new threads opened when the same request was created in GitHub 2 years ago…
That’s how I did with the plex binding to be honest (speaking of which, can someone from the openHAB team check the merge request for the new plex binding? I’ll be around Wernau January 17th, I’ll buy you a hot coco )

[rlkoshak (Rich Koshak)]

@Pedro_Liberal

I’d like to see the pending/open requests page in GitHub being checked first, before seeing new threads opened when the same request was created in GitHub 2 years ago…

Now you’re just being unreasonable.

[livio]

Dears
Users and groups management was already asked?

[Wolfgang_S]

@livio

Users and groups management was already asked

first and second post

[Max_G]

Really good points…

People have elected to outsource their thinking to the collective… however, this is a problem we can’t fix.

When pointing people to OH, I often got the same response: HA is much easier", yet, w/o being qualified.

I am not sure about the OH strategy… does it want more users? Does a developer care, whether OH is used by a thousand or one million people? Do more users equate to more developers to ease the load? Are more users more of a pain (whiners?), than less?

I can’t answer these questions, and don’t expect answers either. However, the questions may help to direct any focus on doing work that increases the user base (if so desired).

---

As for the wish list: keep up the good work; ignore the whiners

Maybe a lot of examples for HabPanel would be nice…

[rlkoshak (Rich Koshak)]

@Max_G

Maybe a lot of examples for HabPanel would be nice…

There’s a whole category on the forum dedicated to them. Topics tagged widgetgallery. There are not a lot of people publishing new HABPanel widgets though. Most effort has moved to MainUI which, IMO, is easier to work with. YMMV.

[Max_G]

Thanks…

As usual, I should have been more precise; I mean template coding examples, rather than finished widgets or panels. While there are seemingly only four commands related to OH, the CSS and ng-blah thingies are what I need to catch up on. At least it is new to me; my last web site dev was 15 years ago. Lots has changed…

[Sebastian_Neu]

If I could wish for something, it would be the possibility to create different themes for the Openhab Main UI.

I think it would be great if you could define a time control for each item directly via the metadata.

[ssalonen]

My wish list

1. I would love to see errors popping up in MainUI.

Today many errors are only visible in the logs which makes the whole UX challenging for novices.

Could we eg have stream of logs in UI? Could we “highlight” (virtual “bell”) when there is error or warning?

2. Polishing UI

The new UI is absolutely fantastic! Small(?) polishing is the thing we need

• custom metadatas visible in UI. I know there has been design discussions to autogenerate UI for metadata and all that is great. But for me it would great even to have a list of namespaces configured
• drag and drop in model view
• Model tree view gets collapsed again after going “Back” (does not remember its state), issue 1480
• number type cannot be linked to switch (even though profiles make it compatible), issue 1478
• group items have hidden parameters but only show up in edit view, issue 1483

3. Documentation

Should we brutally eradicate/archive the old documentation?

There are a lot DSL references, jython and other deprecated technologies. Configuration is discussed via textual config samples, with no reference to MainUI

Overall this increases cognitive load. I feel it would be better we archive it clearly and start slowly building anew.

4. Mass edit/overview functionality

I am not sure if I can put this in words but let’s try

I am missing an overview of configured items/links/whatever, highlighting differences and similarites.

For example, have I forgotten expire setting from some items?
Do I have the same profile configured to these thing-item links?
Whichitems have “debounce” metadata associated with them? Can I get the names of debounced items in the same view?

Perhaps Node Red type of graphical representation from things to items would work? Including channels and item metadata? Bits of info could be hidden by default, and enabled with a checkbox. Edit views could be a modal popup by clicking in the graphs?

In the best case edit functionality would be there but even spotting the differences would be great

5. Basic profiles and transformations

It would be great to see basic transformations provided out of the box, eg debounce, scaling, transformation etc

Fromt this thread I learned that Smarthomej seems to have quite many of these…

[mstormi (Markus Storm)]

@ssalonen

Could we eg have stream of logs in UI? Could we “highlight” (virtual “bell”) when there is error or warning?

You already get popups i.e. interactive feedback if you enter bad information in UI.
We should improve here but that would need to happen in bindings for the most part (I’m referring to definition of units and valid ranges and documentation of their meanings) so it’s an ever-ongoing “sanity task” for maintainers.

Other than that, with non-interactive aynchronously appearing errors, it’s a tough request. MainUI is not a monitoring central or full IDE but made for interactive config activity. I doubt it is the right place for it.
What is an error to display ? A DSL or JS interpreter error, any Java output ? Some user-defined error message a selfmade rule is spitting ? Most errors depend on debug log config which is user specific.
[sidenote: there has been a request somewhere up to make debug levels configurable in UI. That would be an important first step. I don’t know if there exists an issue yet].
Remember these errors messages aren’t responses but asynchronous.
The real potential value to users but at the same time the real difficulty in this is to correlate those errors to thing/item config and rules they are caused by or related to.

@ssalonen

Should we brutally eradicate/archive the old documentation?
There are a lot DSL references, jython and other deprecated technologies.

Dear, no! DSL isn’t deprecated. It’s still required and in widespread use. Same for textual configuration.
Asking to remove it is like calling out for a revolution of long term and dedicated users here even if it’s just about the documentation. And revolutions rarely go peaceful.
And thing is, hiding documentation wouldn’t change a thing about it. Most don’t read the docs but g**gle anyway and the Internet never forgets.
A related part of the problem complex is that despite some good attempts such as YAML tabs and the marketplace, there is still no equivalent means to using text to share configuration data among users when config is all-UI. We’re seeing the difficulties in this every day on the forum. I guess forum traffic volume will triple because of the number of screenshots to increase.
Just think of what your proposal in effect would mean e.g. for modbus use cases, let alone the mass data aspects.

[stefan.hoehn (Stefan Höhn)]

I am already currently working on improving custom metadata usage as I feel it has a lot of potential.

There is already a PR open that will list all custom metadata namespaces in the UI to allow easier access and overview.

show custom namespaces for items

We also improved the js library that allows to use them in rules and I am currently implementing pretty easy to use blocklies for reading and changing the configs. Regarding the UI: Custom Namespaces allow hierarchies of properties, so it is not as easy as it sounds to provide a slick UI for it (there is already an issue open that where anyone can discuss ideas) but we will do our best.

[Cplant]

@Max_G

I am not sure about the OH strategy… does it want more users? Does a developer care, whether OH is used by a thousand or one million people? Do more users equate to more developers to ease the load? Are more users more of a pain (whiners?), than less?

Very valid points. And as @mstormi rightly replied to my thoughts: Points for a separate thread, or for a beer at a potential user meeting.

[Dennis1984120 (Dennis)]

My biggest wish is that the background-color/image of the homepage will be displayed if you style it with one.

[ssalonen]

So DSL and old-ecma will be there for oh4? Good to know

[stefan.hoehn (Stefan Höhn)]

Dennis, is there an issue for that? If yes, please edit to your comment with the link to, if not please create one. thx.

[florian-h05 (Florian H.)]

@mstormi

there has been a request somewhere up to make debug levels configurable in UI. That would be an important first step. I don’t know if there exists an issue yet

FYI: There is an open PR: Allow changing log-levels for add-ons by J-N-K · Pull Request #1452 · openhab/openhab-webui · GitHub.

@ssalonen

So DSL and old-ecma will be there for oh4? Good to know

NashornJS is still there as an addon, although it has been removed from core.
DSL will stay, there is just the idea to move Rules DSL to its own addon.