What will it take to remove the "Experimental" from the Next-Gen Rules Engine

Development Misc
1

I might be jumping the gun here but I wanted to start the conversation here for what it will take to take the “Experimental” off the name of the Next-Gen Rules Engine (NGRE) and start promoting it’s general use. @kai, if this is premature I can hold off until the governance structure is in place. I was just thinking that we can at least start the conversation in parallel with that.

I don’t intend this discussion to include what it will take to make the NGRE the default. I firmly believe that we need to spend a good bit of time (at least one release, maybe two) to give users a chance to use and find the bugs in the NGRE before we do that. So I want to focus on getting to that point first.

@5iver, @lewie, @ysc, @Confectrician, @David_Graeff, @kai I know all of you have contributions of one sort or another on this topic.

I’ve spent some time experimenting with the NGRE to find out how to do pretty much everything one can do with the Rules DSL so I know a good deal but I don’t know everything and I’m still learning.

So here is my list, in no particular order:

  • Rules must be backward compatible. When 2.4 was released, everyone who ignored the “experimental” in the name found all of their Rules no longer working because there was some change in the format to the JSONDB entries (I suspect, haven’t had time to research). Rules take a long time to develop. We can’t break everyone’s Rules on an upgrade so there must be an automatic upgrade or provisions put in place so the old Rules work after the release.

  • A first draft of the documentation needs to be completed and moved to the official docs. I estimate I’m probably 50%-60% done at Experimental Next-Gen Rules Engine Documentation 1 of : Introduction. I’m still missing calling third party actions, exploring rule triggers and but only if… more, Rule templates, how to write your own library, stuff like that.

  • The triggers that exist in the PaperUI GUI right now are not sufficient to replace Time cron triggers from Rules DSL. There are all sorts of use cases (e.g. once per hour) that cannot be easily supported. Also, they seem to be broken.

  • There are a lot of quirks and issues with the PaperUI GUI that would need to be fixed including:

    • Not all enum type commands are in the drop down list for command types when using the “send command to an Item” in the then… clause

    • The code editor for defining custom but only if… scripts and then… Scripts is really poor. It doesn’t resize properly as new lines are added and there is no syntax checking or highlighting

    • In general the PaperUI GUI needs a ton of usability improvements which I’ll come back to iterate over. It is pretty painful to point click and edit Rules with the UI as it currently exists. Some of the things that would be helpful include stuff like letting me save a Rule while keeping the editor open, fix the bug that prevents me from using the “play” button to test a Rule after it is first created (there is an issue open for this), stuff like that. We need to improve the overall edit/test cycle in the UI.

  • The ability to define Timers that can be accessed from other Rules or multiple runs of the same Rule. The NGRE does not support the equivalent of global variables like in Rules DSL where we can define a global variable to store a Timer and access that variable from our Rules. Because the Expire binding is a 1.x binding we can’t rely on that. @David_Graeff and I have already discussed this and there is an open issue on ESH’s repo that I hope get’s moved over.

  • Equivalent to the Member of Rule triggers. We already have the equivalent to triggeringItem (and more) but we cannot trigger a Rule using a Group and get the Item that triggered the Rule.

  • Only Group changed triggers work. Group received update triggers do not work. There is an issue opened for this on the ESH repo.

  • Not all features of NGRE appear to be supported in the PaperUI GUI yet. For example, I can’t add tags to Rules through the UI.

  • A subset of @lewie’s library should be included by default for JavaScript.

  • We should have the ability to install a library through the GUI (IoT Marketplace?, file upload?)

  • I can’t create a Rule Template through the PaperUI GUI (as far as I can tell at this point)

  • I can’t create a library through PaperUI

  • Jython (with a subset of Scott/et al’s library) and Groovy should be supported

  • We should have the ability to export/import Scripts at a minimum, entire Rules would be great. This is related to some of the above Items but my main thought here is to give a migration path of sorts for user who want to move between NGRE and JSR223.

  • @ysc’s prototype GUI would be awesome as I think it’s approach actually clears up a lot of the clunkyness of PaperUI graphically.

I’m not sure we need all of these to get to a beta version of the NGRE but a lot of them are, particularly a lot of the ones that have open issues.

Thoughts, comments, concerns? Too soon?

3 Likes
2

Perfect timing to speak about this, now that Kai has made his announcement. Paper UI is (kind of) officially discontinued, as there is no AngularJS developer left. Yannick (@ysc) and me, we prefer VueJS for frontends.

And for the Rule Engine to loose its experimental status, you must be able to assemble your rules more easily than writing those not-so-well documented json files.

Cheers, David

2 Likes
3

Thanks for making this remark, I was not aware of that. It would require some dusting off on my end, but I might be able to help if desired.

4

So, PaperUI is dead and we have to wait for a brand new front end to be built? And they’re is only two developers. So we will be waiting awhile…

Does it even make sense for me to continue the docs then? It sound like we’re starting over UI wise and the bulk of what makes NGRE is the UI.

I knew there was going to be work on consolidating and steadfastness the UIs. I didn’t realize we were completely replacing PaperUI.

I don’t disagree with the direction, I just need to reset my expected timelines. Most of the UI items I discussed above are paperui specific.

Since we are looking to start from scratch is like to see Yannik’s prototype NGRE GUI mature to become the Rules UI. I haven’t had a chance to use it so don’t know what is missing there but the ability to see all the nodes and flows is priceless for non-developers.

I look forward to an admin UI that is kept up to date and improved at the same rate of the rest of the core, or at least better than PaperUI was.

If you need a “voice of the new user” I’m happy to fill that role. There are plenty of “voice of the old timers” around.

1 Like
5

I’ll second that.

6

I guess that you can recycle a lot. A new GUI will provide everything of Paper UI from today and just a bit more on top.

7

In all good fun…but this jumped in my head

2 Likes
8

Paper UI is a web technology. Web technologies at the moment last for about two years before coming totally obsolet and stop functioning at all at some point even. That’s how it is.

That’s why we need to carefully select the right technologies and tools for the next UI. Has not much to do with competing standards I’d say.

Cheers

9

The title here talks about the rule engine, the discussion is about Paper UI etc…
I think we should really try to better structure the discussions around here.

@kai, if this is premature I can hold off until the governance structure is in place.

Yes, I’d very much prefer this.

As mentioned in my announcement: I’d suggest that we don’t do too many structural changes for openHAB 2 anymore - I’d instead would hope that many people could help reducing our binding backlog as we have around 50 bindings ready to be reviewed and merged. It is a bad signal to our dear contributors, if we do not care about such contributions.

For openHAB 3, we can then talk about a future UI, how rules should look like, how configuration is done, etc.

5 Likes
10

Because the major distinguishing characteristic between JSR223 and NGRE from the user’s perspective is the UI, I didn’t think those parts of PaperUI that have been discussed were off topic.

OK. I think I can close this thread as a moderator.

But as a tl;dr for the thread so far my take aways are:

  • no major new features or structural charges to be made to OH 2

  • PaperUI is likely going away for OH 3, to be replaced with a rewrite, there is a study in work.

  • NGRE will remain experimental until at least OH3

  • we need code reviewers and or some way to improve the binding approval process.

3 Likes
11

I’ve only gotten to Kai’s post but I had to quote this for truth! If this forum is to be a vehicle for developing this platform… please people… stay on subject or start a new thread

And just want to edit to add. didn’t think anyone had gone to off topic, just found Kai’s comment amusing.

1 Like