triggeringItem in jsr223 scripts undefined

I’d need to use the triggeringItem (as a member of a group) in a rule.

When I define a js rule in UI I can get that triggeringItem, but when I set up a rule via scriptExtension.importPreset("ruleSupport") the triggeringItem is undefined.

What I do now is writing a jsr223 rule in UI:

//log.info("item:"+triggeringItem);
//log.info("item:"+itemName);

this.OPENHAB_CONF = (this.OPENHAB_CONF === undefined) ? java.lang.System.getProperty("openhab.conf") : this.OPENHAB_CONF;
load(this.OPENHAB_CONF + "/automation/wallswitch.js");

-> then I have triggeringItem defined inside wallswitch.js. Note, that there is no reference linked to triggeringItem. I only call my file-script via “UI”.

BUT: When I trigger and set the rule directly in a file:

scriptExtension.importPreset("RuleSupport");
scriptExtension.importPreset("RuleSimple");

var wallswitchTrigger = new SimpleRule() {
    execute: function( module, input) {
        // triggeringItem is undefined here!
        return true;
    }
};

wallswitchTrigger.setTriggers([
    TriggerBuilder.create()
        .withId("Trigger_wallswitch")
        .withTypeUID("core.GroupStateUpdateTrigger")
        .withConfiguration(
            new Configuration({
                groupName: "gButton",
                state: "ON"
            })).build()
]);

automationManager.addRule(wallswitchTrigger);

…I do not have triggeringItem defined

Does anybody know why? And how I can get that triggering Item?

Note: I have no problem getting an involved Item on triggeres like itemstatechanged

PLease tell me if I can help with some logs or complete files!

Did you switch to openHAB 3 recently?

This sounds like you could be affected by the breaking changes for the triggeringItem variable.

See BReaking Changes section for more information:

I think the preferred approach for JS and Python rules is to use event.itemName instead of triggeringItem. I personally wasn’t even aware that triggeringItem was available under any circumstances in JavaScript.

Also, the breaking change Jerome points out is that triggeringItem only exists now for Member of triggers. Any other Item based trigger uses triggeringItemName instead.

1 Like

Thanks for all the hints!
Please note that I’m talking about completely file-based scripts only.
In js scripts added via UI I can get all the implicit variables. Even when I call a file-scipt from a script-added rule all those variables are there.

I have this minimalized file-only rule:

var sRule = new SimpleRule() {
    execute: function(module, input) {
        log.info(input.triggeringItem); // works fine
        log.info(event.itemName);  // NOT available, even 'event' is undefined
        log.info(triggeringItemName); // NOT available
        return true;
    }
};

sRule.setTriggers([
    TriggerBuilder.create()
        .withId("Trigger_TEST")
        .withTypeUID("core.GroupStateUpdateTrigger")
        .withConfiguration(
            new Configuration({
                groupName: "gButton",
                state: "ON"
            })).build()
    ]);
automationManager.addRule(sRule);

The rule is triggered via a GroupStateUpdateTrigger, hence the triggeringItem should be there.
It is - but only hidden underneath the second argument passed in execute() - in my case: input.triggeringItem, which is an easy solution to my problem, but could be a worthy knowledge for future readers.
event.itemName and triggeringItemName are not available and using them throws this error:

[ERROR] [e.automation.internal.RuleEngineImpl] - Failed to execute rule 'b8093803-cd0f-4ef5-bc2a-a2c466622f33': Fail to execute action: 1

Still I’m curious why triggeringItem is available as implicit var when the js is based on a ui-rule-script.

1 Like

Doesn’t matter.

All I really can say is that all the Python examples I’ve seen and written (all file based) and all the JavaScript rules I’ve written (though I only done these from the UI) all use event.itemName. But I suspect, in your case the way you’ve defined the arguments to the function it would be input.itemName. That input is where you will find all the information about the event that triggered the rule, assuming that the rule was triggered by some sort of Item based event. It will be null for manually run rules and rules triggered based on Time.

For consistency with how it’s done elsewhere you might change the name of the argument to event.

I didn’t look closely enough at your code before to see that.

I took the base of the script from openhab-scripters examples here:

because it was the most comprehensive source I could get about jsr223 scripting in openhab.
It is also shown as example in the official docs that way (though the example-section seems broken to me):

var sRule = new SimpleRule() {
    execute: function( module, input) {
        print("This is a 'hello world!' from a Javascript rule.");
    }
};

My fault, that I didn’t realize, that it’s totaly on me on how to name the 2nd argument: input or event.

Thanks for your efforts!
Hopefully I’ll find some time to update/enhance the “See language-specific documentation for examples.” in the docs.

I was facing the same issue.
Also tried your solution to use input.triggeringItem.
That unfortunately did not work. However, dumping all content of input in the log, I saw that there is an object event in there.
So I tried : input.event.itemName and that worked fine.

var sRule = new SimpleRule() {
    execute: function(module, input) {
        log.info(input.event.itemName); 
    }
};

However, if the changed item was a group, I don’t know how to get the name of the triggering item from the group. The above just shows the name of the group.
Any ideas on that ?
UPDATE
I actually found out that most of the things in the Scripted Automation column work from this link :
https://openhab-scripters.github.io/openhab-helper-libraries/Guides/Event%20Object%20Attributes.html
by just changing the event.XXX with input.event.XXX
So to get the triggering member of the group is then input.event.memberName

If you trigger from a group, the triggering Item is the group.
You’ll be looking for a different trigger - Member of

Yes you are right - updated my post with my findings :slight_smile:

@jeffstagedoor could you submit an issue on github regarding this please?

@JimT I don’t think it’s an issue with the code, but only with my understanding - maybe an issue with the documentation, which is kind of vague as far as scripting is concerned anyway…
So I wouldn’t know where to submit an issue!?
My take is that a change in the docs with a pull request would be better - as soon as I get time.
Of course I could be persuaded to file an issue easily.