Experimental Next-Gen Rules Engine Documentation 1 of : Introduction

Thanks for the links and info. That helps a lot.

You probably wouldn’t know the answer to this but are you aware of any reasons why triggering a Rule by updates to a Group wouldn’t work? I can trigger a Rule all day on changes to a Group and I get the GroupItemStateChangedEvent. However, if I use an item updated trigger nothing happens.

It’s probably a problem with the JSON Rules and not something you would have seen but just in case this is a known bug or something like that…

This issue sounds like it fits your description, and I feel it is related to this one, but I’m still absorbing the response from Henning.

All of the ERE issues should have an Automation tag, but you’ll find more that haven’t been tagged yet by just searching for automation.

1 Like

Great resources. I’ve added my two cents to the two issues.

For the second issue I agree it feels related.

I can see Henning’s argument somewhat as the source of the update . But since PaperUI Rules don’t yet support Member of triggers, assuming that Group update triggers worked, we would be stuck back in the bad old days of using the persistence hack to figure out which Item caused the update.

Ideally the “correct” solution would be to get Member of triggers added to PaperUI Rules but I haven’t had a chance to explore triggers deeply yet so I don’t know why they are not already there or how hard it would be to add them.

Heads up… looks like you will want to grab a new build before diving into templates.

Templates could help a lot in early adoption by providing workarounds for gaps in UI functionality, but also by providing the ability to add a complex but standardized rule that only requires a few clicks to setup. I can see templates being setup with rules that follow each of the DPs. Even default templates included in the distro. Would be awesome to get one in before 2.4.

1 Like

Thanks, once I get the Actions documented I’ll look at Templates next. The more I’m learning the more I’m excited about the ERE. If we can fill some of the gaps (Member of triggers) and get Yannick to work on his ERE UI again this is going to be awesome! Node Red ain’t got nothing on us. :smiley:

It isn’t super clear to me yet what Templates are. My first thought was to build a version of lewie’s library as a template so we don’t have to download and separately maintain it. It would be pretty freaking awesome if all those convenience methods were just there for those who want them.

I like the idea of using some of the DPs as templates too. Especially the more stand alone ones like Time of Day or Motion Sensor Timer.

I feel like I’m starting to understand how this works from a scripting perspective. It’s now more just the tedium at this point of documenting each and every thing that people will want to/need to do to transfer their Rules from Rules DSL and finding more JS native ways to do some things and work arounds for things that are lacking.

The lack of global variables is a big hole right now that is unique to PaperUI created Rules. Without them timers and storeStates/restoreStates are all but useless. I can only do so much with Item metadata. I know that isn’t a problem for regular JSR223 Rules.

ERE Rules don’t use up threads in the Rules threadpool, right? Do you know of any limit or problems if we flip the usual recommendation and push using sleeps instead of Timers? Of course there is the Expire based timers, but that will increasingly become awkward as there remain fewer and fewer critical 1.x bindings like that. And because each Rule lives in isolation it means the code that occurs when the Expire timer goes off will be completely separate from the Rule(s) that set the timer. I’ve thought about giving it a go to build a 2.x version of it but I can’t figure out how that would work as a 2.x binding. I don’t want to have to create a separate Thing or Channel for each Item that needs to Expire.

I’m rambling. Thanks for feeding me all this good info. It has been a tremendous help.

1 Like

Correct… I know I’ve posted some examples with logs somewhere… here’s one. There is one difference with the Rules DSL that I’ve noticed, which people need to be aware of. Only one instance of a rule can run at a time, so the rule cannot be triggered again until the first instance completes. Just think of each rule as having its own threadpool with size of 1. Or that each rule has its own thread. I do not know if this should be considered a bug, as it has both good and bad side effects.

Make a rule with a JS Action that sleeps for 5s, then logs. Then trigger the rule quickly several times. There will be a 5s delay between each log.

from org.slf4j import Logger, LoggerFactory
from time import sleep
from openhab.rules import rule
from openhab.triggers import when
log = LoggerFactory.getLogger("org.eclipse.smarthome.model.script.Rules")

@rule("Test delay")
@when("Item Virtual_Switch_1 changed")
def testDelay(event):
    log.debug("Test delay: start")
    sleep(5)
    log.debug("Test delay: stop")

2018-11-08 17:49:05.577 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start
2018-11-08 17:49:10.578 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop
2018-11-08 17:49:10.579 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start
2018-11-08 17:49:15.580 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop
2018-11-08 17:49:15.580 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start
2018-11-08 17:49:20.580 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop
2018-11-08 17:49:20.581 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start
2018-11-08 17:49:25.581 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop
2018-11-08 17:49:25.582 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start
2018-11-08 17:49:30.582 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop

It should be possible to use globals in JSR223-JS, I just don’t know how to do it… or if they would be accessible through the JSON rule Actions. I just did some research on it, but I shut it down since I would prefer to put the effort into adding Jython scripts to JSON rule Actions.

I’m currently down and out with what appears to be a flu, so plenty of time to look at things… but not much comprehension possible, ATM. Although, I did have a thrilling conversation with some JS code earlier today! Coding fever dreams are my fave… makes them somehow slightly less trippy.

