How to Setup Jython

This would be great! At some point last december I decided not to update until the developement cooled down a bit. So all breaking changes would be covered with one update. Think I already sould have done this but other things kept me busy. But with versioning and changelog it would’ve gone different.

No harm done :+1:

1 Like

I found
I managed to setup jython this way. An automatic install would be very much appreciated.
I’m not a linux guy, so, I had to search linux commands… But in the end, I succeeded.

This is on it’s way and can be tested here…


I am trying to setup Jython on Openhabian 1.5 (Openhab 2.5) following the instructions here:

I have downloaded this the Jython JAR here, which should be the correct one(?):

I have setup the folders and paths according as described. However, I do not get any output in openhab.log, when creating the file in automation/jsr223 as described in configuration-testing.

I have also tried enabling debug-output in the Karaf console log:set DEBUG org.openhab.core.automation. But that still does not give any output.

I also tried moving to automation/lib/python/ and automation/jython/, which also appear in the EXTRA_JAVA_OPTS, but that does not change anything.

I restarted Openhab in between by doing sudo systemctl restart openhab2.service.

I have no idea what to try next, so any support would very appreciated. Thanks in advance!

The easiest way to setup Jython is to use this bundle…

It also includes the core and community helper libraries, which you can read about here…

In those docs, you can also find detailed installation instructions, if you’d like to manually install everything. The official documentation needs to be updated, but it’s hard to get started with that until some of the details for OH 3.0 become finalized. Shout if you need any help!

I tried to install jython on my dev machine (RPi4 running openHABian) but failed.
Purged OH, installed 2.5.9 and followed the install instructions first.
But I kept getting this error
2020-10-09 11:48:41.152 [INFO ] [me.core.service.AbstractWatchService] - ScriptEngine for py not available

EXTRA_JAVA_OPTS is properly set as you can see below.
I can’t find out what’s wrong. All settings (seem to) match that of my (working) production box.
Any ideas ?

[12:28:48] root@devpi:/etc/openhab2/automation/jython# ps -ef|grep java|grep ython
openhab  10579     1 23 12:29 ?        00:01:51 /usr/bin/java -Dopenhab.home=/usr/share/openhab2 -Dopenhab.conf=/etc/openhab2 -Dopenhab.runtime=/usr/share/openhab2/runtime -Dopenhab.userdata=/var/lib/openhab2 -Dopenhab.logdir=/var/log/openhab2 -Djava.library.path=/var/lib/openhab2/tmp/lib -Djetty.http.compliance=RFC2616 -Dorg.ops4j.pax.web.listening.addresses= -Dorg.osgi.service.http.port=8080 -Djava.awt.headless=true -Xms192m -Xmx320m -Xbootclasspath/a:/etc/openhab2/automation/jython/jython-standalone-2.7.2.jar -Dpython.home=/etc/openhab2/automation/jython -Dpython.path=/etc/openhab2/automation/lib/python --add-reads=java.xml=java.logging --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED --patch-module java.base=/usr/share/openhab2/runtime/lib/endorsed/org.apache.karaf.specs.locator-4.2.7.jar --patch-module java.xml=/usr/share/openhab2/runtime/lib/endorsed/ --add-opens java.base/ --add-opens java.base/ --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.naming/javax.naming.spi=ALL-UNNAMED --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED --add-opens java.base/ --add-opens java.base/java.lang.reflect=ALL-UNNAMED --add-opens java.base/java.text=ALL-UNNAMED --add-opens java.desktop/java.awt.font=ALL-UNNAMED --add-exports=java.base/ --add-exports=java.base/ --add-exports=java.base/ --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED -Dkaraf.instances=/var/lib/openhab2/tmp/instances -Dkaraf.home=/usr/share/openhab2/runtime -Dkaraf.base=/var/lib/openhab2 -Dkaraf.etc=/var/lib/openhab2/etc -Dkaraf.log=/var/log/openhab2 -Dkaraf.restart.jvm.supported=true -Djava.util.logging.config.file=/var/lib/openhab2/etc/ -Dkaraf.startLocalConsole=false -Dkaraf.startRemoteShell=true -classpath /usr/share/openhab2/runtime/lib/boot/org.apache.karaf.diagnostic.boot-4.2.7.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.jaas.boot-4.2.7.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.main-4.2.7.jar:/usr/share/openhab2/runtime/lib/boot/org.apache.karaf.specs.activator-4.2.7.jar:/usr/share/openhab2/runtime/lib/boot/osgi.core-6.0.0.jar:/usr/share/openhab2/runtime/lib/jdk9plus/istack-commons-runtime-3.0.8.jar:/usr/share/openhab2/runtime/lib/jdk9plus/jakarta.xml.bind-api-2.3.2.jar:/usr/share/openhab2/runtime/lib/jdk9plus/javax.activation-1.2.0.jar:/usr/share/openhab2/runtime/lib/jdk9plus/javax.annotation-api-1.3.1.jar:/usr/share/openhab2/runtime/lib/jdk9plus/jaxb-runtime-2.3.2.jar:/usr/share/openhab2/runtime/lib/jdk9plus/txw2-2.3.2.jar org.apache.karaf.main.Main

