[OH3] Add metadata to Items via configuration files

Tutorials & Examples Solutions
21

I’m afraid it’s not possible. While metadata config values may be objects with nested properties, the grammar used to parse .items files doesn’t support it.

For those cases you would have to use the UI.
(the metadata is decoupled from the item itself so you can have the item in a file and the metadata for a certain namespace in the JSONDB as long as it’s not conflicting).
For this UI widgets-related metadata it’s not that far fetched to want to use the UI since you’ll get a live WYSIWYG preview.

2 Likes
22

In OH2 for my items with more complex but static metadata I used a Jython script, it’s a method @openhab-5iver showed me. The script doesn’t contain any rules, just the calls to set_metadata (from the Helper Libraries). So when the file gets loaded it applies the metadata immediately, that means it happens at startup, but also any time you edit the file it gets reloaded too.

@Kaspars_Rocans you should be able use this method to get your nested structure using nested Python dicts inside the dict passed to set_metadata as the configuration parameter. I have not looked at the data in the JSONDB or used it outside Python, but I’m pretty sure the configuration parameter gets passed directly into openHAB and a Python dict turns into a Java Map and that’s what the metadata configuration is on the Java side.

23

Thanks for explanation! Possibility to configure metadata separately is better than nothing but anyway it’s “configuring one thing in two places” and that is bad thing in general. :frowning: Same about other workarounds like set_metadata scripts.

So here comes next question - are there any plans to extend .items format/parser, may be introduce some new possibility to configure items in YAML or something like that?

24

Hi folks,
how i can find out the syntax to populate the “read only” property of an item within the *.items conf-file? Options are working fine…
Thx, Sascha

25

Hi @shaselb, Hi Search User,

Summary

stateDescription=""[pattern="%d%%",min="0",max="100", readOnly=true]

I was looking for the same question because it is case sensive and I did not know that.

So the following stateDescription has to be configured for your item:
stateDescription=""[pattern="%d%%",min="0",max="100", readOnly=true]

Kind Regards

26

hi all!
is it somehow possible to use a range value in options? for example:

<980=stormy
980-1000=rainy

and so forth?

thanks

27

Probably not. Are you aware of the Scale Transformation Service?

1 Like
28

thx, that did the trick :slight_smile:

29

Thanks!

UPDATED: However… it does not work on openHAB 3.0.2. The language parser chokes on this format of stateDescription metadata. Maybe it’s the empty double quote portion that is the culprit, as also mentioned in:

More precisely:

The trick is, to add the pattern as metadata in the textual definition. E.g. , stateDescription=" "[ pattern="%1$tR" ] (Make sure you have a space or some other text in stateDescription=" " / Empty does not work)

(The example successfully assigns and properly configures the custom temperature_list widget for list items, but skips the offending stateDescription metadata definition block.)

It however works when adding a single space between the pair of double quotes.

Bug report:

1 Like
30

Impossibility to set the “actionAnalyzerItems” in items file.

Let me highlight another limitation of items files concerning setting metadata for widgets.

I noticed that the oh-label-list widget does not offer the possibility to “analyze” the time behavior of the item, differently than the oh-label-card. This behavior can be modified by editing with the UI the metadata “Default List Widget”, in particular by filling the fields action with the value “analyzer” and the field actionAnalyzerItems with the name of the item (Question: why doesn’t it default to the item to which this widget is applied?).
The YAML is as follows

value: ""
config:
  action: analyzer
  actionAnalyzerItems:
    - Pres_Anna

With this manual modification of the configuration the widget expose the analyze button and everything works as I wish.
As I am wishing to apply this modification to a number of items, I am trying to set a metadata in the **items file **, following the informations in the OP, as follows

Switch Pres_Silvana    "Pres Silvana [%s]"   <presence>  (gEquip_PresPD) ["Status","Presence"] {channel="xxx",
         listWidget="oh-label-list"[action="analyzer",actionAnalyzerItems="Pres_Silvana" ]
         }

but this item does not appear in the list of items under the equipment. If I remove the metadata it obviously reappears. The item is, in both cases visible from the settings pages (both in the model and the items pages) and it also shows that metadata are modified. Probably it is discarded, because the metadata are not correct. In fact, by looking closely to the code section in the UI, in order to inspect the YAML, it is as follows:

value: ""
config:
  action: analyzer
  actionAnalyzerItems: Pres_Silvana

The line actionAnalyzerItems does not look the same as the one set manually. The same YAML appears also if I import from the UI with the option “import from .items file”.

When importing from the UI the YAML can be modified by inserting the missing newline, dash and indentation in order to make it look like the previous one. With this modification the item re-appears in the list under the equipment in the UI.

31

Workaround for the previous post limitation.

By using a custom list widget, slight modification of @rlkoshak example custom list widget for presence, setting the actionAnalyzerItems field is not required any more.

uid: listWidget-presence
tags:
  - list
  - presence
props:
  parameters:
    - description: The label for the widget
      label: Person
      name: title
      required: false
      type: TEXT
    - context: item
      description: The presence switch Item
      label: Item
      name: item
      required: false
      type: TEXT
  parameterGroups: []
