Hi,
I’m on OH 5.0 stable.
I have an item of type string that obviously seems to have some metadata constraining the values it can take and yet MainUI does not show any metadata, as the screenshot below shows (taken after having clicked on the value as if I wanted to change it - see the popup at the bottom)… I must be missing something obvious but I can’t find what exactly…
Where exactly are the 4 values (internal, external, external_2, external_3) stored?
Thanks,
Bindings can also provide state/command description metadata to Items linked to a channel, those aren’t real „metadata“ though, so they aren’t displayed.
ok, thank for the answer. When you say “not real” metadata, you mean thay they can’t be changed? Or something else?
I think you can override it by adding state description or command options metadata, but I am not sure.
I just had a conversationn about this on another thread and at least for the state description pattern in OH 5.? it does seem to be displayed. Chromecast binding - how do people use it? - #35 by Nadahar
I’ve never liked that the stuff pushed by the bindings never show up and was hopeful this was finally addressed. But if it only works for the pattern and not the command options I’d call that a bug.
I am not sure what’s the status there
I’m not sure what that means. Wouldn’t the sensible thing to do be to let the metadata the binding pushes be the default, which the user could then modify? Wouldn’t these be “as real” as any other metadata then?
I just checked, and the state description “pushed” by the binding does not appear as state description metadata. I think it would make sense to modify the REST API to pretend the pushed state description was actual metadata, so a user could see it, and modify it. Modification would add and save actual metadata than.
WDYT?
I think it would make sense if what was pushed by the binding became the default, which the users would then be free to modify. But, it seems to involve some (scary) changes in Core from what I could see.
I also considered just modifying MainUI to show whatever state description applied where no metadata exists (MainUI has the stateDescription object as well), so I was thinking of showing what was applied with a “weaker color” than actual metadata. But, the problem is when there are no “real” metadata, in that the stateDescription entry won’t be there at all.
edit: To elaborate a bit, “metadata” and “state description” are two entirely different concepts in Core, and they are maintained independently and with different mechanisms. Bindings aren’t the only source of “state description”. From what I can see, there are multiple possible sources, “metadata” is one of them, which I think has the highest priority.
When the Item is created, some code copy some of the state description that applies at that time to the “metadata”, but this seems to be inconsistent. I’m not sure exactly how this could best be “cleaned up”, I would say that probably all of the state description should be converted to metadata when the Item is created, every time, but it’s hard to predict if this would have negative consequences in some scenarios.
What is clear, is that by doing that, you would take away the “dynamic nature” of state description as it is today, it can change depending on what the “providers” provide, a binding can for example add a new option to the list of options, and it would automatically be available for the Items. But, once you copy the state description to metadata upon Item creation, this is all “set in stone”.
In an ideal world, if the binding pushes stateDescription to an Item I would expect to see it under the Item’s metadata. I think both of what you and @Nadahar propose would achieve that.
However, care must be taken that what the user does doesn’t get overridden. If one links to an Item that already has a stateDescription, that already existing stateDescription should not be overwritten by the data from the binding.
We still have the problem where if the Item is linked to two Channels, the first one to establish the link will apply and the second one will be ignored. And based on an issue I’m following on github, that order is not guaranteed. But that’s no different than what we have now. Just something to be aware of while implementing something to address this.
I do think it’s worthwhile addressing this. These hidden stateDescriptions cause no end of surprises and problems to end users, particularly when profiles are involved.
Yeah, this sounds like an obvious problem. What does it even mean to be linked to two Channels? I mean, which Channel does the Item reflect? It can’t reflect both, if they disagree..?
I think modifying the UI to display stateDescription as metadata, allows the user to see what’s currently applied, and by changing this and clicking save, overriding it as then “real” metadata us saved, which takes precedence over state descriptions pushed from elsewhere.
Do you think this solution makes sense? It would be UI-only, no core change required.
Yes, I was thinking of showing in with “disabled” color to indicate the difference. Remember that there can be a mix, where some fields are “metadata” while others are “state description”. But, when no “state description” fields are defined in the metadata at all, the “state description” entry won’t show up at all, which would have to be handled somehow.
But, because I found the implementation in Core to be spread “all over the place” and difficult to get a good overview of, making is “scary” to try to modify, I also felt that maybe just doing it in the UI was preferable.
Another challenge is if you just want to remove the state description pushed by the binding. Apparently, there are situations where this is desirable, and it is hard to achieve, since the UI doesn’t allow you to “apply a blank”. The only solution, according to @rlkoshak, is to go to “Code” view and insert a space.
But, this isn’t exactly user-friendly, so a way to handle this should probably be found as well.
There can be cases where a Channel is state only (e.g. a sensor) and other Channels can be command only. That’s one case and one I often see with bindings like MQTT.
But for the most part it is a niche use case but one that we need to continue to support.
Makes sense to me. It certainly seems like it addresses the main concern and the main thing that causes problems for users. The only gotcha I can think of is removing something from the state description. It’s hard to set an empty string in the UI and sometimes requires switching to the code tab to enter '' to remove a value.
This seems to be more of a problem with the hidden state description. It may not be a problem is the pushed values show up in the form.
Is that true? If Item metadata is defined that takes precedence, right? If the Item metadata is defined and the command options (for example) is undefined, doesn’t that mean the command options pushed by the binding get ignored? Or does it work on a field-by-field basis?
I think that’s exactly what @florian-h05 is suggesting. Making it so that the UI sees the now hidden stateDescription as the metadata. That should make it show up in the UI. Then the moment the user changes something everything gets saved as “real” metadata.
This might have more to do with the UI implementation right now. If you have a field that’s currently blank (because currently the pushed SD isn’t shown) there’s no way to set a field that’s already blank to blank except through the code tab.
But if there’s something already in the field the UI should let one delete it and by deleting it set the field to an empty string.
But that empty string needs to be saved so it overrides the field pushed from the binding. That might not be how it’s implemented now and deleting the field data deletes the property from the metadata. That wouldn’t work then unless entering any data into the metadata overrides all the fields pushed from the binding.
Can you please create a feature request issue for Main UI referencing the discussion here and ping me?
Exactly 
As far as I could tell, yes, that’s the way it works. It’s a field-by-field basis, so that you can have e.g. pattern from metadata, and still receive options from the binding.
One more thing that should be though of, is the ability to “revert to” the binding supplied metadata. This can be particularly useful for options, which often have “codes” assigned to them that you can’t really guess. So, if the binding is updated and more options added, the only way to “find the code” for the new options is to delete the defined metadata and see what the binding supplies.
edit: Regarding the metadata having priority, I couldn’t find the exact code that dictates this, but all the behavior I could observe indicated that it does. So, I can’t say a 100%, but it seems so.
Then it’s even more important that when a user deletes the data in a field that the property is set to '' and not just deleted.
Yes and no. I think there’s a use case where you want to revert to the binding supplied value too, especially for options, so how do you achieve that?
