OH3 - Rules - Wait with writing new rules in OH2?

I got another question in the field of OH2 vs OH3. I have to write a lot of new rules (file based) for my setup running on OH 2.5. Does it make sense to write them in Xtend? Or what is the most OH3 compatible way to write them? (JSR223?)

yes, JSR223 is the best way to go.

Will the old Xtend based rule engine be gone on OH3? (I already have some rules based on the https://www.openhab.org/docs/configuration/rules-dsl.html documentation)

Consider it (Xtend) deprecated so be prepared to shift to another scripting language (especially Jython is so much powerfull).

1 Like

Xtend rules will still be supported in OH3.

Thanks for your answers. So am I right that Jython is the most future proof way to go with JSR223? Javascript (Nashorn) seems to be deprecated in the future. Or is Groovy the better way to go?

You will find far more resources on this community on Jython than other (JS, Groovy), so if you start at the same level on each of these, go to Python.

Yeah well I’m a web developer so javascript is my daily business. (Node etc.)

But I’d like to be as future proof as possible so I’m probably going with Python. (I have done some Python in the past but not that much)

Since you are discussing rules and not OH development, I’ve moved your topic to a more appropriate category.

In regards to OH, a more suitable term is scripted automation.

The old rule engine and the rules DSL are two separate things. The old rule engine has been removed in OH 3.0. Why anyone would choose to use a very limited and clunky proprietary DSL for writing their automations is a mystery to me, but the rules DSL has been grafted onto the new rule engine. Whether it works or not and what changes will be required to existing rules is a ticking time bomb that you are welcome to poke at! :boom:

Having a background in JS, it makes sense that you would gravitate towards Nashorn for scripted automation. However, you may want to consider:

  • For now, you are stuck with ECMAScript 5.1.
  • The JS helper libraries are very useful, but they can never be on par with the Jython HLs with ES5.1.
  • With JS, you will need to use a lot of the raw automation API, which has very little documentation, so you will need to read through a lot of OHC code. The helper libraries provide a layer of abstraction from the automation API to make things easier and to help protect from breaking changes, like are coming in OH 3.0. Using the JS HLs will help a tiny bit, but the coverage is very small, particularly in the creation of rules and triggers. The Jython HLs are a near complete solution where you do not need to come into direct contact with the raw API, so they should prevent any breaks in functionality. If any gaps show up, I will do my best to fill them in before OH 3.0 is released.
  • Would you write tax software in JS? Would you write code to control a spaceship in JS? Would you write an email server in JS? Of course not… you’d select a tool that suits the job :slightly_smiling_face:! JS is great for websites, but Jython is much more suited for automation.
  • There is much more information available in the forum and documentation about using Jython and the helper libraries.

To simplify the installation, I have made Jython and helper library add-ons.

1 Like

Thank you very much for this extended insight. So I will move along with Jython. :+1:

1 Like