JSR223/Jython scripting in Openhab 3.1 (Docker)

Howdy! Remember me? :slight_smile:

I was pretty active on the forum for a while a couple of years ago, while setting up Openhab 2.4 on a Raspberry Pi with a bunch of ZWave gear in my small house.

Then, I got busy building the bigger house, and upon being disillusioned with zwave instability, I’ve taken the mother of all deep-dives into electronics and circuit board design and have made my own relay boards from scratch, which control all the lights in the new house, and present themselves as Homie MQTT devices. Expect a lot more posts from me in the future :).

Anyway. I used JSR223/Jython extensively in OH2.

Today, I finally set up an RPi 4 with OH3.1 running in a docker container. I am starting from scratch, not trying to upgrade the old setup.

But, I would like to be able to move some of the scripts over, and write new Jython scripts.

OH3.1 docker does not appears to have an automation/jsr223 folder.

Is that still a thing? Is there a guide for how to make automation/jsr223 file-based scripting work in Openhab 3?

I definitely like being able to place and edit script files in folders directly with my favorite editor, and have gotten used to this workflow.

I have spent quite some time trying to find information of course, but as a reborn newbie it’s difficult to know what is current, just like it was difficult to separate information about OH1 from OH2 the last time I attempted to do this.

Would appreciate any advice.

Thanks in advance!
///Leif

1 Like

I’m re-using Jython in OH3, and followed installation instructions from here:

1 Like

It might be worth considering the future of Jython at this juncture since you are somewhat starting over.

The problem is that the upstream Jython library is all but abandoned. It still only supports Python 2.7 two years after the end of life of 2.7 with no support for Python 3 in sight. So at this time the future of Python support in OH is somewhat uncertain.

No one is advocating it’s removal but at some point something is going to break and no one is going to be able to fix it.

There is the possibility someone might implement an alternative but no one has started that yet to my knowledge. It will happen at some point I’ve no doubt but not really soon unfortunately.

The built in JavaScript has the same issue. It’s deprecated and will be gone when OH moves off of Java 11 in a year or so.

But a lot of great work is going on right now to make the JSScripting add-on stable, and usable. It’s not yet released but will be soon and right now it’s the best candidate to become the “default” language. And it’s possible to make them old JS rules work on the new one.

So, I’d recommend considering whether you want to stick to Python or consider a switch to JavaScript. If the former I recommend looking at HABApp. It runs outside if OH but is pure Python 3.

If the latter consider waiting a couple weeks, unless you want to be on the bleeding edge of development in which case I can point you where to get the code and docs in progress and help get you started.

Unfortunately it seems those of us who picked Jython baked the wrong horse but at the time it was the best choice.

JSScripting had a lot to recommend it including the helper library will come with the add-on so no need to mess with copying files around. It supports the latest JS which has a lot of nice features. The library has a nice terse fluent syntax for defining rules. It supports npm to install libraries. And the library does it’s best to convert Java stuff to JS so there are fewer type problems.

Also don’t forget to look at the marketplace for rule templates. In the near future you likely won’t even have to write your own rules in a lot of cases.

3 Likes

For the courageous there is also Groovy scripting and JRule.

Hi Rich, thank you for a well throught through and insightful reply as yours always are!

That is a very, very timely warning. I can absolutely wait a couple of weeks – most of what I need right now is really just a remote control of all my homie devices, automation can wait.

I was actually already considering switching to Javascript – I’ve been a C++ programmer for almost 25 years now and I’m a lot more comfortable with that syntax, and Javascript mirrors in pretty closely.

Can you tell me more about the upcoming JSScripting add-on?
Is this related to the ECMAScript option when creating a new script?

And, most importantly – will I still be able to organize and create scripts simply by creating files in folders? This point is absolutely imperative, a web GUI will never fit into an efficient workflow. I’m sure you agree, Mr. Ansible :slight_smile:.

If you like to stay with python gib HABApp a try. It is based on Python 3, has direct mqtt connections and many more nich features.

