Python3 Binding (Discussion)

Add-ons Bindings
, ,
182

I was not able to reproduce it.

I created a simplified version of your script

from threading import Timer
from openhab import Registry

#This part is ugly but works to see if the timer already exist.
try:
    dummy = timer
    print("Reuse dummytimer")
except NameError:
    timer = Timer(2, None)    #Dummy
    timer.start()
    print("Create dummytimer")

def timer_lights_off():
    print("Triggered dummytimer")
    timer = Timer(2, timer_lights_off)    
    timer.start()

timer.cancel()
timer = Timer(2, timer_lights_off)
timer.start()

after the first execute, the timer runs forever. And also If I create a second script with a syntax error, it still works and is not affected.

one thing I found in your script
 You forgot a timer.start() call, after Restart timer

another bug I found is that you need to mark the variable “timer” as global if you overwrite it in timer_lights_off.

below you find the final much simplified and working version of your script

from threading import Timer

def timer_lights_off():
    print("Triggered dummytimer")
    global timer
    timer = Timer(2, timer_lights_off)    
    timer.start()

if 'timer' in globals():
  timer.cancel()
  
timer = Timer(2, timer_lights_off)
timer.start()
183

Hi,

It works now with the ‘global’. I was not aware of that. And the missing “start” off course.

Normally the timer is only running for the 120 seconds and then it is done until the next time the light is switched on.

When I was working on the other script it was probably the first time that the timer was supposed to restart


“A day when one has not learned anything is a lost day”

Thanks a lot, Valter

1 Like
184

@holger_hees GraalPy 25 has just been released. Is this the version that could fix the OSError: [Errno 5] Illegal seek. problem?

185

yes. That’s the version, containing the fix. I hope it will be used as part of openhab 5.1.

1 Like
186

@holger_hees I noticed that in the helper functions for Timer the default values are mutable, e.g.

def createTimeout(duration, callback, args=[], kwargs={}, old_timer = None, max_count = 0 ):

Though I did not notice any odd behaviour so far, and it might not have any effect in this case and is just cosmetic, to my knowledge that should be avoided

see in 8. Compound statements — Python 3.13.7 documentation

This is especially important to understand when a default parameter value is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default parameter value is in effect modified. This is generally not what was intended. A way around this is to use None as the default, and explicitly test for it in the body of the function, e.g.:

187

this happens only to objects where you work with references.

e.g. you add an object to an array, where the array is the default value. In this case, the default value is still the same array, but it contains one more object.

in our example, this does not happen. Because the number itself is not modified. Instead a new number object is created.

you can confirm this with the following code.

def test(value=1):
    print(value)
    value = value + 1
test()
test()

but anyway, the createTimeout function is deprecated and does not exists anymore in the newest helper lib. You can do the same with pure python Threads and Timers.

If you still need the complete functionality of the old createTimeout, just check the example scripts.

188

That’s correct for immutable types. For mutable this would give an (in most cases) unexpected behaviour.

def test(value=[]):
     print(value)
     value.append(1)
test()
test()
...

>>> test()
[]
>>> test()
[1]
>>> test()
[1, 1]

As createTimeout will be deprecated, does not matter anyhow and it did not have any effect in the current code too

Another thing I saw in the readme regarding logging

Using the logging module behaves like normal print statements, are prefixed with "org.openhab.automation.pythonscripting" and marked with log level INFO, ERROR, WARN ...
from openhab import logging

logging.info("info message")

logging.error("error message")

logging.warn("warning message")

from openhab import logging leads to

ImportError, cannot import name 'logging' from 'openhab' (/etc/openhab/automation/python/lib/openhab/__init__.py)
189

good catch. This is a documentation error. I fixed it right now.

Instead of

from openhab import logging the correct form is from openhab import logger

1 Like
190

Error with Timezone

Hi,

I have got an problem with handling on time zones.

I have this test code in a UI rule:

from openhab.services import getService
from java.time import ZoneId
from openhab import Registry, logger
from datetime import datetime, timedelta

now = datetime.now()
today = str(now)[0:19]
print("------------------")
print(now)
print(today)
testdatetime = "2025-09-26 10:00:00"

#start_time = datetime.strptime(testdatetime, "%Y-%m-%d %H:%M:%S")

print("User Timezone (from -Duser.timezone) " + ZoneId.systemDefault().getId())
timeZoneProvider = getService('org.openhab.core.i18n.TimeZoneProvider');
print("Regional Timezone (regional settings from webui) " + timeZoneProvider.getTimeZone().getId())
print("Datetime (test if timezone is used) " + str(datetime.now().astimezone()))
print("------------------")

I can run and save the rule as many times I want, no problem.

Logging is:

2025-09-26 17:50:15.774 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------
2025-09-26 17:50:15.775 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 17:50:15.772000
2025-09-26 17:50:15.775 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 17:50:15
2025-09-26 17:50:15.776 [INFO ] [utomation.pythonscripting.74bb0877b4] - User Timezone (from -Duser.timezone) Europe/Stockholm
2025-09-26 17:50:15.777 [INFO ] [utomation.pythonscripting.74bb0877b4] - Regional Timezone (regional settings from webui) Europe/Stockholm
2025-09-26 17:50:15.781 [INFO ] [utomation.pythonscripting.74bb0877b4] - Datetime (test if timezone is used) 2025-09-26 17:50:15.777000+02:00
2025-09-26 17:50:15.781 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------

The problem comes when I UNCOMMENT this line:

start_time = datetime.strptime(testdatetime, "%Y-%m-%d %H:%M:%S")

After save and run once the Time zone has changed:

