Use of prefixes in UoM

[vzorglub]

I have an item:

Number:Pressure    AtmosphericPressure        "Atmospheric Pressure 
[%.0f mbar]"                     (Weather) { weather="locationId=home, 
type=atmosphere, property=pressure" }

If I use [%.0f bar] the value is in bar

If I use [%.0f mbar] the value is in default hPa

How do we use the prefixes, or as mbar and hPa are the same in SI the system shows hPa?

Thanks

[htreu]

Thanks for reposting this issue. The problem here is, that the UoM framework does not recognise the unit symbol mbar. Therefor it is just ignored and the default unit for pressure is used (here hPa).

So the issue hits all of our "custom" units which are not integral part of the tec.uom libraries.

@keilw any suggestions on how to use the uom framework, so metric prefixes are recognised during parsing when custom units are used?

[keilw]

Are you parsing or rendering?

[htreu]

parsing. The string [%.0f mbar] will be parsed to convert the quantity at hand to the given unit in the string (here mbar) and then output it with the decimal format given (here %.0f). Example: the item with the afore mentioned state description has a state value of 1000 hPaand should be converted tombar. Expected output would be 1000 mbar` (the target unit is implicitly rendered).

[keilw]

Have you tried alternate parsers/formatters like EBNFUnitFormat instead of SimpleUnitFormat? We'd have to try but while not so easily extensible via label() it is a little more powerful when it comes to formatting and parsing.

[htreu]

Thanks for the hint, we will try with different formatters/parsers.

[vzorglub]

@htreu Have you made any progress with this issue? Thanks

[htreu]

No, didn't find the time yet. The "help wanted" label is supposed to attract people from the community though ;-)

[keilw]

@htreu @vzorglub @kaikreuzer I already mentioned it by mail, but as I "shifted" (because Ivar was overwhelmed with getting most votes in all 3 committees;-) into the Jakarta EE Spec WG I should also attend F2F meetings which are in my understanding on the Community Day @ ECE. If you think it was beneficial to say a few words about JSR 363 and proposed changes/improvements with JSR 385 and what suggestions or requirements projects like SmartHome have, I'd be happy to suggest UoM as a topic for the Community Day. Other days depend on whether I'll have a talk then, but on Community Day I should be there for sure.

[giovannt0]

Although not very elegant, a possible workaround as shown in 5b620f8 does the trick.

[keilw]

Unlike the other UnitFormat implementations, that is pretty much what SimpleUnitFormat also does internally for units it already knows out of the box.

[keilw]

While it may not be possible to switch to JSR 385 immediately (it should go Final before Summer) a Spring Boot solution by participants of our Adopt-JSR-385 hackathon by Utrecht JUG last weekend https://github.com/NLxAROSA/uom-sb-demo showed, how the new Prefix model in JSR 385 makes it easier to parse prefixes given on the command line or a REST interface.