openHAB 5.0 Release Discussion

Setup, Configuration and Use News & Important Changes
258

We should discuss the details somewhere else, but from what I’ve found, virtual threads would be a bad fit here. They have too many caveats. That said, you don’t need virtual threads to solve this, you only need a thread pool that is dynamic. When using virtual threads you also use an “unlimited dynamic pool”, you just don’t see it because it’s maintained by the JVM.

I could probably do the conflict resolution, but I would be unable to test/verify anything, since GraalJS doesn’t work at all for me outside of Karaf.

1 Like
259

Indeed. There are two ways that bindings could block OH core. Namely a) making calls on the OH core common HTTP client without setting a request timeout, and b) blocking the OH core thread pool.

260

Yes, and the “HTTP timeout fix” might have served its purpose, because all the problems we’ve discussed lately have been about the core thread pool.

1 Like
261

Of course one could certainly imagine adding another monitor thread in OH core that checks the running time of other threads passed to bindings, and kills them if they take too long. It would add overhead to OH core when all bindings are performing properly, but would eliminate the overhead when they are not. Also it would probably leave the respective binding in a trashed state, and perhaps therefore also trash OH core too.

262

Hi all,

now to something different… Coming from OH 4.3.6 / JRE 17, I installed Java 21 over openhabian-config and did the upgrade to OH 5.0.1. OpenHABIan on Raspberry Pi 4.

Only little stumble, but stuff went through. System is up and running.

Anyhow, there’s one thing I found in the logs:

2025-08-21 09:59:51.850 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language ‘application/javascript’ could not be found for identifier:61d46f6f-5fe2-4a7e-b655-e9af3a422cac

2025-08-21 09:59:51.880 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - ScriptEngine for language ‘application/javascript’ could not be found for identifier:3505f058-c488-4a29-8430-33700f7fef96

It appears during OH startup, rather early - it’s there on every restart, but each of then exactly only once. There is nothing similar appearing afterwards.

I tried to find the UIDs in my Things, Items, Rules - nothing. I also did not notice any malfunctions yet. So it seems like something internal which is called in the startup phase seems still to be unhappy with Java 21. Any idea how to find it? Or can it be ignored?

263

Look at this and the conclusion:

Nothing to worry even if it would be better to not have these warnings.

264

An issue has been opened. ScriptEngineManagerImpl invoked too early in the startup process · Issue #4965 · openhab/openhab-core · GitHub

1 Like
265

Does anyone have problems with saving sitemap. I cannot save changes to sitemap, there is no warning or errors only information on exiting sitemap editor

“Changes have not been saved

Do you want to leave this page without saving?”

Openhab 5.01, ubuntu 22.04.5 LTS, Raspberry Pi 4. Browser Chrome on Windows 11.

266

Yes. There was a fix in the patch release for sitemap saving, but it was incomplete. I already submitted a PR: Sitemap editor: Fix sitemap save by mherwege · Pull Request #3339 · openhab/openhab-webui · GitHub

You can save the sitemap by going in the code view and saving from there.

2 Likes
267

It has now been backported to 5.0.x, so it should be in 5.0.2 whenever it comes along.

To me, it looks like these are logged during an attempt to precompile the rules at a time when the add-ons aren’t yet available.

268

It was still in the add-ons folder and I always do one step after the other. I now removed the jar file and use the included one

269

Hi everyone,

I’ve noticed that when editing .things files, the following error occasionally appears in the logs:

[ERROR] [ore.thing.internal.ThingRegistryImpl] - Could not inform the ThingTracker 'org.openhab.core.thing.internal.ThingManagerImpl' about the 'THING_UPDATED' event!
java.lang.reflect.UndeclaredThrowableException
Caused by: java.lang.InterruptedException

Description:

  • The error happens sporadically, usually when saving Thing files.

  • OpenHAB tries to propagate the changes to the Thing handlers, but the process gets interrupted.

  • The log shows UndeclaredThrowableException and InterruptedException.

Possible Causes:

  • Rapid or concurrent saving of Thing files.

  • Very large or complex Thing configurations.

  • Temporary thread interruptions within OpenHAB.

270

Hi,

I thought I was upgrading to the latest 4.3 version of OpenHAB but eventually 5.0.1 was installed.

I faced several problems after the upgrade. The major problem is the running of the rules. I got the following error when a rule (DSL) is executed:

2025-08-22 15:35:16.177 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘dabef6d032’: Failed to execute action: 2(Cannot invoke “com.google.inject.Injector.getInstance(java.lang.Class)” because the return value of “org.openhab.core.model.script.ScriptStandaloneSetup.getInjector()” is null)

and:

2025-08-22 16:15:31.375 [ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule ‘dabef6d032’: Failed to execute action: 2(null)

Does anyone knows how to solve it ?

Thanks in advance.

271

Well after some investigations, I decided to “save” the rules with id dabef6d032even if I did not modify it.

And no more error in the log file for this rule…

I will thus have to do it for the remaining 122 rules…

272

It’s likely disabeling and reenabling the rule would be sufficient. You could use the following JS code to do them all in one go.

const { ruleRegistry } = require('@runtime/RuleSupport');
utils.javaSetToJsArray(ruleRegistry.getAll()).map(r => r.getUID().toString())
                                             .filter(id => id != ruleUID && rules.isEnabled(id))
                                             .forEach( id => {
                                                console.info('Disabling ' + id);
                                                rules.setEnabled(id, false);
                                                Java.type('java.lang.Thread').sleep(500);
                                                console.info('Enabling ' + id);
                                                rules.setEnabled(id, true);
                                              });

I ran this from -Scratchpad-.

Note that the above code skips rules that are already disabled and ti skips the rule it’s running from. Rules that are triggered by a system started/start level reached trigger will be triggered again when the rule is reenabled.

I only minimally tested the above code. There may be edge cases I’ve not thought of.

2 Likes
After updating to Openhab5 inline scripts within rules not excuting anymore
OH5 - rule errors
273

Thanks a lot for this JS code. I would be very happy to master OpenHAB like you :wink:

I should also thank you twice because your JS code found that some rules were obsolete with some missing items to trigger them. So the upgrade is a good occasion to clean my OpenHAB settings.

Now, OpenHAB 5.0.1 seems to run fine but I will continue to closely monitor the log file to see whether there are still some other problems (or if there are complains from my family members ;-))

OpenHAB mentioned 10 Semantic Model Configuration Conflicts but I will have a look on it later. I was aware of this when I read the OpenHAB 5.0 announcement.

Have a nice evening

275

Unfortunatelly for sitemaps is not working from code view also. I checked it on “old” and new just created sitemap. For new was working only during creation. Then for next editing stop working.

276

As discussed in the milestone discussions, I also get at startup those warnings:

[WARN ] [ore.common.registry.AbstractRegistry] - Cannot add “GroupItem” with key “gGlobal”. It exists already from provider “GenericItemProvider”! Failed to add a second with the same UID from provider “ManagedItemProvider”!

All my items are defined in *.items files. The warning arises when the file with the definition of the GroupItem is loaded.

As far as I can see, the mentioned GroupItem is used in the definition of other items, defined in files loaded before. Obviously the GroupItem is also created when used, not only when defined.

The order of loading the .items files looks quite random. Is there a possibility to force a certain file to be loaded first?

277

Check your JSON file containing managed items in userdata/json, you will be surprised to see that this group item is also defined there.

278

maybe open a github issue otherwise this could get buried in here