[SOLVED] State presentation: no difference between [%.1f %unit%] vs. [%.0f %unit%]?

Hi guys,

I´m on Openhab 2.5 and have a question about state presentation: I have a temperature item (from openweathermap binding). Because I don´t need any decimal place I´ve changed %.1f to %.0f (https://community.openhab.org/t/solved-question-aboute-1f-c-d-3f-kw/62420/2)
But nothing changes. Here is an example:

Number:Temperature  TestTemperatur0  "Temperatur0 [%.0f %unit%]"  { channel="openweathermap:weather-and-forecast:api:local:current#temperature" }
Number:Temperature  TestTemperatur1  "Temperatur0 [%.1f %unit%]"  { channel="openweathermap:weather-and-forecast:api:local:current#temperature" }
Number:Temperature  TestTemperatur2  "Temperatur0 [%.2f %unit%]"  { channel="openweathermap:weather-and-forecast:api:local:current#temperature" }

I always get:

2020-05-23 15:15:17.151 [vent.ItemStateChangedEvent] - TestTemperatur1 changed from NULL to 17.13 °C
2020-05-23 15:15:17.152 [vent.ItemStateChangedEvent] - TestTemperatur0 changed from NULL to 17.13 °C
2020-05-23 15:15:17.152 [vent.ItemStateChangedEvent] - TestTemperatur2 changed from NULL to 17.13 °C

Where did I go wrong? Thanks a lot!

Have you tried without using the UoM feature?


Number  TestTemperatur0  "Temperatur0 [%.0f °C ]"  { channel="openweathermap:weather-and-forecast:api:local:current#temperature" }

yes, no changes at all.

If you only want no decimal places for your sitemap then you can edit how it’s displayed in sitemap file.

Doing this you’re only changing the way the value is displayed, not the actual value behind

And that is where the problems beginn: I want to merge two items into one for a daily min./max. in my sitemap.

To calculte the daily min./max. I´ve used this example: https://community.openhab.org/t/openweathermap-daily-forecasts-with-free-api-using-plain-openhab-rules/68513. Of course I changed all temperature elements to %.0f %unit%, but I still get the decimal places. And because even the simple items in my example above don’t work as I expected, something else has to go wrong.

Maybe try and round the number in a different rule.

rule “Round Temperature Livingroom Sensor”
Item HT_Temperature_LR received update
if (HT_Temperature_LR.state != NULL){
val roundedNumber = (Math::round((HT_Temperature_LR.state as DecimalType).floatValue()* 10)).floatValue() /10

That’s working as designed. The [ format ] part is used for presentation of the state in a UI. It makes no difference to the actual state of an Item.

In your rule, you could use something like
newString = (someNumber.state as Number).intValue.toString + ...

You can’t do that “automatically” in a sitemap: only single values can be rendered this way, not multiple values (such as a temperature range).

So you need to write a rule to populate that item. That rule can then take care of properly rounding the temperatures to the desired precision.

Please note that I moved away from Rules DSL a while ago so all my rules are now based on Jython and NGRE. Works much faster and requires less CPU & RAM.

That is the part that I missed. I thought the [ format ] part directly affects the item. Thanks for making this clear.

It would be helpful if you could specify a scale for items. Either when you define them or a global for all items. I have all sorts of items with false precision when they get converted between units of measure, for example C to F, mm to inches, etc.

Maybe this could be a new feature for 3.0?

The uploaded picture is from my sitemap and the populated item is generatet by your rule :wink: I thought if I take rounded values right away, I could save myself the conversion.

In general, nobody cares what the internal representation is. Display representation is easily managed e.g. with [format] sections.

Having to use format is something you shouldn’t have to do. Especially, if OH wants to become more user friendly in the future.

Well, while we don’t have a mind reading binding, you will have to provide some means for openHAB to guess if you want three decimal places or none.

Yes that is correct.