FYI: I started work on a tool that upgrades UI defined items (and probably other things related to breaking changes): Initial contribution of an upgrade-tool by J-N-K · Pull Request #3268 · openhab/openhab-core · GitHub
This still makes removing state description from the unit determination logic breaking, but it allows the user to easily fix it by copying the state description pattern (if present) to the new metadata.
I just came across another issue if we internally normalize the item states: %unit% would always display the system unit (or default unit), not the unit from the command/update. If a binding selects the unit based on the value (e.g. distance of your car from home can be 600m or 435 km) this works automatically now, but not if we store a normalized state.
What does it show now if I post an update in °F to a temperature item in °C?
I still think this is okay and consistent.
If desired the graphical representation can be auto scaled to be 600 m instead of 0.6 km but of course this would be a new feature. Upside would be this would then work for every item state regardless of the binding.
°C because a change in unit system is the only place where “normalization” occurs. It admit that this is inconsistent.
Why do I need to add the unit in the offset?
Like this
[profile="offset", offset="0 ppm"]
if I do it without the unit I get a warning
[WARN ] [nternal.profiles.SystemOffsetProfile] - Received a QuantityType state '22.35 °C' with unit, but the offset is defined as a plain number without unit (0), please consider adding a unit to the profile offset.
Mind the forum rules and open your own threads, please.
#3