timestamp: Aug 17, 2021, 10:37:02 PM
component: oh-list-item
config:
  icon: f7:person_circle
  iconColor: '=(items[props.item].state == "ON") ? "green" : "red"'
  color: '=(items[props.item].state == "ON") ? "yellow" : "gray"'
  title: =props.title
  item: =props.item
  badgeColor: '=(items[props.item].state === "ON") ? "green" : "red"'
  badge: '=(items[props.item].state === "ON") ? "IN CASA" : "FUORI"'
  action: analyzer
  actionAnalyzerItems: =[props.item]

The last line is tricky. I was naively trying

  actionAnalyzerItems: 
  -  =props.item

but it didn’t work. I found in another rlkosk example that the right syntax was the one that i showed in the working yaml.

Once this widget is saved under the developer tools , a simple items definition such as

Switch Pres_Silvana    "Pres Silvana [%s]"   <presence>  (gEquip_PresPD) ["Status","Presence"] {channel="xxx",
         listWidget="widget:listWidget-presence"[title="Silvana" ]
         }

allows me to define the widget in the items file

32

Dunno why it does not work for you but for me it does (without defining a widget).
Probably item: is required.

- component: oh-label-card
     config:
     item: PVNetzeinspeisung
     title: bla
     action: analyzer
     actionAnalyzerItems:
       - PVNetzeinspeisung
33

Thank you for reading my post and giving me the opportunity to clarify it.
The point of my post is the fact that the YAML line concerning the actionAnalyzerItems field is not correctly generated when the metadata is specified in items writen in items file. The value (i.e. the item name) is on the same line and not preceded by a new line, dash and indentation.

When using a custom widget, the parameters that need to be specified in the widget metadata are correctly generated when imported by items file, because values are in the same line as the the key.

The other problem I found with the custom widget always concerned the actionAnalyzerItems but this time it was in the YAML itself.
Using the inline syntax

actionAnalyzerItems: =[props.item]

The time history of the item is shown, while when using

actionAnalyzerItems:
  - =[props.item]

the popup window showing the time history is opened but empty. This also applies if I remove the square bracket. On the other hand, if I replace =[props.item] with an actual item name (as in your case) the the analyzer window do show the time history of the item. Clearly this makes the custom widget useless because it cannot be customized.

I hope that this is clearer now. I am not a programmer nor a native english speaker, so probably my previous posts were not sufficiently clear. I modified them in order to try to state the problem more clearly

34

I think you have a misunderstanding here:
The point is that actionAnalyzerItems is a UI property but it is NOT item metadata so you cannot specify it via .items.

It’s confusing that specifiying fields that way seems to work generically (i.e. even for properties that do not exist), but note that the fact that it works for non-metadata, too, is strictly speaking a bug.
It’s however always assuming the standard property: value format. But actionAnalyzerItems is a list and therefore requires a different format.

35

Actually, based on the fact that this property is set in the UI when I edit the item metadata and it is stored in org.openhab.core.items.Metadata.json I concluded that it was an item metadata.

Anyway, thank you for your comment: may I conclude that the workaround that I have found may not work in newer versions of openHAB when bugs will be removed? Maybe @rlkoshak can give some comment on this point.

Thank you

36

I might be mistaken there, too. I think only @ysc can tell.

37

The “Default X Widget” definitions are in fact stored in Item metadata.

I can but you will probably not like it. In an effort to better use my time helping less experienced/less technical users I’ve pulled back from providing help with text based configs. I’ll still help with basic stuff and stuff that can’t be done through the UI but particularly Things and MainUI Widgets/Pages I’m just not going to mess with. It’s a huge time sink.

Having said that…

Alternative approaches that will let you more easily apply the same modifications to multiple Items with minimal effort while still using the UI include:

  • Create a Custom widget with all the settings. Then you just need to apply the custom widget to your Items. That’s pretty much the whole point of the tutorial you linked to with the custom list widgets. I define a widget for, say temperature Items. Then I apply that custom widget to each temperature Item. If I decide later I want to change the way my temperature Items to look I can change the one Custom Widget and it changes all the Items that use it.

  • Use the REST API. Create and test the metadata once using the UI in the usual manner. Then use the REST API to query for the metadata and copy/paste/edit/resubmit to apply it to additional Items.

  • Stop openHAB and manually copy/paste/edit the metadata.json file. This approach is not recommended except as a last resort.

Beyond that all I can really offer is that defining the metadata on the Items in .items files should be possible. There really is nothing special about the default list widget metadata from expire or Alexa metadata. It follows the same rules and formats and it processed by the same block of code I believe. So if it’s not working there is likely a typo somewhere in the Item’s definition.

1 Like
38

Thank you for your post: I deeply appreciate your efforts for letting non-experienced user to take advantage of openHAB.
Actually, I mentioned you because I was only wishing to understand the question of what is stored in metadata and about the small widget issue that I found.

It was not my intention to ask for help on textual configuration, but simply to let other know about its limitations.
I fully understand your point and, while porting my OH2.5 to OH3.1 with text files, I’m practicing with adding new things and items with the MainUI, keeping track of the YAML code in text files.

The other observation that I described was about a widget YAML, but I will open a separate thread because it is only marginally related to writing metada via configuration text files.

39

A post was split to a new topic: Textual widget definition

40

Adding metadata to Items configuration files, enables the usage of displayState property, right?

Is there any documentation regarding the stateDescription field, for each of the item types?