Maybe there are several errors coming together. But at least I was now able to reproduce one error.
When I install the included Python Scripting, everything works perfectly.
When I install Python Scripting Next from the Marketplace or via the addons folder, it automatically uninstalls after a short time.
The strange thing is that this only happens on my test system.
It works on my production system. The difference here is that I didn’t install the binding via the web interface or just moved the kar file to the addons folder.
Instead, I moved the kar file to the addons folder and additionally I also added the following configuration to the conf/services/addons.cfg file:
automation = jsscripting,pythonscripting
To avoid spamming this thread, I created a follow up thread for this strange behavior.
New setup:
Python rule runs the whole code.
Runtime 30s
So I can confirm that the Python Scripting is factor ~4-5 slower than native Python.
Until 2 years ago, I worked with the Jython scripting and I would judge Jython performance similar to today’s Python scripting performance, but cannot include Jython into the benchmark as I don’t run it anymore and don’t want to backport everything which has been changed since then.
When I ported everything to JS around 2 years ago, I also implemented the algorithm in JS, but that was dramatically slower, it was running for 3-5 min, I think. That is why I was using the workaround with JS calling a native Python script.
I’ve just tried out the latest version (Version 27.07.2025 16:15) with VENV and tried to install the adafruit-pca9685 pip package to control the servo board connected to my Raspberry Pi. But I got the following error during installation:
Building wheels for collected packages: adafruit-pca9685, Adafruit-GPIO, spidev
Building wheel for adafruit-pca9685 (pyproject.toml): started
Building wheel for adafruit-pca9685 (pyproject.toml): finished with status 'done'
Created wheel for adafruit-pca9685: filename=adafruit_pca9685-1.0.1-py3-none-any.whl size=3968 sha256=16497a4ed21942a246aaf567cf8279666c0be5eec3b241716d708912468b7a16
Stored in directory: /openhab/.cache/pip-graalpy/wheels/87/32/d3/e6f1332807b8e458794bffbab6e836dc29250748dbbdf37f23
Building wheel for Adafruit-GPIO (pyproject.toml): started
Building wheel for Adafruit-GPIO (pyproject.toml): finished with status 'done'
Created wheel for Adafruit-GPIO: filename=adafruit_gpio-1.0.3-py3-none-any.whl size=38320 sha256=344b39c34087eeaab6550e486588ee8734a87573bfb270ca336a7d8ced47803d
Stored in directory: /openhab/.cache/pip-graalpy/wheels/4c/74/33/e95b55456a3da495f518d8779681dc3fb23e2f88cffea514fa
Building wheel for spidev (pyproject.toml): started
Building wheel for spidev (pyproject.toml): finished with status 'error'
error: subprocess-exited-with-error
× Building wheel for spidev (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [20 lines of output]
/tmp/pip-build-env-7eley6zd/overlay/lib/python3.11/site-packages/setuptools/dist.py:759: SetuptoolsDeprecationWarning: License classifiers are deprecated.
!!
********************************************************************************
Please consider removing the following classifiers in favor of a SPDX license expression:
License :: OSI Approved :: MIT License
See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
********************************************************************************
!!
self._finalize_license_expression()
running bdist_wheel
running build
running build_ext
building 'spidev' extension
creating build/temp.linux-aarch64-graalpy242-311
cc -DNDEBUG -D_GNU_SOURCE=1 -fPIC -I/openhab/userdata/cache/org.openhab.automation.pythonscripting/venv/include -I/opt/docker/openhab/openhab/graalpy-24.2.1-linux-aarch64/include/python3.11 -c spidev_module.c -o build/temp.linux-aarch64-graalpy242-311/spidev_module.o
error: command 'cc' failed: No such file or directory
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for spidev
Successfully built adafruit-pca9685 Adafruit-GPIO
Failed to build spidev
ERROR: Could not build wheels for spidev, which is required to install pyproject.toml-based projects
The slowdown for python and javascript is similar, because both are using the slow Interpreter mode of graalvm. But we are evaluating the use the faster JIT Compiler. With that you will have similar performance like native python.
In the logs, you can see that the “cc” compiler is missing to get this module running.
now, it depends how you tried to install it.
if you are using the openhab python console like “pythonscripting pip install…” then there is no real way to fix, because I can’t make the “cc” compiler available inside a VM
but you can try to preinstall this module on you host system using the native venv pip. Before you must install the “cc” compiler on your host system. After just run e.g.
In my case - definitely not.
Handling of large lists / matrices was extremely slow in JS. I looked up my old posts, and I had JS execution time 8-10 times larger than Jython. I did not find effective measures to speed up and then at that time moved to a solution with calling native Python. In addition js-joda is really slow compared to Python datetime, those calls I could reduce to a minimum, but did not help much.
I’ve now managed it to get the adafruit-circuitpython-servokit library installed. I also had to install lgpio. This did not work with the pip installer in GraalPy, so I compiled the library directly from the source. After that the installation of lgpio in GraalPy worked.
But now I’m getting an error when importing the library in a Python script in OpenHab:
2025-07-28 20:31:40.809 [ERROR] [utomation.pythonscripting.pca9685.py] - Exception in thread Thread-1:
2025-07-28 20:31:41.161 [ERROR] [utomation.pythonscripting.pca9685.py] - Traceback (most recent call last):
2025-07-28 20:31:41.212 [ERROR] [utomation.pythonscripting.pca9685.py] - File "/openhab/userdata/cache/org.openhab.automation.pythonscripting/python/python-home/e41832d1c8ba537cb2b83ce5a12dcd289d98a725/lib/python3.11/threading.py", line 1045, in _bootstrap_inner
self.run()
2025-07-28 20:31:41.215 [ERROR] [utomation.pythonscripting.pca9685.py] - File "/openhab/userdata/cache/org.openhab.automation.pythonscripting/venv/lib/python3.11/site-packages/lgpio.py", line 542, in run
buf += self._file.read(RECV_SIZ)
^^^^^^^^^^^^^^^^^^^^^^^^^
2025-07-28 20:31:41.224 [ERROR] [utomation.pythonscripting.pca9685.py] - OSError: [Errno 5] Illegal seek
I’ve also tested the same script using native python in the same Docker container and the script worked. So I guess this is a problem with GraalPy.
I found out that the lgpio.py script on this line tries to read file .lgd-nfy0. Here is the line in lgpio.py that causes the error:
buf += self._file.read(RECV_SIZ)
I found out that the directory where this file is saved can be set with the LG_WD environment variable. After setting this to/openhab/userdata/tmp I can see the file and it also has the user and group set to openhab. So this should not be a file permission issue.
Is this some sort of limitation with GraalPy or what could be the problem?
Also When I change something in the Python script in OpenHab I get the following error:
SystemError, Option python.NativeModules is set to 'true' and a second GraalPy context attempted to load a native module '_lgpio' from path '/openhab/userdata/cache/org.openhab.automation.pythonscripting/venv/lib/python3.11/site-packages/_lgpio.graalpy242-311-native-aarch64-linux.so'. At least one context in this process runs with 'IsolateNativeModules' set to false. Depending on the order of context creation, this means some contexts in the process cannot use native module, all other contexts must fall back and set python.NativeModules to 'false' to run native extensions in LLVM mode. This is recommended only for extensions included in the Python standard library. Running a 3rd party extension in LLVM mode requires a custom build of the extension and is generally discouraged due to compatibility reasons.
I already read some posts about this error. Will this be resolved in the next GraalPy release?
I don’t know, but I hope. GraalPy will be improved a lot with every release. I heard also that they want to improve a lot of things with venv which could affect native modules like yours.
I have not yet enabled native modules. When I understand this correctly with native modules I would only be able to use the library in a single Python script. Is that correct?
And what could the problem with the OSError: [Errno 5] Illegal seek error I get in the lgpio python script?
No, with native modules, you will be able to use the lib in more then one context.
My guess is that “Illegal seek error” is related to that. Because it is an error somewhere in this lib and maybe the reason for it is a not fully initialized/loaded lib.
Thanks for the hint. I just tried to enable native modules by adding -Dpython.NativeModules=true -Dpython.IsolateNativeModules=false -Dpython.ForceIsolation=false to EXTRA_JAVA_OPTS. But pythonscripting info still reports that nativeModules is false.
I also looked if the setting is in the Configure Python Scripting in the UI, but for some reason the whole config page it missing. (I installed the addon by uploading the kar file to the addons folder)
Normally via “Configure Python Scripting”… But I can confirm. In Python Scripting Next, the is an issues that the config page is not visible, because the config setup is still bound to the name without “next”…
I tried the new kar file, but the settings did not appear. So I just installed the Python Scripting Next addon from the marketplace and then the settings did appear in the UI.
I’ve now enabled the nativeModules setting and confirmed that it is enabled with pythonscripting info.
The error regarding the native modules is now gone when I change something in the Python script.
But the OSError: [Errno 5] Illegal seek error is still there. Any other ideas what could cause this problem?
It looks like that addon folder based bindings, don’t register their settings dialog. In this case you can configure it in /conf/services/pythonscripting.cfg
As a very hacky debugging, you could add some print statements in the following pythons script near line 542
.