Since openHAB version 4.1.0 I have the problem that the humidity is no longer displayed correctly. Instead of 60%, it now says 0.6%.
It affects all sensors. Is the problem known?
Have you tried setting the unit metadata to %?
First, make sure the item type is Number:Dimensionless. If not, edit and change it
Next, go back out and back in (so the change in the item type takes effect on the browser) then click Add Metadata
Then click Unit
Then enter % in there.
If you are using file based .items, the method is different. If you go here and search for “Rainfall” on the page, you’ll see how to set the unit Units Of Measurement | openHAB
Try adding “State Description” metadata and enter %.1f %%
value: " "
config:
options: “”
pattern: “%.1f %%”
would it be correct like that?
If yes, also no change.
Could you post the yaml code please?
My mistake. I think you need to remove the unit metadata. Setting that to % is wrong.
Just put the type to number, not number:dimensionless and delete the unit metadata. Then use state description metadata and place %.1f %% in the pattern field.
What value is being sent to this Item. Is what ever us updating this Item publishing 60, or 0.6?
As I understand it, if it’s sending 60, adding the unit metadata should have been the fix. Note that it won’t apply the new unit until the next update. It doesn’t change the current state of the Item.
I suspect it was sending 0.6 in the first place. that’s the value it was showing when he first started. My suggestion for unit=% was wrong, mainly because I don’t fully understand how unit works! 
As I understand it it works like this.
First of all, state description only changes how the state of the Item appears in some places in MainUI. It no longer has any impact on the raw state of the Item.
If an Item has a unit metadata, what ever value is sent to it gets converted to that unit (see below). If the Item does not have unit metadata, the system default is assumed to be the unit. In the case of Number:Dimensionless the system default is ONE (I’m not really sure what ONE actually is or why it’s the default, I think it’s a simple ratio). To convert from ONE to % multiply by 100.
The rules:
| Update | Item State | Example (assumes Item unit is %) |
|---|---|---|
| doesn’t include units | Item units are applied to the number | 50 => 50% |
| includes same units as Item units | Nothing changes | 50 % => 50 % |
| includes different units from the Item units | Value sent is converted to the Item’s units | .5 ONE => 50 % |
| includes different and incompatible units from the Item units | doesn’t change, error generated in the logs | 50 °F => error |
So if you define unit=% on a Number:Dimensionless the Item will always carry a % as it’s raw state. If the binding doesn’t send a value with units, the value just gets the % tagged on to the value. If the binding does send a value with units, the value is converted to %.
That’s why it’s important to know what the binding is actually sending. If it’s .6 without units, adding the unit metadata is just going to tack a % on to the value so a transform to multiply by 100 will be required. If the binding is sending 60 %, something is wrong and we might need to file an issue.
@rlkoshak I understand what you mean. Where can I check or see what value the binding “livisi” passes?
Small addition: The problem exists only recently, when I updated to 4.1.0. Before with all versions of 3.* and also with 4.0.2 the values were always correct, without that I had to adjust something.
Since it worked in 4.0.2 the problem has to be something new in the binding or in core. the UoM stuff was added in 4.0 and there have been no changes since then.
One way to tell is to link the Channel to a String Item and see what it gets set to.
It should also be in the docs for the binding readme but not all bindings do so.
If the Channel type is just a Number instead of a Number:Dimensionless we can confirm that it’s delivering a raw number without units.
PMFJI I experienced/had the same situation. I do not know exactly with which concrete version of 4.x it happend, as I upgraded unintentionally as some others did (different story), but from my Homematic outdoor thermometer/hygrometer I saw in the logs, that there were values like 0.nn:
2023-09-11 09:59:18.274 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'OThermoHygrometerEingang_Humidity' updated to 0.87
The item is a number:dimensionless and without a state description it is displayed on the item page as 87%
But going to the analyse page a graph is drawn with values as 0.nn. Same in HABpanel. Adding a state description like %.1f %% I get a value of 88.0% on the item page as expected, but there is no change on the analyse graph or in HABpanel.
I changed the item to a number and it seemed that this made things worse as I then got the 0.87 also on the item page.
The funny thing was, that I followed your hint to try to change the item to a string. This resulted in a NULL, but getting back to number:dimensionless I got a 8700% value. So I tried number again, saw the 0.87 again for a moment on the item page, but then it switched to 87 the next moment, and the graph now also showed a 87 value and also in the log and in HABpanel everything works fine now, including the use of the state description. It seems that you really have to have a number item, and that you simply have to wait for the next value from the device to see that this works. If you do not wait for the next value it seems that things are still wrong.
Changing the type of an Item does not change the state of the Item. Indeed you have to wait for the next update.
However, no you don’t need a Number. As discussed in the breaking changes for OH 4, the way units are handled has changed significantly. The Item requires unit metadata. Without unit metadata the system default unit is assumed which is ONE for Number:Dimensionless.
Whenever a state update is sent to the Item, if that state update has units, the state update is converted to the units of the Item. In this case, the binding is sending 87 % which gets converted to .87 ONE.
I must admit, it works as Rich says ( in OH 4.1).
Yes, you are right. I did not wait long enough after switching to number:dimensionless when I saw this 8700. With the next value and the unit % as an additional meta data it works, too.