2025-09-26 17:50:26.775 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------
2025-09-26 17:50:26.776 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 17:50:26.774000
2025-09-26 17:50:26.776 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 17:50:26
2025-09-26 17:50:26.838 [INFO ] [utomation.pythonscripting.74bb0877b4] - User Timezone (from -Duser.timezone) GMT
2025-09-26 17:50:26.839 [INFO ] [utomation.pythonscripting.74bb0877b4] - Regional Timezone (regional settings from webui) Europe/Stockholm
2025-09-26 17:50:26.844 [INFO ] [utomation.pythonscripting.74bb0877b4] - Datetime (test if timezone is used) 2025-09-26 17:50:26.840000+02:00
2025-09-26 17:50:26.844 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------

After one more save and run the time starts to get wrong:

2025-09-26 17:50:32.553 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------
2025-09-26 17:50:32.553 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 15:50:32.551000
2025-09-26 17:50:32.554 [INFO ] [utomation.pythonscripting.74bb0877b4] - 2025-09-26 15:50:32
2025-09-26 17:50:32.603 [INFO ] [utomation.pythonscripting.74bb0877b4] - User Timezone (from -Duser.timezone) GMT
2025-09-26 17:50:32.605 [INFO ] [utomation.pythonscripting.74bb0877b4] - Regional Timezone (regional settings from webui) Europe/Stockholm
2025-09-26 17:50:32.609 [INFO ] [utomation.pythonscripting.74bb0877b4] - Datetime (test if timezone is used) 2025-09-26 15:50:32.605000+00:00
2025-09-26 17:50:32.609 [INFO ] [utomation.pythonscripting.74bb0877b4] - ------------------

There must be som problem with “datetime.strptime” and it should be possible to recreate.

I run Ubuntu 24.04.3 LTS, openhab 5.0.1.

As You can see the time differs between the log-time and the datetime time.

Restart of openhab removes the issue until next time.

The following setting is still correct:

-Duser.timezone=Europe/Stockholm

All other rules continue to run correctly if I don’t save them.

Best Regards, Valter

191

I’m able to reproduce it with that code sniped too in a file based script

from java.time import ZoneId
from datetime import datetime

print("User Timezone (from -Duser.timezone) " + ZoneId.systemDefault().getId())
start_time = datetime.strptime("2025-09-26 10:00:00", "%Y-%m-%d %H:%M:%S")
print("User Timezone (from -Duser.timezone) " + ZoneId.systemDefault().getId())

I tested it in a context where all the helper lib stuff was disabled. Means no scope, no wrapper and helper scripts. All of them was disabled (to exclude problems there). And I got the same result. Could be that this is a graalpy problem. But I will investigate more into it.

192

Thanks!

I look forward to the result.

Best Regards, Valter

193

The Zone and ZoneId are Java objects. Java also has DateTime, but since it’s written datetime here, I assume that that is a Python object/variable?

I don’t know Python datetime at all, but is it supposed to hold time zone information? I mean, you don’t actually use the Java time zone for anything but logging here, you don’t actually “apply it” to the timestamp, as far as I can see..? So, the “bug” is that the time zone of the datetime object/variable seems to suddenly shift?

As far as I can tell, but timestamps are actually correct: 17:50:26.840000+02:00 vs 15:50:32.605000+00:00. The first is printed in CET, the second in UTC - but that’s merely a matter of formatting. 17:50 CET is the same as 15:50 UTC.

194

The strange thing is, that a call of the python function datetime.strptime affects somehow the java ZoneId.systemDefault() (changed to GMT) and it is persistent until an openhab restart.

additionally, the python call datetime.now().astimezone() is somehow related to the java ZoneId.systemDefault() and is going wrong, because it has the changed GMT

normally, it should always be your local timezone

195

This sounds like a very serious and bad bug in Graal or something like that then. The JVM has a default time zone that is “copied” from the OS time zone when the JVM starts. This time zone can be set programmatically, but should not normally be set. It will affect all parts of the JVM, so this won’t only affect Python, it will affect everything in OH until it is restarted. It’s a bad, bad bug! It needs to be reported ASAP, a “print function” should never ever set the default time zone.

1 Like
196

After upgrading my Raspberry Pi from Debian 12 bookworm to Debian 13 trixie (but keeping Openhab at version 4.3 for now), the pythonscripting binding fails to start with the following messages:

2025-10-08 15:04:35.494 [ERROR] [Events.Framework                    ] - FrameworkEvent ERROR
org.osgi.framework.BundleException: Could not resolve module: org.openhab.automation.pythonscripting [577]
  Unresolved requirement: Import-Package: com.sun.management

The default JRE switched from OpenJDK17 to OpenJDK21, could that be the cause?

I uninstalled and reinstalled the binding, removed the cache, restarted openhab a couple of times each in various orders, but still I get the error. Does that ring any bell?

197

not really,

jdk21 still contains com.sun.management.

I can only check the official openhab4 docker container, which is using jdk17

the openhab5 docker container, which is using jdk21, works too.

198

While 4.3 should work with Java 21 as well, I wouldn’t be surprised if was the cause. Can’t you just install Java 17 and try?

199

Reinstalling Java 17 (from Debian 12) and setting it as default (with update-alternatives --config java) seems to fix the problem. Thanks for the heads-up. I’ll stick around with OH4 for a while still, but I do plan to upgrade to OH5 as soon as a few unrelated things settle down.

200

just a short update

“pythonscripting next” is now merged with openhab main branch. This means, it will be part of openhab 5.1

1 Like
201

What does “next” mean here? Is that to differentiate it from Jython, or from the “previous GrallPy version”?