Semantic Tags for item not inherited from linked channel (OH 5)

[lolodomo]

@andrewfg : I just made a quick test, removing some semantic tags from few items in my .items file.
I was expecting semantic tags being automatically inherited from the linked channel.
I just discover that it does not work, I mean my items are not present in Properties view in Main UI.
Wasn't it the goal with all the changes done with semantic tags in OH 5.0 ?

[andrewfg]

Wasn't it the goal with all the changes done with semantic tags in OH 5.0 ?

Indeed. The UI creates the Items, links to the channels, and inherits their tags. So it depends if you are testing @mherwege's latest commits.

[andrewfg]

@lolodomo it looks like you are referring to unmanaged Items that are (re)created via a .items file? So far we only focused on managed Items created via the UI. It is not obvious to me how Items in an .items file should behave. Currently we only create tags that are already explicitly in the .items file. Or none if there is nothing explicitly in the .items file. I guess that auto importing newer tags from the Channels could be done, but it would therefore over write the tags of the .items file, which would be a breaking change if the user had written the .items file to explicitly not have tags.

[andrewfg]

@mherwege /@jimtng thoughts?

[lolodomo]

I guess that auto importing newer tags from the Channels could be done, but it would therefore over write the tags of the .items file, which would be a breaking change if the user had written the .items file to explicitly not have tags.

I was expecting tags from linked channel to be applied if there are no tags set by user on the item
But what to do in that case if item is linked to several channels?

But that is also true that a user could like to have no tags set on his item.

[andrewfg]

Yes to all of the above. So we could certainly code something for items files. But before starting coding we should have a clear architecture picture of a) the actual intentions, b) the syntax within the .items file, and c) breaking change impacts if any.

[lolodomo]

It is a little deception to finally understand that all this massive work done in OH 5 will add nothing new to users using config files.

[lolodomo]

I close the issue as it is not an issue, users preferring config files have been just ignored.

[mherwege]

@lolodomo That's a bit harsh calling it being ignored.
There is a similar situation for UOM.
Also for managed items, there is no automatic heritance, only a proposal when creating an item. I would think making it automatic would actually lead to unexpected results. You may not want certain items in your semantic model.

I wouldn't know how you can have a proposal with file based definitions you can decline.

[jimtng]

One possibility is to add a config to itemchannellink called usetags or something to that effect. How that would coexist with a profile though.

[andrewfg]

Referring to this https://www.openhab.org/docs/configuration/items.html#item-definition-and-syntax

I suppose one option could be to support a tag field syntax in the .items file like [*] which means "inherit tags from channel" and maybe even "inherit equipment tag from parent Thing". Or something like that. => WDYT?

[andrewfg]

@lolodomo any thoughts on the above mentioned suggestion? I could write something later this week but it would probably miss the code cutoff date.

[lolodomo]

I suppose one option could be to support a tag field syntax in the .items file like [*] which means "inherit tags from channel"

@jimtng 's proposal with "usetags" as channel link configuration looks like a better idea.
We should even consider as true by default.
But also consider what to do if true on a channel link but tags are also set on the item itself. In that case, tags set on the item itself should have higher priority I believe.

and maybe even "inherit equipment tag from parent Thing". Or something like that.

The equipment tag is useless as it has to be applied not to the item itself but to a group it belongs to. This equipment tag is useless for defining items in config file.

@lolodomo any thoughts on the above mentioned suggestion? I could write something later this week but it would probably miss the code cutoff date.

Forget, it is too late! I was convinced it was a new added feature, I should have checked more in detail and tested earlier.

[andrewfg]

Personally I would suggest NOT to have a config switch on the Items. The whole point of using items file is to have full control over everything in one place. So doing a part in the items file and another part via the UI is non transparent and really "half pregnant". I think everything should be done in the items file. All or nothing..