They all have their advantages and disadvantages. You have to choose the best you can. I don’t think there is anything like a roadmap right now and rules development is hopelessly fragmented at the moment with no sign of changing.
| Language | Advantages | Disadvantages | UI Rules Considerations |
|---|---|---|---|
| Rules DSL | Native to openHAB, no signs of it ever being dropped, best documented, most examples | No support for libraries, limited language features | Cannot persist variables between runs of a rule, cannot import libraries |
| JavaScript Nashorn | Native to openHAB | Based on ECMAScript 5.1, will eventually be dropped when Java 11 is no longer supported. | Does support preserving variables between runs of a given rule. |
| Blockly | Native to openHAB, graphical programming environment | Not yet complete | Only available through the UI |
| Jython | Most examples and docs of the non-Rules DSL languages, most mature Helper Libraries | Based on Python 2.7, Jython project appears all but abandoned, it’s not clear a 3.x Python version will ever be finished | |
| Groovy | Least used of the original three JSR223 languages, support for libraries is not as good | ||
| GraalVM JavaScript | Most recent ECMAScript version, most easily supports third party standard libraries | Almost no documentation, installation of the add-on breaks Blockly and Nashorn rules (JavaScript transformation too?), work very differently from the other languages (harder to take knowledge learned on one and move to another language) | Not clear how/whether they work |
| jRuby | Very native Ruby approach | Not yet merged into openHAB main, work very differently from the other languages | Not clear how/whether they work |
| Java | Full Java IDE support | Still under development | Not clear how/whether they work (probably not) |
| HABapp | Full and native Python 3 rules engine | Runs as a separate service and interacts with OH through the REST API | NA |
| NodeRed | Nice graphical interface | Runs as a separate service and interacts with OH through the REST API | Has it’s own UI |
If there are other languages in work I don’t know about them.
As you can see, it’s all but impossible to say “go use this.”
As for the documentation, there is a little known fact about at least Rules DSL, Nashorn, Jython, and Groovy. Every time you are interacting with openHAB, you are in fact interacting with Java classes and objects. So except for some minor differences in syntax, creating and using a Timer, calling Actions, working with members of a Group, updating and commanding Items, and so on are all pretty much the same no matter what language you are using. The parts that are different are script language syntax. Therefore it’s relatively easy to convert, for example, a Jython block of rules code to JavaScript and this is even more true when writing rules in the UI. Almost all the key stuff is the same.
Personally I’m using Nashorn because Java 11 will not reach end of life until 2026 so it will be around for awhile. And around 2026 perhaps it the rules situation will be more clear. It’s also native to OH so there is nothing extra to install. My goal is to write rule templates once the marketplace is available and having fewer dependencies is an advantage (though the way GraalVM JS breaks Nashorn throws a wrinkle into that plan). That also means I’m writing all my rules through the UI, with support from personal libraries.
I used to have all my rules written in Jython. I wasn’t unhappy with them by any means but when OH 3 first came out the Helper Libraries were not yet compatible with OH 3 (they are now) and my end goal remains building rule templates so I want to limit dependencies.
So you’ll have to look at the above list and make the best choice for you.