After upgrading from 3.4 to 4.0.0 M3 the humidity value reported by my Netatmo Weather station is now a float 0…1 instead of 0…100. While that would be ok, the displayed unit is “one” instead of % or something like it
Any idea where the “one” is coming from? I already tried to add the unit metadata and specify “Percent” as unit.
It looks like you still have a state description, which I believe will override the unit for display purposes. Try removing it.
(I could be wrong about that, as I haven’t moved to OH4 yet.)
Try % instead of Percent.
2 Likes
one is the default unit for Dimensionless, with % and dB being the other two units supported.
You have defined unit metadata but Percent isn’t a valid unit. Use % instead.
2 Likes
Thanks, that was the solution. Interestingly enough I had used in the state description %unit%. I had expected that this should have worked. Without the state description everything looks good now
It actually seem to work with “Percent”. According to the docs “Percent” is the name of the unit and “%” the symbol.
Thanks for all your hints.
Slowly I’m getting frustrated with the unit handling.
I have two items storing humidity. The one item is linked to a channel of a Netatmo weather sensor the other one is populated externally via HABApp.
The netatmo item is displayed correctly when the unit metadata is set to “Percent”. The other item just shows the float value between 0 and 1 although it has the exact same meta data setting
When I add the pattern “%.2f %%” as state description to the items where the value is not displayed correctly it works. That somehow solves my problem. However I don’t understand why I need to add the state description for some items and for other it is sufficient to specify “Percent” as unit
I think you can check with dimmer item and percent type. Such combination should work better with percentage input. There is a logic to convert DecimalType to PercentType and vice versa. Not sure if there is similar logic for QuantityType, but its worth trying.
Overall what you see is an attempt to make UoM handling more consistent. Some of patterns in OH3 which got more or less copied from OH2 lead to suboptimal logic in core which was updated in OH4. I understand it is frustrating, but making this painful switch will reduce amount of surprises in future.
Thanks. I’ve already tested it with some tasmotized devices and it divides by 100. But it does not solve other important issues:
- batterylevel icon only works if percentage is in the range 0…100
- charts are affected too. I expect to see charts showing percentages in the range 0…100 (and not 0…1)
Percentages should have an internal representation in the range 0…100 that’s why I’ve suggested a new UoM
Edit: I was a configuration error on my part, all is ok.
Could you please elaborate on how you solved the problem? My battery icon also doesn’t work with values between 0 and 1. Interestingly, it works in some browsers but not in all. The other values that are between 0 and 100, seem to show the correct battery level icon on all browsers/mobile app.
Here are my item definitions
After defining the item as per above you need to define the metadata
Sometimes you need to refresh the web page so that Unit appears in Add Metadata pop-up
Thanks a lot. That seems to work indeed. =)
I’m really confused with that. I get the load of a battery via MQTT. I set within the channel UoM to %. That is something I do with the same like temperatures.
That is the code:
- id: KuehlschranktuerBattery
channelTypeUID: mqtt:number
label: KuehlschranktuerBattery
description: ""
configuration:
stateTopic: zigbee2mqtt/Kuehlschranktuer/battery
unit: "%"
And this is the result:
I saw some values with 0.98 or 1… So for me the number internal is 1 or less 0.nn and that results that the battery icon is empty. And something must be calculated with 100. That happens when the item is number:dimensionless.
What I’m expect now that the icon show’s a full battery. That didn’t happen. The battery icon is empty. If UoM is set within MQTT settings Basic UI is working without set any unit or state description at meta data setting. The result is an err.
The next interesting fact is now that all my battery’s are in a battery group. The group show this:
For me that is a bug with number:dimensionless and UoM with %! It don’t make sens for me to set any unit or state description within meta data settings. With UoM set to % that must be run out of the box like all other values we have for UoM. And then within UI i expect a full battery icon. Not an empty. That means that the value internal isn’t 100 more then 1.
I’m using Openhab version 4.1.0M1.
Edit: The value of group was a bad setting on my side I found. The group was a number and not number:dimensionless. That’s why i get 1. But that’s wired also. But i found this within UI:
The err in Basic UI will be fixed if I set state description %d %%.
One more thing… If I search my Items I get this:
Why 1?
Number:Dimensionless represents all ratio type units. This includes %, decibels, etc. The default unit is ONE which is just a plain old ratio which is usually a decimal between 0.0 and 1.0.
What value is in the MQTT message? A number between 0 and 1 or a number between 0 and 100?
All that the unit property of the MQTT Channel Config is going to do is slap a % to the end of the value. So, if you are getting 0.5 as the number, the Channel is going to be delivering 0.5 %, not 50 %.
Right, since 0.98 % is less than 1 %. That’s to be expected. That’s an almost empty battery. If MQTT is receiving a number between 0 and 1, it needs to multiply that value by 100 through a transform before it gets sent to the Item, or use the correct unit which, in this case would be ONE.
In addition to the need to multiply the decimal by 100 on the Channel, you must set the unit metadata on the Item to % because the system default is ONE, not %. If the MQTT Channel updates the Item with 50 %, that value will be converted to 0.5 ONE as the state on the Item. So you need to set the Item unit metadata to % too or else your value will be converted right back to a decimal between 0.0 and 1.0.
Number:Dimensionless works just like all the UoM.
-
If there is no
unitmetadata, the system default unit is assumed. ForNumber:Dimensionlessthat default isONE. -
If a state update is sent to the Item without units, the Item’s
unitis assumed. If you send50to an Item withunit=%it will be converted to50 %. If you send0.5to an Item withunit=%you’ll get0.5 %. -
If a state update is sent to the Item with units, the value is converted to the
uniton the Item. If you send50 %to aNumber:Dimensionlessthat doesn’t have aunitmetadata, that value is converted to0.5 ONE. -
The state description metadata converts the value carried by the Item to the unit defined in the pattern only for display. If your Item has a state of
0.5 ONEand you set the state description pattern to%.0f %%it will show50 %in the UI most places even though the Item’s actual state is0.5 ONE. -
The OH battery icon only works with Item states, not units and it only works on values between 0 and 100. A value of
0.98 %or0.98 ONEis going to show an empty battery because 0.98 < 1. Note, this behavior might be better now, I think I saw a PR go across that uses the display state when choosing the icon. But I’m not certain.
So, to get the icon to work as expected:
-
add a transform to MQTT to multiply the value; or alternatively you can set the unit property to
ONE(I’m assuming MQTT delivers a value between 0.0 and 1.0) as that’s the actual unit that the MQTT device is giving you in the first place. -
Set the
unitmetadata on the Item to%. -
Setting the State Description pattern is optional.
It’s not a bug. It’s a combination of using the wrong unit on the value being delivered over MQTT and assuming that the system default for Number:Dimensionless is % instead of ONE. Note, using ONE as the default was chosen by the upstream library that actually implements the UoM capability for OH.
If you fee strongly about it, you can file an issue to change the default to %. I doubt too many are using Number:Dimensionless to represent straight up ratios. OH might be able to do that without changes to the upstream library. But that doesn’t change the other problem that your MQTT channel is configured to deliver the value with the wrong unit.
1 Like
The MQTT value is 100. If i don’t set UoM i get 100 one.
I set Unit meta data % and get this:
I make a rule:
Get this:
[INFO ] [penhab.automation.script.ui.batttest] - 1
I expect now 100%.
1 ONE = 100 %.
The state of the Item is 1 ONE. When the value from MQTT is posted to the Item, it’s converted from 100 % to 1 ONE. On the UI, it’s converted from 1 ONE back to 100 % based on the state description pattern.
Then you need to change the Item’s unit metadata to %. That’s the only way to cause the Item to carry the value as a % instead of ONE.
Note: ONE is the only unit that isn’t printed when using units of measurement.
Thanks Rich for your clarification. I set unit metadata to % but nothing happens. After update of item it set it now as expected.
Yes, I forgot to mention that part. Changes to the unit metadata won’t actually take effect until the Item is updated.