Templates are JSON. Here is a template with a JS Action that you can play with JS_Action_template.json (1.2 KB). (Wow… the forum takes .json files!). I couldn’t figure out what directory they are to be stored in. Copying to /conf/automation/templates/ did not cause them to show up. I ended up importing from a URL through Karaf (automation importTemplates http://localhost:8080/static/templates/JS_Action_template.json). Of course, I copied the file there. After import, I could use them to create rules, but no files seemed to be created for the templates. Will be interesting after a reboot. Still learning… hope this helps.

I will definitely be sure to add that when I expand the triggers section. This can become more of a problem in PaperUi rules because one of the way to wire them up would be to write separate Rules with their own triggers that all call the same Action. And if I encourage the use of Thread.sleep this problem will become apparent.

This sort of approach will probably become common with Yannick’s UI.

I’ll need to set up at test to see if they run fifo or in random order. That can become important in some scenarios

That’s the rub. I don’t think there is anything in JS that prevents this. But in JSON Rules you don’t have any access to a context outside the Action so there is nowhere to define the variable and no way to access it, unless there is something I’ve yet to discover. As far as I can tell, even the libraries are reloaded every single time the rule runs (though I’ve not systematically explored this yet). As far as I can tell, every time the rule runs it has a brand new and clean context.

Beware that if my suspicions are correct, Jython will have the same problem.

Hope you feel better. This year the flu is supposed to be no joke.

Check userdata/jsondb. Everything else send to go there, I would expect templates to go there too. They only reason that libraries are picked up from there for JSON rules is because that’s the path given to the load function. Everything gets stored in the JSONDB.

Always.

This should not be a problem… each would be a separate rule, even if sharing an Action.

It is FIFO…

from org.slf4j import Logger, LoggerFactory
from time import sleep
from openhab.rules import rule
from openhab.triggers import when
log = LoggerFactory.getLogger("org.eclipse.smarthome.model.script.Rules")

ruleID = 0

@rule("Test delay")
@when("Item Virtual_Switch_1 changed")
def testDelay(event):
    global ruleID
    ruleID += 1
    tempRuleID = ruleID
    log.debug("Test delay: start [{}]".format(tempRuleID))
    sleep(5)
    log.debug("Test delay: stop [{}]".format(tempRuleID))

2018-11-08 22:38:55.079 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop [1]
2018-11-08 22:38:55.080 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start [2]
2018-11-08 22:39:00.080 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop [2]
2018-11-08 22:39:00.081 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start [3]
2018-11-08 22:39:05.081 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop [3]
2018-11-08 22:39:05.082 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start [4]
2018-11-08 22:39:10.083 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop [4]
2018-11-08 22:39:10.083 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: start [5]
2018-11-08 22:39:15.084 [DEBUG] [org.eclipse.smarthome.model.script.Rules] - Test delay: stop [5]

I forgot to include that I had searched there too. Actually, I searched the entire directory (it’s a manual install), but found nothing. And removing the templates through Karaf said it was successful, but they were still there in the list and could be used for new rules. May be another bug, but I’m still on 1405 and do not have the template PR.

Except if the rule takes a long time to run and lots of triggers are running the rule we can end up with a backlog of triggers waiting to run.

:+1

Where are the rules created saved?

really ???

I assumed I could take what is there and modify it and put it in default.rules.

1 Like

I assumed that you spend 2-5 minutes reading the info that others spend hours to make

1 Like

Reading is one thing. Comprehending is another.

The text is very clear and precise
You didn’t ask a clarification on the answer. You asked a question that had been already answered in the text.
Drop it :stuck_out_tongue:

The NGRE is completely separate and different from Rules DSL. There is pretty much nothing in common between the two. You cannot just copy the code from NGRE into a .rules file. The code is written in a completely different language.

NGRE isn’t just a new way to write old style Rules DSL Rules, it is a wholly new and separate way to write Rules.

Has anyone else had their NGRE (via Paper UI) rules stop working with the last two snapshots? Just curious before I start digging around to see if I broke something. I haven’t changed the rules, just updated my Docker image to the latest snapshots.

Thanks!

Update: I “edited” each rule (changed nothing) and re-saved it and it seems to be working now. I’ll keep an eye on it and make sure things are working correctly over the next day or two.

Hey @rlkoshak, good news… I’ve got Jython and Groovy scripted actions and conditions working! I’m holding up putting in the PR until ESH is migrated.

3 Likes

Great news. Will the PR also contain what ever is requires so we can select the other languages when creating the Action through PaperUI? Right now the drop down list only has JavaScript.

Presumably Jython and Groovy will need to be installed before those languages can work, or will the PR also include that? It seems reasonable to me that they ship with OH by default from an NGRE perspective. But I don’t know the full implications of doing that. I suspect the reason JavaScript “ships” is because Nashorn is part of the JRE by default.

I’m sorry I missed this comment earlier.

If you have a “before” of the JSONDB file and an “after” of the JSONDB file you should see some difference in the files (format, different entries, something like that). That should tell you what changed.

It’s the fun of using an experimental project. :slight_smile:

Like this :wink:

Ignore Xtend… that’s a WIP.

They will need to be manually installed. There is not any way, currently, to restrict the list to languages supported by the system.

I stongly agree. Automating installation of the languages will come in another PR. If I do it, it may take a while, but I think JSR223 bundles are important to have.

You got it… it’s already in there!

2 Likes