Activate / deactivate a rule

Setup, Configuration and Use Scripts & Rules
5

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
7

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.

when
item (solar item) changed or
item (rush item) changed
then
if rush=ON, do nothing
else
charge(ON).
end

(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.

8

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.

9

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
10

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.

11

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

1 Like
12

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

2 Likes
13

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
14

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

15

You better tell @Kai then. :wink:

image

1 Like
16

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.

17

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

1 Like
18

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.

19

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

20

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

2 Likes
21

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: .

3 Likes
22

I agree, hopefully not removed as that would shutdown all my work with OH2.

Rules is all over the place right now, NGRE, Jython, Python, Rules DSL etc etc etc. No wonder its confusing for people.

23

Wow… you guys totally misunderstood me (sorry!). I was meaning the rule engine, not the rules created in .rules files. These will preserved in some way, either through a migration tool or getting them to work in the new rule engine… that is understandably a necessity! But the old rule engine itself is likely to be taken out back,…

1 Like
24

The distinction between the Rules Engine and the stuff you do to create Rules is not well understood by most users. As far as most users are concerned, .rules files are the Rule DSL rules engine. And because you said “rules DSL” which stands for “rules Domain Specific Language” it sounded like you were saying the language was going away, not a change in how the language is executed which, from the user’s perspective, is what is happening.

1 Like
25

I have almost all my rules able to be toggled, as sometimes I want to disable them. I also use the NGRE, but have all the toggles with the rest of my items, in the sitemap, in groups, within a specific frame.

My rules are created as normal, however I have modified the API calls to generate associated items and link those items to toggle the rule state. They are all added to a ‘gRules’ group that I display on the sitemap. For example:

rules.SwitchableJSRule({
    name: "AC-Manager",
    description: "Manages HVAC system",
    triggers: [
        triggers.GenericCronTrigger("0 */5 * * * *") //every 5 mins
    ],
    execute: doExecute
});

You are welcome to use my libraries if you like, even if for examples on how to do it, although they are likely to change in future.

1 Like