That is a little tricky. The oh-label-item is made of of several different pieces, and the only way to change the styles on the item state label part is to access it directly with css. You do this using a special property tag stylesheet and putting a full css declaration in that (this is similar to, but not the same as the style property, and you can use both in one component)… To change the text color that would look like this:
I know CSS declarations in dealing with HTML files. Some.css data had to be created and made available in specific directories.
But how does that work under Openhab 3, how is one structured and where is it stored?
When you’re working with the widgets, you don’t have to worry at all about separate css files. You can just use the stylesheet property demonstrated above and the css will be applied at that level of the page/widget (i.e., the new declarations will be applied to the widget and any of its direct descendants). Many of the page types can also take advantage of this stylesheets property as well so you can customize the look of an entire page easily if that is your desire.
The way to make this work is actually a two part process. The problem is that the stylesheet property does not get processed by the expression parser that allows for things like the x == y ? if true : if false ternary expressions. So the stylesheet property is just going to be a static string no matter what. The properties under the style heading, on the other hand, do get processed by the expression parser so we can make those dynamic, but we can’t use those to access the label text for formatting. The solution is to combine the two using css variables. We can set a variable in the style property to a dynamic expression and then reference just the static name of the variable in the stylesheet.
But that is very complicated and without their help I would never have gotten it off the ground on my own.
Once again I am very impressed and once again I say: thank you very much
Unfortunately it doesn’t work yet. But now I also don’t know the value of the item when an update is due. Maybe I should wait with a test until the time comes…
I have now installed an older firmware and the item value is set to “update”.
Instead, the color is generally white and does not change.
I can’t find an error, where could the problem lie?
That means that we know the expression is being evaluated properly, but your item state just never equals “updaten”. This is most often an issue of the difference between an item state and its displayState. Every item has a state: the technical value that the item currently represents. Often times, that value is not well formatted for visualization or a UI so items can also have rules for formatting their state in a different way. When working with the widgets, the items object allows access to both. items["some_item"].state gives you the actual state and if there is a state formatting rule, items["some_item"].displayState returns that formatted value instead.
In your widget you’ve put props.item1 in an oh-label-item and that by default displays the dispalyState if there is one for the item. So, “updaten” is probably the formatted value of the state (or displayState) and not the actual value of the state. You can either look in your logs to see what the actual value the state is taking is, or just quickly change one of the text fields (for example, title) to items[props.item1].state just see what value is really being passed there.
Yes, that’s my fault. If the Item.state OFF/ON is used, everything works as intended. The values “aktuell” and “updaten” are the display status.
In the course of the evening I will reproduce the complete code here again so that other users can also deal with it.
Sorry, but another problem has arisen. I have now created several shutters, all based on the same scheme. Although different items are addressed, popovers always show me the same values. My guess is that the popover is hidden but not closed. What changes need to be made in the code?
I mentioned up above that if you have more than one such popup or popover on the same page with the same identifications things will get confused. What’s going on here is that all of the widgets exist on the same page so there are multiple elements with the class info-pop so each widget is just sending a command to open info-pop opening the first one, which is always the same.
The solution here is to find a way to ensure that the name of the popover class is always unique to that widget. Fortunately you already have something that is a string that is unique to that widget and compatible with the requirements for css class names: props.item1. So, all you have to do is to use an expression to build up the class name for the widget:
