jdk.nashorn.internal.runtime.Undefined error with ItemStateUpdateTrigger & ItemStateChangeTrigger

Setup, Configuration and Use Scripts & Rules
, ,
1

I just upgraded to OH3 and in the three rules where I use ItemStateUpdateTrigger & ItemStateChangeTrigger, I’m getting this error:

Error during evaluation of script 'file:/etc/openhab/automation/jsr223/javascript/personal/xxxx.js': Invalid type '{jdk.nashorn.internal.runtime.Undefined}' of configuration value!

Even if I strip the rule down to nothing, like this:

rule
(
  {
    name: "Rule_OnTest",
    description: "Test stuff",
    triggers: 
    [ 
      ItemStateUpdateTrigger("Test1")
    ],

    execute: function( module, input)
    {
    }
);

I still get the error. If I change the trigger to, say, CronTrigger, the error goes away. Do I need to add more parameters?

The examples included with the Crazy Ivan libraries seem to be wrong for OH3.

2

It appears that if I fill in every parameter, the error goes away. But this would require you to enumerate every possible state in separate triggers - hardly practical in many cases.

This works, for example:

    triggers: 
    [ 
      ItemStateUpdateTrigger("AlxTrgOH_VentilationOff", "ON", "AlxTrgOH_VentilationOff_ToON"),
      ItemStateUpdateTrigger("AlxTrgOH_VentilationOff", "OFF", "AlxTrgOH_VentilationOff_ToOFF")
  ],
3

It seems null is also a valid value for the state parameter. But naming the trigger seems mandatory.

4

David, if you are using my JS rewrite you need use the Jython style rule syntax. As I stated in your other thread, there is an example in an expandable section at the bottom of my first post in this thread.

I don’t remember if I put the old style JS syntax back in (your mild success would suggest I did) but I never tested it in OH3 so there may be changes that are needed which are causing you these problems.

5

OK. And is there an alternative to your JS rewrite? Will it be the definitive implementation in OH3?

My impression is that there are hardly any people using file-based .js rules and it’s very hard to work out what’s going on. I certainly can’t work out how to adapt all my triggers from that one example.

6

Very mild indeed. I got rid of the errors, but nothing appears to be working.

7

Based on what you’re telling me here and in your “my first steps” thread I’m thinking I just left the old code in there and that other changes I made or changes from OH2 to OH3 have broken large portions of it.

Use the Jython style rule syntax in the example. Use the Jython documentation for all other reference on what you can do in terms of triggers and other functions in the libraries. Like I said on one of these threads, you will need to look in the JS source code to make sure that the function you want has been ported to JS and takes the same parameters.

I am not aware of an alternative set of libraries for text based JS rules. You are correct, there has been very little interest in text based JS rules. Unfortunately that does make you somewhat of a pioneer at this point.

1 Like
8

I guessed as much. I should have taken a larger swig of whisky before upgrading.

9

So, my understanding is that the item state update trigger would look like this:

function handleItemUpdate(event) 
{
}
when("Item myItem received update")(handleItemUpdate);
rule
(
    "Handle item update",
    "Does stuff"
)(handleItemUpdate);
10

And an item state change trigger would look like:

function handleItemChange(event) 
{
}
when("Item myItem changed")(handleItemChange);
rule
(
    "Handle item change",
    "Does stuff"
)(handleItemChange);
11

And the startup trigger would be:

function handleStartup(event) 
{
}
when("System started")(handleStartup);
rule
(
    "Handle startup",
    "Does stuff"
)(handleStartup);
12

Yes yes and kind of. The system started trigger is gone in OH3 but we have a “start level” trigger now. I don’t remember if I got that working in Jython or JS, I’d have to look at the code. I’ll try to remember to have a look tonight an get back to you. If I didn’t implement it in that syntax I can probably give you a snippet of how to create the trigger by hand (not using when) and add it to your rule.

13

OK. The only constant seems to be that the startup trigger never works. :smirk: It never worked in OH2 in Javascript either.

I converted one rule to use System started but it doesn’t seem to do anything. I worked out a solution using a timer trigger (somewhat less efficient) so I can just keep using that.

14

I have no had much success with the startup trigger either. I found out how the start levels work in OH3 but the Jython engine loads after those events hit the message bus so the trigger never fires.

In either language you can simulate a startup trigger by just calling the rule function at the end of the rule file. That way whenever the engine loads the file the rule gets “run”.

15

Ahh OK. Any rule file, presumably? I have 72 :smirk:
That sounds a good way to solve it.

16

The rule function has to be in the same file you call it from, or otherwise accessible from the file you call it from.

If you have 72 rules that need to run at startup I suggest you create an item called “system_started”, turn off auto update, and trigger all these rules when it receives the command ON. Then in another file simply have a line of code in there, not even in a function, that sends the ON command to this item. That way when that file is loaded it will trigger all the other rules.

17

I actually only have 5 files containing triggers. All the rest are classes/functions that are used by those 5.

I definitely don’t need to run all the rules at startup! Just one. It might not even be necessary in OH3, I’ve no idea - I just fill in a reboot date-time stamp so I know how long the system’s been up.

18

You could simplify that to a single line that updates that item when the file is loaded. Not going to be 100% accurate as it will trigger any time the file is loaded, but in theory if you don’t modify the file it will only be loaded once at startup.

1 Like
19

Right. But that’s actually not a problem, because I use an item and I check whether it has a valid value already. If it doesn’t, I write the date-time. So the tiny inefficiency of calling it if the file reloads is neither here nor there.

Simple, much better.