The functioning of Units of Measurement in openHAB is very complicated, itās no use getting cross at it or demanding it never changes. Iāve no doubt that something has changed, because there were issues here and there. I couldnāt say if what you see now is intended or anomalous behaviour until we pin it down more closely.
Stuff that comes into play here;
Some Quantity types have system default units; like Temperature. Some do not have a system default unit, like Energy (used e.g. for kWh).
What that affects is how updates work (and persistence, but weāre not concerned with that here).
If you update a type-with-default with just-a-number, it will assume the default unit.
If you update a type-with-no-default with just-a-number, it will probably fail.
Dimensionless types (usually used for %) are a weird exception here - just-a-number is treated as a ratio, and accepted. Updating with 20 is assumed as meaning 20-to-1 i.e. equivalent to 2000%.
In any case, you can assign a default unit to any individual Item using that Itemās state description metadata. This will either override the system default for that Item, or give it a default if it hasnāt got one.
Itās a bit of a kludge that the same unit metadata is used for display purposes and for the different function of designating a default, but thatās the way it works for now, inherited from OH2.
Why care about default units? Some bindings (like KNX) only update with numbers - they donāt know what unit any incoming value is expressed in. Thatās okay, we can assume one from the default.
MQTT binding used to be in the same category - only making number-only updates. The channel āunitā parameter was ignored for incoming data.
So far as I know, this has recently been changed and the given āunitā will now be appended to incoming data and used to update the Item.
When an Item does have a default, updates expressed in other (valid) units will be auto-converted to the default. Say you update with 32F but your system default is C, you will end with 0C actually held n the Item state.
So thereās a bunch of things that can affect what ends up in your Item state.
Separately from that, what gets displayed? In general you get what you ask for, i.e. you see what you have specified in the Item metadata.
But of course Quantity types are more complicated.
Some specialist bindings, like Weather, know exactly what units incoming data is expressed in. So they can āsuggestā a suitable default for your Item. When you link to that channel, it effectively sets the Item default unit by forcing metadata e.g. km/h for windspeed.
(This is one of the woolly areas of UoM - what happens if that āsuggestionā clashes with something else, like the userās display choice?)
Some generic bindings, like Modbus or MQTT, can have no knowledge of what is incoming. So they cannot āsuggestā Item configuration. Itās up to the user to configure their Item.
You are looking at some combination of these effects. Follow the chain of your problem from end-to-end to see what is not doing what you expected. A good halfway point is to find out what is loaded into the Item state, from log or REST API.
