The most common way to deal with that is to keep the number as is, but when displaying it to the user use formatting (like you already do on the sitemap).
For the display in the log it would need the change code deep in the core of OH and what is of a bigger concern, that would change the display of all values. However other values need to be displayed with all their decimal places. Since this is in the log, which is not the display for the normal user I would not change it there!
This isn’t a setpoint feature. this is a side effect of the fact that computers are really bad at doing floating point math. The way floating point numbers are represented in computers and the way the calculations are performed means that the computer never actually comes up with the exact right answer. It can only get really really close (e.g. 1.099999999999999999 instead of 1.1).
This usually works. It won’t work all the time because see above.
Math::round((MyItem.state as Number * 10).floatValue) / 10
You have to do the same rounding trick illustrated above. Again, this will work some of the time, not all of the time.
You can also use String::format (search the forum for examples) which would let you use the %.1f symbols to round the value for logging.
See above. Computers are just not very good at floating point math. There are all sorts of things you can do but the usual best practice is to leave the floating point results of calculations with all of their decimal places and round them for display to the human.
Thanks Rich for your help.
I am afraid I do not agree that computers are bad at performing floating
point calculations, I would think this is a coding issue.
I have noticed that is if a value is horrendously long if I use setpoint
and add 0.1 and then take it away again returning the value back as it was;
it actually sorts out the issue and becomes the correct value with only one
decimal place. I am wondering if this workaround could be implemented in a
I will do a search to see if I can find the way to use String::format
In fact, you (or the coder) can do different things to hide some (but not all) wrong results, but the dilemma is, how to represent a potentially infinite floating point number with 32bits (single precision) or 64bits (double precision)?
Well, I have degrees in computer science, spent a whole class on this one topic (Numerical Analysis), and have professionally had to code in scientific computing domains where we needed precision in the millionths place which computers are simply not capable of doing without lots of conversions to integers to do the math.
I can supply further links or some references to text books if Wikipedia or my links are not sufficient to convince you.
Indeed. In scientific computing we usually convert the floating points to integers by multiplying to move the decimal place past the precision we need and converting them back to a float at the end or leaving that as an exercise to the student. But I hadve to ask, is it really worth going through all of this extra work for something like the Setpoint in OH? I’d say no and it appears the developers agree.
In fact, it is rarely worth the effort which is why most programs leave them alone and round them when displaying them to a human. Which is what we are suggesting to do here.
You may be looking in the wrong place. Have you experimented with different UIs ? I vaguely recall a thread where the setpoint widget(s) gave different results, in terms of 1.1 or 1.099999 etc. Which were transmitted onwards to OH of course.
so is setpoint not part of OH2? I was understanding that this was part of
the openhab application, if not then I can see asking OH to add
functionality to something that is not of the coders doing is a big ask.
I am currently looking into horrendous hacks to step outside of OH2 to fix
the issue which seems a little nuts to me hence why I started the thread.
I’m not sure what horrendous hacks you are attempting. Using the string formatters in labels and logs is not really a hack when it is THE standard way to manage floating point numbers for human consumption.