How to write rules in OpenHab (native rules vs scripted automation)

Tags: #<Tag:0x00007f616cd723a8>

If you ask yourself if you should use OpenHab’s “native” Rules DSL language to write your rules, you are in luck, because here’s the only and definitive answer. :wink:

I’ve switched yesterday to jsr223/Jython - after writing about 10 rule files in OH’s “native” rule language (Rules DSL / Xtend), which then became unreliable to load & work. After hours I found out that the variable name “ruleName” is causing problems. Wow.

Fixed, moved on, wrote most of the things I need, worked some days. Now again problems: I have to re-save .items and .rules after OH starts, to make rules work (undefined items, non-running rules). There’s no clear pattern, maybe file names are also in issue.
Some rules work, some not. Searched the forum - other people with similar problems, and at best, Voodoo-fixes. :japanese_goblin: It’s just broken stuff. :face_with_thermometer: And foreseeable that I will lose more and more time with this, and will not get a rock solid home automation. I cannot always fear “Is everything really running?”, and do babysitting…

So I decided to bite the python :snake:, before the Rules DSL bites me again. :bomb: I have never used Python before.

Some time ago, out of curiosity, I had a look into the JavaScript Nashorn language ref, and the Python ref, and I liked the Python’s features, and the code more. Good bye curly bracket nonsense. {{{:face_with_monocle:}}} They have undoubtedly been invented to allow developers to release more hot-bugfix releases, with clear release notes like “This update allows you to use our app more easily”. :wink:
Python’s code semantic is also not perfect, as it requires proper indentation, but it’s a lot less cluttered than curly bracket code.
(A simple “end” would solve so many problems in both languages)

Apart from that, the last Nashorn has already died, and to me it looks that JavaScript (and Groovy) may become less attention in OH’s future than Python. It could be riding a dead horse, it seems to me.

Also Python is more attractive to me since it can be used to program the Raspberry Pi, but honestly I will likely not find the time in this live to play with that…

So, Python:
In one day I had installed jsr223 / Jython, wrote some helper functions for logging, timer use, etc, and converted two rather tiny rules to Python. Not that bad.

Coding in Python is not really harder than in the Rules DSL.

And Functions, waahhhh! :smiling_face_with_three_hearts: You only know WHAT a killer-feature :gun: that is if you don’t have them (in Rules DSL).

The key to make it to jsr223/Jython were for me the good and clear instructions I found (much too late), after some irritating link hopping from the OH jsr223 page, to github and what not.

Click here!
Click now!
Or at least today!
Last chance!
Click and win! It’s almost serious!

I really should have do (find) THAT from the beginning, and if you read this and ask yourself what rule language you should begin with: JSR223 and Python!
This is the truth, the only valid and possible answer - everything else is completely wrong, even if stated in a reply otherwise. Be wise and do it, and also don’t forget to elect me as your next president - you will not regret, I promise! :lying_face: :grimacing:

(Error: This post reached the maximum count of smileys.) :wink:


But only if you are using the helper libraries! Without them, rules in any scripting language are extremely complex and ugly. The interface for the new rule engine needs to be cleaned up a LOT. Once that is done, the core helper libraries will no longer be needed.

Scripted automation and Jython

More details here…

… and an easier install…


One correction to the install process:
The link to the standalone Jython 2.7.0 jar is dead. This one works:

Thank you very much. The descriptions are strict, clear and nice, and the whole documentation is exceptional well organized! And “How do I…” :smiley: :+1:

1 Like

Thank you… this has been reported several times in GH. The next update will correct it and update the link to 2.7.2, which has been working great for me.


Once you migrate your rules to jsr223/jython and the helper libraries you easily get into that mode that you feel the need to thank everyone who put work and intelligence into it to make that happen. :pray:
One of the marvellous gains is how fast the scripts load. openHAB2 restart time is about a third now of what it used to because the loading of scripts that took like 10 minutes before goes like woosh now. :smiling_face_with_three_hearts:
The situation had come to the point with DSL that I feared to add or edit any item because that would trigger a a reload of all .rules, 10 minutes of chaos and slowness. And all that is forgotten now, .py files don’t appear to get force-reloaded (or it happens so fast that I couldn’t notice it).
Thanks to everyone involved!

Interesting that I’ve just been made aware by @rlkoshak about the lack of rule reloading in python and how it is actually causing problems. I didn’t know that rulesdsl gets reloaded whenever group membership changed.

What kind of problems? Do you have a link?

Your mixing a couple things up, @JimT

  1. In the old rule engine, ‘System started’ triggers will fire whenever Items or Things are added or removed.
  2. The "Member of’ trigger is something I made in the Jython helper libraries to simulates what you see in the rule DSL by adding Triggers for each of the group members. I have not added functionality to update the rule’s Triggers when the group membership changes, since this needed to be done properly and built into a ModuleType for the new rule engine, where it would be available for all scripting languages and JSON rules. A ModuleType has been built for ‘Member of’ in OH 3.0. I haven’t tested it yet, but I expect that it will update the rule Triggers when group membership changes. Until then, you will need to restart the rule if group membership changes, which I’ve explained this a few times in the forum. When I find time to get the OSGIEventTrigger working again, it can be used to programmatically restart the rules when group membership changes for those people who do not jump into OH 3.0.
1 Like