Thanks for reporting, I’ve created a fix: Code editor: Add `input` to globals for JS linter by florian-h05 · Pull Request #4233 · openhab/openhab-webui · GitHub
I suspect so. Will have a look at this.
I have already reproduced it using a simple rule with only rules.runRule() in it, so this doesn’t have to do with Blockly and doesn’t require other “special circumstances”.
Blockly calls with rules.runRule('someUid', {}). (Note the object {}.)
Before runRule() executed in the rule’s thread, it did so in the caller’s thread. This way, rule A called rule B and rule B executed in A’s thread, no object was shared across multiple threads.
With your change, the object is shared from rule A to rule B, and they run in different threads, accessing the object at the same time.
I guess the best solution would be to clone the object in the RuleEngineImpl, though I have to verify that solves the issue.
Another solution would be to handle this in the Java part of the JS Scripting add-on.
I understand that this is the situation, I just don’t understand why JS objects are sent as context to runRule(). If Java objects are sent instead, they will be accessible to other scripting languages and not be subject to GraalVMs “rules”. But, there might be something I’m missing here.
I don’t think this should be RuleEngine’s responsibility, the objects sent should be “free of liens and encumbrances”. So, depending on where the JS objects originate, I’d say that it probably should be handled either in the JS helper lib or in the JS add-on.
You construct the object in native JS. If you sent that to a Java method, GraalJS will make it a Java Map (at least if the object consists of simple key-value pairs), but the implementation (something from Graal) is linked to the original JS object, so modifications are shared. That way, you can define a key-value pair object in native JS and Java gets a Map.
Let’s try if the behaviour changes if we create a Java HashMap inside JS and pass that.
Yes, something like that was what I meant.
So passing a HashMap works just fine. I’ll take care that the helper library (which provides rules.runRule) converts to a HashMap before calling openHAB Core Java APIs.
I will release a new openhab-js version soon and ship this with the add-on.
It’s impossible to do anything with this information. What rules are missing, what type of rules are they, language etc. What does the log say? There should be errors in the log if rules fail to load.
The log says nothing
Js rule file based configuration
If you tell me what I need to add as logger I can do
Just FYI I had this on the initial S/U and the container restart 10 minutes later. It is on a stripped-down test environment, so I don’t see an issues. Didn’t see anything in the release notes that might correlate
2026-05-31 17:57:32.152 [INFO ] [org.openhab.core.Activator ] - Starting openHAB 5.2.0.M5 (Milestone Build)
2026-05-31 17:57:33.578 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Time zone set to 'America/New_York'.
2026-05-31 17:57:33.583 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Locale set to 'en_US'.
2026-05-31 17:57:33.587 [INFO ] [.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'US'.
2026-05-31 17:58:03.657 [ERROR] [.core.model.lsp.internal.ModelServer] - Error starting the Language Server
java.net.BindException: Address already in use
at java.base/sun.nio.ch.Net.bind0(Native Method)
<snip> (available if needed)
This indicates that something is already bound to the port that OH is configured to bind to - an IP/port combination can only be bound by one application. It might be an OH instance already running, or some other application using the same port.
Good suggestion. Found a stray container running. Problem fixed. Not a 5.2M5 issue.
I tried version 5.2.0.M5, but had to go back to version 5.2.0.M2. Dynamic objects in Sitemaps are now working, but the issue with calling Script from Rule (see above) needs to be fixed
“Above” is 155 posts. Could you be more specific?
I tried M5, but had to switch back to M2 which was the last one properly handling the .historicState
Running on RPI5, docker, OH container, influxdb2 container, persistence set-up ok
Following code:
val feedinNow = feedin_energy_today.persistedState(now, "influxdb")
val feedinPrev = feedin_energy_today.persistedState(now.minusHours(1), "influxdb")
logInfo("script_dbg", "DEBUG [Saved] Feedin components -> feedinNow: " + feedinNow.state + ", feedinPrev: " + feedinPrev.state)
on M5 returns:
2026-06-01 17:32:43.856 [INFO ] [openhab.core.model.script.script_dbg] - DEBUG [Saved] Feedin components -> feedinNow: 24.67, feedinPrev: 24.67
on M2:
2026-06-01 17:46:56.512 [INFO ] [openhab.core.model.script.script_dbg] - DEBUG [Saved] Feedin components -> feedinNow: 21.69, feedinPrev: 19.23
Similar result is persistence service is not specified at all.
val feedinNow = feedin_energy_today.persistedState(now)
val feedinPrev = feedin_energy_today.persistedState(now.minusHours(1))
Similarly to my earlier post, I suspect the value that M5 returns comes from some abandoned history from “internal persistence” that was alive during while some previous “breaking change” broke influx before I fixed it back.
Maybe I have some mistake in definitions, but why it works on or before M2?
When I call Blockly Script from Blockly Rule in version 5.2.0.M5, the Rule is terminated and the log contains the message “Multi threaded access requested by thread Thread[#658,OH-rule-senditemstatus-1,5,main] but is not allowed for language(s) js.” A similar situation is with js Script. In earlier versions this works correctly.
This has already been addressed, but the fix hasn’t been released yet. It will be in a matter of hours I believe. The problem isn’t with M5, but with version 5.18.0 of the JS helper library. If you use 5.17.1 you should be fine, or you can wait for the next release, probably 5.18.1.