Next-Generation Rule Engine - state and future

Hi,

is the “Next-Generation Rule Engine” in 2.5 still be experimental or already considered stable?

Does it make sense to start re-writing the rules I have and using " Next-Generation Rule Engine" or will OH 3.0 come with so many breaking concepts that it will be a duplication of effort?

Will current rules and scripts also work in 3.0?

Sorry if this has been answered already somewhere else.

1 Like

@5iver can confirm but I seem to remember a discussion that it is no longer experimental but it was too late to get the label removed from 2.5.

I do not know for the future but you can assume NGRE as stable.

The new rule engine was still labelled as experimental in OH 2.5, mainly due to the UI rule editor. There have not been breaking changes in the new rule engine or in scripted automation for a long time. Even though there is an experimental label, they are not considered as being in active development where major changes would be pushed out without consideration of the users. There WILL be some breaking changes in OH 3.0, but at this time I don’t foresee anything more than a minor filesystem restructuring.

IMO, people should have been writing rules in Jython for the last couple years! The helper libraries will still work in OH 3.0, but there will be a new Scripting API that will replace their functionality and be even easier to use. The more people using scripted automation, the more people and examples we’ll have to support it.

The DSL rules will have some form of migration path, but the DSL is getting a bit dated, Python is a wonderful language for scripting automation, and, as a community, we should focus our efforts on one technology. Options are really nice to have, but they multiply the development, support, and user efforts. Most, if not all, people who try the new rule engine and scripted automation will prefer it over the DSL and will migrate all of their rules. There will be either a one-way migration tool or the DSL will be rebuilt to work with the new engine. The second option would be a very large effort and would dilute the support in the forum and documentation, and would slow down further development. This is barely in the discussion phase yet, but it makes sense to consolidate. We can do many things passably or a few things very well!

This has been answered a few times now, and it’s going to need to be answered a few more! I will get a post out in the new year with more details. The easiest way to get into the new rule engine is…

2 Likes

I think it’s important to add something to Scott’s existing answer.

To a lot of people, it will look like there are two ways to work rules, one using text files where you code up your rules pretty much like in Rules DSL. The other is through the REST API (e.g the UI).

The engine that executes the rules for both is the same and it is very mature.

But the UI in PaperUI is barely functional. If you are good at JSON, you could hand write and submit Rules to the REST API end points and they will be super stable and run well just like file based rules.

So the only part that is unstable is the UI, which isn’t required to develop NGRE rules. And even it is usable for some fairly simple rules.

2 Likes

Thanks folks for quick and comprehensive answers.

I will give it a try.

1 Like

I use to get excited every time I read of improvements and new functions on OpenHAB. However, the NGRE fell short of my expectations. Don’t take me wrong, I still congratulate you all for all the hard work and dedication to make this system better and strongly believe it is one of the best home automation systems out there. Therefore, this is more like a constructive feedback in order to improve the system.

As a power-user, I prefer to use JSR233 for my rules as it is very flexible and powerful; because of this, I never used Paper UI to create rules.

However, before using OpenHAB, I was using other tools to do some “basic” automation with my lights, which was the only smart appliances I owned at the time.

The reasons why I’m not so excited about NGRE are:

  1. It’s still a text interface
  2. It’s quite inflexible (only IF - THEN structure)

I believe we should progress towards a more flexible, powerful, fully graphical user interface, which allows drag-and-drop, nested conditions, loops, etc. Then I believe the term “Next Generation Rule Engine” will be more appropriate.

I think those who used Stringify (and cursed when it was shutdown) will understand what I’m talking about. Stringify had an infinite matrix where we could drag-and-drop items and connect them together to configure triggers, actions, etc.

I’ve never seen a better user-friendly rule engine. Unfortunately since it was purchased by a competitor and shutdown, only images can be found on the web.

A second option is Zapier, which is actually a system to interconnect web apps and automate events.

I would encourage the developers of the NGRE to check these 2 apps as it might provide some ideas for future improvements.