[UoM / persistence] Setting a typed item's value changes its unit

[jewesta]

There might be an issue with UoM I stumbled upon recently. I am not sure if it can be called a bug per se but it is at least inconvenient and may at worst break the integrity of an item's persisted values. IMO the behavior is also unexpected. So I wanted to file a bug for your consideration. Thank you very much in advance!

Let's say we have an item of QuantityType Power:

Number:Power PowerItem "Power [%d W]"

We initialize it in this way:

PowerItem.postUpdate(2000|W) // PowerItem changed from NULL to 2000 W

If we then update it in this way:

PowerItem.postUpdate(2|kW) // PowerItem changed from 2000 W to 2 kW

The unit changes. The unit in the item definition (W) is ignored.
Within rules this is not necessarily a problem: After all, 2000 W are 2 kW, and if UoM are applied everywhere strictly, nothing should happen. Having said this, it is IMO unexpected, that the visual representation of the item's value in the log changes.

More problematic (I think) are the repercussions this has on persistence. I set up a persistence based on MariaDB (mySQL) and logged the test item's values. When the item's value is set to 2000|W, the value in the DB ends up being 2000. When the value is set to 2|kW, the number 2 will be written to the DB. I think this is problematic. The reasoning behind using UoM is that the programmer doesn't have to worry about the unit of an item as long as the value set is qualified with the correct unit (of the same type). As things are now one careless postUpdate with the "wrong" unit can break the item's persistence.

The only solutions currently are not switching the unit or (probably - I have not tested this) using a proxy item.

[jewesta]

See also:
Discussion in the thread "I gave up on OH 2.3 Unit of Measure (UM)" over at the openHAB community.

[lolodomo]

This is a known problem and an issue certainly already exists.
Persistence is OH1 and does not handle UOM.

[lolodomo]

Very similar subject: eclipse-archived/smarthome#5675

[jewesta]

Thanky you for making me aware of the UoM discussion! I have to admit that I missed that when I was looking for duplicates. Sorry, fell in the OH vs. ESH trap... my bad. :-/

Having said this: The workaround proposed by you and @htreu isn't really working if the decimal point moves depending on whether I set the value as (e.g. in the case of power) 1 kW or 1000 W. IMO if I a define an item to be carrying "W" it should not change to "kW" if I set a value. This may be by design and maybe - or quite possibly - there is something I'm not seeing or knowing. I just think it is unexpected and kind of begs the question why there can be a (fixed) unit in the item definition in the first place.

[lolodomo]

Of course, our workaround was for a different case than the one you explain here. I just link your issue to the other issue because the source problem is the same, the persistence layer has no idea of the used unit.
Maybe an idea would be in your case (item change from a DSL rule) to first convert the new value to the default unit of the item, that is Watts in your case.

[cweitkamp]

he root cause for this issue is that persistence in general is not ready for UoM (see e.g. eclipse-archived/smarthome#5675 (comment)). The units were not persisted in legacy persistence add-ons in openhab1-addons. After migration of openhab/openhab-addons#5275 the situation has changed and we can enhance some persistence services.

Will be fixed once this feature has been implemented in all persistence add-ons (see #1954 for more information).