So I then installed the addon (still the download link from post #1?) but got

2020-10-09 11:40:30.926 [ERROR] [le.script.scriptenginefactory.jython] - bundle org.openhab.core.automation.module.script.scriptenginefactory.jython: (320)[org.openhab.core.automation.module.script.scriptenginefactory.jython.JythonScriptEngineFactory(537)] :  Error during instantiation of the implementation object
java.lang.NoClassDefFoundError: javax/script/ScriptEngineFactory

If your EXTRA_JAVA_OPTS is set correctly, then double check permissions on the directories and Jython jar. Also, make sure it downloaded properly and is a valid jar.

The Jython add-on should not be installed along with a manual installation. Remove the lines from EXTRA_JAVA_OPTS and the $OPENHAB_CONF/automation/lib/python/core and /community directories.

BTW, you left your post in the other topic when you split it.

Hmm, no. Looks proper and same as on my working box.

Downloaded and compared again. It’s the same as on my production box.
(BTW the download link to Jython on the instructions page is bad, omit the “s” at the end)

Any other idea before I move on to try the addon again ?
Is there any Karaf log setting or other that could shed more light ?

I actually did a ‘move’. Possibly a forum issue.

Permissions, EXTRA_JAVA_OPTS, the jar in the right directory, and a restart is all there is. The logging recommended in the installation instructions will provide all of the relevant logging. If you post a log from startup, I might be able to spot something. Are you running in docker? IIRC, you had issues the first time. Do you recall what they were?

Checked all of that. While I’d really love to figure out why the install didn’t work out I have no idea what else to look for.In the meantime I’ve disabled EXTRA_JAVA_OPTS and deployed the beta addon and this time it works. Is there anything wrong or unfinished with that ? If no, why don’t you make it the recommended solution ? It’s simpler than all those manual steps.

Not really. I believe it was a wrong path in EXTRA_JAVA_OPTS but I’m not sure any more.
This time that’s not the problem however.

No. The jar has not changed for about a year, so there’s nothing wrong with it :slight_smile:! There have been some significant changes that went into the add-on though, like being split into two, but they both have been rejected (ignored and unmerged) from all of the 2.5.x releases and are currently both closed. I have some significant updates for the libraries, some already merged, that I planned to include before the helper library add-on was merged. I’m always updating the core and community libraries.

That was the plan. I have a documentation update that I’ve been waiting to push that changes the installation to use the official Jython add-ons. After a year of fruitlessly trying to get them merged, it is clear that it will never be allowed, making you question what “first class citizen” means.

1 Like

Ugh, that’s frustrating and not how it should be. @Kai do you listen and could have a look please?
I’d consider (a single, tested) Python integration to be of utmost importance to OH’s future given that more and more people move to Jython to get rid of various DSL related issues (and probably even more would like to).
And given Scott is AFAIK the only person to drive this, you shouldn’t frustrate let alone ignore him.


I think there must have been some tremendous misunderstanding on both sides then. It definitely isn’t the case that anything was rejected or ignored.
I was under the impression that @5iver is working on and the main reason why it was considered work-in-progress and thus not being merged is that it does not yet comply with the add-on naming convention. Adding and dealing with the helper libraries was clearly a second step after that.

The reason why the PRs are closed is that Github automatically did that when we rewrote the history of that repo - this happened to many PRs and I hope this didn’t cause anyone to think that we simply close PRs without any further comments - I tried to make it clear to everyone through the automatic migration comment.
I’m thus very happy to see a PR with the migrated code (and adapted to the naming convention) and will do my best to very quickly help reviewing and merging it.


That is a complete fabrication and absolutely not true! The following list is not complete, but it clearly illustrates a pattern of how you and the maintainers have ignored and blocked my contributions. Because of this, I have no PRs merged into OH 3.0.0, even though I had planned for many of them. So much for automation being a big part of OH3! I get it… this not openHAB, but kaiHAB… but when dictators are not benevolent and treat contributors in this way, they doom the entire project.

  • The original issue requesting direction for adding a Jython add-on was created almost 2 years ago. I had asked many questions in hope of getting some feedback and direction on how to implement an add-on like this. This was completely ignored except for a single comment.
  • The original Jython and helper library combo PR was submitted with ample time to be included in OH 2.5.0, but it was ignored until there was no time left to include it in the release.
  • My issue to discuss separating automation from OHC was excruciatingly slow and continuously offtrack. Most of the maintainers ignored the discussion completely, even though it went on for seven months. Removing all of the side discussions, the outcome of the issue itself boiled down to me, compromising in order to move things along, agreeing to separate automation from OHC, with the exception of the rule engine. Seven months later, the repository still has not been created for this to progress.
  • The Jython helper library add-on sat since March 23 without a single review.
  • An RFC to simply add OPENHAB_CONF/automation/ and rename the jsr223 directory has been ignored since July 15.
  • The Jython add-on has been held up waiting for a reply from you since July 18. For the last year, I have done everything I could possibly do to get this and the helper libraries included into a 2.5.x release. The only reason that there is not a Jython add-on in 2.5.9 is that you chose to put no effort into helping, but rather prevented it from being merged by not approving a simple naming convention and repeatedly dragging things out until it was too late. I see this as an intentional act to prevent the Jython add-ons from being included in a 2.5.x release.
  • @wborn submitted a PR for a Groovy add-on just yesterday. Three hours later, it was approved, even without an agreement on what the namespaces should be or the repository that should be used for these types of add-ons. Hmmm… three hours vs one year… would that be ignored or rejected? It is great that someone else is looking into this sort of thing, especially someone like Wouter, but I have communicated several times that I have been waiting for the Jython add-on to be merged before I submitted add-ons for Groovy, jRuby, and Kotlin. Ignored or rejected?

it is unfortunate that you would wait until now to offer your assistance. Why wouldn’t you have helped over the last two years, while I struggled to move this along? Or the last year, to get the PRs into 2.5.x? Something has obviously changed to make you want to help now. After all of this time, I can’t possibly believe that your newfound enthusiasm and willingness to help get the Jython add-ons merged is truly genuine.

The first thing you would need to do is to create a repository for automation. Next, respond to my question about the naming convention for the namespaces.

My time is currently committed to another project that also has an upcoming release. However, I will continue to do everything I can to advance automation and get add-ons for scripting languages and helper libraries into the hands of the community.


For my part, i won’t bother moving over to OH3 until @5iver’s valuable contributions to scripting are being merged :slight_smile: What I have tried from his work works almost without problems and I am convinced that the few remaining problems are due to the circumstance that his code is not being appropriately reviewed and integrated. I am using JSR scripting (Jython) for at least two years now and I am sad to see this great opportunity of creating automation rules being kept an outsider for all this time.


I agree with that sentiment. What gives me hope is I think better things are coming.

I envy your optimism but in my opinion things will be mainly be different. :wink:

1 Like

I did not know/remember you had planned something for Groovy too. But your Jython PR definitly helped me and I also incorporated the review comments on it in my PR to get it merged quickly.

Meanwhile I also fixed rules from files not properly loading (#1725) and added an extension type for automation add-ons. These PRs should also help with adding a working and installable Jython Scripting add-on in OH3. So the automation add-ons train is definitely rolling. If there are still some issues with getting Jython working in OH3 please let me know.

Personally I think openhab-addons is currently the right repo to add these kind of add-ons. It saves us from the work of having to setup a new repo and infra (with overhead) and it comes with nice benefits of already having a lot of contributors/maintainers who can help reviewing so that prevents bottlenecks or single points of failure. We can always decide to restructure repos after we have seen how this new add-on type evolves.


I thought the reason OH was open source was so people were free to extend its functionality without the requirement it be included in the official repos. That is the way other competing smart home projects operate.