I would like to renew my rule based automation of Openhab.
Here, of course, the use of JSR223 is recommended.
After my first analysis, I am not sure how to proceed. Which language should I use for my project?
The implementation of the Javascript solution is in my eyes very little documented in relation to the Jthon solution. From this I conclude that it is not used that much either.
Jython is by my understanding based on EOL version 2.7.
I haven’t really dealt with Groovy yet, but it doesn’t seem that common to me either.
I want to avoid converting my home automation to a solution that will no longer be maintained in 2 years and I have to start all over again.
Which JSR223 variant do you advise me, or what is the alternative?
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.
I agree with @Dibbler42: Nice collection, thank you @rlkoshak !
I see Thomas, has same thoughts as me.
After reading the collectoin of Rich, I thought to give the native python3 library for REST access OH3 a chance, but the arguments of Thomas are good. I think, I will try HABApp first.
Your chart really does help to break it down, and reinforces why I’m sticking with Rules DSL. I’m not a programmer and realistically don’t have time/interest in learning a new language…particularly since my existing rules haven’t changed much over the past year. If it ain’t broke, don’t fix it.
The next time you use the chart, I’d suggest revising the Nashorn section to say “dropped when Java 11 reaches end of life in 2026”. I read “when Java 11 is no longer supported” and immediately wondered when that would be (and if it was soon).
2026 is when Oracle or whom ever controls that ends support for Java 11. However I have absolutely no insight into when openHAB will move to Java 17 or the long term supported version of Java after that. 2026 is the absolute latest point I can see openHAB moving off of Java 11. But it could be much much earlier. That’s why I didn’t put a date in the table.
I agree that sticking with rules DSL seems to be the best choice for now. At least until someone makes a decision on which scripting options will be officially supported in the long run. Ideally this should be a very small number. One or two would be best. Three or more is confusing and counter-productive, IMHO. Having 10 different poorly supported options with no clear strategy on which will be carried forward in the long run is almost as bad as having none at all.
Technically, that would be the three options that are native to openHAB: Rules DSL, Nashorn, and Blockly. However, the nature of openHAB is such that others are always going to be able to contribute other approaches they favour–that’s how we’ve gotten to this point. When someone suggests another method for creating rules, they’ll usually hear our concerns about fragmentation. But they’re still welcome to do it.
Personally, I’m more concerned about new users with minimal coding experience. I believe that they should almost always start with UI rules, same as they would if they set up SmartThings. Then they can “graduate” to a scripting language when they’re ready to take the next step. It’s not really this easy though, because a new user will sometimes come in with grand ideas and want to jump right into the deep end (no matter how much we advise against that). And again, they’re welcome to do it.
After giving it some thought, I might try setting up Node-RED. Part of me thinks that openHAB would benefit from featuring it more prominently, as we could attract existing Node-RED users and be more visible to people who are thinking about learning it for other reasons. However, I’m not ready to endorse it without first trying it myself.
Rules DSL is probably the best because of more examples and more users to give help and lastly the number of users will mean it is less likely to be thrown away. By running it in a rules file and not created in the UI, you get variables that persist between runs.
Other ones which are worth looking at are Javascript, J/Python and Java or any other language that you learn that can help you professionally and are not a waste of time learning. I hope Java grows and gets more accepted as it makes sense to learn a language that can then be used to build bindings and other code that helps the project. If you know any C/C++ it is easy to learn Java.
Don’t misunderstand my table. Everything in that table except for jRuby and Java are officially supported now and I see no reason why those two won’t be officially supported at some point too.
That ship has sailed. We can go to the developers who are working on these add-ons and say “sorry, we won’t accept your donated hard work because we already have too many languages.” As a 100% volunteer driven project, there is a limited ability to direct this sort of thing. Volunteers are going to work on those things that they want to work on. Over time we will have more and more languages supported as add-ons. That’s just how it is and it’s not going to change.
And then ignore them.
That’s true for all the languages when written in text files. In the UI there is a way to preserve the value of a variable inside a given Script Action in JavaScript. I suspect a similar way is possible in Python.
That will initialize myVar to null if it doesn’t already exist or use it’s current value if it does exist (i.e. the value it was set to the last time the rule ran.
You cannot, however, share that variable with other rules or with other Script Actions or Script Conditions on the same rule. So it is a little bit limited.
As I talked about above, everything that actually interacts with openHAB itself is done through Java Objects (except for the external rules engines). As such, learning a bit of Java is a good idea anyway. Rules DSL tends to hide the Java a little more than Nashorn, Jython and Groovy but it’s still there in the day-to-day rules writing. But if you need to do something advanced in any of these languages, you have the entirety of the Java standard libraries available to you. But to use it you need to know a bit of Java.
My Personal favorite is Node-Red. I like the UI, the modules are quite extensive, I have been able to complete many many - not even OpenHab related projects using Node-Red in an easy to comprehend interface.
The UI for me is the best part, It allows me to visualize the paths of each program choice in a way traditional coding languages can not. I would be forced to use my imagination (Or worse, draw on paper) to visualize this before. That being said it isn’t as efficient, and I find myself duplicating a lot more code (Mostly to keep the UI looking clean) then I normally do.
Now it is a separate entity then openhab so I have has some issues if I say Overload node-red so it doesn’t respond quickly, or crashes in the background and OH doesn’t notice it. Typically my personal code is causing these issues and can be fixed with optimizations or bug fixes. But if pure stability is what your looking for, a solution that is more directly tied to OpenHab would be easier to notice/fix if there was an issue. Because restarting OpenHab doesn’t restart Node-Red, also if Node-red crashes in the background, OH keeps trying to use it, getting “bad results”/“no actions” and making the system not stable anymore.
Like I was saying its mostly from my own code that causes crashes, so really the answer is how active I am. The crashes I am talking about are typically self induced, My own code has logic errors etc… right now I have not been messing around much so it has been quite stable as of late.
So I’m sure my experience will differ from yours in this aspect.
