Migration to v4 gives "itemRegistry" is not defined error related to blockly rules

MathiasVDA · July 24, 2023, 10:52pm

After migrating from openhab 3.4 to openhab 4, I see these errors:


2023-07-25 00:36:06.420 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:

org.graalvm.polyglot.PolyglotException: ReferenceError: "itemRegistry" is not defined

	at <js>.:program(<eval>:1) ~[?:?]

	at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]

	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]

	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]

	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]

	at org.openhab.core.automation.module.script.internal.handler.ScriptConditionHandler.isSatisfied(ScriptConditionHandler.java:54) ~[?:?]

	at org.openhab.core.automation.internal.RuleEngineImpl.calculateConditions(RuleEngineImpl.java:1158) ~[?:?]

	at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:995) ~[?:?]

	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]

	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]

	at java.lang.Thread.run(Thread.java:833) ~[?:?]

and:

==> /log/logs/openhab.log <==

2023-07-25 00:32:00.500 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:

org.graalvm.polyglot.PolyglotException: ReferenceError: "events" is not defined

	at <js>.:program(<eval>:12) ~[?:?]

	at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]

	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]

	at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]

	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262) ~[java.scripting:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]

	at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:78) ~[?:?]

	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:71) ~[?:?]

	at java.util.Optional.ifPresent(Optional.java:178) ~[?:?]

	at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) ~[?:?]

	at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1188) ~[?:?]

	at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:997) ~[?:?]

	at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:87) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]

	at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]

	at java.lang.Thread.run(Thread.java:833) ~[?:?]

2023-07-25 00:32:00.507 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'f2ad118f70' failed: org.graalvm.polyglot.PolyglotException: ReferenceError: "events" is not defined

I suspected these have something to do with rules. I have a few of them that are triggered frequently and which have actions defined in Blockly. I took one and tried running it. And it gave me one of the above errors but with a bit more text to. I then opened the blockly design, tried to run the rule from there and saw in the log:

2023-07-25 00:46:49.379 [INFO ] [openhab.event.RuleUpdatedEvent      ] - Rule '3e005b972e' has been updated.

The rule then passed fine.

So it seems that I have to go through all my rules and do this ‘open blockly code’ and ‘save it’ manually to fix the generated script?

rlkoshak · July 25, 2023, 2:43am

As mentioned in the list of breaking changes and documented here you need to convert your Blockly rules to be compatible with OH4 by opening each one and saving it anew. You also need to install the JS Scripting add-on.

stefan.hoehn · July 25, 2023, 6:02am

And the way I did it is:

open the Developer sidebar with Shift+Alt+D
search for itemRegistry
press the edit “pencil” on each of the rules
open the blockly rule
press save
(you can finally search again for itemRegistry and you are fine if you don’t find anything anymore)

Sounds a bit tedious but even with my 100+ rules it didn’t take really that long.

MathiasVDA · July 25, 2023, 6:14am

Thank you Rich and Stefan! I read through the release notes but did not fully understand the part about breaking changes in the Javascript automation. Afterwards when searching for a solution, I didn’t reread this part because I couldn’t find the word ‘blockly’ since in the text, the plural ‘blocklies’ is used. My fault! Thanks again!

edgararroyo · August 19, 2023, 11:25am

Howdy. I also upgraded to 4.0.2 and getting both these errors. I created my rules using ECMAScript, how can I fix this error? I don’t use “blocky”

rlkoshak · August 19, 2023, 10:02pm

In that case you need to do one of the following:

Install the JS Scripting add-on and rework your rules using the new ECMAScript 11 syntax using the openhab-js library.
Install the Nashorn JS Scripting add-on and change the type of your script actions and conditions to “application/javascript:ECMAScript5.1” (I think that’s right, search the forum if not or just create a new script choosing Nashorn JS as the language and see what it uses for the type). You can find and change the type by clicking on the code tab of the rule.

edgararroyo · August 20, 2023, 4:10am

