Activate / deactivate a rule

new to rules have a couple of basic ones using if / then statements

I have a tesla model 3 and my solar on openhab
When Im not in a rush for it to charge id like to activate a rule to match my charge level to my solar production.

but need to be able to deactivate this rule if in a rush

what would be the best way to implement this ?

thanks Arden

Hello Arden,

you can install the next gen rule builder (

in paper ui you can simple deactivate or activate a rule.

Kind regards,


You might have a switch on your UI marked “In a hurry”.
When your charge rule runs, check to see if the switch Item is on.
You might also want to re-run the rule when the switch changes.


That is like using a sledgehammer for a small brad nail. In my opinion the NGRE system needs more development before it is ready foe beginner use.

1 Like

yes, you’re right. it’s in the development stage.

Nevertheless, it’s right for its application. You can quickly switch rules on and off.

1 Like

But why should he use NGRE for this? (its in developement, and it´s highly limited).

All is required is simple triggers for each situations, just like rossko is saying.

item (solar item) changed or
item (rush item) changed
if rush=ON, do nothing

(simple principal):

My guess is, this rule would be created faster than it takes to activate the NGRE rule builder and create a simular rule in there.

How so? In the old rule engine, you can’t enable/disable rules, so this seems like a perfectly valid solution when asked how to activate/deactivate a rule.

Do you mean the UI rule editor, scripted automation, or both? NGRE encompasses both. The UI rules need some help, which they will get a lot of in OH3. Scripted automation is solid.

It is a valid option, regarding to actually activate/deactive a rule.
But is it really worth it in his situation to actually do it like that? (activate/deactive the rule). In my opinion, it´s not.

At least he got more options now :slight_smile:

1 Like

I view that as part of NGRE and it is beta, bit for the faint of heart in my strictly personal opinion. We agree to differ here.

Well, whatever the choice of rules language, the first hurdle is providing the means of control.

1 Like

It´s a bit pointless creating a rule without :slight_smile:


For a Rule like this it’s fine. It needs more work in the UI before it’s generally useful, but for really simple stuff like this it’s just fine. I don’t think the user would even need to write any code at all for this. Just set up the trigger and add a sendCommand Action to update the charge rate Item. Then in another Rule you can trigger based on the “in a hurry” switch and have the Action disable/enable the Rule. Neither Rule would require hand written code at all and PaperUI is sufficient to set up something simple like this.

I suspect I’ll be writing this reply over an over again in the coming years.

NGRE is super mature and fully capable. There are two ways to write Rules in NGRE:

  1. Previously called JSR223, more properly called Scripted Automation
  2. Through the REST API (e.g. PaperUI)

Both run using the NGRE.

The only part that is immature is the PaperUI part. Everything else is rock solid and ready for use.

Given that OP needs some very simple Rules, even in it’s current state, PaperUI is more than adequate to solve this problem.

Of course, it is not the only way to solve the problem, but it is not a poor choice to solve this problem either.

It’s officially been a part of OH since OH 2.0 or 2.1. The use of the JSR223 languages has been officially part of OH since at least OH 1.6 IIRC. It’s main and only weakness is PaperUI. But PaperUI is not NGRE, it’s just one possible way to build NGRE Rules.

You can decide not to use it, but I think “beta” is a very significant mischaracterization of what NGRE is.

1 Like

In response to this thread I’ve created another design pattern:

You better tell @Kai then. :wink:


1 Like

That is probably an oversight as I saw the Issue and PR to remove “Experimental” from the name quite some time ago. Maybe @5iver remembers better than I do.

Well, code freeze now so I guess it stays in 2.5.

1 Like

I remember a PR to add the experimental logo to the docs, but I don’t recall anything to remove it. TMK, there was no plan to pull it out of experimental before OH3. My understanding is that OH3 will come right after 2.5 and the new rule engine can finally be moved to the mainstream. The rules DSL will be removed or possibly made an optional feature.

I hope made optional. I can only imagine the blow back if it’s completely removed.

Hopefully not removed… I would have to rebuild all my rules then, to something I have yet not understood.


Not removed, no worries.
My hope is to be able to execute the DSL rules on the new rule engine or at least 98% of them :slight_smile: .