openHAB 4.0 wishlist

The problem for me as a “simple users” is that I do not work on such a system every day. And I think that I am not alone in this situation. Sometimes I have no time for months and returning then means that a lot of knowledge on my own installation and the concepts I implemented is gone. Then I buy something new, implement it the way I think to be correct, and perhaps weeks later when the thing has its items, some rules already use it, I see that I used an abbreviation for the room in the name of the thing instead of the full name I usually use; that automated generated items are named generic instead of room_device_point, … leading to a situation that I loose overview of my growing list of things (~170) and items. Or I did not think far enough when implemeting the first thing in a room, named it quite generic as “office_lamp” and then implement another lamp sometimes later and want to distinguish between these two lamps by the names now (and that is what I mean with hierarchy, just add an additional element to/within the name like “office_lamp_desk” to make it more specific).

I will read about the textual export/import to do some tidy up. But what do you mean by copy’n’create the YAML tab of an item? I do not see a YAML tab in the items.

1 Like

While reading through the whole tread I came across of two other wishes besides LDAP.

1) Grouping items to a custom one or a kind of struct.
E.g. these items are necessary for a custom roller-shutter widget:

Rollershutter Shutter_OG_Bad <rollershutter> (gStoren, gShutter_Favoriten) { channel="knx:device:bridge:storen:Shutter_OG_Bad" }
Contact Shutter_OG_Bad_Moving { channel="knx:device:bridge:storen:Shutter_OG_Bad_Moving" }
Dimmer Shutter_OG_Bad_Blinds  { channel="knx:device:bridge:storen:Shutter_OG_Bad_Blinds" }
Switch Shutter_OG_Bad_timerActive (gStoren_persist)
DateTime Shutter_OG_Bad_timeUp (gStoren_persist) { stateDescription=""[ pattern="%1$tH:%1$tM"] }
DateTime Shutter_OG_Bad_timeDown (gStoren_persist) { stateDescription=""[ pattern="%1$tH:%1$tM"] }

So the idea would be to define a custom item which contains the standard items.
This way the hand over to the widget might be easier as only one Item is needed.
currently it is like this:

          - component: widget:my-rollershutter-cell-v2
              vItemRollershutter: Shutter_EG_Essen_1
              vItemShutterMoving: Shutter_EG_Essen_1_Moving
              vItemShutterBlinds: Shutter_EG_Essen_1_Blinds
              vTitel: Essen 1
              vItemActiveTimer: Shutter_EG_Essen_1_timerActive
              vItemDateTimeUp: Shutter_EG_Essen_1_timeUp
              vItemDateTimeDown: Shutter_EG_Essen_1_timeDown

2) Grafana integration as an alternative to the built in graphs of OH
Grafana is a powerful Graph visualization. Many use a webserver as proxy server for openhab and grafana. So the credential hand over is always a pain. For me with the current setup (which worked before) I have to double login:

Thanks for reply. I know that the standard tabs have the full “path” available, but I am looking more for something to “build” the labels depending on the type of an individual GUI page/dashboard, … I started my journey in version 3 with the new MainUI but was quite disappointed when using it on my mobile as this often does not render properly. So I returned to the app and needed a sitemap again. Then I have two Raspi touch clients using habpanel. And every time a add a new item I have to take care that I use a identical concept to label an item for different purposes on every GUI. For a lamp on a page of a room I need just “lamp” or “lamp desk”, for a page with all lights on a floor I need the room, too, and for a page with all lamps in the house I need the foor. Therefore I look for something like “Label = Item+Room+Floor” where I can build a label as a set of variables quite similar to uiSemantics, @hmerk already mentioned above. But without additional programming and “individual approach”.

This can already be achieved and is heavily used in the „main_widget“ project by just passing the equipment group to the custom widget and having the individual items retrieved through a proper configured semantic model. (oh-repeater usage).
No need for a new item typ.


Excel is nice, a grid control within oh in which I can filter for items and parameters to compare and to change (allowing mass changes), would be nicer (in my eyes)

Ah ok, I have an example of your new rollershutter widget from here [OH3] Main UI - main_widget - part 4 - The Rollershutter Card I think.
I will use the oh-repeater component as you did. I hope it works also if items and things are only defined in text files.

You should be able to use consistent Item naming to achieve this. The component would just need you to enter “Shutter_EG_Essen_1” (or maybe select a Group Item named that which has all the Items, perhaps the Equipment?). Then, using expressions the rest of the Item names can be constructed from the property.

Beyond that, I think what this wish is really asking for is the ability to use Group members in widgets. So you can select a Group Item (e.g. the Equipment) and then pull the members as needed, using the Item names or perhaps the semantic tags to identify which Item goes with which widget element.

I don’t see how this is feasible. Grafana is a wholly separate service written in a completely different language with its own authentication and authorization. It’s not something that can just be embedded into openHAB.

