Some metadata StateDescription seem to be in play and yet MainUI does not show it

Setup, Configuration and Use Beginners
21

Here is some info about this structure:

So, as I understand it, these “fragments” are the individual fields in the state description, and “providers” can provide any parts/fragments that they want to.

Metadata is something entirely different, and state description (fragments) is only one of the things it can provide/carry, if I understand it correctly:

I can find 4 providers:

  • DefaultStateDescriptionFragmentProvider
  • GenericItemProvider
  • MetadataStateDescriptionFragmentProvider
  • ChannelStateDescriptionFragmentProvider

The naming isn’t exactly crystal clear for the two first, but I think GenericItemProvider belongs to “DSL”.

I also see that there’s a “ranking” applied, which probably determines what overrides what:

@Component(service = { StateDescriptionFragmentProvider.class,
        DefaultStateDescriptionFragmentProvider.class }, immediate = true, property = { "service.ranking:Integer=-2" })
public class DefaultStateDescriptionFragmentProvider implements StateDescriptionFragmentProvider {

@Component(immediate = true, property = { "service.ranking:Integer=-1" })
@NonNullByDefault
public class ChannelStateDescriptionProvider implements StateDescriptionFragmentProvider {

GenericItemProvider and MetadataStateDescriptionFragmentProvider don’t have a “ranking” applied, so if both of these exist, I don’t know who wins.

22

Right now without any additions to the code you’d delete the State Description metadata entirely. I’m not sure what would reset the link though. Maybe disable and re-enable the Thing would be sufficient.

23

Yes, I meant in this “revised solution”. I don’t think disabling/re-enabling the Thing would do anything, Metadata has its own registry, from where the data would have to be deleted.

24

Yes metadta has its own regsitry. That’s why I said “you’d delete the State Description metadata entirely.”

