Question to the design of UoM

Hi there,

I’ve noticed an odd behavior with units of measurement:
My setup contains several Number items with no UoM. Thanks to a bug in openhab-android (https://github.com/openhab/openhab-android/issues/1221#issuecomment-469022874, sending UoM even when no QuantityType is specified), I’ve seen how surprisingly openhab handles posted updates when UoM are involved.

Item:
Number target "Target Temperature [%.2f °C]"

When posting “22” to this item, the item contains “22”.
When posting “22 °C” to this item, the item contains “22 °C”.

However, my rules querying the state of a number item get Kelvins returned, thus misscalculating.
I had antipiciated that openhab just skips this “°C” part and my rules continue to work.

So, is this by design or is there a bug lurking somewhere here?

Best,
Sascha

Indeed. It’s debatable whether Number should act like Number:JustANumber or Number:AnyUnitYouLike

There doesn’t seem to be a way to force “numeric only” just now.

Number:Dimensionless?

Nah, that fooled me too. “Dimensionless” means the Number is a proportion or fraction, like %, dB, or ratio.

Who says so? There is no reference in JSR-363 that dimensionless refers to proportions only. IMO it is valid to use it for counts or something like that. It is just a number that has no dimension.

He doesn’t want a dimensionless value though. He wants a number with unit which he can treat like a number without unit, that is, as a numeric value as opposed to string.

That wish totally makes sense to me, but IMHO the problem with it is that there’s no way to specify a ‘default’ unit, which set states could be converted to.

I’ll happily take your word for that. But in openHAB implementation, Number:Dimensionless can have a “units” symbol like %, ppm or dB, which still lands us back at the original observation.

At least for % and ppm that is ok. 1% is just another representation of 0.01 (similar 1 ppm 0.000001).

Yes I know it works. The OP’s point is that you can post say “10 %” to a plain number by accident, in this case due buggy UI widget, and when you read your expected number back - get the value 0.1 not the 10 you started with.

Deliberate design, unfortunate consequence, bug?

I fully understand his point - “Look, I just designated a Number - no units, no dimensions - but because I chose to display it with some text “°C”, my number 20 has become 293. I didn’t order that.”

That‘s two different things. I agree that entering 20 C and getting 293 is confusing.

But nobody would call it confusing if you enter 1km and get 1000m. The same holds true for 1% and 0.01.

If one wants to be 100% correct, from the docs it looks like one can easily convert between units in the rule. Just check whether the item is of QuantityType and always convert to the desired/expected unit…or even compare with unit.

I guarantee I am not the only one thinking “I just want a bluddy Number with no UoM allowed” :smiley: