Error with openhab(?) py script after Update to 4.0.1

All I can say is that things change.

When OH 3 was released the developer maintaining the Jython add-on and the Helper Library disappeared. A fork was made and there was a scramble to make the helper library compatible with OH 3 as only the one person who disappeared had any rights on the original repo. Since then there has been no one volunteer to support the Jython add-on and the Helper Library hasn’t seen a merged PR for at least two years.

And all that lack of work and interest from the OH side of things probably has something to do with the fact that there has been no progress on the upstream Jython project itself. Python 2.7 has been end of life for several years now yet the Jython project still shows no sign of Python 3 support any time soon. And there is very little working being done on that project at all.

No one can predict the future with 100% accuracy. At one time Jython’s future looked bright. Not any more.

All the more reason to start looking at migrating now when you have the chance to take your time rather than later when there’s an update somewhere that completely breaks Jython for good.

My understanding it there is very little that HABApp cannot do that the built in OH rules can. But keep in mind that most of the rules syntax stuff you are used to working with was provided by the Jython Helper Library. So anything is going to look different from what you are used to.

What about it? No one is really maintaining it. But as things change in openHAB core that require changes to the add-on to keep it compiling and running maintainers do step in and make those changes. However, they are not making additions to the add-on to account for new features added to core. Also, the Helper Library isn’t part of openHAB. The core Jython capability itself is not part of openHAB. Those are both third party and neither really has sufficient support any longer. All the work in the world on the add-on doesn’t matter if the upstream Jython or downstream Helper Libraries are not kept up.

Some of the features in OH 4 that I’m pretty sure Jython doesn’t support even now include:

  • new rule triggers like Time is <item> and system startlevel triggers
  • sharedCache and privateCache which lets you store stuff outside of the rule and, in the case of sharedCache share between rules. The caches are nice in that they clean up after themselves if all the rules that reference an entry are reloaded to include cancelling timers.
  • features to make coding rules in the UI reasonable like auto injecting the helper library rather than requiring the same explicit imports for every single script action/condition.

:person_shrugging: I see no reason why it wouldn’t be. But it too is not a part of the official openHAB repos. I don’t know what, if any, succession plans they have should the lead developer disappear for whatever reason. But it runs on standard Python so at least you don’t have to worry about that going away or breaking.

Most of the above lessons learned have been applied to the remaining languages in OH 4, particularly GraalJS (i.e. JS Scripting) and jRuby. In both of those cases the upstream capabilities are currently actively supported, the helper libraries are a part of the openHAB project (and come with the add-on), have multiple maintainers, and since they are a part of the openHAB project itself, the project leads can assign new maintainers should the need arise.

Blockly, the graphical programming language in MainUI “compiles” to GraalJS for what ever that’s worth.

And I suspect you might find that you can do more with less lines of code in both jRuby and GraalJS than you can with Jython, if lines of code is a concern. Also don’t forget to look at rule templates on the marketplace. Why recode a rule that you can just install and configure? Finally, look for other third party libraries which can help as well. For example I have openhab_rules_tools which provides a bunch of libraries for making working with timers a lot easier. For example, if you have a rule that needs to keep a separate timer for each Item that triggers the rule:

var {timerMgr, helpers} = require('openhab_rules_tools');
var timers = cache.private.get('timerMgr', () => new timerMgr.TimerMgr()); 

var runme = () => {
  // code to run when the timer goes off

var flapping = () => {
  // code to run when the timer already exists

timers.check(event.itemName, 'PT5M', runme, true. flapping);

That call to check will create a new Timer keyed on the Item name if one doesn’t already exist to go off in five minutes and call runme. If one does exists, reschedule it and call flapping. The last two three arguments are optional.

Thanks for sharing it.

We all need to learn a lot from you! So a very warm thank you for all you are doing.

Just coming back to original post giving an actual state:

  • Error on 100_Directory still exists, but seem to have no negative impact (at least on my system)
  • Reloading .py-Scripts after changed running again, maybe I just didn’t wait long enough after the update (about 1 or 2 hours after update, I still had the problem, now its gone)
  • Some confusion exists on my site, because my “old logging mechanism” in python (import logging from core.log) don’t cause an error, but logging not working anymore. Needed to change to Syntaxt based on import LogAction from core.actions

Still some scripts seems to have minor issues, maybe because of checking Number-Items with unspecified number-types.

I will report.

Thank you so much, Rich.

I will port my rules to something else. Even if HABApp looks great, I will also have a look at JS Scripting because my impression is that the structure (not the syntax) could be more similar to what I have at the moment.

That might be just a missmatch in the logger names and log4j2.xml. IIRC the logger names created by the helper library do not correspond to any of the loggers configured in log4j2.xml meaning the default logging level will be WARN. You can show if this is the case by logging something at the warn or error level and watching openhab.log. You should see the name of the logger as part of the log line.

When you use the LogActions, you are using the Java openHAB loggers same as you do from Rules DSL meaning most of the logger name is predefined for you based on the standard.

I started right away and tried to implement a very simple JS Scripting rule.
The add-on was already installed, I am on OH 4.0, and I tried to save the .js file to openhab-conf/automation/js. It said:no permission to make changes or add files here. So I chose “fix permissions” in the openhabian-config menu, then it worked.
First impression: It reacts extremely slow compared to Python. It took ~40 seconds to tell in the log:
Adding rule: …
Also the rule itself took 20s longer to report a changed item state in the log than the same Python rule.
Any similar experiences out there?
I mean, available memory (2 GB total) is very limited, but Python does not seem to have any problem with it…

I asked the question about performance here, think that it fits better into that thread:

I think there is a known bug that is in work being fixed regarding the slow first run of a JS Scripting rule.

But I’ll also just caution you that even if Jython is the fastest best option in the world, it doesn’t really matter. If sticking to Jython forever were an option you wouldn’t need to be going down this path in the first place.

I agree, but if there were serious performance concerns I would rather wait until either they are solved or it is urgent enough to spend more hardware.
Actually, at the moment it is also really slow in subsequent runs, not only in the first run. I am not seeing any major memory or CPU usage spikes.

There have been no reports of JS Scripting rules running slowing all the time. The first run it needs to be “compiled” and that can take some time and there was a problem with some changes in the way caching is implemented in the add-on. Are you using the helper library that comes with the add-on and is the Settings → Automation → JS Scripting ->Blue Gear Icon → Use Included Library checked? That should be the default.

Yes, that is checked.
Maybe Jython and JS scripting interfering with each other somehow?

Not likely. Jython uses JSR223 (or what ever it’s called now) and JS Scripting uses GraalVM. There should be little to no interaction between the two.

I’ve long since abandoned file based rules so maybe something specific to that is going on. Are you usign JSRule or the rule builder approach?

I am using JSRule.

About all I can recommend is gather what information you can and file an issue. No one else is reporting this specific problem so :shrug.

OK, thanks.
And what you assumed was right. I tried the UI-based approach and it didn’t have any significant delay with respect to Python. So must have to do something with file-based in general or JSRule approach.

It’s really funny: I have now four rules doing this one log entry when the phone status changes to status DIALING. This is the output:

2023-08-01 18:23:06.518 [INFO ] [jsr223.jython.Jython Telefon-Anruf  ] - Python rule triggered: DIALING
2023-08-01 18:23:06.524 [INFO ] [nhab.automation.script.ui.dae3a200ac] - UI-Rule triggered:  DIALING
2023-08-01 18:23:06.528 [INFO ] [nhab.automation.script.file.anruf.js] - JS(RuleBuilder) rule triggered:  DIALING
2023-08-01 18:23:10.528 [INFO ] [nhab.automation.script.file.anruf.js] - JS(JSrule) rule triggered:  ACTIVE

So every approach except for the JSRule one is working fast, some delay occurs for the JSRule rule. JSRule is so slow that the status in the meanwhile has changed to ACTIVE. :grinning:

Definitely file an issue. What’s really odd is behind the scenes rule builder uses JSrule so it’s definitely odd.

Should I file it in GitHub? If so, where exactly?

1 Like

Ok, did the bug report on GitHub:

1 Like

Nevertheless, I started porting very simple Jython rules to JS with the rule builder. So far nothing I am missing. I will have to dig more deeply into how to use libraries and so on.