I’m afraid I do not believe that.
At the very least, retrieving persisted data currently depends on the default for that Item to reconstruct the quantity from numeric-only records.
But I don’t believe regular updates work like that either - state updates in arbitrary units are auto-converted to the Item’s given default. Try it, just postUpdate from a rule.
I don’t think that’s a good idea. While we would rarely find nm or light-years in home automation, we do find both km and mm.
What happens if someone moves, changes locale?
I do understand the whole persistence-with-UoM is a difficult business to resolve,
Real-life example of data source µg/m³ wildly different from quantity type default
You’re right, it applies the default (again). I misinterpreted a statement in the PR.
I created a Number:Length item mtest. No pattern, no stateDescription. 3.4 of course.
openhab> openhab:status mtest
NULL
openhab> openhab:send mtest 6
Command has been sent successfully.
openhab> openhab:status mtest
6 m
openhab> openhab:send mtest 6km
Command has been sent successfully.
openhab> openhab:status mtest
6 km
openhab> openhab:send mtest 7
Command has been sent successfully.
openhab> openhab:status mtest
7 m
As you see the applied default is m.
But as you also can see setting mtest to 7km does not set it to 7000m (that’s how I understood your statement you think it would).
So what? You can today and will continue to represent any km or mm value in m.
I don’t think you got the point of my proposal.
It’s just about the unit that is implicitly used for persistence storage. As units aren’t persisted we have to define the storage unit and apply it on restoration. If the current item unit is different, we need to convert the value accordingly before persisting it.
But my proposal does not change the item value, it just scales the value to match the base unit and that value then is written to persistence.
Read on conversion to base unit on persisting · Issue #3167 · openhab/openhab-core · GitHub
The recent change will ensure that on restore, any item will get the default unit assigned right away.
The base unit is defined by physics, and it is independent of locale. If you globally change locale or pattern per item neither will change the value, only the display.
That kind of blows up Rich’s use-case, where a sensor reports say in F and he’d like the Item in C.
Can’t be done, you must have the state update in F regardless of default, though you can choose to display in C
This isn’t some artefact of sending a command and relying on Autoupdate to generate state, is it?
Makes you wonder why have km or mm at all …
I’ve tried to suggest that various sub-systems, like persistence, will give slightly different rounding errors with data 0.00000005m and data 5um.
Speculation only, ‘simple’ charts become harder to configure with sensible scales.
It just feels like a bad idea. I do appreciate it looks like a solution to a difficult problem, I do not think it is good enough though.
So there won’t be locale dependent C/F anymore?
Or you’re talking a system type default and another base type default below that?
If you read the docs it exactly describes Rich’s use case and that it can be done with UOM:
A weather binding which reads temperature values in °C would use the QuantityType to
indicate the unit as °C. The framework is then able to convert the values
to either °F or Kelvin according to the configuration of the system.
This is the only useful application of the whole UOM system:
Implicit state transformations from one unit to the other without having to manually do all the calculations.
FWIW let’s change from a technical perspective to a more functional description on how users would like to have their UoM handled?
I’ll start:
I’m fine with having a default UoM per itemType
I must be able to define the actual UoM of a device’s data per item
I must be able to define a per presentation UoM in case I want to do some fancy sh… with graphs or sitemaps or whatever.
** If I don’t define a UoM on my presentation layer (sitemap, UI, whatever) I’ll also get a default presentation UoM (I’m fine with having that attached to the actual UoM of the item)
** If I do define a UoM for my presentation layer I can do so somehow within that layer or OH let’s me define UoM for API, dashboard, sitemap, …
I must be able to know exactly the unit the item persistence UoM will be, perhaps this is the actual UoM or it is also configurable
on a different note: it must be well documented, how all that works, where to find/see default UoMs and how to use UoM in rules. Right now this info is clattered across the forum, some docs and perhaps some github discussions?
forgot something?
My 2cents on edge cases like “someone’s moving to different locale” or “suddenly I’m using another UoM for my item and my persistence gets messed up” shouldn’t be of concern. They can be adressed by those who like accordingly with some effort, but shouldn’t be part of the actual requirements here.
Actually it’s even easier since we are talking only UoM about items here.
We agree on almost almost everything but I’m trying to rephrase so it’s (imho) easier
Each UoM item has a unit (that’s why it’s a UoM item)
The unit can be set per item (optional)
The unit of the graphical representation can be set per item (optional)
The unit of the graphical representation doesn’t have any other impacts
The persisted value is always the value of the item (in the unit of the item)
With these rules we get the following:
If no unit is explicitly supplied a default is picked
If no unit for graphical representation is supplied a default is picked
It’s possible to have persisted values in the (for the user) correct unit, e.g. I can persist values in °F or km/h even though the system default is different
It’ll even cover one of your corner cases (“I’m moving to a different locale”) because the unit of the item can be explicitly set to the unit before the locale change.
Another point (not sure if it’s better to start a new thread for this): If using UoM Items to get historical data (lets say a graph of energy consumption) and changing the Item e.g. to use kWh instead of Wh, this will result in a skip of factor 1000. So the line drops to the new level and old values are wrong of factor 1000.
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
