Use Units of Measurement i.e. use Number:DataAmount, thatâs right what the feature was built for.
If you have a value of say â1024 MBâ and define a metadata pattern of say â%.1f GBâ then OH will automatically convert it when displaying in MainUI.
Remember you need to initially set the value with a unit.
Eventually also search the forum for âbootstrapping itemsâ, thereâs a tutorial how to do that best.
If the source of your number (which is a secret from us) does not have units, and it is a channel, you can use a profile to modify the channel output before it updates the Item.
The source is a Number without Dimension and it has no units but I know it is in fact bytes. This is from a channel from the marketplace binding for UniFi Protect.
I am not the developer of the binding, I am just using it. How can I use a profile in this case?
Using a transform profile that is a little javascript, you can append the text unit for bytes to the the basic number from the channel, and link it a Number:DataAmount type Item. How it gets displayed is controlled by the Item metadata, with auto-scaling just as @mstormi says.
Or of course the little javascript could do the maths as well, and pass Gb if you like.
Or you use a plain Number Item and apply a display transformation that scales it to what you want for the UI while leaving Item state unaltered.
If you are charting this value, your choice might be steered by what value you want to store and chart (which will be the raw Item state).
I think you donât even need a profile. You should be able to simply link the channel to an item of Number:DataAmount type.
Bootstrapping will define the default unit to apply. If that does not work use the profile as @rossko57 suggests.
But if the number from the channel comes in bytes, that is what you must set the Itemâs default unit to to get the correct value imported.
Then you donât get the display in wanted Gb because the default is used for that as well âŠ
I already changed the item type from Number to Number:DataAmount but where do I set the default unit for an item?
If I set the State Description pattern to â%.1f GBâ, I just get the bytes value + âGBâ.
As Iâve tried to explain, if you load a âplain numberâ into a Quantity type Item, it will assume that Items default unit.
So set default âbâ, post â22â, get â22 bâ.
Set default âGbâ, post the same 22, get â22 Gbâ.
Obviously if you post a plain number you must set Item default to the units the number is really coming in.
Thatâs fine, it works.
But it leaves you unable to show the value in Gb - the default unit is used for for both purposes and can only be one thing at a time.
If you post the full â22 bâ (e.g. by using a profile) it doesnât matter what the Itemâs default units are, auto-conversion works.
I understand why it is not working as it is. Thatâs clear.
What I still donât know, even with the forum link above, is where to set an itemâs default unit.
However, if auto conversion then does not work anyway, I would not be able to convert the b to Gb in the State Description, so this is not the solution for me anyway.
That leaves me with a channel profile conversion via JS and that is what I will try next. Although, I think that the whole thing should be easier to do for the user, setting a default unit that is working with auto conversion.
Yes, the binding should provide correct units in the first place, but it is like it is.
Edit:
OK, got it working. I installed the JS transformation. Then I wrote a small JS named âbytes.jsâ in the transform folder like this:
(function(i) {
return i + "B";
})(input)
And then used that in the channel transformation profile setting:
Then I set the pattern â%.1f GBâ in the model State Description. Now I have everywhere âX.Y GBâ, like I wanted. Still think this is too complicated.
It does work, but it needs to know the value is in bytes to begin with.
The binding is not supplying that info - this is what is needed for -
You might make an enhancement request for that binding, thatâs all that is needed to make it seamless.
What I think is a real restriction is that an Itemâs âdefault unitâ and âdisplay unitâ are both derived from the same metadata, two different uses for same info. Thatâs not likely to change in OH3.
If the binding does not provide the quantity unit, ideally I would like to be able to edit the item, change type from Number to Number:DataAmount and enter the base unit there.
Using channel transformation is very powerful but seems like overkill for this simple thing.
One strange thing with my current solution remains:
I have set pattern â%.1f GBâ and when I click on the item, I see this:
Because the pattern metadata is about display of Item state. It used to be that was all it was about, and never affected actual state in any way.
Later, they introduced Quantity types, with units. Some way to define a default unit was needed, and in the middle of OH2 development âtheyâ decided to hijack the existing pattern (where everyone was putting text to represent units in their displays anyway) and re-use it for this new purpose as well. Rather than changing the core Item model with a new property.
So as you found, you cannot define a default different display. The units part of the pattern gets (ab)used for a default when the data source is deficient and has no units.
(It gets involved in persistence as well - if you change the default unit it has bad effects on historic data)
Meantime the non-units part of âpatternâ remains purely for display purposes, the real Item state is unaffected (e.g. can be many decimals) and in the admin facing parts of the GUI you will see raw states, not the prettified version for end users.
Not that Iâm aware of. A logical approach would be to separate the default/display properties in OH4 by redefining core Item object. Thatâs probably much simpler than it was in OH2, with more flexible metadata already available in OH3.
All this is only of interest when the data source is deficient of units, but you want to force unit assignment anyway.
Some bindings remain that can âknowâ data units but do not currently supply them, so they can be usefully enhanced.
Other bindings handle generic data and cannot guess what units might be appropriate, so we do need a way to manually designate. But that is just what profiles or channel-based transformations are for.
Yes, I think users should file feature requests on each and every binding that could be enhanced by using UoM. It is always sensible because this causes breaking changes but it goes in the right way to empower OH.