However, what I used to do was use the [Grafana Image Renderer](Grafana Image Renderer to export Grafana Charts as images which OH can easily use.

Another alternative might be to use basicauth in the URL to the Grafana chart in the webview widget.

Yet another alternative is to turn off authentication for the charts you need in Grafana in the first place. Grafana has a way to publish charts for view without requiring authentication.

I’ve never not had it render properly on my phone. Did you file an issue on the problems you encountered?

So ultimately your wish is to make Sitemaps and HABPanel semantic model aware.

The problem though is that’s only supported by the oh-repeater. If I have a widget made up of labels, buttons and dials I don’t have access to that metadata, right?

1 Like

Actually, that is correct, so not available for the shipped widgets, but as you can see in our project, perfectly useable in custom widgets.

But your suggestion to use a consistent naming scheme is also a very good one and used in the OWM widget. (itemPrefix)
Benefit over oh-repeater usage is that the prefix is performing better instead of the need to scan the item registry many times in a widget.
This is something we already see with main-widget.

If you have defined tags, semantics and metadata in text files as well, it should work.
I can give you some examples on how to define those in text files. This will be part of the documentation enhancement we are workin on for main_widget.

Now I got it. This is my solution:

Timer item:

DateTime EingLampe_Ti "EingLampe_Ti"

and rule:

val TI = 15     // Timer in minutes

// Triggered - switch item on
rule "EingLampe triggered"
    Item ItemTest_SE changed to ON

// Switched on manually or triggered - set timer item
rule "EingLampe ON"
    Item EingLampe changed to ON
    val DateTimeType elt = new DateTimeType(now.plusMinutes(TI))
    EingLampe_Ti.postUpdate(elt)        // set timer item

// Timer expired
rule "EingLampe OFF"
    Time is EingLampe_Ti

It’s an elegant solution, clearer code and no need to reset the timer.

Thanks for your support - you made me happy :wink:

@rlkoshak - Fair point (which I agree with) - I was more just trying to recall the only things which really need intervention outside the UI… The persistence is the only one on my wish list, as I no longer use the exec binding (Although that may change if I look to implement the cloud disconnect workaround posted on the forum earlier !!)

Looking at the response from @J-N-K , it looks like my wish might come true for the persistence config in the UI… :slight_smile: … Great work!!


I wish for the textual config to be accessible in the browser !
Syntax highlighting and hover status peek included, of course :wink:

This is already possible with VS Code.

Part of idea beyond first implementation of security api for Eclipse Smart Home was possibility to bring different implementations of AuthenticationProvider. Default one was based on JAAS (username + password) and text file, however JAAS login module are interchangeable and text file login module can be always replaced with LDAP login module. For reference - Apache Karaf on top of which openHAB is being built, ships built in ldap login module: Apache Karaf Container 4.x - Documentation, which can be configured at runtime.

I’ve already made work on bringing initial security API back in fork of openHAB I use: Reorganization of authentication and security API. · opensmarthouse/opensmarthouse-core@947e116 · GitHub (this is commit which contains bunch of internal reorganizations on top of openhab core which been divided into smaller modules). Main points in linked commit are - unification of servlet and rest resource processing, support for different credential types (user+pw, jwt token with external identity provider, cookie, or completely custom).
Some points are discussed in other topic on this forum: RBAC model in openHAB (and potential security vulnerability found).
If there is desire and wish to go over that change from core maintainers I can port mentioned changes into OH 4.0 codebase in 1Q2023. :wink:



Hi Lukasz,
thanks for the explanation and all the work you did.
I looked at the github link you sent but my python skills are too limited to understand what you did :frowning:

Is there a reason against LDAP and a centralized user authentication system (apart from the work which needs to be done)?
I guess many OH users have more services running than OH and this would ease the user management.

Personally I would find it very appealing to have LDAP groups (e.g. admin, childs, wife, guest) and the UI would be loaded according to the group the current user is in. Nobody in the house, accept me for example, is interested in the heating statistics and I also don’t want that my son changes the boiler water temperature.


1 Like

Why making things so complicated instead of implementing user management within openHAB (see RBAC diskussion)
I really do not want to set up anything outside openHAB to use such a feature. Or did I miss something ?


Hi Hans-Jörg,
real life reason: Wife changes the default password for all services which have LDAP support.
In our household:

  • nextlcloud
  • openvpn
  • mailserver
  • kimai
  • samba file sever (actually a samba domain controller is used which provides LDAP).

Than she logs into openhab and she needs change it there too. Workaround is the proxy webserver with LDAP support. Drawback: Different look and feel, no logout button, all users have the same main ui.

It would be good to have the same user/group management for all services and I think LDAP is more or less a standard.

E.g. the openvpn config:

	BaseDN "CN=Users,DC=trautes,DC=heim"
	SearchFilter "(cn=VPN Users)"
	MemberAttribute "member"

Or for nextcloud I have a group “Cloud Users” and for the others services other groups.

Sorry, but I would call this an edge use case and overpacing.
Not everyone has such a complex setup at home like you have. :wink:

What I could imagine though, having a chooseable usermanagement, LDAP and internal.
That might be harder to implement, but makes ist more flexible from user perspective and would suit both of us :wink:

1 Like

That’s a valid point :slight_smile:
If it is not useful to other OH users than it dosn’t make sense to have this.
I don’t know if a kind of vote for all the points on the whishlist makes sense. Of course the developers and maintainers decide what they want to implement but at least this way they could see what would be most loved by the users.

1 Like