  1. delete the state description metadata from the Item
  2. take some action that causes the Channel to be relinked to the Item

It’s my understanding that the stateDescription pushed by the binding gets pushed at link time.

25

Ok, I misunderstood. I thought that you meant either delete OR restart, but you meant both.

I don’t think that’s how it works. I think that the StateDescriptionProviders are active/live all the time, and if they change what they provide, it will change the state description that applies. But, the “copying” of some of the state description fields to Metadata seem to occur at “link time”, so in that sense, it has some merit.

But, as you can see from the details I posted above, Metadata is just yet another provider, although one with a “high ranking” (probably zero since it’s not defined, and those that are defined are negative).

26

One “interesting” thing is where state description from YAML provided Items would come from. I’d guess GenericItemProvider perhaps, but that’s interesting, because that means that it’s probably “a tossup” which state description data would “win” if you specify one thing in the YAML and another in the UI metadata.

Maybe MetadataStateDescriptionFragmentProvider should be assigned ranking 1 so that it would always win, also over DSL or YAML provided state description? Or maybe you’re not allowed to define UI metadata for “read only” Items?

edit: “Maintaining” the metadata registry might be a challenge, so perhaps it’s not allowed to assign metadata to “read-only” Items for that reason. It’s “very hard” to know at which time one should delete those metadata, as the Items are “deleted and recreated” every time OH restarts or the source files change.

27

Unless something has changed the metadata isn’t deleted until a user manually deletes it. Metadata is not autocleaned. There are some use cases which would be broken if it were.

When an Item is loaded from a file what ever metadata is defined in that file will replace what happens to already be there.

There never used to be a limitation in adding metadata to read only file, but I don’t know if the UI still allows that. It works from rules though.

28

There are some inconsistencies/bugs here. I created a YAML Item:

version: 1
items:
  YAML_Network_Device_10xxxx200_Latency_YAML:
    type: Number
    dimension: Time
    label: YAML YAML Network Device (10.xx.xx.200) Latency
    format: '%d la %unit%'
    tags:
      - Duration
      - Status
    channel: network:pingdevice:printer_yaml:latency

It shows like this in MainUI:

bilde
bilde843×155 4.99 KB

(Note “Not Set”)

Yet, when I click the locked state description, I see this:

bilde
bilde845×687 11.1 KB

The pattern from the YAML is there, but this is read-only, I can’t edit it. Fair enough, except that I don’t understand why this is “not set”, and the fact that I still have “Save” in the navbar.

But, nothing prevents me from adding a “new” state description using “ADD METADATA” (did this use to be capitalized - it looks a bit “messy” IMO?). However, the “page” that comes up after “adding” is the same, non-editable one that is shown above, still possible to “save”, but still not editable.

So, it seems to me like you’re in fact not allowed to add state description metadata to read-only Items.

edit: For completeness, I also added a YAML Item without state description (pattern) defined in the YAML file. It doesn’t show the “locked” state description entry, and it does allow me to define state description from the UI (although the pattern I apply isn’t actually used, but that might be because I define an invalid pattern).

bilde
bilde852×861 18.1 KB

29

I only scanned through this discussion and may not see all the details yet. But one of the things that the upnpcontrol binding does is dynamically update state options and command options in the state description. If you start copying these to metadata at link time, it will break this behaviour.

30

Yes, that’s an example of what I was thinking of up above when I said that state description was basically “live”. So, I think that the “dynamic behavior” must be kept, but it shouldn’t be “hidden” in the UI, and the user should have a chance to override it - and to revert the override.

In my own production environment, I often override the options provided by the bindings, both because I just want the options that are relevant for us, and because some of them are provided with pretty “strange” (non-descriptive, wrong language) labels. But, doing this poses a problem if what the binding provides changes for some reason, because I can’t see what the new values are and what I need to do to apply “my twist” to the new options.

31

Seems there are some inconsistencies in the UI. Do you mind summarising them in an issue and pinging me there?

Reading through the discussion that has evolved here, my original proposal won’t cover many of the aspects mentioned here, for sample the above one. I think it’s quite difficult to achieve all mentioned aspects without „overcomplicating“ things for the user though.

32

I’m afraid I have already forgotten exactly what I meant there, but yeah, there was some inconsistency related to “read-only” as far as I can remember. There’s also the “issue” that format is often shown as a separate field, while in reality it’s the pattern of the state description - or something like that?

I think anybody can see this pretty quickly by doing some testing, I’ll have to get back to it if nobody else does so.

Yes, I agree that it quickly gets “complicated”. At the same time, I think it’s quite confusing the way it is, where you only see “part of the truth”. I was thinking of something along the line of having a small icon/button on each line where you could toggle “inherit” or not, where “inherit” was enabled by default. If “inherit” is on, the value would be shown in a “softer color” and not be editable. When turning “inherit” off, the field would become editable, and it could optionally copy the inherited value. That way, you could “enforce blank” by turning off “inherit” and leaving the field blank.

But, I never thought it fully through, the problem is among other what to do if the user clicks “inherit” and there’s already a value there. Should there be a warning that the value could be lost, or should maybe the “inherit” button be disabled until the field was empty - etc…

33

Some things are coming back to me… I think the problem was:

If you have a file-based Item (YAML or DSL), you can choose whether you define state description in the file or not. Whether or not you do, have consequences, because if you do define state description in the file, you’re not allowed to edit in the UI (naturally, the state description becomes “read-only”). State description is shown with a padlock in the UI, but crucially, this doesn’t prevent you from adding a new state description in the UI. However, when you try to add a new one, the “form” that you should fill in is in fact read-only and already populated with the file-defined state description. It still allows you to “save” this form that you can’t edit - although I don’t know if any saving actually takes place behind the scenes. During this process, no information is given that you can’t add state description because it already exists or similar, or why the “form” that shows up is read-only. You get no error when you “save” it either. All in all, it’s a bit short on information about what’s actually going on.

The other inconsistency is if you don’t define the state description in the file. In that case, the UI allows you to define them and edit them just as if it was a managed Item. But, the format field that is extracted from the state description that you can freely edit and shown on the “Item page” itself, is read-only (because the Item is read-only). So, you can’t edit it on the Item, but you can edit the same field if you open the state description - and the “read only” field that you can’t edit reflects that :wink:

I understand that some of these things can be hard to avoid, or at least, require some intricate logic, but I must say that I’m not sure the completely different “rules” for if you define state description in the file or not makes that much sense from a user’s POV. It’s enough that you define one of the state description values, and they are all locked in the UI.

The reason is probably that the “generic Item provider” and the “metadata provider” have the same “rank” as state description providers, so you can’t have both, as the system wouldn’t know which one to use. One way to solve that would be to bump metadata’s rank, so that it outranked the file definition. That would allow you to handle whatever fields you didn’t define in the file, from the UI. But, maybe that’s overkill - I don’t know. I just imagine that it’s not always very easy for a user to understand why this and that happens, when you must have very thorought understanding of the underlying data structures to be able to figure out “why”.

When on the topic, there’s one more thing: It was mentioned further up that metadata aren’t cleaned up automatically and that the user must do that manually. I’m just wondering exactly how a user is supposed to “clean up” metadata for an Item that doesn’t exist.

It should perhaps end up together with orphaned links or similar, in a list that the user could choose to delete - but after some delay..?

@florian-h05 It’s not so easy to create one or more issues here, because I’m not exactly sure where to draw the lines between “bug”, “feature” and “design”. There are clearly some things that don’t add up, but I’d say that some of those things are in the design itself, not necessarily a “UI bug”.

34

A rule, the REST API, or manually by editing the JSONDB file.

To do it from a JS rule I think you’d need to access and use the MetadataRegistry directly though instead of going through openhab-js.

That would be nice.

35

I think it’s safe to assume that very few users actually do this then. That said, the amount of metadata probably doesn’t usually amount to anything that actually matters for performance.