I finally took the leap and moved to the Netatmo binding, even though it’s missing functionality of the 1.X binding. The precision is a bit too much:
2020-03-25 15:16:35.166 [vent.ItemStateChangedEvent] - nIndoorTemp changed from 68.00 °F to 69.0800006866455078125 °F
2020-03-25 15:16:35.342 [vent.ItemStateChangedEvent] - nIndoorPressure changed from 29.79575878487639337252553458138878 inHg to 29.78690014868441684768549853117835 inHg
2020-03-25 15:16:35.458 [vent.ItemStateChangedEvent] - nOutdoorTemp changed from 44.95999965667724609375 °F to 44.779999828338623046875 °F
2020-03-25 15:16:35.476 [vent.ItemStateChangedEvent] - nRainNow changed from 0 in to 0.008385826752880426842396653543307087 in
It’s not the precision, it’s the fact that the number 69.08 is probably impossible to represent using standard way floating point numbers are stored and used by computers. Or the number is the result of a calculation that included at least one number that can’t be represented. It would be impossible to represent every single possible floating point number so computers take short cuts. But those short cuts mean that some numbers just do not exist. In those cases the computer gets really really close, but ends up with lots and lots of decimal places.
As rossko57 indicates, the usual way programmers handle this is to keep all that unnecessary precision and round the number for display to a human. It’s really not worth worrying about making events.log look “pretty” so your best bet is to just deal with it.
Yes I agree, but openHAB should at least provide some level or precision during conversion. What happens if somebody doesn’t wan’t to format what is displayed in the UI? Also, Aren’t the numbers stored as BigDecimal, if so during the conversion you should know how precise the number is and use a corresponding precision.
Uh, it’s a dumb machine. You get what you ask for. If someone doesn’t care about format, they get the default, and … they don’t care.
When they care, they take action to get what they want.
How the numbers are stored does not relate to what form they are processed in during conversion (which is most likely float).
It’s a reasonable argument that when you start off with a BigDecimal you can detect that is has, say, two decimal places. Maybe you would like to convert a “float” conversion answer back to same precision.
But really, this falls down when we convert mm to km say, or % to dB. The act of conversion means the precision isn’t related from input to output in a straightforward manner.
