Question for those experienced in using JavaScript/Jython/Groovy under JSR223.
Simply, which language would be the best to use?
(at this point I probably should duck, as there will undoubtedly be those in all three camps with strong views!)
My use of openHAB is relatively limited at the moment with some simple stuff set up in DSL, but I have a lot of plans to expand functionality. All lighting in the house is coupled up (Z-Wave) and using Alexa, will be adding motion sensors and binding for a few other things.
Professional background is a systems developer (30+ years) so fine with advanced programming structure etc., but mostly with the Basic syntax, not Java/C. I’ve done small bits of C++ (on Arduino), but nothing substantial.
So, with this background, which of the three languages (JavaScript, Jython, Groovy) would be best for me to jump into, moving from DSL?
I’ll jump in and say that I’m looking at Javascript as I migrate my rules over from DSL. For me this choice came down to the fact that it was implemented early on in the 3.0 development phase and is the most like Java which the core is written in.
I also dabbled in javascript earlier on my OH3 trials, I have switched back to python though. For me it has a little to do with being familiar with Python and a lot to do with the fact that only ECMA Script 5 is available which is a pain to work with.
The python helper libraries are also the most feature rich at this point and you will find more examples on the forum.
Feel free to reach out if you need a hand with Python or JS.
Same situation.
I have the feeling Openhab developers are trying to get rid of DSL in the long term, and I moved over all my rules from DSL to Javascript and did not look back yet. Runs a lot more stable (used to get OutOfMemory issues a lot) and faster I have the impression.
Personally I feel most comfortable with Javascript, so I went down that path.
What I do think is that despite of the really nice UI their next gen rule engine is, I find it useless for me.
For people wanting to get a light going by pressing a switch and that is it, perfect to use the UI.
But I use a lot of expiry timers (so 1 rule to start it, one to take action on end), and lots of complex actions, I just prefer to organize my stuff into different files, with related rules right next to each other so I can keep good overview.
Too bad that JS rules cannot be visualized in the UI (it just says scripted action).
Had lots and lots of issues to get the script library (from openhab scripters) going, because the refactoring in v3 broke every one of them. Also, object names changed completely and it took a while to figure out how to get to all the triggering objects and so on. But once there, worked a lot better especially since I no longer have to deal with the strange DSL language which would always confuse my when dealing with dates, writing timer logic etc.
Downside of using JS is that the rules look “ugly”, lots of syntax overhead to define them as opposed to DSL that looks very clean.
Python also looks a lot cleaner, and there seems to be even an external rule executor engine for it.
Looking at the UI, I see that defining an action in ECMA is supported so I recon that JS has the most chance of being supported best and most. P/Jython being close second.
Long story short, I agree with Sunny’s comment
Jython was a simple choice for me since I use python in other areas to solve different problems/task.
If you see yourself using either one (js/jython) in other areas, that’s the one I would recommend
The advantage of JavaScript is there is no extra add-on required.
The advantage of Python is the Helper Libraries are more mature.
The advantage of Groovy is it looks to be relatively terse and simple with a lot of similarities to Rules DSL.
The disadvantage of JavaScript is even with the Helper Libraries is the code is pretty verbose and looks “ugly.”
The disadvantage of Python is you pretty much have to use the Helper Libraries to avoid the same problem that exists with JavaScript.
The disadvantage of Groovy is almost no one on this forum appears to use it so you are largely on your own.
There are good reasons to choose and not to choose each of the options.
And there is nothing forcing you to move. You can stay on Rules DSL if you want to focus on learning elsewhere.
But I will say that a major factor in your choice will be whether or not you will be writing rules in text files or through the UI. If you are planning on using the UI, almost all of that “ugliness” goes away because you don’t have to actually create the rule in code, just what the rule does. At that point the three languages become much more alike in capabilities and in how they work. And there are a number of things that I like about working through the UIs. I find it a relatively pleasant way to write openHAB rules and I’m just as productive there as I was in text rules.
Personally, I’m using JavaScript (after having previously ported all my rules to Python) because:
I’m using all UI rules, nothing in text files
OH 3 comes with JavaScript so I suspect most new users who don’t choose Rules DSL will choose JavaScript
I have plans to distribute libraries and rules and wanted to learn how to do that with as few dependencies as possible which pretty much means JavaScript is my only choice.
There are a number of significant limitations with Rules DSL which makes it less capable than the other languages. Now that it has been ported to work on the OH 3 rules engine I suspect it will always be supported, at least until the rules engine is replaced again. But it without significant changes to the syntax and imports and such it will remain less capable compared to the other languages.
If you are referring to HABApp, that is really a wholly separate rules engine that interacts with openHAB through the REST API. It is completely different from Python rules in openHAB.
Any supported language can be used in the UI to create Script Actions and Script Conditions. If you install the Python add-on you will see Python added to the list of choices.
