This brings me to two interesting points I think about when talking abou a wishlist:
Up to now we have unchangable identifiers for things and rules and names for items, … Understandable from a technical point of view, but a pain when an installation grows over the time and naming conceps may have to be thought over. A big step to solve this situation would be to implement a third level between given, unchangable, technical identifier and label, as a changable identifier following a also changable hierarchy. An easier solution could be a user defined namespace as you mentioned, just giving up already given identifiers, sticking with random identifiers for new stuff and using the user name space instead.
The human friendly label is nice, but to be honest: If you set up pages/UIs for different uses you always have to chance the label. Within a room a label “heating” oder “radiator desk” is nice, having a page with all the radiators on one floor you would like to see just the room and perhaps a more detailed information like “office - desk” for the radiator behind the desk in the office. And for an overview of all radiators in the house you might look for something like “1st floor office” to differ it from the office in the basement. This is also something that could be implemented directly (with some effort) or be done by using a user name space that could be used to name items in the UIs instead.
As you indicated yourself it’s the object identifier and changing those is a hassle in about every database.
You shouldn’t really be changing namespaces more than once or twice at most, and that’s a mass edit thing you could be doing with text ex/import.
For single items it’s really just copy’n’create the YAML tab, that’s easy enough.
In total, it’s not much worth spending efforts so don’t expect that to happen.
Hierarchy should NOT be changeable beyond the extent it already is and we do not need more layers. More flexibility is not a good thing per se if you can represent all your building in the given model taxonomy because it encourages (call it “forces” if you like) users to build housing models alike, reusing existing concepts, allowing for reusable code to be built on top.
My wish would be configuration of persistence via the UI. From what I have seen this is one of the few remaining aspects which still need to be configured via text files? (Other than the command allow-list for the exec binding, which is a binding I no longer need to use).
Now that I have made the transition to putting all my configuration and rules into the UI (a while ago), its one of the few reasons I actually need to play around in a text file in a shell session.
My thinking is:
Configuration against each persistence binding within UI, where the persistence strategies are defined
Configuration within each Item where the persistence strategy is selected from a list
Sounds so easy when you type it into a Forum, but I’m sure implementing it will be quite the opposite… But it’s a wishlist, so why not put the idea out there?
For security reasons, I can’t see the allow list ever becoming editable through MainUI. The whole point of the allow list is to prevent someone who has network access to your OH the ability to run arbitrary commands on your machine. Allowing it to be edited in MainUI kind of defeats the whole purpose.
This allows having the same user/password within multiple services and group management.
The current workaround is to use a webserver with LDAP support doing the authentication.
This has some disadvantages, e.g. a simple log out button is missing. Also this does not have the same “look and feel” than the OH3 UI:
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.
