No, not the default unit is used for persistence but the unit that is returned by .getUnit. This has always been the case and prior to 3.4 was
- the unit derived from the state description
- the locale’s default unit from the
UnitProvider null(in this case the plain number with unit stripped was persisted)
Since 3.4 all dimensions (i.e. Length already had, Acceleration did not) have default units, so point 3 is no longer valid.
That means: as long as you have a state description set which defines the unit, nothing changes. If you did not have a state description defining the unit, you can easily add a state description and everything is like it was before. No need to fiddle around with the database. If you add the state description (with the original unit, e.g. mm/h) BEFORE the upgrade to 3.4 you also prevent wrong entries in the database.
My proposed change decouples state description and item unit. The unit defined in the defaultUnit metadata will take precedence and getUnit returns
- the unit defined in metadata
defaultUnit - the unit derived from the state description
- the locale’s default unit from the
UnitProvider
It’s debatable if step 2 should be removed. This all independent from the internal representation in the item. There is simply no need to normalize the values. In fact IMO the conversion from °C to °F should also be removed. I assume it was only to provide sensible units without setting a state description and maybe a better modeling would be to provide a state description with the locale-default if there is no user-defined state description.
For programmatic access there is always .toUnit(...) to get the value in the unit you want.