So I planned to migrate to 3.4 from 3.1 today, when I found this thread.
Unfortunately, the more I read, the more unsure I became on what actual implications I could run into.
I have almost all my items like this
Number Smart_Fan_Temp "Fläkt temperatur [%d °C]" <temperature> (GF_Office)
So not the Number:xxxx format.
I do have years of persistence that I do not want to lose.
So does this mean that I cannot upgrade (without messing up historical data?) to 3.4?
Yes, that’s “known” for sure. In those cases you can either stick with the original UoM at the item and use the “presentation transformation”. or you can change the values in the persistence manually for historic items. (don’t know, if that’s possible with rrd4j persistence, though).
But I don’t think persistence issues are to be solved within UoM definitions.
the breaking change applies to configured itemTypes like Number:Temperature and the like. “Number” or “Number:Dimensionless” should be exempt from this. so you should be safe while upgrading.
But of course the standard recommendation applies:
backup
backup
backup
then allow the update. and backup your persistence also - just to be safe
You can always keep the old item and just create a new one with Wh and link both to the same channel.
So you’ll have your old persistence working as before.
In general I assume that you gave the item unit some thought so imho this is a non-issue, especially since you can always change the view representation without implications for the item.
If you need the value in a different unit you can always just create a new item with a different defined unit and use the follow profile
This thread is a discussion how the implementation should be, not how it currently is!
Please be aware of that.
(re auto-conversion of arbitrary update to Item’s default unit)
Yes, I thought it worked that way too.
But @mstormi demonstrates the opposite, retaining the updates unit.
We’d better understand this.
@mstormi worked with Number:Length, you worked with Number:Temperature.
I suspect the difference might be that temp has a locale-dependent “default”. Maybe the functional difference is that locale-default is somehow different from generic/base-default.
Would you repeat you test with a Number:Length @Spaceman_Spiff ?
Last time I tried UoM it broke all my DSL rules. For some weird reason I would have to change all Item.state expressions to something else. Would I have to do this if I upgrade ?
“It depends” - upgrade what?
If you change openHAB version, it does not change how your Items are handled.
If, unrelated to OH version, you choose to change your Items from Number types to Number:xxxx quantity types, then you would probably need to change the way your rules handle them.
Nope, You cannot make a future recommendation here without reference to how it works today. Because a wide-ranging breaking change will not be permitted (and rightly so). “But I’m not suggesting a breaking change!” - how can you tell if you don’t know how it works today.
Quite apart from if it is a bug - or perhaps a design flaw - we should be finding it.
The internally used data type BigDecimal has a very big range and precision, but the more important point is that occasions where rounding errors can happen are rare. With persistence they can only happen when a rounded value is restored. That only happens on OH restarts and is only of relevance if you continue working with that value across multiple cycles without ‘fresh’ input from a sensor (very improbable you do).
That’s sorta FUD argumentation.
I don’t see a reason to assume that. If the value is nm, charts will display them in nm not in the base unit (you need to tell charting the scale including the unit to use, but that you should know about from your use case).
Not at all I’d think? You can update a item that has a current C value with a F value or have any binding do it automatically. You need to attach the unit, of course. If you don’t, it’ll use C (the just introduced default), but you can explicitly attach F then it’ll use F (and converts it to the base unit, C).
To choose if to represent the value in UI in C or F, use the display pattern, no matter if the current value is C or F.
Not at all, it’s doing right what I expect it to. Which is how users would expect it to work, too.
Beware that C/F is sort of a special case as the locale setting will affect this.
Dunno if US locale will use miles per default, but it works likewise:
openhab> openhab:send mtest 1km
Command has been sent successfully.
openhab> openhab:status mtest
1 km
openhab> openhab:send mtest 0.6mi
Command has been sent successfully.
openhab> openhab:status mtest
965.6064 m
openhab> openhab:send mtest 0.7mi
Command has been sent successfully.
openhab> openhab:status mtest
1126.5408 m
The default conversion the framework will use is locale-based:
The framework tries to convert a QuantityType to the default unit of the
configured locale.
...
The metric system with SI units is used for the rest of the world.
That docs quote is older than the recent change. And it’s just docs, not the spec, so it can be wrong without that the implementation is buggy.
At least it leaves room to interpretation.
It’s not the same kind of “default unit” what these docs and what we are talking about.
km and m have the same default unit, m that is - the k in km is just a scale prefix.
The “default unit of the configured locale” is something else, like C vs F or km vs mi.
I’d expect an item with a m value to display in miles or feet or whatever that default is if I switched to US locale.
For persistence - don’t care.
EDIT as this seems miscontrued. For persistence data - don’t care what form the openHAB internal data is in, it is how the database stores it (which will not be BigDecimal)
How the service stores its data is the part that counts.
You understand that people do retrieve stored data for other purposes, usage calculations etc.
Okay. I think I’m a bit confused about your proposal.
Is it -
All database storage will be in some pre-designated normalized unit for each type.
e.g. a Length will always be stored in m (nanometres and light-years will be converted)
Upon retrieval, the value will be converted to whatever this Item’s default is. (Hard luck with rounding errors from double conversion and scale limitations)
Woahh that’s really screwy. If you post 1mm or 10km to a default Length you get 1mm or 10km - unit preserved If you post 0.6mile to the same Item you get 985m - unit converted.
I would not call that expected behaviour.
Is this where it gets complicated and for default purposes we do not consider k, u etc, suffixes - km and mm are all “m default”? Hows that work with feet and inches?
sending unitless values => that value with the active UoM
sending same unit values => that value with the active UoM
sending different unit values => value gets converted before reaching the item and is stored with the active UoM
dimensionless item
sending unitless values => that value
sending unit values => unit will be discarded, only value will be stored at item
What I do not expect: sending an unit different vom active UoM at the item: the item suddenly changes it’s active UoM.
So, the above example von Markus should qualify as a bug to me as the Number:Length item assumes a dimension from updating its value - I don’t want that.
I care!
And I think most users will. Because default persistence is rrd4j. That will work horrendously with nm stored in m. even storing mm (rain/snow precipitation standard) will not work out very well with m.
The active UoM should be stored - as it is already. (and the UoM must not change by sending another unit!)
I think the crucial point is that with a a UoM of “meters” one would expect that commands with a different scaling (“kilometeres”) is scaled appropriate.
Instead the scaling on the item changes which is very confusing.
This will also result in jumping values in the persistence service, e.g.
if a distance counter with a value of 999m increases and now is 1km.
Persistence:
So the ‘default unit’ we have introduced in turn depends on locale, but just in some cases.
Boy are we liberal. Knowing that “the” original length and temp units are “meter” and “Celsius” (or “Kelvin)” and those are what Europeans still use, we even bend physics just for our U.S. friends
