Understanding / Avoiding ERE (Experimental Rule Engine)


I am using OH 2.4 runn by openhabian on Rasp Pi 3

Because ERE does not seem to have good documentation, I don’t understand yet the setup.

Usually I succesfully user all my rules in my various text based .rules files.
However one binding I use (volvo on call) introduced a separated action.jar beside the regular jar.


I can see the actions in the ERE in PaperUI:

However, I would like to stay with my regular rules approach using e.g.


Is this possible at all with the separated actions shown in the screenshot above?
I don’t know how to link the action to a regular item to be able to use sendCommand to this item.

Any help is greatly appreciated.

Forgot to search? :grin::


Shame on me.
I just read several threads mentioning that the documentation is not yet ready.
Actually I should have known that @rlkoshak would have posted another helpful documentation.

Thanks @sihui !

1 Like

When those articles are tested and improved a bit, we will move that to the documentation too. :slight_smile:

Rich wanted to start here, so that people can discuss about the contents before submitting it to the docs.

Hi @Confectrician,

makes sense.
I started reading them and for those who would like to start working with NGRE it’s already an excellent piece of documentation.

However, I think a basic information i missing (or I don’t get the point) :wink: :
How to address the “channels” available as an action only from a regular rules like a simple:
CarLock.sendCommand(ON) (Where CarLock is just available in the NGRE PaperUI interface).

I understand, that the PaperUI generated rules are stored in jsondb.

My main point is, that I just want to use regular rules only - and not NGRE, because I don’t have access by a web UI like PaperUI to my system at home and furthermore I very much like to have everything centralized in text based rules.

So is there a way to switch those actions without using NGRE?

Almost certainly. They are not complete yet.

That is one of the parts that isn’t documented well yet. It is where I left off.

If you look at the " Non-core Actions" sections on the fifth page of the docs you will see an example of getting access to the Mail Action using the JavaScript library. I suspect in this case it would look something like


That would actually be pretty easy. Create a Proxy Item and click together a few Rules to trigger the proper Action in the then clause based on when but only if conditions on the Proxy Item.

Then why are you doing anything with the ERE in the first place? The Experimental NGRE is and will always be a way to build Rules through PaperUI (or other tools that may come along). If you just want text based Rules you either need to stick with Rules DSL or use JSR223. If you use JSR223, your Rules will be running on the same engine as the NGRE but they are not defined using a UI and are stored separately. They also require more work for you to define the Rule code and such.

1 Like

I’ve been doing a lot with Jython and JSR223 lately for some “heavy-lifting” stuff. It was a pain to get it going reliably, but the latest installation doc on the jython-scripters repo is MUCH better. I have parallel implementations in DSL and Jython for some critical complex stuff. Jython is considerably shorter LOC and MUCH faster execution. (Meta-framework doing causal path detection and metrics to find automation opportunities and measure action path utilization.)

Thanks, Rich.
That’s exactly the point.
I actually don’t want to use ERE at all.
My problem is, that the action binding of volvo on call just provides actions for ERE.
The only place I can see them is the ERE environment.
So how to trigger (switch by sendCommand) these actions without ERE.
Sorry for beeing imprecise.

NGRE should also be shorter (as far as what is exposed to the user) and since it runs on the same execution engine will run faster as well.

In fact, NGRE should be shorter than the equivalent JavaScript JSR223 as you don’t have to create the rules and triggers in Script itself. You only end up writing the “body” of your Rule. Of course that does come with the drawback that you have to point/click/select all the other parts of the Rule together in the GUI. Yannick has started a really awesome GUI for building Rules that I hope he can get back to which will give us a NodeRed like GUI for Rules building.

I don’t think that is even possible. OH 2 handles Actions completely different from OH 1 and there is not a separate jar file for OH 2 Actions.

What you need to do is look at the docs for these Actions to find out what the method names are and what arguments they take. You will not be using sendCommand with Actions. Actions are function calls in Rules DSL. Some Actions you may be familiar with

  • sendCommand("ItemName", "Command")
  • postUpdate("ItemName", "Command")
  • executeCommandLine("command", 12344)
  • sendHttpGetRequest("url")
  • createTimer(now.plusSeconds(1), [ | //some code ])

You will have functions to call along these lines. What they are and what arguments they take will come from the documentation for the Actions. I can’t begin to guess what they might be. I don’t know where these jar files came from. Look there for docs.

Thanks again Rich.
I guess it’s too early for detailed docs for this binding.

This excursion definitely helped me to get a better understanding of the handling.
I will start to play around with the action by trial an error if I can find out more.

I really appreciate your help!

Actually, with this volvo binding, there is a seperated actions jar. I started looking at that repo but it was too late in the night to fully understand what was going on there.

What I was referring to is that there is a new mechanism for how Actions are made available for new OH 2.x bindings. In this case, the Binding itself will provide the Action and it doesn’t need to be installed separately. But accessing the Action is handled separately. See https://www.openhab.org/addons/bindings/mqtt.generic/#rule-actions for an example.

To my knowledge the MQTT 2.4 binding is the first to use this approach.

Thanks, Hakan.
That’s right and it took me a while until I even recognized that there is another jar