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!
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”
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.
1 Like
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.
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.
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
Please open a new thread and be sure to include the actual rules in question as well as relevant logs. With the information provided 
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
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:
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.
In that case, I don’t understand how merely opening and saving a blockly script after updating to OH4 will update the script.
If you just want to update the second items state you don’t need to use sendCommand but postUpdate instead.
It’s been a while since I set up this rule, but I seem to remember I chose Command because otherwise wouldn’t work.
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.
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.
In this case, sendCommand is the right approach.
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.
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:
Everything that is provided via the marketplace is not automatically updated.
Looking at that date I agree this seems to be not compatible with the current OH 4 version. You can leave a comment on the marketplace and ask the author to provide a new version.
Thanks for explaining. But I am still not sure how to see somethingfrom the market is up to date or not. For example, is the Shelly Binding up to date or not?
It shows that it is on version 4.1.2 but I have never updated any binding and it still appears to be up to date. But you are saying that the version number shown is not the version I have but the one available in the repo? Where can I see which version I have?
It’s a bit confusing because when it shows version 4.1.2 and a button “Remove”, to me that implies that it is version 4.1.2 that I have (and would remove if I press that button).
That’s not from the marketplace.
It comes from the “openHAB distribution” in the bindings page in the Add-on Store and the version shown matches the version of OH you’ve installed.
- it’s listed under “openHAB distribution” section on the bindings page in the Add-on Store
- the “author” is “openHAB”
- the “Source” is “openHAB Distrobution”
- it’s “Provided by” openHAB
- the version of the add-on matches the version of OH you are running.
A marketplace add-on looks like this:
- No author is shown at the top under the binding name
- source is “Community Marketplace”
- provided by shows the name of the developer who posted it to the marketplace
- there’s a link to the community forum posting which constitutes the marketplace entry for that binding
- no version is shown
- created and updated at fields are present.
All rule templates and block libraries come from the marketplace.
Official bindings always update when you update OH itself. Always have and always will. Marketplace add-ons do not automatically update. You are comparing apples to oranges.
That’s it. You have 4.1.2 of the Shelly binding installed.
That’s exactly the case. If you clicked “remove” it would remove that add-on. And the add-on version from “official” add-ons always matches the version of OH you are running, because they are a core part of OH itself.