OH3: Semantic Model, units question

[nigel_magnay]

So I’ve been using OH for a number of years, and started playing with OH3, which looks a great update.

However, there’s a few bit’s I’m not clear on. For example - I have a temperature monitor delivering over MQTT. So, I have a Bridge, Thing and Channel:

Bridge mqtt:broker:haus "Haus MQTT Broker" [ .. ] 
{	
	Thing mqtt:topic:boilermon "Boiler Monitor" {
		Channels:
			Type number : feed_house [ stateTopic="/boilermon/temp/28FFB80C9215043E" ]
         ..... 
}

And a corresponding item

Number Temperature_Boiler1 "Feed House" ["Measurement", "Temperature"] {
	channel="mqtt:topic:boilermon:feed_house"
}

This all works great - I see a “Temperature” block in the Properties UI, I click it, see the feed temperature… but: no units. The documentation [https://www.openhab.org/docs/concepts/units-of-measurement.html#quantitytype] says the default metric for a temperature dimension is Celsius, and Kelvin as also supported (but not Fahrenheit?)

So I try to guess at how to override that. Adding unit="K" to the item definition does… nothing. However, adding it to the feed_house channel… does work.

This is confusing to me for a number of reasons:

• surely it’s the item which is, semantically, the measurement and property(temperature)? The channel might be specifying some other unit, and I may have had to perform a transformation within the item in order to normalize it to degrees C.
• I seem to be able to specify any bit of text I like; “K”, “F”, “Blagh”, makes no difference. I was expecting to only be allowed to specify one of the two supported temperature types (so the system could reason about the units in use).

Secondly, I think I was expecting the semantic tags to “type” additional metadata. So, for example, if I tagged something as a location type “Floor”, there might be an additional declared field of ‘floorNumber’ that I could set. Similarly if I had a property of type ‘temperature’ I was expecting to have a unit property of ‘unit’ from a controlled vocabulary, defaulting to celsius if not specified. The UI could then perhaps add editing for that metadata because of the semantic classification.

Similarly I have items tagged as Voltage, which don’t seem to be displayed as dimensionless, which seems a shame given that ought to be a safe default.

It’s possible I’ve just missed something, or this isn’t finished yet, or I’m wildly off track?

This also feels related to profiles, which feel like a soft-subtyping of item types, where the tagging is extending functionality as well as properties. Kind of like a subtype of the “Equipment” subclass “wallswitch”, making me think “wouldn’t it be nice to be able to subtype these things at runtime” ?

[rossko57]

You may not yet have come across Item definitions like Number:Temperature to represent quantity values.

That supports three units by the way - C F K

[nigel_magnay]

Ah, thanks, I hadn’t noticed that part of the description. But the observed behaviour to me looks even stranger!

Firstly, if I tag an item with temperature like this:
Number Temperature_Boiler1 "Feed House" ["Measurement", "Temperature"] {...}

It appears in the “Temperatures” collection in the properties view UI. But if I set it as a temperature as a unit, e.g:

Number:Temperature Temperature_Boiler1 "Feed House" ["Measurement"] {...}

Then it doesn’t. ISTM that these both ought to be semantics for “this item here, it’s a temperature”.

If I set my things to use a unit like K, with a unit:
Type number : feed_house [ stateTopic="/boilermon/temp/28FFB80C9215043E", unit="K"]

I can override the display of any of the items by changing the text
"Feed House [%.1f °F]"

But I can put any old rubbish there, °Foo and it’s just as happy. No conversion ever takes place, even though the “unit” is declared for the MQTT channel (either as °C or K).

If I look at the Items list in Admin>Settings>Items, I get a very different picture:

Items not defined as Number:Temperature are displayed as completely dimensionless on the list. But if you click them to the page, it’ll use the unit from the thing, or the display string [%.1f °F] - although still no conversion has happened.

Putting the unit within the Item definition (e.g { ... unit="°F" }) seems to have no effect. Now I assume that it’s only operating based on “the formatting that I find within square brackets within the text description of the item”, but that seems a touch convoluted? Why can’t it just take a unit setting just like the channel does? And maybe a “number of display significant figures”, or whatever other things might be of use?

[rossko57]

I don’t know what collection view you are talking about, I don’t use PaperUI much. I wouldn’t expect Items of type String to appear in a collection of stuff tagged string, though.

Adding units to an MQTT channel of type number still leaves them as channel type number. There is no Quantity Type channel in the generic MQTT binding as it stands.

Bindings such as zwave fully implement Quantity type channels, and auto conversions work.

Putting Item related units in the [presentation] part of an Item definition is clumsy. It’s an add-on task to a place where people were already putting units for display of plain numbers, before Quantity Types were incorporated into OH2.

Careful with term dimensionless, in openHAB a Number:Dimensionless is a valid Quantity Type, with units (like %)
% is actually a good example of units not being the same as practical meaning. Are you talking humidity or dimmer brightness or fill level of a water tank or …

[ysc (Yannick Schaus)]

@nigel_magnay

Firstly, if I tag an item with temperature like this:
Number Temperature_Boiler1 "Feed House" ["Measurement", "Temperature"] {...}

It appears in the “Temperatures” collection in the properties view UI. But if I set it as a temperature as a unit, e.g:

Number:Temperature Temperature_Boiler1 "Feed House" ["Measurement"] {...}

Then it doesn’t. ISTM that these both ought to be semantics for “this item here, it’s a temperature”.

You actually need both

The Number:Temperature item type specifies that the item is a quantifiable number expressed in degrees (Celsius or Fahrenheit or Kelvin, and you can convert between them if you wish), whereas the semantic tags “Measurement” & “Temperature” specify that the item is related to the “notion” of measuring a temperature.
I know it seems redundant, but there’s no way now to relate these two things, you have to be careful and thorough and specify both the semantic tags and the dimension (the :Temperature part of the item type).

[nigel_magnay]

So this is OH3:

Here the items in “Temperature” are only the items “tagged” as temperature, and not (for example) items defined as Number:Temperature. I think that’s bad, and makes it feel like the whole semantic model is a bolt-on which makes the new UI very complicated but isn’t fully committed to in the actual system. Which is a real shame.

Adding units to an MQTT channel of type number still leaves them as channel type number. There is no Quantity Type channel in the generic MQTT binding as it stands.

That’s confusing: Looking at MQTT Things and Channels - Bindings | openHAB, I can have a channel type of number that defines a unit of measurement. Are you saying that this doesn’t have any effect?

[nigel_magnay]

I know it seems redundant, but there’s no way now to relate these two things, you have to be careful and thorough and specify both the semantic tags and the dimension (the :Temperature part of the item type).

Well, IMO it seems a bit more than redundant - it feels like the semantic model is an afterthought, and there’s two streams of code trying to solve, fundamentally, the same thing.

As a user, I’d expect a “Number:Temperature” literally define “this thing here is a temperature” without having to additionally tag it. I can’t think of any scenario where I wouldn’t want that to be equivalent?

I’ve used OH since v1, and I have software experience with both ontologies (OWL) and OMG MOF, and to be honest it took me a while to comprehend the semantic model and OH3 UI (particularly stuff like this, which I suspect a new user might find challenging:

ISTM that there’s going to be a lot of confusion, and if there’s currently “no way to relate these two things” then that really ought to be fixed as we’re going to get lots of confused users wondering why temperatures don’t appear under… temperatures!

[rossko57]

@nigel_magnay

Here the items in “Temperature” are only the items “tagged” as temperature, and not (for example) items defined as Number:Temperature . I think that’s bad,

I think you misinterpret the usage.
That’s easy with Temperature, because the amount of different ‘things’ one can measure with “temperature” type units are limited.
But even there, it is used for e.g.indicating a setpoint, a target temperature for a thermostat. Would you expect that to appear in a collection of ‘temperatures’?
I wouldn’t - it’s not any measurement of any real temperature, it’s a notional target.

Consider an Item of type Number:Dimensionless
These can be expressed in units like %, db, ratio.
Would you expect all such Items to appear in a list of ‘humidity’? Or ‘cloud cover’? Or ‘rollerblind position’? It’s going to get messy.

Number:Length might tell you how far your spouse is from home, or the depth of water in your tank, or how far the automower has travelled today, etc.

[nigel_magnay]

But even there, it is used for e.g.indicating a setpoint, a target temperature for a thermostat. Would you expect that to appear in a collection of ‘temperatures’?

Well, actually, yes - I would. And I would expect it to contain different sections depending on how the point itself had been tagged (which the OH model covers for your examples by allowing “Setpoint” and “Measurement” as distinct types).

Which - coincidentally - exactly what the UI in OH3 actually does

I click the box with “10 temperatures” (in the properties view, see earlier post), and it pops up with those 10 items in more detail, subdivided into sections by the point type - so all the measurements are together, and all the setpoints are together.

Consider an Item of type Number:Dimensionless
These can be expressed in units like %, db, ratio.
Would you expect all such Items to appear in a list of ‘humidity’? Or ‘cloud cover’? Or ‘rollerblind position’? It’s going to get messy.

Well, no I wouldn’t, because there isn’t an obvious mapping through to a property type there defined in the semantic model.

But many are. Temperature is, Pressure, Energy, Power, Pressure.

To take another disappointment - the semantic model defines a point type of Voltage (which is not only a measure of potential difference, but it’s constrained us to a single type of unit). I can tag my items as ["Measurement", "Voltage"]. This is sufficient to place them in the “Voltage” section of the properties UI. But:

Notice how the measurement has no units. Nothing in the UI acts on this semantic data - the graphs don’t have the correct units, adding cells to the UI layout doesn’t label the value just shows ‘244.79’ not ‘244.79 V’ (and I can’t override the display from what I’ve seen so far, let alone the UI be able to understand 'this is an SI unit, so if there’s not enough space to display 12809.99 kWh, I can go to the next unit up and show 12.8 MWh)

Which feels a bit of a shame.

[Getting Started with OH3: rewriting the tutorial - 6. Model your home with Items & link Channels]

[rossko57]

@rossko57

Adding units to an MQTT channel of type number still leaves them as channel type number. There is no Quantity Type channel in the generic MQTT binding as it stands

Because MQTT is a generic binding, there is no way for it divine what any given incoming message means. There is no standard for a device for a device to say “this number represents a current and is expressed in milliamps”.

This is different from say zwave, where the binding can recognize a particular make/model device and "know’ that channel 22 is humidity expressed in percent.