seems like @Nadahar 's suggestion really solved the problem. Something happend with OpenHAB between 0.5.2.M3 and some later versions which broke the code. I still was not able to figure out exactly what caused this, it’s difficult to find and I’m also having some trouble with the bandwidth here…
But gave it a try now, just installed the latest openhab-js on OpenHAB 5.2.0 and it seems to run in a quick test. OpenHAB 5.2.0 with the standard openhab-js 5.14.0 has errors, now with openab-js 5.21.0 it seems to run. I followed the documentation from github mentioned above and installed it on some test-docker 5.2.0 (which has no openhab-js pre-installed) as below:
> cd $OPENHAB_CONF/automation/js
> apt-get install npm
> npm i git+https://github.com/openhab/openhab-js.git
I will have a further look into this during the next days, hopefully with better bandwidth and will provide more updates. But thank you all for your comments and @Nadahar for the solution, all the best,
Just so you all know this, as soon as 5.2.1 is released, there will be no need to manually upgrade openhab-js, since the “standard version” will be upgraded to 5.21.0 or later.
I know exactly why it broke, but it’s a bit complicated. Basically, there was a long-standing bug about which thread ran a rule when it was started from another rule. This bug meant that a rule could “run in parallel with itself” if it was triggered at the same time as another rule ran it, or if two rules ran it.
However, this bug had one “advantage” for JavaScript scripting, because GraalPy “forbids” that an object that is created by one thread, is used by another (this is what triggers the error you’ve seen here). So, because of this bug, you could “get away with” sending JS objects between rules, although it was never supposed to “work”. When the fix was merged, these exceptions started occurring, because it “revealed” how this had become a “loophole” used by many. The fix that “broke it all” was this:
We had a few reports of “strange issues” during the last milestones, and various things were adjusted to try to mitigate. But, it was after 5.2.0 was released that the scope, and cause, became clear.
Since then, a number of things have been done to not just “dump this in the lap of the users”, telling them that “you can’t do that” (although, technically you can’t).
Most of this has been done in openhab-js:
There’s still one fix that isn’t merged, that makes this available for Blockly:
The core of the fix is the two new functions, javaify() and jsify(). These functions can take any object/variable and will recursively try to convert the content either to Java objects or to JS objects respectively. Java objects can be shared between rules, JS objects can’t. So, what 5.21.0 basically does, is apply javaify() to argument you send to another rule via runRule(). Java objects can mostly be used directly from JS, but if you want to “convert them back” in the other rule, you can call jsify() on input (or parts of it) manually.
The direct reason that the error goes away is that javaify() is called automatically when you invoke runRule(). There is a caveat though, it can’t convert absolutely all object types, but we’ve covered everything we can think of that users will usually want to send. So, for the most part, it will just work without any further action on your side, but there can be exceptions.
As a “bonus”, javaify() and jsify() has also been automatically applied when you use the shared cache. There have historically been a lot of restrictions to what you can put in the shared cache from JavaScript, with these changes, you should be able to put most object types in the shared cache as well.
Thanks to @Nadahar for the proposed solution and detailed explanations about the problem and @rene_rostock for having checked it. Just to be on the safe side, one needs to disable the Cache openHAB JavaScript Library Injection here:
I’m still receiving the WARN log entries after updating to openhab-js 5.21.0:
Failed to execute action ‘script’ of rule ‘nspanel_ssaver_update’: Multi threaded access requested by thread Thread[#922,OH-rule-nspanel_ssaver_update-1,5,main] but is not allowed for language(s) js.
OH: 5.2.0
openhab-js: 5.21.0
/etc/openhab/automation/js# npm ls
js@ /etc/openhab/automation/js
±- openhab_rules_tools@2.1.0
`– openhab@5.21.0 (git+ssh://git@github.com/openhab/openhab-js.git#a3444b55e98466802c30530b99095b1d431e694f)
I also disabled the “cache” function in the addon config, did several restarts and also opened the blockly rules/scripts and pressed “save” again.
I have very little experience with npm and all that, so I don’t know how to verify that you’re actually running the correct version. Is there are way to verify which version is used? @florian-h05@rlkoshak
To run a different version of opengab-js than comes with the add-on, which is required until OH 5.2.1 is released, one must:
use npm to install the openhab module. detailed instructions are at the bottom of the JS Scripting docs.
In MainUI navigate to Settings → JS Scripting and toggle off " Cache openHAB JavaScript Library Injection"
You can check which version is installed by looking at $OH_CONF/automation/js/ you’ll find two .json files. You can look in either one I think to see which version of openhab node module is installed.
You can see which version the JS add on is actually using with the following add to -Scratchpad- or any other rule.
(… another way to see the javascript-version, completely frontend- based …)
if you turn on debug level logging for any org.openhab.automation.jsscripting.rule you should see the debug-log of your nspanel callback, which will show you some information about the used javascript (like below).
Open the OpenHAB logging panel with the menu “Developer Tools” → “Log Viewer”. Click on the lower right “Configure Logging” and add “org.openhab.automation.jsscripting.rule” in the text field, enter. It will be added without much feedback, search the list and change the level to “Debug”. You should see the relevant debug log and a lot more
Just back from holidays. I updated OpenHAB to 5.2.1 but I have still the error message in the log when the screensaver is executed:
2026-09-02 09:35:18.045 [WARN ] [e.automation.internal.RuleEngineImpl] - Failed to execute action 'script' of rule '25a97b3b49': Multi threaded access requested by thread Thread[#3540,OH-rule-25a97b3b49-1,5,main] but is not allowed for language(s) js.
java.lang.IllegalStateException: Multi threaded access requested by thread Thread[#3540,OH-rule-25a97b3b49-1,5,main] but is not allowed for language(s) js.
at com.oracle.truffle.polyglot.PolyglotThreadAccessException.rethrow(PolyglotThreadAccessException.java:75)
at com.oracle.truffle.polyglot.PolyglotContextImpl.enterThreadChanged(PolyglotContextImpl.java:1109)
at com.oracle.truffle.polyglot.PolyglotEngineImpl.enterCached(PolyglotEngineImpl.java:2240)
at com.oracle.truffle.polyglot.PolyglotEngineImpl.enter(PolyglotEngineImpl.java:2187)
at com.oracle.truffle.polyglot.OtherContextGuestObject.sendImpl(OtherContextGuestObject.java:138)
at com.oracle.truffle.polyglot.OtherContextGuestObject$Send.doCached(OtherContextGuestObject.java:115)
at com.oracle.truffle.polyglot.OtherContextGuestObjectGen$ReflectionLibraryExports$Cached.send(OtherContextGuestObjectGen.java:119)
at com.oracle.truffle.api.interop.InteropLibraryGen$Proxy.isNull(InteropLibraryGen.java:2468)
at com.oracle.truffle.host.HostToTypeNode.convertImpl(HostToTypeNode.java:206)
at com.oracle.truffle.host.HostToTypeNode.doCached(HostToTypeNode.java:135)
at com.oracle.truffle.host.HostToTypeNodeGen$Inlined.execute(HostToTypeNodeGen.java:183)
at com.oracle.truffle.host.HostLanguageService.toHostType(HostLanguageService.java:130)
at com.oracle.truffle.polyglot.PolyglotToHostNode.doDefault(PolyglotToHostNode.java:67)
at com.oracle.truffle.polyglot.PolyglotToHostNodeGen$Inlined.execute(PolyglotToHostNodeGen.java:80)
at com.oracle.truffle.polyglot.PolyglotMap$Cache$GetNode.doCached(PolyglotMap.java:657)
at com.oracle.truffle.polyglot.PolyglotMapFactory$CacheFactory$GetNodeGen.executeImpl(PolyglotMapFactory.java:572)
at com.oracle.truffle.polyglot.HostToGuestRootNode.execute(HostToGuestRootNode.java:124)
at com.oracle.truffle.polyglot.PolyglotMap.get(PolyglotMap.java:137)
at com.oracle.truffle.js.scriptengine.GraalJSBindings.get(GraalJSBindings.java:172)
at com.oracle.truffle.js.scriptengine.GraalJSBindings.remove(GraalJSBindings.java:185)
at java.scripting/javax.script.SimpleScriptContext.removeAttribute(SimpleScriptContext.java:214)
at org.openhab.core.automation.module.script.internal.handler.AbstractScriptModuleHandler.resetExecutionContext(AbstractScriptModuleHandler.java:244)
at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:118)
at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1424)
at org.openhab.core.automation.internal.RuleEngineImpl$RunRuleCallable.call(RuleEngineImpl.java:1828)
at org.openhab.core.automation.internal.RuleEngineImpl$RunRuleCallable.call(RuleEngineImpl.java:1)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Any idea to get rid off this error message ? By the way, the NSPANEL seems to work correctly.
