That is indeed a limitation but it does’t seem like a significant one. But if it is significant enough to add that one can open an issue. But Olivier is not trying to show the same Item with multiple units here. As far as I can tell, he want to show it with just the one unit without using the feature that was explicitly designed to allow setting the unit for display. I still don’t understand the statement about needing implicit knowledge about the units. You need that knowledge no matter what when dealing with UoM Items. You can’t get away from it.
That’s not the only UI thing that is tied to the Item either. The default widgets too are defined using Item metadata. OH has always had a mixing of View and Model in the Items definitions. I’ve never liked it but all these years later it seems too late to complain.
However, Item metadata really isn’t part of an Item any more than a Link is part of an Item or a Channel. It’s actually a separate entity just like a Link is. And I don’t see why it’d be technically unfeasible to define more than one display pattern for use. It’s not clear to me though how/whether there is any way to do that without changes to core in addition to MainUI which makes it more than a quick job. All the generation of the labels, be they on the sitemap or displayState in MainUI actually occurs in the core.
Ultimately, as MainUI exists right now, one can only specify the one unit for display, two if one of the units desired is the default set of units.
But the Group should behave the same as Items do concerning default units. It’ll be next week before I can do the experiments necessary to determine what is going on there and whether an issue needs to be filed and if so what:
how is the unit that is the result of a calculation determined? That should tell us why the SUM returned a default units of km/h.
is the state description pattern in fact used to set the units for an Item?
is it used in every case or only sometimes?
what role do the bindings play in the selection of the units?
The answers to these questions will tell us whether the Group is in fact behaving in an inconsistent way compared to the Items.
This part isn’t related to Group.
My expectation is that you will find that where, say, a number:temperature channel feeds an Item
a) If the Item has no [pattern] channel data gets converted to system default units (as set by imperial/metric locale).
b) If the Item has [pattern with unit] it gets converted to that before arriving in state.
c) If the update has no units - which should not happen with a properly built channel, but can be done with postUpdate or profile intervention - the [pattern] units will be assumed, or where no [pattern] then system default.
This Item will always have units.
But that’s not the whole story…
Not every Quantity Type has system default units, example Number:Energy
a) If the Item has no [pattern] channel data is accepted as-is, with hopefully a valid unit
b) Inappropriate units are rejected - no update
c) No units at all are accepted, a plain number ends up in the state. No unit.
d) If the Item has [pattern-wih-unit] channel data is converted.
e) No units are still accepted, but this time the [pattern] unit is assumed - as we’d hope for “Item default” unit.
Note that these effects of [pattern] are all about Item state content, not presentation.
Historic reasons, they chose to use the existing presentation ‘format box’ which often already contained units to serve double duty as a units indicator.
The one that really trips people up is Number:Dimensionless, which has no system default units … but the absence of a unit is always acceptable and is interpreted as unit “ONE” meaning ratio. When you display or chart that as percent you get x100 values.
I wonder whether it could be possible to expose UoM in the browser, since parts of the UI are built with NodeJS/Vue/Framework7. It would be great if the UI could use UoM, e.g. offered by the NodeJS UoM package.
Part of the confusion emanates from the many custom widget examples which assume the state has a predefined UoM setting, and where the following construct is (ab)used:
items.itemName.state.split(' ')[0]
If I understand you correctly, I should:
explicitly and systematically provide the state pattern expression for each Item and Group whose state is a QuantityType (i.e., uses UoM); and
always use the displayState property (instead of the state property) in YAML widget code.
This is the only way one can guarantee the end result (and the units used).
I guess it depends on the context whether or not it’s an abuse. For example, you can’t do math or comparisons of number with units in a widget. You have to strip off the unit and parse the state/displayState into an integer/float/long. But in fact you don’t have to split the string to do this because the parseInt et. al. functions will stop on the first non-valid character so you can parse a number with units to an int without splitting off the units.
In other cases, for what ever reason perhaps the widget author does not want the units to show at all. In that case that would be a perfectly fine expression to strip off the units.
In still other cases, as Markus points out, perhaps the widget author wants the widget to work with regular Numbers as well as Number Items with units. In that case the units need to be stripped off so both numbers are treated the same in the widget.
There really is no “do this all the time” advice that can be given. It’s all context dependent. It all depends on what you are trying to achieve.
This is a good plan. You should already know which of your Number Items have a UoM. And when you have a UoM you are pretty much the only part of the system that knows enough to choose an appropriate unit.
If you’ve not defined the state pattern there will be no displayState so in the widget code you’d want to use an expression that defaults to state when displayState doesn’t exist.
It’s related insofar that the behavior of units for Items linked to a Channel may be influenced by the binding. Since a Group isn’t influenced by a binding this apparent inconsistency in behavior may really be coming from the binding and without the binding involved, both the Group and Items behave the same. That would mean that there really isn’t an inconsistency in the behavior at all.
Sure; I’d expect Group state to behave the same with updates from an aggregation, as Item state does from a postUpdate. Haven’t caught any difference yet.
