I have some basic question about the new rules engine:
I have tried the new rules inside the paper, is it the only way to define new type rules?
Is there a possibility to have some sort of rules files and visual studio code?
I mean the old rule engine how outdated it might be is unbeatable when used with visual studio code.
I have looked around the forum did not find answers for these questions
You need to look at the posts about Jsr233 and related here in the forum. Scripting in those languages uses the same engine as the ngre in paper Ui and you can use any code editor you like as you write your rules in mainstream languages. Have a look here:
Or here for example:
The forum is your best friend to get information about this right now.
Best regards Johannes
There are some good docs coming soon. But there are some things to realize which almost certainly causes confusion.
The rules engine (i.e. the thing that executes Rules) for the PaperUI defined Rules and JSR223 Rules is the same. So the simple answer to your question is yes, you can use JSR223 Rules (language of your choice) and use the new Rules Engine.
However, if you define your Rules using PaperUI (or the REST API directly) then instead of text code files located in /etc/automation your Rules will live in the jsondb. So from a storage and usage perspective, there is a big difference.
There were a few bugs in PaperUI that made creating rules through it challenging (I see that @5iver is responding right now too, maybe he will include an update on the PaperUI bugs like not being able to select a day or time with time based triggers?) . So you can either hand roll the REST API calls, proceed at risk knowing that the UI is not completely working, or use JSR223.
Yes, JSR223 Rules are standard languages. However, the ability of OH to do things like code completion and the like is not uniform across all programming languages. And I don’t think there is a much integration with OH (e.g. it knows the names of all your Items) as there is with Rules DSL Rules. Yet.
Many of the prototypes for the replacement to PaperUI will include VSCode in the web based UI for syntax checking and such so you will get the same nice environment whether you choose to write your own separate text based code files or stick to creating Rules through the UI.
I’ve done my best to tag all of the posts with jsr223, like I just did with yours. If you click the tag, you can subscribe to it and see the discussions in one place. By the time OH3 comes around, I hope to have several more features added to help with scripted automation. Until then, it is best to use the helper libraries, which will all be located here, after the organization and repo names are changed (probably within a week). The Jython libraries are the most robust, but the ones for Javascript and Groovy will be built out with matching functionality. You can use all of the languages and both rule engines simultaneously, so you can keep your old rules running as you test and migrate to the new rule engine.
If you have any questions, I’ll be glad to answer!
I haven’t had time for the UI, but also wanted to wait to see how the new one was getting along. Although, if you have S1566 or newer and Jython and/or Groovy installed, you can now use them in scripted Actions and Conditions in the UI. 
Once the helper library repo is setup, I’ll get back to automating the installation of Jython and Groovy either as addons or rule engine configuration options.
Thanks for the update.
While I understand not wanting to spend much time on PaperUI, as long as the killer bugs still exist in it the NGRE will be off limits for use for the vast majority of new users. Do we want to wait until OH 3 sometime next year before we start having users play with the UI defined Rules?
Thanks to all.
I now have all the info I looked for.
I might be old fashioned but I am not a big friend of configuring too many things PaperUI. Won’t start here the controversial discussion here. I see the paths now for me migrating DSL rules.
One thing to decide is either javascript or Jython. Jython seems to be much more mature, hope javascript will catch up.
I just looked at the git repositories of both lewie/openhab2-javascript and OH-Jython-Scripters/openhab2-jython.
The Jython community seems to be much more active having 15 contributors, javascript just one.
Though for me seems to be a hard decision going towards Jthon it might be the right one.
I would expect Javascript to get some more activity in the future.
I am waiting for @5iver to get their current tasks then and will then try to contribute to javascript too.
And as he also stated it is planned to give js and groovy some attention and will be built out.
I think the goal is to give users a free choice of lib they want to use and provide equivalent features for each lib. (Correct me if i am wrong Scott.)
So maybe, with a bit patience, you can see some progress in the scripters repo.
No… using rules in the UI is on my list of things that I’d like to address, but this is lower in priority for me right now than the other things I’m working on. I don’t use the UI much for rules… are these the only issues? I realize there are some other issues in core that affect the UI rules too, but these are the only ones I could find that are UI specific.
It wasn’t a rhetorical question nor intended to question priorities of what you and everyone else is working on. I honestly just wanted to know if the UI was something we planned on just waiting until the hopefully more usable UIs in OH 3 come about. I can see lots and lots of good arguments for waiting and I’ve no problems with that.
Those are the real deal killers for the PaperUI itself. I think we can get by with the rest of the usability issues which are annoying but not totally making the tool unusable.
Though the lack of cron triggers is a pretty big limitation so I’d put that a little higher on the list of new features if we get that far. As is the lack of Member of triggers. I know both of these are possible, but they are not available in PaperUI. There is no issue open for these yet I think.
I think the Group event trigger not working was an issue with the core and already fixed IIRC.
That’s everything I have in my list.
The current Paper UI bugs are low priority for me, but adding functionality which improves UI rules and scripted automation are not something I’m waiting on.
There are a lot of ModuleTypes that I plan to add. Member of should be easy. @David_Graeff recently added an absolute datetime trigger into the hueemulation binding, that will hopefully be moved over to OHC sooner than later. He also unhid Cron Trigger, so these are currently available in snapshots. 
It’s not the best place for it, but in case you’re interested, I’ve created a personal automation backlog over in the helper library organization.
I just want to remember that the addons2 repo may also provide additional extensions of all kinds, including automation modules.
I really dislike to make PRs against the core repo. Too slow of an adaption rate, and everything has to be for eternity which results in endless discussions.
For core we should really go back to: Ship something with a version number below 0, but at least ship something. People can already use such a feature at this point and over 2 or 3 releases we improve (and break) it a few times until the feature is settled.
I can factor out my modules from the hue emulation into an own bundle, but I will not submit it to core.
As just a user what gets merged into core or not is really a “don’t care”. However, having a bunch of unintegrated modules scattered throughout the repos doesn’t really help me.
You can build your own custom version of OH that includes the stuff you want and excludes the stuff you don’t and I know you do. But 99%+ of OH users cannot or will not.
I thought that was one of the whole points of moving to a new major version number for breaking changes.
Also, from a users perspective, the “move fast and break things” approach is the exact thing that is a major complaint that drives users away from Home Assistant. It may be frustrating for you as a developer, but being a more methodical and strategic in how changes are introduced and released has major benefits for users. We end up with a predictable system and are not faced with constantly struggling with chasing upgrades that include lots of breaking changes or face a huge amount of work if we happen to miss a couple of upgrades. Some of us (most of us) want to focus on building our home automation, not rewriting our existing configs because of some breaking change every two weeks.
I know that there are a number of ideas and efforts in talks to address some of this stability of the platform and separate the versioning of OH and the add-ons. And that will be really good. But that doesn’t help me now.
Similarly, all the great work that Scott is doing on the underlying parts of the new rules engine are fantastic, but unless and until they can be used from PaperUI (or some other GUI) they may as well not exist for those users who are afraid of a little coding. In the past you’ve complained about calling it “Experimental”, but how can we do otherwise when even when the fixes I describe above are made, creating Rules from PaperUI is barely usable?
The root cause is very simple: we have no semantic versioning applied to the different parts of openhab.
We have the luxury with java and OSGi that we can even let multiple bundles with the same functionality but different version run at the same time, so we are far from homeassistants config instability.
But right now nothing happens to core in terms of functionality.
Have you seen any timeline or roadmap? I haven’t. And no, I don’t think Markus will let us break everything. He is using core in his solutions in its current form.
I think it is not allowed in oh2-addons to have dangling bundles. They must be part of the overall build, so they end up in the distro as installable addons.
And yes that means something basic like “absolute date/time triggers” would need to be installed first. Its also not my preferred solution but I really don’t feel like commiting anything to core under the current circumstances.
PaperUI is more than dead. Openhab actually does not have a working UI solution at the moment. That’s the reality.
I really appreciate that Yannick is working on his UI which makes the entire webui repository obsolete and let us have something modern for controlling and basic setup.
He just started the wrong way around, because the required modernizing that I’m doing in core on the API level right now and after the 2.5 release will affect his UI to a high degree.
It’s just sad that developers are not coordinating and that we don’t have like a discord channel for real time chat.
So I go back to my statement from before, how can we call the next gen rules engine anything but experimental if it can’t be used?
Right now what in seeing is all this great work being done and pretty much nice if it being available to the average user. With statements like “don’t plan to check it into the core” it also appears that it will never be available to the average users. So they are all just it off luck? At best you offer me the Gentoo Linux experience where the users end up having to pick and choose each and every little feature they want to use and install it separately. Not that OHv was ever the paragon of user friendly but the isn’t exactly a step forward.
And like I said before, the details about which repo stuff gets built in and such is a don’t care to most users. But if it becomes something that users have to care about we’ve failed as a project.
There’s no UI for DSL rules as well ^^
Thumbs up.
I cannot imagine to how much effort it would be to maintain some “nodered-like” approach for rules, everything else is useless.
Making my first steps from DSL in jsr223 jython and it is really promising. I cannot imagine anybody need a gui, nor a gui can be that sofisticated to do stuff most need (even nodered-like)
The demand for a GUI is strong, consistent, and persistent. There is a class of users who will never be comfortable using text based configs. I spend a huge amount of time dealing with those who try to use PaperUI to build Rules only to run into some problem or limitation caused by the UI. And that’s at a point where it’s explicitly labeled “Experimental” and there are no docs what-so-ever on how to use it.
So I’ll just jump in with my $.02 as a mostly lurking user who is quite technical but has very little time to hack on stuff. I am using the NGRE with PaperUI and it is working mostly good enough for me right now. I have less than 20 rules and they are mostly absolute time of day, or sunrise/sunset stuff for lights and door locks. I also have a few that control things with scenes via remote switches. The UI has quirks and a few issues and every time I restart my OpenHAB instance (running in a docker container), I have to open and save every rule from the UI to initialize them…a PITA. But it works. I wish I had time to dig through the code and figure it out but I just don’t. I instead will go look at the JSON db files just to see what they’re doing on occasion, but I mostly trial-and-error stuff until it works and for most things it just works. I think having a UI is important and simplifies/improves the experience for even some technical people and is a must for adoption for those who don’t/won’t write code. I’m not at ALL criticizing anyone and am thankful for all the effort from the contributors - I’d just like to add my voice to that of Rich in stating that a working UI for the NGRE is important.
Thanks for listening. 