OH3.3.0: The units configured for things for items have ceased to be displayed


After update from 3.2 to 3.3 The units configured for things for items have ceased to be displayed.

UID: mqtt:topic:mosquitto:sonoff_snzb02_dev01
label: Sonoff Temp & Humidity Sensor SNZB-02 01
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mosquitto
location: server
  - id: battery_level
    channelTypeUID: mqtt:number
    label: Battery level
    description: ""
      unit: "%"
      min: 0
      formatBeforePublish: "%s"
      stateTopic: zigbee2mqtt/sonoff/snzb02/dev01
      transformationPattern: JSONPATH:$.battery
      max: 100
  - id: humidity
    channelTypeUID: mqtt:number
    label: Humidity
    description: ""
      unit: "%"
      min: 0
      stateTopic: zigbee2mqtt/sonoff/snzb02/dev01
      transformationPattern: JSONPATH:$.humidity
      max: 100
  - id: temperature
    channelTypeUID: mqtt:number
    label: Temperature
    description: null
      unit: °C
      min: -100
      stateTopic: zigbee2mqtt/sonoff/snzb02/dev01
      transformationPattern: JSONPATH:$.temperature
      max: 100

Units disappeared in all elements of the OpenHub interface: %, С and others

Did I do something wrong? I can add state descriptions for items and display units, but in 3.2.0 it was not necessary to do this. (unit from thing channel)

Did I do something wrong? I can add state descriptions for items and display the measurement IDs, but in 3.2.0 it was not necessary to do this.

What should I do? Is this a bug or an feature?

Displayed where, where are you looking?

You’ve given us an example of an MQTT channel, not an Item. The channel will use the “units” in connection with values it passes to or from any Item, but the Item is separately configured. It’s pedantic, but this sort of detail will matter to identify your problem.

As I wrote earlier. In version 3.2.0, I specified units only in the channel, this was enough for these units to be displayed everywhere.

Absolutely everywhere in the interface (cards, pages, objects) OpenHub formatted the value using units from the channels (if they did not change in the metadata of the state description). For example, humidity of 55% was displayed in all places where OpenHub can display as 55%.
In version 3.3.0, it displays units only on the face of the card in OpenHub → Locations. In other parts (model, items, pages) it just shows 55.

Why do we need units in channels now if they are not used? Should I add value formatting to the item’s metadata (new OpenHub behavior) or am I just having a bug?
And if this is a bug, what to do, where to look to fix it?

In the openhub demo, the metadata of the item is not edited and everything on the model is with units (how it was before the update)!

And now everywhere I have 100 without % battery charge. Before the update it was 100 %.

But for example, the OpenWeatherMap is shown with units out of the box.

The functioning of Units of Measurement in openHAB is very complicated, it’s no use getting cross at it or demanding it never changes. I’ve no doubt that something has changed, because there were issues here and there. I couldn’t say if what you see now is intended or anomalous behaviour until we pin it down more closely.

Stuff that comes into play here;

Some Quantity types have system default units; like Temperature. Some do not have a system default unit, like Energy (used e.g. for kWh).

What that affects is how updates work (and persistence, but we’re not concerned with that here).
If you update a type-with-default with just-a-number, it will assume the default unit.
If you update a type-with-no-default with just-a-number, it will probably fail.

Dimensionless types (usually used for %) are a weird exception here - just-a-number is treated as a ratio, and accepted. Updating with 20 is assumed as meaning 20-to-1 i.e. equivalent to 2000%.

In any case, you can assign a default unit to any individual Item using that Item’s state description metadata. This will either override the system default for that Item, or give it a default if it hasn’t got one.
It’s a bit of a kludge that the same unit metadata is used for display purposes and for the different function of designating a default, but that’s the way it works for now, inherited from OH2.

Why care about default units? Some bindings (like KNX) only update with numbers - they don’t know what unit any incoming value is expressed in. That’s okay, we can assume one from the default.
MQTT binding used to be in the same category - only making number-only updates. The channel “unit” parameter was ignored for incoming data.
So far as I know, this has recently been changed and the given “unit” will now be appended to incoming data and used to update the Item.

When an Item does have a default, updates expressed in other (valid) units will be auto-converted to the default. Say you update with 32F but your system default is C, you will end with 0C actually held n the Item state.

So there’s a bunch of things that can affect what ends up in your Item state.

Separately from that, what gets displayed? In general you get what you ask for, i.e. you see what you have specified in the Item metadata.
But of course Quantity types are more complicated.

Some specialist bindings, like Weather, know exactly what units incoming data is expressed in. So they can “suggest” a suitable default for your Item. When you link to that channel, it effectively sets the Item default unit by forcing metadata e.g. km/h for windspeed.
(This is one of the woolly areas of UoM - what happens if that “suggestion” clashes with something else, like the user’s display choice?)

Some generic bindings, like Modbus or MQTT, can have no knowledge of what is incoming. So they cannot “suggest” Item configuration. It’s up to the user to configure their Item.

You are looking at some combination of these effects. Follow the chain of your problem from end-to-end to see what is not doing what you expected. A good halfway point is to find out what is loaded into the Item state, from log or REST API.

Perhaps this could be relevant to look into:

if you only experience the problem for MQTT channels?

Yes. Only MQTT. But all my sensors work through MQTT )))

I thought I understood well how it works.
I am new to this system, only started with version 3.2.0.
But I am an experienced programmer.
Today updated to 3.3.0. UoM from channels is gone.
Rolled back to 3.2.0 and UoM are displayed again.
I returned to 3.3.0 and they are gone again.
If no one else is reporting this issue, is it a problem with my configuration?
I look at the files and don’t understand.
The configuration is the same, the output to the UI is different.
There is a sensor that just reports a number in the MQTT broker. I create a thing, describe a channel and say that in this channel there are Percentages (Degrees, Watts).
In the model or on the page I saw those UoM that I indicated in the channel.
Apparently in version 3.3.0 it works differently and I have to specify UoM in the metadata.
But I still don’t understand what happened.
No one uses UoM in things channels and everyone uses metadata to display values ​​with UoM?

It was the same in versions before 3.3
If a channel is not indicated ad UoM channel (e.g. temperature), it is dimensionless and you have to declare the UoM in the metadata stateDescription ad pattern (e.g. %.1f %%)
Nothing has changed and I did not have to correct anything after upgrade.

So there was some kind of bug in my 3.2.0 (and it was very convenient), and now it works for me like everyone else (which is very good).
OK. I have added metadata to all items. Four hours and I’m done. Strange of course…

So I should take the degrees specified here as a base value for converting to Fahrenheit (for example), and not for display?


Don‘t know, I don’t have MQTT temperature readings. But as your channel is defined as plain number, it does not have a dimension or unit. You need to transform the value manually.

Now I’ll know, that’s how it works :wink:

My MQTT broker:

i have the same issue,one of my 5 temp/humidity mqtt sensors is giving me the Humidity value as “one”.All the other humidity sensors with the same settings give the right value “%” as the items are all stated as Number:Dimensionless .Only this one is giving e.g “35 one” instead of giving “35%” humidity.Deleted the channel,the item,recreated all ,double checked all the settings but cannot figured it out…

1 Like

Fathers do not believe us. They say that we just came up with. I just added metadata with transformation.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.