Python3 Binding (Discussion)

Add-ons Bindings
, ,
21

What do you think would be a perfect default behavior? You can already

  1. enable/disable the scope/import wrapper. If it is disabled you have the global jsr223 variables back again
  2. enable/disable the availability of the helper libs (deployment and update)
  3. enable/disable pyc caching
  4. enable disable jython emulation

I think a perfect default behavior for UI based rules would be the automatic import of 3 things

  1. the “scope” object which wraps all jsr223 objects
  2. the “Registry” object which is more or less the entrance point for the whole API
  3. the logger object

This means I would inject 2 statements for all UI based rules by default

import scope
from openhab import Registry, logger

And I would inject these statements only if

  1. scope/import wrapper is enabled
  2. the helper libs are enabled
  3. maybe a new “inject” setting to control this behavior
22

I don’t really know what the best defaults would be. Ideally controlling whether or not stuff gets injected is a strong users can access through MainUI.

Beyond that, when enabled users should have access to most everything you’d usually want to do in a rule without imports like getting states of Items, commands and updates, actions, item metadata, etc. If all that is available in those two and those can be injected by default and the setting for that is accessible through the UI then it all should be good

I only posted to make sure that the UI users are not forgotten. Often choices which make perfect sense for file users and may even be programming best practices can impose a high burden on UI users, and these are the users least able to accommodate that burden.

It sounds like it’s all good.

23

Because I think it is a very useful feature, I just implemented it. :slight_smile:

There is now a new release in the marketplace which implements auto injection for all non file based rules (UI Rules and Transformation Scripts). And it is configurable.

There are 3 config options now

  1. Disabled
  2. Enabled for all scripts
  3. Enabled for UI and Transformation scripts (Default)

UI users were not forgotten :wink:

1 Like
24

Another new release is available in the marketplace

Changes are

  • script context cleanup/close fix for compiled scripts (e.g. transformation scripts)
  • log prefix for UI based and transformation scripts fixed
  • logging cleanup and simplification
25

Hi

I’m trying to run my pythonscript. However, I always get the error: “ModuleNotFoundError, No module named”
I put the module in “/conf/automation/python/lib/”.
Do I have to consider anything else to continue importing modules correctly?

26

There is nothing special to consider.

I tried to reproduce, but without success.

I created a file __init__.py inside the folder /conf/automation/python/lib/named/ with the content

TEST = "1"

Then I created a test.py inside /conf/automation/python/ with the content

import named
print(named.TEST)

The log shows me that everything works.

2025-02-26 15:30:41.271 [INFO ] [ort.loader.AbstractScriptFileWatcher] - (Re-)Loading script '/openhab/conf/automation/python/test.py'
2025-02-26 15:30:41.528 [INFO ] [b.automation.pythonscripting.test.py] - 1

Maybe you can provide more details.

  • are you using the latest binding version?
  • which openhab version are you running
  • what kind of module are you talking
  • how are you using it (how looks your import statement)
  • are you running a file based script or a script created via webui
  • have you checked the file permissions?
  • is there anything else in your openhab logs or systemd journal
27

Thank you for the quick response.
It is working now, was my fault.
I put the modules in /conf/automation/python/lib/openhab/

28

just want to mention this discussion here.

29

I’ve started writing a migration guide to help porting the old legacy helper lib scripts. However, it’s far from complete.

Since I’m lacking some perspective on your porting efforts and each perspective is different, I’m looking forward to receiving suggestions and experience reports so I can incorporate them into the guide and include relevant examples.

check MIGRATION.md

3 Likes
30

a new release is available in the marketplace

it contains a lot of cleanups and fixes, but the biggest highlight is the upgrade to graalvm 24.2.0. There, the highlight is, that a lot more polyglot.Foreign objects are inheriting from native python types. Means, they feel and behave like the native python object.

Foreign objects are now given a Python class corresponding to their interop traits. Foreign lists now inherit from Python list, foreign dictionaries from dict, foreign strings from str, foreign iterators from iterator, foreign exceptions from BaseException, foreign numbers from polyglot.ForeignNumber, foreign booleans from polyglot.ForeignBoolean, and foreign null values from NoneType. This means all Python methods of these types are available on the corresponding foreign objects, which behave as close as possible as if they were Python objects.

1 Like