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.
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:
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?
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.
val TI = 15 // Timer in minutes
// Triggered - switch item on
rule "EingLampe triggered"
when
Item ItemTest_SE changed to ON
then
EingLampe.sendCommand(ON)
end
// Switched on manually or triggered - set timer item
rule "EingLampe ON"
when
Item EingLampe changed to ON
then
val DateTimeType elt = new DateTimeType(now.plusMinutes(TI))
EingLampe_Ti.postUpdate(elt) // set timer item
end
// Timer expired
rule "EingLampe OFF"
when
Time is EingLampe_Ti
then
EingLampe.sendCommand(OFF)
end
It’s an elegant solution, clearer code and no need to reset the timer.
@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… … Great work!!
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.
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
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.
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.
Sorry, but I would call this an edge use case and overpacing.
Not everyone has such a complex setup at home like you have.
EDIT:
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
That’s a valid point
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.
… Great work!!