PercentType to DecimalType conversion inconsistent after recent state conversion logic changes

[arstorey]

Conversion of a PercentType representing 0%-100% to a DecimalType should return a DecimalType in the range of 0.0 to 100.0 rather than latest behavior of 0.0-1.0 (a breaking change for anything displaying a PecentType value using a NumericItem with a format string to control the number of decimal places). This change also does not round-trip between the type types. For example, the current snapshot would round trip PercentType of 100.0% to DecimalType = 1.0 back to PercentType = 1.0%

While conversion of a percentage to a range of 0.0-1.0 is mathematically correct, the PercentType class is designed to represent a real number limited in range from 0.0-100.0 rather than as a true mathematical percentage in the range of 0.0 to 1.0. The intent of the original design and conversion behavior seem to have been to make it possible to display percentages on sitemaps using a NumericItem in a format suitable for display using java numeric format strings.

Thanks!

[J-N-K]

I can't see from the code why that should happen. Can you provide a short example to reproduce that?

[arstorey]

Sorry it's taken me so long to get back with you on this.

Please check the file org.eclipse.smarthome.core.library.types.PercentType.java.

In the "as" method PercentType as DecimalType is being converted using the following line of code:

return new DecimalType(toBigDecimal().divide(BigDecimal.valueOf(100), 8, RoundingMode.UP));

The call to .divide() in the line of code above is causing the issue (scaling 0.0 - 100.0 down to 0.0-1.0).

The change in conversion logic was introduced as part of pull request #2334.

Thanks!

Alan

[kaikreuzer]

How do you actually end up with PercentType values on NumberItems? Usually, PercentType is only used in conjunction with DimmerItems.

Can you show a concrete (small) example where a problem occurs (item definition, sitemap definition)?

[J-N-K]

Quite simple. KNX DPT 5.001 is mapped to PercentType and often used for humidity sensors, these are NumberItems in ESH.

https://github.com/openhab/openhab1-addons/blob/master/bundles/binding/org.openhab.binding.knx/src/main/java/org/openhab/binding/knx/internal/dpt/KNXCoreTypeMapper.java#L127

[arstorey]

In my case I have a binding I'm working on which is providing remaining battery capacity in the range of 0.0-100.0. PercentType seemed a natural fit to use given its description in the Javadoc. However you decide to convert it, the conversion logic should round-trip between the data types. Currently NumberType as PercentType, and PercentType as NumberType use different and incompatible conversion logic so the same number will not survive conversion to one type and then back again to the original type.

[kaikreuzer]

There has been some huge improvements on all the type conversion logic within the framework.
May I ask you if the issue still exists or if it can be closed?

[arstorey]

I coded around the issue at the time and have had zero time since then to upgrade past the last beta version so I really can't say if the issue is fixed or not. However, if no one else is complaining then I would go ahead and close the issue. Thanks!