OH4 migration rules fail but work if type: application/javascript;version=ECMAScript-5.1 added

Setup, Configuration and Use Migration
1

I am trying out the OH4 milestone 4.0.0.M4 and the rules don’t work because they are version 5.1 rules.
This is what I have done:
OH 3.4.4 installed and up and running with zulu java11
Stopped OH3
Removed java11 and installed zulu java17
Changed the apt source file from stable to testing
upgraded to openhab 4.0.0.M4
Started OH4
Installed Nashorn addon
Stopped OH4
removed javascript entry from /var/lib/openhab/config/org/openhab/addons.config as I was getting javascript warnings and it was being ignored.
Removed javascript transformation using the openhab console:
openha-cli console
config:edit org.openhab.addons
config:property-list
config:property-set transformation regex,jsonpath
config:property-list
config:update
Cleared the cache: sudo openhab-cli clean-cache
Started OH4

When any old rules run I get this:
023-07-07 14:39:19.403 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID ‘40ceac6bd4’ failed: org.graalvm.polyglot.PolyglotException: ReferenceError: “itemRegistry” is not defined

I stopped OH4 and ran the upgradetool.jar: java -jar $OPENHAB_RUNTIME/bin/upgradetool.jar --force

Started OH4 again and same thing.

NOTE: I have found if I go to the rule and open it and then and change the display from design to code (top right hand corner) and change:
type: application/javascript
to
type: application/javascript;version=ECMAScript-5.1

IT WORKS!!!

Because I have lots of rules then going through and changing every rule is going to take a while.

Is there a way to change this in the /var/lib/openhab/jsondb/automation_rules.json

I did do a test and changed it manually using vim and I had to edit the automation_rules.json if I wanted the scripts to work as the script doesn’t have the design / code tab.

What does the upgradetool.jar change in the database if it doesn’t change type: application/javascript to type: application/javascript;version=ECMAScript-5.1 ?

ALSO NOTE: when I start typing type: application/javascript;version it auto completes to type: application/javascript;version=ECMAScript-5.1

Any comments suggestions are welcome.

2 Likes
2

Through MainUI?

Which JavaScript entry? There could be up to three entries: transformation, Nashorn and GraalVM JS Scriptings addons

Was there anything logged related to rules when the tool ran?

The upgrade tool should have happened. However, if you were to need to change these manually, stop OH, open $OH_USERDATA/jsondb/automation_rules.json with a text editor and use find and replace. You could do them all in one go that way.

There is a growing list of breaking changes that the upgrade tool implements for managed configs including dealing with the changes to unit handling, changes to Things syntax, etc.

I think that the change of the mime type was included in the upgrade tool but an not certain. I moved to OH 4 on day one and had to manually do everything because an upgrade tool didn’t exist yet. @florian-h05, IIRC you did at least a little work on this, though maybe that was only concerning Blockly. Are the mime types for Nashorn rules supposed to be changed through the upgrade process, either through the tool or some other way?

3

I used the mainui to install Nashorn addon.
The javascript remove was because it was getting warning saying it was being ignored. found it here: OH4 install issues

Am I seeing all of these problems because I am upgrading from 3.4.4 to 4.0.0.M4 and other people are gradually upgrading via milestones? EG going from M1-M2-M3-M4?

I am using a VM and have snapshot so I can go back to 3.4 and try different ways to install.
I will persist and see how I go.

4

I have done another test:
I stopped OH4

ran: 
cd /var/lib/openhab/jsondb
cat automation_rules.json |jq '.[].value.actions[0].configuration.type |= "application/javascript;version=ECMAScript-5.1"' > automation_rules.json.tmp
mv  automation_rules.json automation_rules.json.save
mv  automation_rules.json.tmp  automation_rules.json

Started OH4 and most of the rules seem to work now.
This line of code doesn’t work:

 var stateof = event.itemState.toString() ;

I am getting a lot of these warnings but I had these before the above changes.

