These two items have the same configuration, the same details, the same origin (modbus binding). The only difference between the two is that the first is a float32 and the second is an uint16.
For some reason, when a value comes from a float, the unit is not displayed. It’s parsed correctly, since it’s shown on the graph if I click on it. But it’s not displayed in the UI. If I change the kind to uint16, the unit is shown (but, obviously, the value is garbage since the kind is wrong).
Nah, you have a fundamental misunderstanding of OH. What you configure to be float or uint16 is things or more precisely how to actually interpret the bits on that modbus register.
What’s shown here is items (or their default representation, actually). Those two for sure will not be of the same type. I don’t know what “average intensity” means and what the appropriate physical unit to apply would be, but this is a pure Number type item. If you wanted it to be shown as a percentage, you would need to configure it to be of Number:Dimensionless type.
Sorry, I should have been clearer in my original post. I thought I had explained the bug precisely enough, but I’ll try again.
The picture shows two items. Both have a format of “%0.1f A”. Both point to things defined in a Modbus binding. Both should be displayed as a decimal value with one fractional digit and a suffixed A.
The only difference between the two is that the first’s thing is a float32 and the second’s is an uint16. By “is a”, I mean that the readValueType property in the Modbus binding settings is float32 or uint16.
My question is then, why does the display format only work when the source value is an integer?
The difference will lie in your Items (which do not know or care what Modbus is doing)
Could you show us API Explorer info for each Item? Or state change events for each Item from your events.log?
The item display format is totally unrelated to what you configure on thing/Modbus level.
As I already responded, the cause will be in your item type definition which you keep failing to show.
If item #1 represents some kind of intensity and not some electrical current, trying to apply %0.1f A is wrong and will lead to all sorts of undefined behavior.
Please, read my post again. I feel like you think I’m dumb and this is getting uncomfortable.
I have things, defined in pollers, defined in bridges. All of these using the Modbus binding.
Sole of these things are read as a Modbus uint16, some as a Modbus float32.
There are items, mapped to those things. These items have format strings, “%0.1f A”. “A”, because the values are currents, measured in amperes. Current is “Intensité” is French, though it is beyond me why this would matter in the resolution of this problem.
All of the items mapped to a thing with a Modbus readValueType set to uint16 display their unit properly. All of the items mapped to a thing with a Modbus readValueType set to float32 don’t display their unit in the list view.
Please, tell me if you need any more information from me
After looking up the items in the API Explorer (nice tool, did not know about it before), I found out the source of the problem. My format string for all those items was %0.1f, which is valid for sprintf and Python’s format but not for Java’s String.format (specifying the 0 flag requires specifying a padding width). But then, it should have been broken for all items, shouldn’t it? Turns out openHAB silently modifies the format string if you try formatting an integer with %f, so the %0.1f in the format strings of integer items were being replaced by %d, without ever printing an error to the logs. Thus, the integers were working properly. Problem fixed, though I’m surprised that no error was ever printed to the logs about the format string being invalid.
Nope, it does not modify anything. It probably ignores it and moves on to use the default for the item type (which btw you still refused to tell us although both of us asked you for this).
But there’s no proper behavior defined if the input is off spec. Sh*t-In-Sh*t-Out, not a bug.
It would have been if you had set the proper logging detail level.
