after using OH3 quite a while now and experimenting with the new semantic model, I more and more understand the concepts behind it. That said, after struggling with the transition from OH2 to OH3, I’ve become quite a fan of it. So do not get me wrong if I say that there is always room for improvement or evolvement of concepts.
Evolvement of items
One of the concepts I would like to see evolve is the item. IMHO the item currently lacks a clear separation of identification, naming and labelling. Let me elaborate on this.
When I started with OH3 I decided to setup my smart home system up from the ground. I tried out two basic approaches:
Give every item a technical key (e.g. a UUID) as a primary identification. That would currently be the items name.
Give the item a human readable key (e.g. room_equipment_function).
Approach # 1 - technical item key
The first approach follows the model of bridges, things and channels, where each instance of these types are identified and referenced by a technical key (named UID, id, etc.). For human interactions and readability both the identification and the label are used to identify a specific instance.
In my point of view this approach has the following pros and cons:
#
Pros
1.
No naming conflicts
2.
No delete and recreate (renaming) necessary
#
Cons
1.
For human readable references only the label can be used
2.
Label must contain additional information, e.g. location/equipment/etc.
3.
Label is therefore no longer free for display
Approach #2 - human readable item key
#
Pros
1.
Name can contain additional information, e.g. location/equipment/etc., included without influencing a human readable label
#
Cons
1.
If item changes its relation to parent or children, it usually must be deleted and recreated
2.
If semantic model evolves with more or less hierarchical levelt, usually a lot if items must be deleted/recreated
3.
After creation of the item, the human readable key (identification) cannot be changed any more
Possible solution
To give the items a better usability and functionality I would like to adapt the items to have both a technical key (identification) as well as a human readable key (business key). Whereas the technical key is fixed after creation, the business key can change if the user wishes so.
In dialogs to create/delete/modify relations, the technical, the business key as well as the label should be presented to identify the item.
I may be misunderstanding something but I fail to really see the distinction between what you are proposing and what is already the case.
Currently we have:
Identifier
Restrictions
How it’s used
Item name
no spaces, can’t start with a number, cannot be changed after creation
Unique identifier for the Item used in configs (rules, sitemaps, widgets, etc.)
Item Label
none really
human readable name for the Item, doesn’t have to be unique, it is the primary way that the Item is seen in the admin parts of MainUI, used in Widgets if an alternative is not provided
Sitemap Label
none
Determines the label and how the state is actually shown to the user in sitemaps
Widget Properties
none
Combined with the State Description metadata and expressions gives you full control over how the Item’s label and text is displayed in widgets
Given this, your “human readable item key” already is there as the Item Label. When that label is no suitable for display to end users, there are options to override it. So I don’t see what you are proposing over what is already there.
then let’s have an example. Given is an openHAB installation with a couple of bindings as the physical layer. For this example let’s fix that to the KNX and Homematic binding.
The installation covers a flat with a couple of rooms. Each room has more than one equipment and each equipment has more than one item.
The following uses cases are pretty basic in my point of view:
Rooms change over time. They get split up, merged, created or deleted. They also get rebuild or inhabitants relocate.
Equipment change over time. They get split up, merged, created or delete. They also take in or out items of which the equipment is made of.
Items change over time. They get renamed, relocated, associated to locations, associated to equipment, disassociated from locations and disassociated from equipment.
All of this use cases I had in less than a year: children switched rooms, wife has rebuild a couple of rooms, child moved out, fan was extended with sensors, weather station moved location, Actors of lights were exchanged (dimmer vs. switch), electrical wiring was changed or expanded, functions of smart button panels changed or moved location.
Because in this use cases locations, equipments and items change relations, it would be most useful to have a purely technical key for identifying and referencing them. Giving entities a technical primary key is best practice for a long period of time now.
And because the associations to locations and equipments give meaning, the labels should be independent of that. So e.g. a radiator equipment in the bath should have the label “Radiator” (do not repeat yourself principle). That it is part of an equipment and located in the bathroom is the given context of the semantic model.
But, for referencing them as a human, an additional business key to identify them, would be useful when assigning them to other entities.
I’ve attached a small diagram to give a very short example:
With the separation of id, name and label you can rearrange the locations, equipments and items without to change their primary id and give them meaningful business keys as well as independent labels.
This is not correct. Items cannot be renamed, when the name is referring to the Item’s unique identifier (first row in the table above). To change the name of an Item what is really required is to delete the old and create a new one. This actually happens automatically for all Items defined in .items files every time a .items file is reloaded.
Ultimately, if I understand correctly, the root issue is “I don’t want to have to uniquely label my Items because it’s redundant to put the location in an Item’s label to make it unique because the location is already encoded in the model.” But what if there isn’t a model defined? Remember, the model is optional. The model is only used in:
the automatically generated parts of MainUI
HABot
there are a few new Actions one can use in Rules to determine if an Item is a Point, Equipment, or Location and stuff like that.
That’s it. There is no deeper meaning in the model. There is no code in core that derives meaning from the model. All the model is is a bunch of Groups and Items with special tags and a hierarchy defined by Group membership in a special way that MainUI and HABot can interpret.
You have one already. The Item’s name is the purely technical key for identifying the Item. The Item’s name is fixed at creation time, must be globally unique, and it is the primary key used to reference the Item everywhere in openHAB.
They only give meaning when they exist. The model is optional. Thus most of the things that use the model (rules, the Items Settings page, Developer Sidebar, etc) can not rely on it.
You can do that now.
The Item’s name is the primary id. That’s the “primary key” used in all the internal databases to identify the Item. And it’s unchangeable, so choose wisely.
The “name” as you call it is the Item’s Label. This is the “human readable” unique(ish) name of the Item. This is how you will distinguish all those Temperature Items in the Items Settings page, Developer Sidebar, and elsewhere where the model is not used to present the Item in a hierarchy.
The “label” as you call it is what gets presented to the end user on one of the Pages or the sitemap. This is where, if it makes sense, you strip out the “redundant” information should you choose to so the Item only shows up on the UI labeled “Temperature”. This can be done by overriding the label on the Sitemap definition. In MainUI this can be done by overriding the “default X widget” and setting the text shown as you desire.
However, beware because having all your Temperature Items named “Temperature” will only really make sense on the Locations and maybe the Equipment tab. On the Properties tab you’ll end up with card with a bunch of list Items all labeled “Temperature” with no way to tell which one is which. This is because there is no way to define a different label to be used on each of the three tabs. Consequently all of the context provided by the model (Location, Equipment) will become lost on the Properties tab which groups everything by Point. There is no reference to Location or Equipment on the Properties tab unless you provide it in the Item’s presentation label.
I do see where @franks is coming from. I have lots of items with the label Temperature, for Alexa Integration as this uses the items label. These are then placed in room groups within Alexa.
If I have ‘Lounge Temperature’ in the lounge group instead of ‘Temperature’, yes it works by saying ‘what’s the lounge temperature’ most of the time, but she does get confused bless her
That’s a good illustration of unintended consequences where a feature meant for one purpose (UI display) is uhh “hijacked” for another purpose (interface to a 3rd party system’s semantics).
Far from the only one in OH - internal example is state presentation (again a UI feature) being used to select internal units of measurement.
They’re both kludges forced by accident of history, which need appeared first.
I understand there was a deliberate decision in OH2->3 to minimize changes to Item uhh infrastructure, focusing development on other aspects.
This could of course change for imagined OH4 - say, a specific “default units” property of each Item, unrelated to display.
Taking the Alexa example … maybe that is what should be looked at properly here, addressing that issue might have a side effect of tackling the OP labelling stuff. It feels very much in the same area.
In real life, things change their names all the time and I was not talking about the technical restriction on the items name. That is the reason why you do not confuse an identity with a name when modelling entities. And that is my discussion all about. And even, if name was meant to be an identity, why not name it then id or identifier? And why is the id then a value that has to be typed in by the user?
Names on the other hand do only in rare cases define the identity of an object. Most of the times they are meant to be used by other humans. And if they change, the identity of the object still stays the same in a consistent manner.
Some simple questions here. Can you insist that your login with, let’s say google, is John Smith because that is your name? Can you choose your bank account number, when opening a bank account? Can you choose your passport number, when applying for a passport?. And if your name changes, because you got married, does that mean, that your bank account number changes than as well?
The root cause is that there is no differentiation between identity and names or labels and I can see where this lack comes from. It is an inheritance or previous versions of OH and simply was not needed for that purpose at that time.
And please, do not take this personally. I’ve learned the hard way, that users come up with a lot of useful or unuseful use cases. Whether I do like them personally or not, a good product development team always listens to users and try to see the thing their way.
I know,let’s call it “name”! It doesn’t matter, the thing we decided to call “name” is the unique identifier, and we even let people choose for themselves what it can be. This makes admin easier for most people. Other people can choose to set “name” to a9f62267bQ if they wish, that’s the beauty of it.
This isn’t your point, don’t get bogged down here.
For Google Assistant there is a name and synonym property one can use to provide alternatives to the label that GA will understand. Does Alexa not have the same?
Overall we have a hierarchy of needs and I’m very wary of something “lower down in the hierarchy” forcing something to be implemented higher up in the hierarchy.
The Hierarchy as I see it is:
Globally Unique Identifier (for use in Rules, Widgets, etc)
Human readable unique(ish) identifier (for use in Items Settings Page and other admin places where the Items are presented and searchable in a flat list)
End user’s interfaces
External integrations (I’d include HABot here as well though it could be put under 3 as well)
Anything under 2 is optional. Not everyone will use it. Not everyone will be aware of it. And there are multiple options for use in those levels. To me, if it’s something at level 3 (e.g. Pages, Sitemaps, HABPanel) or level 4 (e.g. Google Assistant, Alexa, etc.) and issues with conflicts created by the fact that the way the Item name (level 1) and Item label (level 2) are used at those higher levels need to be addressed at the current level. For example, if giving a unique and meaningful label to an Item so it can be found in the Items Settings Page (level 2) causes problems for Alexa Integration (level 4), the solution needs to be implemented at the Alexa Integration (level 4). The solution is not to invent a whole new level nor to force a solution at a higher level.
Frankly, as conservative as the core maintainers are when it comes to making changes like the one proposed, the only likely way any solution to this problem will be approved is to follow the above.
Largely because of history. “Name” was chosen as the term to refer to the unique identifier for the Item back in the very beginning of openHAB and it remains called that to this day. And it has to be typed by the user because it needs to be human friendly enough to use it in rules, widgets, etc.
It seems the biggest problem you have here is that it’s called the Item name. But the Item name does not conform to your definition of name. It is and always has been a globally unique ID for the Item.
That’s why the “name” of the Item given your definition of the term “name” is actually the Item label. The job you want the Item’s name to do is the job that was given to the Item’s label. The label is the unique human readable way for the human administrator to browse to and find an Item in places where an Item is listed and found without benefit of the model.
Ultimately these questions are not relevant. The big concern here is you don’t like that the UUI for the Item (the bank account number if you will) is the Item’s name and isn’t called something else. The fact that you can set the Item’s name when you create it is irrelevant. A UID is not required to be automatically generated.
Note: Thing IDs and Channel IDs are also settable yet these to are UIDs for the Things and Channels. And again, the reason this is the case is because there are times where we, as a human, need to find them by their ID. Allowing the users to set an ID themselves lets them choose an ID that is meaningful and findable.
Since we are giving examples, here’s one of my own.
I’ve a smart plug that drives a humidifier, except when it’s Christmas time in which case it’s repurposed to drive a string of lights.
Item Name: PeanutPlug_3
Item Label: During Christmas Time “Banister Lights”, rest of the year “Main Floor Humidifier”
On my pages I have an expressions and Widgets that only shows the Item as a Humidifer when it is not Christmas time. It’s only shown as a light switch during Christmas time.
Notice how display is more than just the text that gets displayed on the UI. The whole UI element might need to be different.
I never take discussions like this personally. Unless it devolves to personal attacks which I can’t imagine happening here.
And sometimes I see an idea and say “yes! we need that” and other times I need a lot of convincing. This is one of the latter cases.
If we changed the names of the parts of the Item though, I hope you could see that what you are asking for is basically already there.
Name → ID
Label → Name
“Labels” (given this notional notation shift) don’t really have a place on the Items themselves because what they are, how they are defined, and how they need to be used are context dependent. The label in a Sitemap is defined differently from a Text in a Page Widget is defined differently from a synonym in Google Assistant metadata. And that’s how it needs to be. If you move the label up to the level of the Item itself that means you can only address one of these at a time. What if you need a different label for your Page Widget and the Alexa integration? If there is only the one “label” on the Item you can’t.
