So far I’ve been writing all my rules using Rules DSL. Is it going to continue to be supported by OpenHAB in the future? I read some comments about making JSR the default. What would that mean for me and my rules?
Should I spend time to learn Jython and convert my rules there now?
I’m asking this because I seem to be writing more and more rules every day.
I think it is really worth switching to Jython as soon as you can. You’ll unleash the power of OH compared to DSL rules.
Then there’s the question of Jython vs Javascript vs something else.
It will depend where you’re already comfortable with. Jython is the more document of the various scripting languages offered by JSR223, so I took it. It is quite easy to learn.
OH3 is “tomorrow” and still fluid, but you’re working today.
No-one will force you to move to OH3.
Existing OH1 systems are still running today.
Most users here are still developing in DSL.
Long winded way to say I wouldn’t worry about continuing in DSL for now. Undecided but almost certain to be a legacy conversion or support.
There is no harm in checking it out. Chances are, you will wonder why you stuck with the DSL for so long. The new rule engine is an evolution… and supporting both would be wasteful. So, it’s just a matter of time when the DSL will be retired. It’s possible this could be in OH3. For anyone still developing their rules (who isn’t?), I recommend moving to scripted automation with Jython and the helper libraries. 1) You’ll need to learn it at some point, 2) everything you write now will need to be migrated, so just write them in Jython to begin with and save the migration effort, 3) the more people that get into Jython, the more support and documentation there will be.
Before you dip your toe in, you might consider waiting a tiny little bit. I’m about to submit a PR that will massively simplify the installation of Jython and the helper libraries. I’m currently testing and it is working great. I hope to have the PR submitted this weekend and I’ll be looking for some beta testers! However, it doesn’t take much to setup manually.
In the meantime, browse through this… Helper Libraries for openHAB Scripted Automation — openHAB Helper Libraries documentation.
I’m going to recommend moving to JSR as soon as possible for a different reason. Notice how right now there are lots and lots of examples for Rules DSL on this forum and elsewhere. But you still need to copy/paste/edit to use in your own system. With the NGRE which includes both UI developed rules and JSR223, that will go away. With enough people contributing, Rules will become more something you download and configure and use like bindings. For even very complicated setups, you may not need to write a line of code.
In fact, the concept is that rules will be found and installed exactly like bindings through the UI.
For now, there is already a bunch of very useful “configure and use” rules in the Helper Libraries and hopefully that will continue to grow.
If you don’t already know one of the JSR223 languages, there is more documentation and examples for Jython right now. And with the Helper Libraries, coding Jython Rules is now really a while lot different from Rules DSL. You can almost do a line for line translation and be fine.
Some additional benefits include globals that you can use across files, real functions, the loading order problem doesn’t appear to exist (rules state executing before Items are all loaded), and there is no limited thread pool meaning you have to avoid long running rules.
Other benefits include the fact that you will learn skills to help you read and understand and perhaps write code that runs outside OH in cases where OH doesn’t support it yet.
Thank you everyone for your suggestions and input. Boy, am I glad I asked! The point above about downloadable rules, sounds really great. That almost sounds like Node Red in concept…?
It sounds to me that everyone is recommending Jython over JavaScript? Syntactically, I am much more familiar with JavaScript as I’m more familiar with C++/Java and haven’t dipped my toes in Python yet. However, it appears that Jython is the leading and most popular scripting for openhab and hence it is the most “feature complete” of the two?
I just don’t want to have to migrate my rules again 
You can do anything that can be done in OH in any of the three languages. The only way that Python is ahead is the Helper Library is more complete and there are more docs and examples. If JS is more comfortable for you, by all means use that. Though I’m my experience, the similarity between JS and C++/Java is very superficial and when you actually start coding, JS and Python are about equally far from C++/Java.
But, where Python will compare more favorable than JS, at the moment, is to Rules DSL thanks to the decorators. Python Rules with the Helper Libraries looks much more like Rules DSL make no mistake, the JS will get there too. But right now Python is ahead.
The thing with the NGRE is you can run all the different languages all at the same time. So if you choose Python and later decide JS works better for you, you don’t have to rewrite your Python Rules. They can run along side and are completely compatible with each other.
Thank you @rlkoshak for your detailed and considered reply, as always. You are truly a very valuable member of the OpenHAB community.
@5iver how can I know when your improvement is ready to use, i.e. where can I check? I haven’t got a clue yet how to start setting up for jython, but I will spend some time browsing through that link you posted above.
That’s why Scott wants you to wait. When this change is done all you have to do is install it like any other add-on.
You can use Kotlin, jRuby, Groovy, and many other scripting languages. However, the automation API is not easy to navigate, even if you are familiar with the code. The helper libraries make it easier to interact with the API. Take a look at the helper library docs that discuss the raw API for rule generation to see what I mean and compare to the decorators. And that is just rule generation! The Jython HLs have much more functionality than the ones for JS, which will not catch up until JDK9 is mainstream for OH or the functionality in the HLs is absorbed into an OH scripting API, whichever comes first. Python is easy to learn, perfect for automation, and is much more functional than Nashorn, which is stuck at ES5.1 in JDK8. Odds are you are more familiar with a much more recent version of JS.
I’m working on submitting it right now, so it should be in tonight. I will also be posting in the forum to drum up some beta testers. The maintainers may not like how I’ve put it directly into OHC and may want it separated out into an addon, but that is an easy swap. If you want to get to it tonight, I can PM you a link to download a preview.
Thanks, but I’ll wait for at least the public beta, so I won’t create extra work for you. I’ve been reading through the docs in the mean time.
i tend to disagree.
till it will be part of the OH as DSL is, it’s more like scratching left arm with somebody’s else foot
I have it purely for me to know how to, but it was quite not straightforward and definitely something which I would not recommend for regular Joe.
maybe after some time, maybe later, maybe OH3, but now… not yet
Are you referring to the installation of Jython and the helper libraries? This is exactly what the PR I linked addresses. You’ll just install it all in one go in Paper UI.
dunno, havent been following recent updates at all.
have to check my docker updater
if I have it old fashioned - external installed way, will it be backwards compatible?