YAML string compare

props.item contains weather information.
Independent of the value
icon: ‘=(props.item == “Bedeckt”) ? “f7:cloud” : “f7:snow”’
results in “f7:snow”
( I checked that props.item is “Bedeckt” )
Where can I find a description of YAML and string comparison
Thank you

props.item is, presumably (although you haven’t shown any additional information to make this clear), the string representation of the name of the item, not the item’s state. Unless the name of the item is Bedeckt that ternary expression then will always return the negative result.

The basics of widgets expressions are here:

Note the first of the listed important objects is an items dictionary which allows you to use the name of the item to access it’s state. Better than that, at the bottom of that section you will see the shortcut operators that make using the items dictionary even easier.

The getting started tutorial also has several examples of how to use the item state in conditional statements in the sections on creating pages and widgets:

Hey Justin
Thank for your answer.
The item is a member of the wheater thing
Vorhergesagte Wetterlage (Lokales_Wetter_und_Wettervorhersage_ForecastHours03_Condition)

If using the UI it is for a beginner too difficult to transform the text definitions into the UI .
Perhaps you can give me a detailed hint how to compare the strings.
Thank you


icon: ‘=(props.item.state == “Bedeckt”) ? “f7:cloud” : “f7:snow”’

props.item is the item itself.
if you want to compare the state of the item use props.item.state

It is not too difficult, you just won’t find the answer by using intuition if you don’t have any experience with the system already. That’s why the getting started tutorials are critically important. The detailed hints you need are already in those pages. I cannot emphasize enough how much time and frustration you will save yourself if you just take the time now to go through the whole Getting Started tutorial; not just on this topic but all of it. OH is too complex to be 100% intuitive.

No. An Item is a complex java object which there is no access to in the widget expressions. When you select an item via the properties of a widget what you are getting is a string containing the item name only. Nothing else.

This will not work because a string does not have a state property. It will result in an undefined value which will always evaluate to false in the ternary statement and always produce the negative result.

As I said above, the only way to get the current state of an item in the widget expressions is through the items dictionary:



1 Like

But If I use props.item.state it is the same result.
Klaus-Dieter :biking_man::swimming_man:t3::sailboat::skier::tennis::blush:

Hey, why is it so difficult to give a exact hint how to do it ?
I was working many years in the „ windows world“ and there it was common sense to send a screenshot or the exact solution. Why not for OpenHAB ?
BLEIBT GESUND Klaus-Dieter :biking_man::swimming_man:t3::sailboat::skier::tennis::blush:

It is not difficult. But I prefer, when possible, to encourage users to get the basic information from the help files where they can get the complete information and develop a deeper more long-term understanding, and to discourage just copying answers without understanding. Getting users to understand the system they are working with saves many thousands of hours and hundreds of threads on these forums.

If I thought you were incapable of understanding what was going on, I would have provided a direct answer for you to use without thinking about it further. But, I am 100% sure you can grasp this information.

If I thought that you were working on a issue there was no reason to expect you to be able to find the answer to then I would have provided as in depth an answer as I could with full examples and screenshots. But, in this case it is quite reasonable to expect that you can come across this answer yourself in one of the links I have already pointed to (or many others besides).

If you had read my following post you would have seen why that was never going to work. Instead, it appears that you just blindly copied something without attempting to understand. Exactly what I was hoping to avoid to save you and the rest of us time and frustration. To be able to successfully work with many of the features of OH you must have a reasonable understanding of the difference between items and the item properties and methods.

It is common here too (and, in fact, I have already provided the detailed hint you have asked for). But you also cannot just expect members of this forum to give you every single answer when you do not give the appearance of putting in work on your end as well (such as reading the getting started tutorials, or carefully reading the posts in a thread).

If there are parts of my answers that you do not understand, then, please, point out those areas, ask specific questions about them (questions that demonstrate you have put some time into the help docs but cannot reconcile what you read there with what is presented here), and I will be happy to clarify as much as I can.

1 Like

Why don’t you use the developer side bar?
It will show you what the result is for the item.
Make sure the equal sign doesn’t have any spaces before it in the panel as it won’t work. I have been stung by that before and wondered why it wasn’t working.
Screenshot from 2024-02-13 11-54-04

The example above shows that the gate status is open so the f7:lock_open_fill icon will be used.

That’s an interesting bug I hadn’t encountered before. Have you filed an issue? That one should be easy enough to fix.

Does it do the same for you?
I just make sure I don’t have leading spaces.
I am running 4.1

I see now that it does. For me, when there’s a leading space the full string value of the expression box is returned. It’s actually worth a discussion on the repo, because this may or may not be the intended behavior. It makes perfect sense if the expression box was truly intended to replicate what the widget yaml values do (any string that does not explicitly start with an = is treated as a string literal). But I’m not sure that’s very valuable in the “expression tester” I don’t need a box that parrots a string literal.

Yes that is what I found. All it did was show what I was typing in the tester box. Not very useful.
I copied and pasted from a widget and wondered why it didn’t work. I thought it might have been because of the upgrade to OH4.1.

What ever I do expression tester gives result “-” , that means that my code seems to be correct.
item results in (wanted) weather information but title is “-”
item: =props.klima_item
title: =items[‘klima_item’].state

I do. But always xxx.state is “-”

Actually, no. Unless the item you are trying get the state of actually has a state of '-' (which seems unlikely), that means you are trying to access an item that doesn’t exist. You are using the wrong item name in your expression.


The expression tester does not have access to the same context as the widget editor. If you have selected test properties in the widget editor, those are not available in the tester. So if you have:

uid: demo
  parameterGroups: []
    - name: item
      label: Item
      type: TEXT
      context: item
      description: An item to control
tags: []
component: f7-card
  title: Selected Item
  content: =`Item name is ${props.item}`

Before you select an item it will show that props.item is undefined:

Then when you do set the props:

It now correctly shows that props.item is the name of the item you have selected

But, that props.item variable only exists in the context of that currently open widget editor. It does not extend to the widget expression tester:

This is the one weakness of the widget expression tester. You can’t use variables or properties in the widget tester, you have to put in the actual values you want to test.

You are still not using the items dictionary correctly. The variable props.klima_item contains the string of the item name you have selected as you see above. The item properties of the oh widgets only require the item name and all the other access to the various item properties and methods is done “under the hood”. That’s why that line works.

'klima_item' is just a string literal. Its only value is 'klima_item' and it will never be anything else. The items dictionary always returns '-' when you try to access an item that doesn’t exist and your expression is trying to access the item named 'klima_item' not the item named by the value is held in the variable props.klima_item.

If you create a ECMA script and put below in as an example but change testitem to the name of your item that is a string that you want to compare with:


Then run that script and look at the developer sidebar you will see the result. I believe this is the bit you are missing.
Screenshot from 2024-02-14 16-08-18

Basically what you have to do is put the data you want to compare into the item.

Hey Greg,
where did you find these functions ( getitem , postupdate )
Klaus-Dieter :biking_man::swimming_man:t3::sailboat::skier::tennis::blush:

Von KDBs iPad gesendet

Have read any of the documentation as it is all in there?

The documentation has examples as well…

It does take time to work it out. I am not an expert and have managed just enough coding to do what I need.

I use the UI only only so no file based anything and JavaScript only rules, no DSL.
You can write a lot of rules without needing to code anything.

Did you work out it?