UoM default units and consequences

Having a pattern for presentation separate from the item’s unit would also be useful for something have a large range of values - like power and energy (mW, W, kW; mWh, Wh, kWh, and up to MWh). I plan on writing a script transform at some point so that the display for such values auto-ranges to an appropriate unit. But I can’t do that if I need to use the pattern to convince openHAB of the proper unit I want values stored in.

2 Likes

I’m not sure the defaults are documented anywhere. It should be apparent though once you start using them.

There’s another untidy case that has been done away with too. Number Items will strip off the units if one is passed to them. So if it’s a plain number, it won’t magically start carrying units because some binding decided to publish units or the like.


dancing with the stars celebrity GIF

Because we know it’s going to happen. What if I want to use it in my system as one unit but display it in a different unit? I can’t imagine why someone would want that but I’m 100% sure someone will be mad because they can’t. They may just have accept their use case can’t be handled.

Or, since we are talking OH 4 and breaking changes are OK, drop the State Description pattern from the chain entirely and let the break happen. I think that would be cleaner overall. Why wait for OH 5?

There might be something else we can do to help with this, such as scripts to normalize the historic data and the like.

Note: I got a chance to set it and it does appear to work as expected when using the unit in the MQTT Channel config. I set °C as the unit and it converts it to °F on the Item which has %.0f °F for the State Description pattern. Woohoo! This is the only transformation I have in my system. :smiley: Unlike the rest of the world, I try to eliminate transformations and profiles instead of rules. :rofl:

1 Like

Not at all.
You don’t ever change the Number itself. You only change the representation for display,

I’m not getting why you would need this.
Note the default unit only applies once, initially, when you have no unit yet and assign a value but no unit through either a binding or a rule. Subsequent assignment without unit will reuse the item’s existing unit, NOT the default again.

Well, it also happens on persistence restore, but that’s a little bit different discussion.
For that I’ve agreed with @J-N-K to not put it into 3.4 but discuss in a separate issue first and introduce in OH4 as it comes with a breaking change.
I’m there asking to have a base unit for every type and every value would need to be converted to that base before storing it to persistence. That base unit is usually defined by physics. For your nm example the base would be m so the persistence value stored is 0.0000005.
For temperatures we would need to define it as either C or K I think.

Yes here there will be a one time breaker when you have been using and persisting a value as a non-base unit version such as nm or °F and now introduce a base m or K. That jump in scale cannot be avoided but that ONLY happens for persistence of non-base units and is no valid reason not to take this step forward.
You can convert your old data if you are so really keen on keeping and displaying it in one chart together with your new data.

But in all other cases, in rules you can convert as needed (.toUnit()) and afaik in charts, too, you can set the scale to whatever you want to see the chart in so it looks fine.

I think that a “UNIT” profile is very easy, it should

  • from handler to item: add the defined unit to the DecimalType, making it a QuantityType
  • from item to handler: convert the value (QuantityType to the defined unit and strip it (DecimalType)
1 Like

Heh. :slight_smile:

I try to eliminate transformations for core data paths, but am okay with them for display purposes (i.e. I use a string item to represent “A/V Source”, with value like “1.3” meaning “coming from room 1, input 3”. the transformation will translate into a human-readable value of “Living Room - SHIELD”).

I try to eliminate proxy items if they can be handled by some other native functionality, like proper UoM handling or profiles.

I tried to eliminate a profile usage (okay, I hadn’t even though of using profiles until later) to “veto” commands by using rules, but my PR got shot down ;).

1 Like

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.

1 Like

I stand corrected then, I think this has changed.

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?

1 Like

That’s probably a bug

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. 

And it works:
item:

Number:Temperature    TestTemp     "Temperature [%.1f °C]"   

grafik


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:

  1. I’m fine with having a default UoM per itemType

  2. I must be able to define the actual UoM of a device’s data per item

  3. 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, …

  4. 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

  5. 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?

Sorry for being slow…

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. :wink:
and backup your persistence also - just to be safe

1 Like

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.

It started as an outcome of breaking changes in 3.4.

FYI: I have created Add defaultUnit metadata for NumberItem by J-N-K · Pull Request #3248 · openhab/openhab-core · GitHub

That is the important part, your Number are simply not “Quantity” type Items.

None of this affects you or your historic data.

(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 ?