openhab-core icon indicating copy to clipboard operation
openhab-core copied to clipboard

Fix QuantityType dimensionless one and time formatting

Open mherwege opened this issue 1 year ago • 1 comments

Resolves https://github.com/openhab/openhab-core/issues/4166 Resolves https://github.com/openhab/openhab-core/issues/4163

This PR tries to resolve two issues with QuantityType:

  1. Updating a Number:Dimensionless Item with a value of unit one, when the unit is set in metadata to another unit, will not update correctly. The proposed solution is to remove the special handling of unit one and make the unit part of the string again. It can be removed from visualisation using a state description.
  2. Formatting a QuantityType<Time> tries to use the DateTime String formatting methods. When it fails it may output a UTC date. Durations will also not be correctly formatted when days/hours/minutes/seconds are above the month (31)/day (24)/hour (60)/minute (60) limits. In this PR, the formatting strings are preserved, but interpreted specifically for time with a relative scale (durations), rather than an absolute time.

mherwege avatar Apr 04 '24 13:04 mherwege

@mherwege many thanks. I like the extra bonus for the duration formatting.

andrewfg avatar Apr 05 '24 17:04 andrewfg

We have a few failing tests in the add-ons now, see https://ci.openhab.org/job/openHAB-Addons/lastCompletedBuild/testReport/.

Might these be related to this change, @mherwege?

kaikreuzer avatar May 18 '24 16:05 kaikreuzer

It probably is. I am investigating. It looks like the mqtt tests assume a formatting of a QuantityType with format pattern %s just drops the unit. It may have done that in the past because in core, first a conversion to BigDecimal (which dropped the unit) was attempted before passing the value verbatim (with unit). I don't think the unit should be dropped like that when formatting a Number with Dimension.

mherwege avatar May 19 '24 08:05 mherwege

@kaikreuzer I have made a change to the MQTT binding that resolves the issue caused by the change in this PR.

The fundamental problem is that the format method on a type is used both for representation purposes in UI's and internal processing when converting to a String. Some logic depends on the formatting to be done in a certain way, which blocks improvements in the UI, and the other way around. I hope this change resolves the issue. At leasts the failing tests work again, so it should keep backward compatibility.

mherwege avatar May 19 '24 09:05 mherwege

@mherwege Many thanks for taking care of it so quickly!

kaikreuzer avatar May 19 '24 11:05 kaikreuzer