with “loop.witem.metadata.semantics.config.hasLocation” within an oh-repeat I get the location item name. It is working correctly.
Now I want to get the respective label. My 1st idea “loop.witem.metadata.semantics.config.hasLocation.label” is not working.
Any hint?
Of course that won’t work because the Item label has nothing to do with metadata, semantics, or whether the Item has a Location in the semantic model hierarchy.
loop.witem.metadata.semantics.config.hasLocation.label is just a string containing the name of the location item. It is not an object containing any additional information.
The short answer is that you cannot do this in any built-in way.
I did not say no chance at all. I said no built-in way. There are certainly a few ways to brute force this, but they would all be overly elaborate (and there for prone to breakage) and/or result in a measurable performance hit for the widget an any page the widget is on.
This is the crux of the problem. The MainUI is not OH core. It is a standalone frontend that must communicate with the OH core via the API the way every non-core application must. Furthermore, MainUI must also then serve that information to the users web renderer (browser, app, etc.). In order for this combination of actions to be as performant as possible the MainUI is streamlined and made as efficient as possible. As a result, the information that is provided to the widgets is kept minimal. The items object, therefore, does not include the label of the item. To include the label in the items object was judged to be including more data than it was worth given how infrequently it would be used.
Something like loop.witem.label works because the oh-repeater is special and makes it’s own extra api calls to the core items endpoint and returns all the information the comes from that call (that is the item object json) and that includes the label.
The only workaround I can imagine is to nest a second oh-repeater for all location type items.
The filter could include the name of the location item the parent repater gave.
Then the child oh-repeater has access to the label.
That’s certainly one example of the “performance hit” options.
If I were forced to do this myself, I would probably create a rule that runs at interval and reads the semantic metadata for each semantic item and updates a different custom metadata with the labels of the the semantically related items. Then the main repeater has access via the new metadata namespace to the label info. This would be an example of the “overly elaborate” and brittle options.
edit: but first I would work hard to refactor the widget so that this label problem is a non-issue…
I use a similar approach where I “enrich” my per-floor list of lights with a label which room they belong to that I use in a per-floor light(s) status widget, script below:
function enrichMetadata(item) {
var semantics = item.getMetadata("semantics");
var isPointOf = semantics.configuration["isPointOf"]
var isPointOfItem = items.getItem(isPointOf)
item.replaceMetadata("widgetDisplayName", isPointOfItem.label, null)
}
function enrichMetadataForGroup(group) {
items.getItem(group).members.forEach(i => enrichMetadata(i))
}
enrichMetadataForGroup("gFF_Lights")
enrichMetadataForGroup("gGF_Lights")
enrichMetadataForGroup("gBasement_Lights")
enrichMetadataForGroup("gOutdoor_Lights")
since my model is pretty much static nowadays I manually run the script, when needed.