I have an Unit of Measurements item of say Number:Energy type and want to make that enterable from mainUI using a oh-stepper-item widget.
Now if I do, the item is set to the pure Number, without the unit.
How can I avoid that and get say 1.1 kWh set as the item value ?
I know I have to give some initial hint to indicate the UoM unit, but setting the item does not help, it still gets overwritten by the pure Number.
I’ve seen a “unit” YAML parameter but didn’t find docs on that and it does not seem to take effect either.
FWIW, I want to avoid changing widget type to string or whatever and do some own validation/conversion processing. I also want to avoid using workaround such as rules that re-set items if changed via UI (as among other drawbacks, it isn’t guaranteed that the correction rule takes effect before other rules).
Can you clarify, MainUI doesn’t set anything - but it will send command.
There has been work in this area, the OH version you are using is relevant
So far as I know the stepper widget should use the Item pattern metadata e.g. %.1f kWh if it exists.
What happens if that is absent or placeholder %unit% I donot know.
What happens. When you click the widget, it does not “set” the Item to anything, ever. It sends it a command. Are you saying the command it sends is not what you expect, or are you saying the effects of that command are not what you expect?
Well, let’s not leave it that? The ‘pattern’ allows us to control the widget presentation, and it should derive its action (command) from that in turn.
But it is legitimate to have an Item with no pattern at all (or pattern %unit%), and a valid state like “3.1 kWh”, and I would expect the widget to fall back to working with the state as given.
Sounds like a reasonable enhancement feature?
Not exactly sure what you think the improvement would need to be.
Yes for an empty display pattern and a well-defined default unit leaving pattern empty would not work so you want to have two fields, one for display and one for default UoM ?
I would have thought if you have a QuantityType item with a UoM, like the state is 234 kWh and you send the command 235, the UoM would be kept and the state would now be 235 kWh, isn’t that the case? I was pretty sure of it but now I don’t know.
Now this could be an improvement to the widget to send a command with the explicit unit. On the other hand, you could argue the units of measurement are for just that, measurements, so if you have the need to update these states interactively in the UI, then it’s not so much a measurement anymore and you’d be better served by a regular Number item with a pattern.
I personally think that UoM is way too loose and being so is not doing us nor our users and favors.
For example, did you know you can send a value to a plain old Number Item with units and it will retain the units? Just because it’s a Number doesn’t mean you can trust it’s not carrying 62 °F and you have to treat it as a QuantityType instead of a DecimalType.
Based on the described behavior it seems to be the same in the opposite direction. Just because you have a Number:Energy you cannot trust that it’s carrying a QuantityType and not just a plain old DecimalType.
There is also some weirdness going on with State Description too. It seems to apply in unexpected circumstances and in counterintuitive ways and not just in displaying the state in the UI. As I was looking through the core code for other stuff I find references to it all over the place.
And @rossko57 can confirm some strange behavior in conjunction with the MQTT binding I’ve been exploring (I’m planning on doing some more experiments today to further explore the behaviors).
Everyone on this thread are power users and experts in OH. If even we are having problems and unexpected behaviors, imagine what the average user is having to go through.
It is possible to e.g. post an update to a Quantity type Item with no units. Then a “default units” action takes place, and we might end up with units anyway.
For example, postUpdate “32” to Item with pattern %.1f kWh and get state “32 kWh”
Hurrah, we don’t need to send units! Well no, we’re talking widget and sending commands, and a binding might look at those. If the binding needs units, we’re broken.
The widget ought to command with units, it’s just a case of finding out what.
I reckon the root of many ills is that the ‘pattern’ designation, which was previously all about presentation only, was “hijacked” back in OH2 days to also provide internal units info, instead of adding an separate per-Item units designator for internal processes.
I just took my item (to have metadata and 5 kWh as its value) and removed the UoM pattern (or all metadata in fact) then changed it via main UI, there you are back without UoM.
Note I used file based configuration for that item including the metadata part.
2021-10-19 17:09:56.959 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'NachtvorratHaus' received command 4.9
2021-10-19 17:09:56.960 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'NachtvorratHaus' changed from 5 kWh to 4.9
Indeed, this has bitten me a number of times already.
For example, I have DSL code to use NachtvorratHaus.state as QuantityType<Energy>, and code execution starts failing at that line when NachtvorratHaus was commanded to non-UoM like above because it does not know which unit to apply. Very annoying particularly as it happens at run time only.
This turns out very true (as I find most documentation examples very “files” oriented and lacking “OH3-Main UI” setup explanations). I would like to add an unexpected behavior in this respect: I decided to add a pattern to an Item that reports the lifetime production of my solar panels. it was not convenient to have them in Wh, so I changed it to MWh by implementing a pattern using the state description from the metadata.
unfortunately after pressing “Analyze” for the item, it generates the following report output:
Obviously, my lifetime output did not suddenly diminish with a factor 10^6. analysing the values stored in the persistence database, I think OH is unable to correcly display the values, as the UoM is not recorded in the persistence database. how would it know which values to convert to my newly set patern and which not…
Here be the problem. The Item ‘pattern’ is used for two purposes; it scales whatever the Item state is for display, that’s the original purpose. e.g. state in m, pattern km, display will be state / 1000. hurrah.
The Item ‘pattern’ has additionally been pressed into service as a default units indicator. So pattern m, post a number 123, get state 123m. Fair enough.
This becomes an issue with persistence, exactly as you’ve noted. No units are stored, so when a value is retrieved the ‘quantity’ is reconstructed from retrieved numeric + Item default unit.
That generally works out because the stored data is also scaled to the default unit.
But it falls in a big heap when you change the default (change ‘pattern’), which you might well do for your display reasons.
Now retrieved data gets the wrong unit applied; it was recorded with one unit and is reconstructed with another.
I don’t know of any workaround.
In sitemaps/BasicUI, you can specify a ‘pattern’ in the widget - so you can display in whatever unit and not affect the Item default or state at all.
There doesn’t seem to be any way to do that in MainUI.
The practical advice is “never change the units of an Item with important historic data”.
