I gave up on OH 2.3 Unit of Measure (UM)

Tags: #<Tag:0x00007f617edc5370> #<Tag:0x00007f617edc5280> #<Tag:0x00007f617edc50a0>

I basically decided that using units of measure might be a good idea but not for me. For the last 2 days something that should be as easy as evaluating in a rule if the temperature outside is higher than a set threshold became a saga of frustration and trial by errors.

The problem root cause was that the temperature item was defined as a Number:Temperature type and I could not find an easy way to strip the UM from the item state in order to evaluate it against a plain numeric value.

So in the end I thought that I really don’t need this aggravation eating my free time and do what I used to do prior to 2.3, meaning getting and storing the temp sensor results as simple numeric values, which makes everything much simpler in rules and using the sitemap to format the temperature symbol. It works perfectly well that way, but that’s probably because I’m an idiot.

Can someone explain to me why do I really need UM in the items definition and if I really need it, how can I strip the extra text from the item state so that something as simple as deciding if 25 is really higher than 20 will not become a chore?



Did you try using Your_Item.state as Number in your rules?

I tried. You can’t use this method because the results are stored as text with the centigrade symbol.

How are you getting the outdoor temp in OH, what binding or sensor is used?

It’s a netatmo weather station. When UM are active the result might come as 30.12345678 ? (? being the symbol for Celsius). This is stored as a text and good luck trying to revert it back into a numeric value.

Well, you don’t need UoM, but it would ease some stuff:

  • automatically change from e.g. “1500 mA” to “1.5 A”
  • automatically change from Fahrenheit to Celsius or Kelvin
  • use metric sensors in “imperial” regions and vice versa

to get the value without the unit, just use

(My_UoM_item.state as QuantityType<Number>)
1 Like

Yo are right, I don’t need it if it turns simple tasks such as deciding if 25C is higher than 20C into a chore. Other who might need to decide if 25C is higher than 68F might find it interesting but I’m not one of them and I seriously doubt this kind of calculation is performed more often than mine.

I discovered yesterday that I have the same problem after I changed my items a few daays ago.

With @Udo_Hartmann post I think I fixed my rules now.

But I had to append .doubleValue.

So Instead of SunAzimuth.state I now use:

var SunPositionAzimuth = (SunAzimuth.state as QuantityType<Number>).doubleValue

Don’t give up and strip off units! Just use something like:

if (TemperatureItem.state >= 20|°C) {
    // insert code here

See also Scripts & Rules in this Eclipse SmartHome blog.



I just implemented UoM in my binding and like it a lot (Home Connect addon: Looking for beta testers). The binding is fetching values from a cloud service - The problem is that this API is able to return °C or °F values. With UoM I can easily process the values, regardless of the passed unit.

Another point I like is the unit conversion. The following example is converting seconds to minutes: Text item=GeschirrspLer_RemainingProgramTime label="Restliche Programmlaufzeit [%d min]" icon="time".

Heres a example of evaluating UoM states in rules:

        var power = Waschmaschine_Leistung.state
        if (power < 0.2|"W") Washingmachine_OpState.postUpdate(MODE_OFF)
        else if (power > 9|"W") Washingmachine_OpState.postUpdate(MODE_ACTIVE)
        else if (power < 4.4|"W") {

I think I tried that too and it also didn’t work. The thing is that I’m using and playing all the time with OH because it’s my hobby and hobbies are supposed to be fun and educative.

Struggling with UM was neither of them, so while I appreciate the argument of Udo, that UM have some value for converting units, it’s a value that is completely irrelevant in rules where it just add a layer of complexity.

If you don’t like units. AFAIK UoM is backwards compatible.
So when you define your items you could also try using Number instead of Number:Temperature

1 Like

Which is exactly what I did in the end.

But in case you didn’t notice this backward compatibility isn’t obvious. When 2.3 was released the UM were presented in such a way that I believed it was mandatory to define an item with temperature as Number:Temperature.

1 Like

I think this should be mentioned in the docs.

It would be really usefull for everyone who reads that page.
Especially with some examples.

But thanks for that link anyway. :slight_smile:

I’ve created a documentation issue for this:


Just came accross this yesterday. Using *state as Number used to be enough even with UoM
But since a recent snapshot, the *.state as QuantityType<Number>).doubleValue as become mandatory.
Any change to revert back to what it was. Much easier for everyone, especially newbies.

1 Like

I’m stuck with the UoM’s. I have a rule that reacts when a thermostat is changed from a certain temperature.
Since the UoM’s is no longer “4.5” but “4.5 ° C”.
Here is my (old) rule:

 when Item OG_BUERO_ST changed from 4.5

How do I catch that?

– Christoph

My solution was to strip and delete all the UoM from the items definition which brought back the simple report of numerical values only. I found UoM to be a pain in the butt to deal with and completely unnecessary for my purposes.

1 Like

This can be a workaround but not what I want. I’m sure the developers have thought of something and also a solution for it. Unfortunately, the documentation is not (yet) the best. Generally I would like to use the UoM’s.

– Christoph

Have you tried
Item OG_BUERO_ST changed from 4.5|°C
Item OG_BUERO_ST changed from 4.5|"°C"