As I don’t wanna mess up this thread anymore, I created a seperate topic for this question:
You missed the quotes at the ON/OFF string in your expression - the above code should work in a oh-label-card like this (as said, it only works for the content part of the widget and not for the title and footer)
The other question that may also link with this is text-alignment.
Can this be achieved using the standard widgets?
Generally no - the standard widgets uses pre-defined styles so that other styles gets overwritten.
What exactly do you want to achieve?
Assuming you want to align your text left or right inside the widget - you could recreate your above shown variant of the ‘oh-label-card’ like this and changing the style attribute inside the ‘text’ slot to your liking:
uid: labelCard-clone
component: f7-card
config:
title: Presence
style:
background: "=(items.Presence.state === 'ON') ? '#4cd964' : '#ff3b30'"
overflow: hidden
slots:
default:
- component: f7-card-content
slots:
default:
- component: f7-list
config:
class:
- padding-top
- padding-bottom
slots:
default:
- component: f7-list-item
config:
noChevron: true
slots:
media:
- component: oh-icon
config:
icon: presence
style:
width: 32px
text:
- component: Label
config:
text: =items.Presence.state
style:
font-size: 24px
font-weight: normal
width: 100%
text-align: left
@RGroll thanks very much for the example - that is great! 
I guess I’m just trying to understand the extent of customization that can be done to a default widget.
Not sure if you’d be able to point me in the direction of some documentation, from my understanding for OH3 the F7 framework has been adopted. Would be beneficial to understand the framework itself and how the YAML files are structured for use within OH.
Thanks as always!
No problem. I’m happy to help.
There is a huge potential for customization, yes. As you already recognized, the MainUI uses mostly F7 components which allows to create a lot of fancy stuff. (for example: Keypad widget, Sonos widget, Multiroom Audio Player widget, Aircon controller, Camera widget, Weather widget to only name some of them - you can find most of them in the UI category of this forum)
Assuming that you’ve already read the documentation threads (1, 2 and 3) a usefull next step would be digging into the f7-documentation itself, which you can find here and here - on a detailed component level.
It would also be usefull to look into the above mentioned widgets and try to understand what was done there and maybe adapting them to your liking to get comfortable with the YAML-syntax of the widgets.
Last but not least, It helps keeping an eye on the openhab-webui github repo and try to keep yourself updated with the latest changes and the examples that comes with the commits. @ysc for example is doing a great job providing examples to nearly everything he implements into the MainUI.
Hope this helps a bit.
P.S. Here you can find the standard widget-components (in raw vue-markup) that are currently implemented into the UI. This might also help to see what components were used.
@RGroll You are a legend - thank you for detailed response!
Gives me more than enough bedtime reading material 
Hi Rainer,
I came here because I didn’t want to mess up the other thread. My problem however is quite similar.
Formerly I had defined the color with:
color: '=(items.AqaraMQ_THPS2_TEMP.state < 0.0) ? "white" : null'
which worked as inteded.
Now I have added the Item to the semantic model making it a Number:Temperature Item with the semantic property Measurement->Temperature.
Suddenly, the state gives me the Temperature including units, which is also shown in the widget snippet test in the sidebar:
Here my THPS2 with the settings as described above
I have played around with the metadata of my other sensor and when I set the State description to %.2f °C it looks like this:
{ "state": "1.47 °C", "displayState": "1.47" }
No I’m super confused as I expected it to be the other way round - can you help me?
Thank you so much!
Hmm, strange…
I’d think that it should affect both tbh - the UoM (e.g. Number:Temperature) influences both states (the raw and display-state) and adds the respective scheme and value symbol (at least, if no stateDescription is given) - so this part is correct. But if you additionally set ‘%.2f °C’ as the state description, it should change the displayState to your desired value & symbol. At least, this is how it works in my setup and how I understand this article in the docs.
This is how the states behave in the different scenarios for me:
| Item | .state | .displayState |
|---|---|---|
| UoM_without_state_description | 1.55 °C | 1,6 °C |
| UoM_with_state_description [%.2f °C] | 1.55 °C | 1,55 °C |
| Number_without_state_description | 1.55 | 1,6 |
| Number_with_state_description [%.2f °C] | 1.55 | 1,55 °C |
I don’t work with the semantic model that much tbh and only uses textual configuration (and try to avoid QuantityTypes in the most cases as it makes it hard to using Math functions) - so don’t count too much on my words.
Maybe someone else has an idea what’s going on in your case?!
Dear Rainer,
thank you so much for your detailed answer. After remeoving the state description I now only get
{ "state": "2.57 °C" }
which should be correct as I understand. Now the only big question for me is: How do I now run comparisons in the widget code?
I have tried (result shoud be true):
=items.AqaraMQ_THPS3_TEMP.state < 10 (false)
=items.AqaraMQ_THPS3_TEMP.state < 10 |°C (false)
=items.AqaraMQ_THPS3_TEMP.state < "10 °C" (false, of course)
=Number(items.AqaraMQ_THPS3_TEMP.state) gives NaN
At least a Method called Number seems to exist - maybe there’s a method for conversion?
Thank you so much,
Bob
These should normaly work, I think (and it does in my case). As the javascript comparison also can work with strings afaik (source: javascript.info)
What happens if you try to set %.2f as the state description (without the unit) and try this:
=items.AqaraMQ_THPS3_TEMP.displayState < 10
=items.AqaraMQ_THPS3_TEMP.displayState < 10
that works after setting the state description to %.2f without unit. But that should not be how it is intended, right?
=items.AqaraMQ_THPS3_TEMP.state < 10
=items.AqaraMQ_THPS3_TEMP.state < "10 °C"
don’t work for me 
I don’t know what is the ‘intended’ behaviour tbh. At least it’s somewhat strange, that the behaviour seems to differ from my setup to yours. Personally I would say, that everything that works is fine. 
But we could try to find the reason for the differences in our setups. I’m on build 2103 and using only textual configuration for my things and items. This is how my config looks for this test-item (I used some temp item from the OWM-binding for testing)
Number:Temperature Informations_uom_number "UoM Temp" <Temperature> (Wetterinformationen) ["Point"] { channel="openweathermap:weather-and-forecast:api:WeatherID:forecastHours03#min-temperature" }
which looks like this in the UI:
As said above, this is what I get, when I execute the following expression in the dev-tools =items.Informations_uom_number:
{ "state": "2.31 °C", "displayState": "2,3 °C" }
If I try to compare the state value like this then, I get the expected true/false informations =items.Informations_uom_number.state < "3" (true)
=items.Informations_uom_number.state > "3" (false)
Do you see any differences in the settings, which could lead to the seen behaviour?
Thanks for your feedback!
Hi and thanks for your feedback!
I have set my item in the Ui and the rest gets following result:
{
"link": "http://myip:8080/rest/items/AqaraMQ_THPS3_TEMP",
"state": "3.24 °C",
"stateDescription": {
"step": 1,
"pattern": "%s °C",
"readOnly": true,
"options": []
},
"editable": true,
"type": "Number:Temperature",
"name": "AqaraMQ_THPS3_TEMP",
"label": "Aussen THPS3 Temperature",
"category": "temperature",
"tags": [
"Measurement",
"Temperature"
],
"groupNames": [
"THPS3"
]
}
It’s interesting that there is a state description meta data even though I deleted it from the Ui. Also, it is not the one I set earlier so I guess it is automatically added somehow? Could you check what getting your item in the REST results in?
The string comparison indeed works, but it is very cumbersome as I can compare ‘3.00 °C’ < ‘9.99 °C’ but as soon as the number of digits change it won’t work as it is only comparing character wise.
Is there a math method usable in the yaml code?
Yeah, I think it’s the default which it uses if you assign the Temperature type - even if I don’t realy understand why it uses the °C as the default in your case and not the %unit% then…
{
"link": "http://192.168.1.31:8080/rest/items/Informations_uom_number",
"state": "2.41 °C",
"stateDescription": {
"pattern": "%.1f %unit%",
"readOnly": true,
"options": []
},
"editable": false,
"type": "Number:Temperature",
"name": "Informations_uom_number",
"label": "UoM Temp",
"category": "Temperature",
"tags": [
"Point"
],
"groupNames": [
"Wetterinformationen"
]
}
You are right - good find with the digits.
You generally can use Math methods in YAML for example =Math.round(items.XY.state) works - sadly it won’t work here as it takes the value into account which messes up the calculation obviously.
This is the reason for me, I mostly renounce from using types or at least defining a separate stateDescription without the value symbol for calculations like %.0f - so that =Math.round(items.XY.displayState) would work.
I have tried with some Math expressions like Math.unit.parse(items.XY.state) and trying to get the value but I always get “undefined” as result.
Changing the state description will also change the display of items on label cards.
Maybe @ysc can help here? Sorry for pinging you Yannick - I hope it’s OK…
Can you give us an example of a Number:Temperature item comparison in the widget YAML?
Thank you so much!
The widespread technique to deal with these units is to strip everything after the first space before parsing into a float:
=Number.parseFloat(items.AqaraMQ_THPS3_TEMP.state.split(' ')[0])
I plan to add some utils functions in the expression scope to deal with this and other cases.
That’s it! Thank you so so much! I spent a lot of time but to split the string didn’t cross my mind! It’s working perfectly!
Still not done, but eventually they’ll be documented at Building Pages - Components & Widgets | openHAB, I suppose!