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

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?

TIA

3 Likes

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
}
``````

5 Likes

Hi,

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.

1 Like

Iâ€™ve created a documentation issue for this:

4 Likes

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

Hi!
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`
or
`Item OG_BUERO_ST changed from 4.5|"Â°C"`