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

Setup, Configuration and Use Scripts & Rules
, ,
5

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.

6

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
7

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.

8

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
9

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.

5 Likes
10

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") {
11

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.

12

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
13

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
14

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:

1 Like
15

I’ve created a documentation issue for this:

4 Likes
16

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
17

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

18

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
19

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

20

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

21

It’s not really a workaround IMHO because this is the exact way OH behaved before 2.3.

I’m probably a vocal minority here who thinks that UoM is a BAD idea. It’s absolutely not needed in sitemaps, it’s purpose of having automatic conversions is rarely necessary and when it does it’s trivial to accomplish without UoM. On the other hand UoM will cause every single rule to fail unless every state is specified as a number quantity.

3 Likes
22

Hi,
yes I tried that

 Configuration model 'heizung.rules' has errors, therefore ignoring it: [74,34]: mismatched input '|' expecting 'then'

Was my first idea :wink:

– Christoph

23

I’m torn. Maybe that’s a good idea, but maybe not.
We will see how this evolves.

– Christoph

24

I’m having troubles with implementing UoM as well. :roll_eyes: Quick question: Is this supposed to work or am I doing something wrong? I am trying to do calculations with gas consumption, which is in cubic metres.

rule "Test"
when
    System started
then
    val n = 5|m3
end

The expected warning about the unused value aside: I’m getting a:

[ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Test': unexpected token 8

Putting the cubic metres in quotes doesn’t help. Other units like “W” or “week” work just fine.

I’m on 2.5.0.M1 but 2.4.0 produces the same result.

Thanks a lot in advance for any input!