If you are a software developer, try Jython rules

Hi all,

I just want to encourage people to give Jython (JSR223) a try. I took a dive recently, and it has been working very well. I am a developer but not well verse in Python, so it took me a while to get used to the syntax. There are also a few hiccups such as a bug in OpenHab loading order, as well as the unexpected need to reload a changed module during development. However, almost all of these are well documented on the excellent Openhab-Jython github project. The how-to section is especially helpful for beginner…

The benefits are tremendous. I am noting a few here:

  1. The ability to modulize and reuse code as in traditional software engineering manner.
  2. Related 1) above, more practically, the use of OOP to group together related Items.
  3. More powerful language constructs compared to xtend.
  4. Access to certain Eclipse core functionality that is not yet available in xtend (e.g. the item meta data).
  5. The ability to unit test modules/rules.

I started out with migrating my lights rule over to jython, and then created some new rules to control the chromcasts/google home devices. I am still learning, but you can look here for some sample code.


I have been watching your repo for quite some time now :slight_smile:
Very nice examples!
about to switch over from xtend to jsr223
but I was thinking to transition to the new NGRE

I just read Rich’s documentation on NGRE. That looks very promising. I am not a big fan of Javascript. But at the same time it kinds of suck that Jython is stuck with Python 2.7 language. I guess you can’t have the best of everything. If I understand correctly, eventually NGRE would support Python as well, so it really comes down to which language you prefer to work with.

I am not entirely clear how NGRE will enable code reuse if they can be written in a number of languages. I just read about the GraalVM. Very interesting stuff. It allows mixing code from multiple languages.

Time permitting, I plan to merge this PR over the weekend. The intent of the PR is to make it easier for us to have a single set of modules and scripts for core functionality, and a place to store, share, and collaborate on community contributions. If starting up with JSR223-Jython before the merge, I suggest using the files from that branch. After the merge, I’ll be working on merging lucid, weatherStationUploader, and ideAlarm back into this repo (after updating them to use the recent changes in the automation API), adding in all of my own modules and scripts as community contributions and examples, and adding examples illustrating the DPs from the forum.

If you have built an understanding of the rules DSL, or have any programming experience, I would think using Paper UI to build your rules will be a bit of a let down. The functionality is very limited. If Flows Builder picks up again, the UI will be greatly improved, but I don’t foresee it having anything more than basic/beginner functionality.

Keep in mind that there is also a very real possibility of a new DSL being built for use with the NGRE, which will be compatible with rules written for the rules DSL. Personally, if I need to learn something new, it’s worthwhile putting the time and effort into a real programming language, where the knowledge can be used outside of OH. Jython/Python is very easy to pick up and well documented.

  • For beginners and simplicity, build rules in Paper UI (or hopefully in the future, Flows Builder). This will also allow for using rule templates, for easier ramp up.
  • For people with existing DSL rules, the new DSL will be a logical progression and easy migration.
  • For anyone wanting to do more with automation than what is available out of the box, use JSR223, which provides more than just the ability to create rules… entire bindings are possible. And multiple JVM languages can be used at the same time.

There are lots of options and all of them can be used simultaneously, so no need to chose only one!