I already tried that. That’s how I got the “events” not defined error. I get both errors, when I use the non Nashorn I get the itemRegistry error and when I use the Nashorn I get the events error.

edgararroyo · August 20, 2023, 4:27am

Ok, found out the problem. I had to edit the _Run rule as well. It is working now. I guess I will start switching to the newer ECMAScript 11 but I need to have my Alexa working since I rely so much on it.

Klommer · September 27, 2023, 6:52pm

Hey there,

im porting my OH3 RPI-Setup to OH4-VM-Setup and seems like im running into the migration topic with my rules.
I tried to migration backdoors mentioned here, but the connected items does not fire any MQTT-Messages.

As far as now im almost sure that it is somewhere in the OH4 version. The OH4-VM-MQTT-Broker is up and running. Im tested this by routing all my required MQTT-Traffic onto my OH4 VM-MQTT-Broker, also my OH3-RPI “productive system” is connected to the OH4-MQTT-Broker.

Rules in OH3 fire MQTT-TX-msg if triggered. I´ve deleted some rules for testing in OH4 and rebuilding from scratch, but nothing viewable on MQTT explorer or similar.
Any suggestions? I saw https://community.openhab.org/t/sending-mqtt-command-with-script/143425/5, but im not sure if it is running on OH4

rlkoshak · September 27, 2023, 7:20pm

Please open a new thread and be sure to include the actual rules in question as well as relevant logs. With the information provided

tophee · April 14, 2024, 1:45pm

I did this, and it worked for all rules but one. The one where the itemRegistry remains even after saving (in fact, even after recreating the entire rule) is one using the “copy state from to ” block from the “Common Blocks” library

CleanShot 2024-04-14 at 15.44.48@2x

which produces this code:

events.sendCommand('MyItem', itemRegistry.getItem('MyItem').getState());

Could it be that that library has not yet been updated?

Edit:

Managed to fix it by using the equivalent:

rlkoshak · April 14, 2024, 4:29pm

If this is a third party block library from the marketplace then almost certainly it looks like it’s not been updated. No blocks should reference the itemRegistery like that as one does not directly interact with the registery like that in JS Scripting. All access to Items go through items.

However, keep in mind that updates do not get installed automatically. If the original author did update their library, you would have to remove and readd the library to pick up the changes.

tophee · April 14, 2024, 4:36pm

In that case, I don’t understand how merely opening and saving a blockly script after updating to OH4 will update the script.

hmerk · April 14, 2024, 4:36pm

If you just want to update the second items state you don’t need to use sendCommand but postUpdate instead.

tophee · April 14, 2024, 4:52pm

It’s been a while since I set up this rule, but I seem to remember I chose Command because otherwise wouldn’t work.

rlkoshak · April 14, 2024, 5:12pm

It depends on what “it” is in “it wouldn’t work” but if your goal is to just update the “to” Item, postUpdate is the more appropriate thing to use.

If you want to forward a state update from one Item to cause a device to change, for example to stay in sync, only then does it make sense to sendCommand.

tophee · April 14, 2024, 5:15pm

The rule does a simple thing: if one light is turned on, also turn on another light. And if a light is turned off, also turn off the other light. I guess that’s why I need command.

hmerk · April 14, 2024, 6:04pm

In this case, sendCommand is the right approach.

stefan.hoehn · April 14, 2024, 6:19pm

In general, everytime(!) a rule is saved the code is regenerated and it uses the current implementation of these blocks. The core blocks that come with openHAB use the latest implementation and as Rich said are uptodate with the running openHAB version. However, the copy block is a block from a user library that is not maintained by me, so check if there is a newer version that does not use itemRegistry anymore. As mentioned before that same thing can be achieved with the sendCommand block which is why I never added it to the core blocks.

tophee · April 14, 2024, 6:31pm

I find it difficult to understand what parts of my OH instance are updated automatically (i.e. when upgrading to a new OH version) and which parts need to be updated by uninstalling and reinstalling.

In this case, I don’t think there is an OH4 compatible version: