Python3 Binding (Discussion)

[holger_hees]

Python scripting provides its own Registry class for accessing items, things, and channels. The Item API can also be used to access the Persistence, Semantic, and Metadata APIs. Rules, actions, conditions, and triggers are also encapsulated as separate classes. And JSR223 Objects can be used through the scope object.

The rest is more or less a direct forwarded Java API.

The advantages are significantly reduced maintenance effort, 100% access to openHAB core APIs, and the availability of new openHAB APIs without modifying the Python API.

For most use cases, the Pythonscripting API and the scope objects are perfectly sufficient. Experienced users can jump deeper into the openHAB Java API.

Pythonscripting focuses on people who want a “pure” access to openHAB functionality, without large abstraction layers. Oh, and you should like Python for things like that

[STSC]

@holger_hees

From the pythonscripting perspective, I want to wait until the new major update of graalpy. Before I don’t want to spent more time into this topic. Otherwise we implement solutions which may be obsolete with the new way of handling venv. They announced to me that a lot of things will change in this direction

Is GraalVM 25.0.1 the version with the major changes regarding venv or will there come more?

[holger_hees]

@holger_hees

From the pythonscripting perspective, I want to wait until the new major update of graalpy

My answer is not valid anymore.

1. I changed my opinion and implemented venv handling a few days after I wrote this answer. So venv setups is working since 4 month.
2. Yes, graalvm 25.0.0 is the version I was talking about. But I have not observed any major change. Except a python specific config which is now obsolete. Maybe this version is the base for more venv cleanups and simplifications.

Anyway. Venv setups can be used since 4 month with the latest marketplace version or with openHAB 5.1

[STSC]

Does this mean that it is already possible to setup several VEnvs inside a rule without logging into openHAB console? How can the VEnv be selected for each rule?

[holger_hees]

No.

This limitation isn’t due to GraalVM. It’s more a lack of support in openHAB core. Currently, there’s no way to manage these kinds of settings for individual rules. Furthermore, various aspects of rule initialization would need to be reworked. All of this lies outside the scope of pythonscripting and is therefore not currently my focus.

My statement referred to general Venv support. Initially, I wanted to wait for the next major GraalVM release. However, after experimenting a bit, I’ve implemented it now.

[holger_hees]

can I ask you why you want to have separate venvs per rule.

why not having one venv, install all modules you want with pip and then just use it in all rules.

are you expecting any performance impacts. Or do you have some kind of incompatible modules?

[STSC]

I would like to write something like a Rule Binding.

The idea is to install the CarConnectivity Python API with a rule into a Venv. Then use another time triggered rule which calls the CarConnectivity CLI and copys the CLI results to Openhab items. I also don’t want to use MQTT.

GitHub - tillsteinbach/CarConnectivity: Python API to retrieve telemetry data from various...

These are the steps which need to be done manually on console to setup the Venv. I would like to do this in a rule.

ConnectedCar Binding myAudi, Volkswagen, VW ID, Skoda, Enyaq, Seat, Ford, WeCharge

Ok, with help of the carconnectivity developer Till Steinbach I managed to run carconnectivity on openhab 4.3.4 (openhabian) for my Skoda Enyaq. Here is a step-by-step manual (also for my records): Create a virtal enviroment venv (in my case I named it “enyaq-venv”): python3 -m venv enyaq-venv go to directory: cd /home/openhabian/skoda-venv/bin activate venv source ~/skoda-venv/bin/activate Install all packages: pip install \ git+https://github.com/tillsteinbach/carconnectivity-plu…

[holger_hees]

You could create python scripts outside of openhab and call them from a openhab rule with the exec binding.

Or setup CarConnectivity with pip in the default venv and just ignore it in other rules. It should not affect other rules, until it is used.

[Fuzzy (Alex B.)]

Hi everyone, Holger,

first of all thanks to you @holger_hees for investing so much into the Python 3 binding. Finding this was a Christmas present I have a number of Jython rules that I want to migrate and see this as my way forward… And to finally upgrade to a recent Openhab version by doing so.

My rules need additional modules installed (e.g. requests). From what I understand, I need to setup a graalpy-based venv to support additional modules with the Python 3 binding (Python Scripting - Automation | openHAB).

Now I have the question how the upgrade process works with respect to the Python 3 binding. So e.g. from 5.1 to 5.2 in some months. From what I understand, bindings are linked to the Openhab version. So there will be a new binding version delivered with 5.2. For Python3, likely this will also include a new GraalPy version (looks like ~ every 2 months there is a new Graalpy version).

I’m running on docker. In my current setup, I have a dockerfile that installs Jython and the modules needed into the recent image. This allowed to upgrade by re-building the image and run Openhab with the upgraded image.

Looking at the installation process of the Python 3 binding, I assume the following process:

• Fire up Openhab with the newer image but the existing configuration, userdata, etc.
• Openhab automatically installs the latest Python3 bindung
  • Graalpy venv, as located in userdata, will have survived and be on a older version than the Python 3 binding
  • Graalpy itself will not exist anymore, as it was installed in the previous container itself (/opt/graalpy)
• I need to connect a terminal to the running container and i) install the latest Graalpy version, ii) re-install venv and iii) re-install the required modules

Is my assumption correct / any suggestions?

Could the upgrade of Graalpy and the venv be moved into a dockerfile? If I could manually set the venv path (to something not under userdata), this would already allow doing so.

Thanks!!!
Regards
Alex

[holger_hees]

@Fuzzy Yes. Your assumptions are correct. Currently, a venv setup is tied to the correct graalvm version. This means, it must be re-initialized with each openhab release, if it contains a new graalvm version.

In your case, you could simply mount or symlink another venv directory in userdata.

I known that none of this is ideal. But I think it will be improved on the Graalvm side in the future. At least the Graal developers have once mentioned that they are not yet satisfied.
On openhab side, I may include a check that shows a warning when venv is enabled, but does not fit the openhab graalvm version. Furthermore, I will display the Venv Graalvm version in the pyhonscripting infos provided by openhab cli. There was only recently a user who also stumbled across it.

I myself also faced the problem that I used the requests module in jython. However, I was able to map all use cases using http action and currently do not use venv.

[sjcliffe (Steve Cliffe)]

Firstly, thank you @holger_hees for this binding. Some years ago I used the old Jython binding but when it seemed to become unsupported I reluctantly went back to DSL. When 5.1 was released recently I spun up a test server and have been migrating my rules to the new Python3 binding and it’s much nicer.

I saw that back in July that someone asked about the ability to turn off or filter the “Rule executed in …” log messages, but after going through this thread I couldn’t see any update. I too am finding them quite noisy and would like to filter them out so just wondering if there is any update on this?

Thanks!

[holger_hees]

Just use runtime_measurement=False

Or check the README for more details.

[Willem (Will van Gemert)]

Hi, I am new python and have just managed to install the Python3 binding and have my first rule transfered from rules DSL and working. How do I select the correct interpreter in VScode? Keep getting the message ‘select interpreter’.
Can’t find an answer on this, can you point me in the correct direction?

Regards Will

[holger_hees]

@Willem

I’m not a Visual Studio Code user myself, but I’ll try to help.

First, you don’t need a Python interpreter to edit Python code. This means it’s something additional to Visual Studio Code and not related to openHAB’s python scripting.

My guess is that it has something to do with syntax highlighting, and you can select the Python version being used, or your locally installed Python, which Visual Studio has detected. OpenHAB uses Python 3.12.8, by the way.

This can easily be found out using the OpenHAB CLI with the command pythonscripting info.

If you want to learn more about Visual Studio Code and Python, this might help you.

[Willem (Will van Gemert)]

@holger_hees

Thank you for your quick respons, went thru the link you mentioned and that was very helpfull, I’m now a few steps further and just found out that I have installed a wrong the graalPy version, (installed the AMD64 one as per instructions but am running on a RPI so had to install the aarch64. (Had an error message but apperantly I missed that yesterday.) Thanks for your help .