Non-dimensional / discouraged / not permitted in future versions of openHAB

1

First, thank you so much to the folks that have worked so hard to make OpenHAB a reality. I’ve tinkered with this software for several years, and I’m always amazed at the ability to customize things just-so.

Also, I think the updates to Unit of Measurement are great. I’ve fought some of the dragons that are outcomes from not having this as a feature. Thanks to those that have taken the time to work through the nitty-gritty details to making this feature work. Thank you!!!

I’m working through my textual config Items files for Number configurations and applying the appropriate Units of Measurement. Great!

There are a few case where I’m soliciting the proper configuration.

For my garage open opener, here.

In the write up there, one of the channels is a “Barrier State” which is represented by a number, and the number relates to a current item state, which can get translated by a translation table.

Status values are:
0 = Closed
252 = Closing
253 = Stopped
254 = Opening
255 = Open

In my mind, these numbers are pretty dimensionless, and don’t follow under any of the existing Units of Measurement page. What is the appropriate dimension to add to the Item text configuration?

Number:<what_goes_here> F1_Garage_Door_Position { unit=<what_goes_here>" }

For my weather, I’m using the OpenWeatherMap binding here.

One of the items is uvindex. The appropriate Unit of Measurement is

Intensity Irradiance W/m²
Intensity Microwatt per square Centimeter µW/cm²

And while technically this is very correct [here], where the uvindex is a number that when multipled by 25 provides the irradiance number is mW/m², the irradiance number is meaningless to the wife unit. And so, functionally it seems like I’d have to transform into the mW/m², use the persistence store, and then transform it back to a UV index on display. Maybe I’m just lazy, but it seems like it’s just an index number with no dimension, and I should be able to store it with Number:Dimensionless

Anyways, I am seeking an answer to my question, but I’m also seeking to understand a bit better the strongly worded documentation:

Linking dimension channels to non-dimensional items is therefore discouraged and will not be permitted in future versions of openHAB.

I’m all for the “strongly discouraged” comment, but not permitted in future versions?

Sometimes a number is just a number (index value, position, state, etc) that doesn’t really have a Unit of Measurement. What gives?

Appreciate the insights!

Again, thanks so much for make this feature!

sixo

2

You’re correct, your two items (F1_Garage_Door_Position and uvindex) are just Numbers not Quantities.
Number is different from Number:Dimensionless (like e.g. % or dB that holds a Unit). Be it numbers or quantities they can be stored by the persistence service.

3

So is the documentation for OpenWeatherMap correct?

Number:Dimensionless localCurrentUvindex "Current UV Index [%.1f]"  { channel="openweathermap:onecall:api:local:current#uvindex" }
4

No, I think this is a mistake in the documentation of this binding.
Especially an error in the example because in the channel definitions we find :
| current, forecastTomorrow, forecastDay2, ... forecastDay7 | uvindex | Number | Current or forecasted UV Index. |
If you take a look at openuv binding :

Number              UVIndex   "UV Index"  { channel = "openuv:uvreport:local:city1:UVIndex" }

Apparently fineoffsetweatherstation and wundergroundupdatereceiver makes the same mistake. We could image defining a system channel for UVIndex so we unify handling of this data amongst all bindings.

5

I created a pull request for this here

6

None. Not all numbers have dimensions.

Dimensionless doesn’t mean no units. Dimensionless is the unit for all ratios. So simple ratios (i.e. ONE), percentages, and decibels as well as complex ones like you have here.

Also note that units can be the result of a calculation like µW/cm² and are usually calculated on the fly. Have you tried just using mW/m² as the unit metadata? Whatever your OWM is sending should get converted before the Item is updated automatically and then you don’t need to adjust anything. You’ll have your desired units from the start.

UoM supports combining units it already knows like this. Though I would expect this to be a Density instead of a Dimensionless.

Maybe I don’t understand the root problem.

But I’ll reiterate what @glhopital said, if you don’t want or don’t have units, don’t use them and have plain old Number Items. A Channel that says it uses units linked to a plain Number will have those units removed before the Item is updated.

Where is that. That statement is no longer correct and needs to be corrected.

While it can be dangerous to change the units as your persistence data will no longer be of the same unit and scale, it’s perfectly allowable and it’s a big reason why the changes to UoM were made in OH 4. You are not forced to use units if you don’t want to nor are you forced to use the units the binding author is publishing in updates, regardless of what the binding author chooses. You can choose a different compatible unit or no unit at all.

7

From my phone. I apologize for the brevity.

Number item without dimension and QuantityType

A QuantityType state update or command to a non-dimensional Number item will result in a state update that consists of the numeric part only. So updating a Number item with 5.0 kW will set the item’s state to 5.0, updating the same item with 5.0 W will also set the item’s state to 5.0. Linking dimension channels to non-dimensional items is therefore discouraged and will not be permitted in future versions of openHAB.

8

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