[Sitemap UI] Extra space for item state with Number: items

[robnielsen]

Starting with 4.0.0.M4 there is an extra space for the item state for Number: items, this does not occur with Number items. For example:

Number:Temperature   nOutdoorTemp           "Outdoor Temperature [%.1f°]"     {channel="netatmo:outdoor:home:indoor:outdoor:temperature#value"}
Number:Dimensionless nOutdoorHumidity       "Outdoor Humidity [%d%%]"         {channel="netatmo:outdoor:home:indoor:outdoor:humidity#value", unit="%"}
Number               nOutdoorBatteryPercent "Outdoor Module [%d%%]"           {channel="netatmo:outdoor:home:indoor:outdoor:battery#value"}

are now displayed as:

[lolodomo]

It might be the consequence of recently merged PR openhab/openhab-core#3644 that introduced the method getFormatPattern.
Look at this line:
https://github.com/openhab/openhab-core/blob/main/bundles/org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/items/ItemUIRegistryImpl.java#L518
It should affect any widget associated to a number with dimension.
It looks to me as a minor bug but it is true that the format entered by the user is now not strickly respected.
@mherwege : any idea or comment ?

[lolodomo]

For consistency, an option could be to also add the space for numbers without dimension ?

[robnielsen]

For consistency, there should not be a space, unless explicitly specified in the pattern. I wouldn't call it a minor defect since it affects what's displayed, and is a regression from how it used to work.

[mherwege]

This issue will come up with units like % that tend to be concatenated to the value without space. In https://github.com/openhab/openhab-core/blob/main/bundles/org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/items/ItemUIRegistryImpl.java#L506 potential blanks get trimmed and one blank gets readded afterwards. It is the only way to be able to identify erroneous patterns after the unit. One could isolate the leading blanks if they exist and readd that instead of a fixed blank.

[robnielsen]

This also impacts temperature which typically doesn't have a space between the value and °.

I'm also seeing an extra space when displaying the inches of rain as well:

Number:Length        nRainHour              "Rain Last Hour [%.03f\"]"  {channel="netatmo:rain:home:indoor:rain:rain#sum-1", unit="in"}

[mherwege]

That's why I wrote units like %. The same is indeed true for temperature degrees and ". Without a space, I don't think unit conversions ever worked. So it was OK as long as everything was in the same unit. But the new unit management in 4.0 helps a bit here as it forces your default unit. I agree this should, and could, be improved. But I am not able to do so myself before the OH4 release deadline. Maybe @lolodomo could have a look.

[lolodomo]

Basic UI, especially JavaScript code, may expect a space to properly handle/detect unit. To be checked if this space is searched only in item state or also in widget label.

[lolodomo]

To be confirmed, but normally it should also concern other sitemap UIs like the Android app.

[lolodomo]

Basic UI, especially JavaScript code, may expect a space to properly handle/detect unit. To be checked if this space is searched only in item state or also in widget label.

I believe it is OK, the space between the number and the unit is only searched on received item state, not on the received formatted label. The only exception is for slider widget but in this case there is an exception in the server side and only the number is pushed.

[lolodomo]

I just fixed the issue in core framework.

[lolodomo]

Closed by core PR.