OH3 Rule won't run

Screen shot of problem:
Can anyone see or explain why this simple rule refuses to run? It ran fine in OH2.
I have recreated it from scratch in the Rule UI of OH3 and entered the script section into the dsl.rule window.
It is meant to trigger whenever the outside temperature changes and then the script compares the temperature to see if it’s above or below 3 and to set a virtual switch to ON if the latter is true.
I have other scripts running fine so I’m used to the rules engine but they look at items state being ON/OFF.
The virtual switch accepts commands fine, have tried it in other rules. The temp sensor is delivering values in deg Celsius. The temperature item doesn’t have any ‘extra’ metadata and automatically produces the deg Celsius units.
I shouldn’t need to use ‘as Number’ or ‘as DecimalType’ after the ‘.state’ part should I?? I didn’t need this in OH2.
No errors show in OpenHAB log when I manually test run the rule.
Hopefully something obvious/silly I’m missing… :roll_eyes:
Thanks in advance…it’s driving me nuts!


Try adding " | ℃" in your IF statement like so:

if(zwavenode....state <= 3 | ℃)


1 Like

Hi Tom, :clap: :+1: :smiley: many thanks, that worked!
I wouldn’t have found that solution without your help.
Tell me, what exactly does that ‘pipe’ symbol do here? I’ve seen that ‘pipe’ symbol before in Unix/Linux. Why on earth do we need this extra syntax complication?? What has changed since OH2?? The plain arithmetic comparison & number worked in OH2. I hope yourself or someone knows the reason and perhaps the documentation ‘work-in-progress’ should incorporate this. Thank you again

1 Like

Hi Dennis,

I don’t know the whole theory behind it but it has something to do with the unit of measurement. Temperature can be expressed in degrees Celcius and Fahrenheit. So theoretical you could add “|°F” and Openhab will do the conversion for you. The same with distances, measured in meters, kilometer or miles.

Just wanted to chime in and say that I agree. This IS a very strange syntax…

Hi Tom, I see your point. It’s odd that this wasn’t the case in OH2. Is this because in OH2 I wrote rules fully as text files but that now this ‘DSL script’ window is using some other flavoured language? This syntax stuff does my head.
Do you reckon I’ll need to do same for a rule monitoring the status of my Battery group of items? Battery status is normally reported as a %. So will I need " if (battery_group.state < 20) " or will I need " if (battery_group.state < 20 | %) " ? Perhaps its a case when there’s a choice/mix of units being reported, one has to specify the unit in the comparison? Still dunno what that ‘pipe’ symbol does… :thinking: regards,

It all depends on your item definition, if it is just a number (without a dimension) you wont need it. If your item is a Number:temperature you need to let Openhab know what to compare it to. (C or F)

I’m not sure about the pipe symbol, in unix its a way to chain commands and pass output to the next command. In programming a double pipe ( || ) is a synonym for OR.

Oh and I’ve never seen it being used this way before. Maybe its a Java thing?

That pattern seems to make sense about units versus dimensionless. You must be a programmer guru to have tumbled on this solution… :man_teacher: Yes I recall the Unix meaning was something to do with linking/chaining outputs. Amazing that nobody else has stumbled at this syntax hurdle and again why has it only surfaced in OH3 :confused:
Thanks again for your lifeline on this.

Just to summarize a bit.

Units of Measurement (UoM) was introduced somewhere around 2.1 if I recall correctly. Since then more and more bindings have taken advantage of them and more and more units have been added over time.

The purpose of UoM is to give a little more information about a value to include the units. So instead of 75, you have 75 °F. Not only do you have the value, you also know what the value represents.

Now let’s say you have a sensor that only reports in °C? Some of your Items are °F and others are °C and if you want to compare them, do math with them, show them all as °F on your sitemap, etc. you’d have to write a rule to convert the °C to °F. With UoM that’s done for you.

If you want to compare a Number:Temperature to a constant (e.g. > 75) you have to indicate 75 what. °F? °C? °K? You will get very different results if you mean 75 °F from 75 °K. And unless you have a way to tell it what 75 means (the units) how is the rule supposed to know?

So the developers created a syntax for Rules DSL to specify units on a constant number. That’s where the | comes from and its documented at the link Tom provided. The | only applies to Rules DSL. In the other languages you have create a new QuantityType for the comparison. If you prefer, you can do the same in Rules DSL.

So instead of

if(MyTempItem.state >  75|°F)

You can use

if(MyTempItem.state > new QuantityType("75 °F"))

You can even strip off the units of measurement, but beware that what you see in the logs and in your sitemap by default may not be what the Item is actually holding, so you might not get the value you expect.

if(MyTempItem.state.floatValue > 75)

That will work if MyTempItem happens to be holding °F by default. But if it’s actually holding °C the floatValue is going to return a °C number.

It has nothing to do with Unix, Java, or anything else. The developers had to choose some symbol that wasn’t already in use (there are not a whole lot of choices really) to specify that a number has units. They settled on the | symbol.

Because you have to have a way to specify that number is carrying units and what those units are.

Nothing, this has been around for a long time. Perhaps your Item or the binding changed to now use UoM.

Then in OH 2 the Item was not a Number:Temperature and just a plain old Number.

No. If it worked in OH 2 it was because the Item was just a Number and now the Item is defined as a Number:Temperature.

There are many many posts going over this. I think it’s mainly a fluke that you are seeing it now on OH 3 because UoM has been around for years (at least since 2018) and there really is nothing different about it in OH 3.


Hi Rich,

Thanks for that very detailed and clear summary to put things straight. It will be a very good resource for clearing up queries :+1: I wasn’t aware of the UoM, I guess there’s a lot of detail in the documentation that general (novice) users gloss over/miss. You’re right that I got away with it in the OH2 binding because of how the item was defined then as opposed to now.
Re the ‘pipe’ symbol, it is actually also used in the createtimer.nowplus… syntax, just after that 1st timer brace "[ | …do stuff…] :wink: so it’s not unique and that threw me too when I saw it turing up again as a way of handling numbers with units.
Anyway, super clear article, I wish some of the posts abounding were as well written! :+1: regards,