[2023-07-08 09:13:51.262 [WARN ] [.core.io.rest.internal.DTOMapperImpl] - Field 'firmwareStatus' could not be eliminated: Can not set final org.openhab.core.thing.firmware.dto.FirmwareStatusDTO field org.openhab.core.io.rest.core.thing.EnrichedThingDTO.firmwareStatus to null value
2023-07-08 09:13:51.267 [WARN ] [.core.io.rest.internal.DTOMapperImpl] - Field 'firmwareStatus' could not be eliminated: Can not set final org.openhab.core.thing.firmware.dto.FirmwareStatusDTO field org.openhab.core.io.rest.core.thing.EnrichedThingDTO.firmwareStatus to null value

Slowly getting there. :grinning:

5

Ok, I assume that’s the JS Transform.

I doubt it. Others have done similar upgrades without the problem. However, few users willing to run testing versions of OH are still using Nashorn JS. Must have moved to the more modern JS Scripting or Blockly.

Doesn’t work how? How is the rule triggered?

6

It is being triggered when I press a button an a remote control widget.

7

What’s the rule trigger? received command, changed, updated? From a widget directly?

event.itemState only exists when the rule is triggered by an update or changed event.

8

When it was updated. Here is the rule from my working 3.4 OH as my proxmox server won’t boot with a grub error. :sob:

configuration: {}
triggers:
  - id: "2"
    configuration:
      itemName: remotesonytv
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "1"
    configuration:
      type: application/javascript
      script: >+
        //need below to log to openhab.log file

        var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);

        //below is if you are going to use the ececute command

        var Exec = Java.type("org.openhab.core.model.script.actions.Exec");

        //below is also needed for the execute command

        var Duration = Java.type("java.time.Duration");


        //var HttpUtil = Java.type("org.openhab.core.io.net.http.HttpUtil");

        //var HttpGet = Java.type("org.openhab.core.model.script.actions.HTTP");


        var TOPIC = "broadlink/tv/sony/"


        var stateof = event.itemState.toString() ;

        //logger.info("results = " + stateof);


        result = Exec.executeCommandLine(Duration.ofSeconds(5), "/usr/bin/mosquitto_pub","\-h","192.168.1.164","\-t","" + TOPIC + stateof,"\-m","replay");

        logger.info('The script ran the command '  + TOPIC + stateof);


    type: script.ScriptAction
9

Ok, so it has an ItemStateUpdate trigger, that’s good. But it’s it the actual Item remotsonytv that’s trying the rule of is your widget running the rule directly?

It matters because event.itemState will exist in the former but not in the later.

10

The widget looks like a remote control and it just sends what the buttons are when pressed.

The rule gets what comes from the remote and passes that to the infrared blaster via mqtt.

It has been working for years with openhab 3.

Everything is done in the rule.

11

I just installed the latest snapshot version my laptop and now the remote control is working.

12

Another observation with the openHAB 4.0.0 (build Build #3531) is the scripts don’t work if the automation_rules.json hasn’t been edited to have the
“type”: “application/javascript;version=ECMAScript-5.1” in it but the rules run without having that in the file.

13

No, there is currently no task for the upgrade tool to do that. I’ve completely forgotten that, and won‘t make it till the feature freeze on Sunday. I can probably open a PR before the code freeze.

1 Like
14

I’m willing to go to bat and argue that it will be really bad if we don’t have that in OH 4 release. In my opinion it would be worth a day or two delay compared to the masses of people who will get caught up by this.

15

Probably the Nashorn add-on can be also installed automatically when Nashorn scripts are in the JSONDB.

Let’s ping @J-N-K and @Kai, so they can share their thoughts and probably help with the upgrade tool.

16

Auto-load of Nashorn sounds like a good idea.
If the install of java 17 as well would make it a true upgrade.
If it just worked after upgrading that would be the best.

17

Hi, I also had the problem with ECMA 5.1 rules when I upgraded from openHAB 3.4.4 to openHAB 4.1.1.
I thank ubeaut Greg for his contribution.

I also installed the Nashorn add-on and modified the rules in the code tab.

Now they all work without problems and you can reprogram them to JS 11 at your leisure.

ECMA 5.1 Rule on OH 4.1.1 running without Problems

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: Gesamtverbrauch_Kw_h
    type: core.ItemStateUpdateTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/javascript;version=ECMAScript-5.1
      script: >+
1 Like