I read a little about HABApp now, and you know what, it does sound like pretty much exactly what I need.

I mean, really, in many cases the scripts I will be writing will be only tangentially related to openHAB. I just need them to run somewhere.

Also, the fact that it’s detached from openHAB might actually be a positive, because openHAB understandably changes a lot between major versions.

I’ll definitely look into it further.

2 Likes

Give JRuby a try. I didn’t know the Ruby language before I started using it almost a year ago. The Jruby automation has just been officially added to OH 3.2, so it will be available in the next milestone or release. OH 3.1 is supported (and being tested for) too but you’ll need to download the addon jar file manually and drop it in the addons folder. When using docker, you can map the addons folder as a volume.

There’s a jruby helper library where new features are constantly being added.

You can see examples of converting rules into jruby syntax in this thread:

3 Likes

Thanks for the warning! Loosing Jython would be a pitty, but we probably have to face the fact, that it is a dead horse…

I always had the impression, that GraalVM could replace Jython one day, but if I understand you right, this will probably not happen…

This would be my third big migration, first from MisterHouse & Perl to openHAB & DSL, second to openHAB & Jython and medium term away from Jython.

This. Exactly this.

The more I think about the concept of HABApp, the more I like the idea. With the scripting being separate from openHAB, I’ll bet scripts written for HABApp for openHAB 2.x will still be working in a future version of HABapp with openHAB 6.x, because @Spaceman_Spiff probably hates rewriting old scripts as much as we do – and it’s much easier keeping things compatible when they’re already a couple of layers detached.

Also, “Easy automation with MQTT and/or openHAB”

That is really exactly what i need. I haven’t even deployed the docker container yet and I think I’m sold. Man I hope this thing works as well as it seems it might. Now I know what I’m doing tomorrow. :slight_smile:

Thanks, but right now I need another programming language like I need a hole in my head… :wink:

I have never tried it and nearly forgot, that it existed, as I am happy with Jython and the helper libraries. Today I had a short look into it and it seems promising. I will definitely try it out!

The same for me. I like Python, Javascript not so much… For a living I am developing firmware n C/C++. If no need I would prefer to not learn a language just for openHAB, when it is seldom used I will not get very proficent in it.

That does not mean, that I do not want to learn new languages, but currently I am more interested in Rust and Go, which might also be usefull for my day job. Unfortunately there are only 24h in a day…

I learned new languages because there’s a need for it. I used to develop in C++ and Delphi in my previous life. Then I had to learn Javascript, ASP (Vbscript), Perl, Bash scripting, PHP, C# and Java. Because of OpenHAB, I had to learn Python /Jython. Then now also Ruby. I must say that Ruby is unlike anything else I’ve used before. It makes coding so much more enjoyable.

This was all thanks to necessity.

I would LOVE to learn Rust, Go, and what most intrigues me right now: Julia. However, I haven’t found the need to use any of them, so the learning isn’t happening. I need some sort of a project in order to get motivated to learn them.

1 Like

The GraalVM supports Python so it should be doable in OH.

https://www.graalvm.org/python/

1 Like

That is (at least to some extend) true. For example currently it’s possible to run the OH2 scripts without changes on an OH3 instance. And even if there are breaking changes - as long as you stay on an supported OH version you can just deploy an old version of HABApp and it’ll run fine.

You can even run HABApp on your main machine and connect remotely to the OH instance to try it out. There is even a listen_only parameter in the config which will prevent that changes are made to the openhab instance.


I’m of course very happy with HABApp and it has become a very mighty and versatile tool to do automation. However it is totally different from the built in scripting so depending on your already existing python knowledge there might be a bit of a learning curve.

But if you stick to the docs you should be fine and if you have any questions or are missing something from the docs feel free to just ask!

3 Likes

Thank you very much!

Having not had time to try it yet, i only have one question so far:

I read in the docs that HABApp uses the openHAB REST API. That implies polling as opposed to events, unless I’m mistaken. Is there a response time / latency penalty involved for responding to openHAB item changes in HABApp scripts?

HABApp uses the SSE-Listener to listen to the events (so no polling).
You can configure a ping item to measure the round trip time. It’s typically around 20ms but depends on your hardware. So updates are almost instantaneous.

1 Like

The add-on is already there and you can find it under Automations in MainUI. However the latest updates will only be available in the SNAPSHOTS.

I don’t think the helper library is included into it quite yet. That’s part of ongoing work. So you might need to install those separately. The docs for the helper library which includes how to install the helper library itself using npm can be found at GitHub - openhab/openhab-js: openHAB Javascript Library.

The tl;dr for installation is:

  1. install the add-on through MainUI
  2. install the helper library using npm

Step 2 will go away when it’s released.

I exclusively write my rules in the UI now (except for a few libraries) so I can’t help much with the syntax for writing rules in files, but it’s all relatively well documented at the above link. My goal is to write rule templates and only UI rules can become a rule template.

Yes ECMAScript is the official name for JavaScript. OH comes with ECMAScript 5.1 by default. The add-on gives you the latest ECMAScript with all the latest language features.

That will always be possible except under the following circumstances:

  1. you want to create rule templates so others can benefit from your rules just by installing them like an add-on
  2. you want to use someone else’s rule template installed from the marketplace which will only be able to generate UI rules

I completely disagree but not for the reasons you may think. I want to get day-to-day users out of the business of needing to write rules for every little thing. Most of the common stuff any user may want to do should be just installed and configured like an add-on.

Also, all the UI rules are saved in text files which can be checked into git for source control. Finally, I have the ability to pull up MainUI and modify a rule where ever I happen to be in the world, from my phone super easily.

It is a different work flow for sure but with the Developer Sidebar, the code tab, the --Scratchpad-- script, etc. I find that my rules development is every bit as efficient as it was when I had all my rules in text files. And I have the added benefits of being able to create rule templates and I have access to modify my rules through the MainUI.

And since you brought it up, I still use Ansible to checkout my rules from git when I need to move OH to another machine.

Quite the opposite. It very well could happen and I’d venture to say that it will happen. But a knowledgable developer needs to volunteer and make the effort to implement it. No one has step up yet as of this writing.

2 Likes

@leif I can really recommend HABApp!

I moved my JSR rules and it has been so much easier and with python virtual environments and pip it is very easy to install whatever you need. I have only one single OpenHAB rule left which sends a notification to my phone on power outage, other than that all rules are in HABApp.

I have also replaced most bindings and instead written the functionality I need directly in the HABApp rules (or in some helper classes). All this requires that you are prepared to spend time tinkering and doing a lot of trial and error combined with some internet research so it may not be for everyone.

Reasons for not using OpenHAB bindings has been 1. not supported anymore, 2. annoying bugs, 3. limited functionality, 4. too complicated / not doing what I want… By writing my own code in python I have also been able to re-use code between HABApp and a flask-app I am running as my GUI.

3 examples where bindings limited me: 1. AppleTV , the excellent OH2-binding stopped working due to Apple upgrades, with HABApp I have built a wrapper around “pyatv”, 2. My old LG TV isn’t supported and with my own code I can easily mix IP and IR control, 3. Philips Hue. By using the API directly I can switch between complete scenes with any fading time, I can poll directly after changing a light for indication and with the latest Hue API you can also get an event stream (which I haven’t tested yet). I have played around with the entertainment API though!

Another big benefit of using HABApp is that asynchronous routines are supported which makes it much easier to handle user commands and calling external programs. Someone may comment that all this is possible with standard OpenHAB and it may very well be, but with HABApp I think it is more consistent and less limiting.

OK, perhaps my post was a bit wordy but I highly recommend HABApp to anyone and especially to the enthusiasts that like programming and want to integrate OpenHAB with almost anything.

6 Likes