Sometimes item object that triggered rule not accessible inside "then" block - is null

Here is a bug I’ve seen since OH 1.8. I’m currently running openhab2-2.1.0.20170514170108-1 (from the rpm).

Basically sometimes the item object that triggered the rule is not accessible inside the rule’s “then” block - it resolves to null. Restarting OH either fixes or causes the bug.

Example:

The following rule sometimes works 100% upon starting OH, and sometimes doesn’t work 100% of the time upon starting OH (and modifying the involved rules and item files after startup to force reloading doesn’t fix it).

rule "KitchenTableSwitch changed"
    when
        Item KitchenTableSwitch changed
    then
        sendCommand(KitchenTableLight, KitchenTableSwitch.state)
end

When it doesn’t work, KitchenTableSwitch resolves to null and causes the following error:

[ERROR] [.script.engine.ScriptExecutionThread] - Rule 'KitchenTableSwitch changed': An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.script.actions.BusEvent.sendCommand(org.eclipse.smarthome.core.items.Item,java.lang.String) on instance: null

However, changing the rule into two rules that don’t access KitchenTableSwitch inside the “then” block is a workaround that never fails:

rule "KitchenTableSwitch ON"
    when
        Item KitchenTableSwitch received update ON
    then
        sendCommand(KitchenTableLight, ON)
end

rule "KitchenTableSwitch OFF"
    when
        Item KitchenTableSwitch received update OFF
    then
        sendCommand(KitchenTableLight, OFF)
end

I expect you appreciate that KitchenTableSwitch.state might get changed into something that isn’t appropriate to be sent as a command - something like UNDEF perhaps, in the case of a communication failure.
The rule would trigger (because it changed) and the sendCommand would fail (because it wasn’t ON/OFF or whatever is expected here).

That doesn’t seem to be happening here. KitchenTableSwitch itself is null, and stays null (but only in those specific “then” blocks) until one or more restarts of OH - which increases chance it is some sort of race condition at startup IMHO.

What makes you think that?
You could add a check of course

rule "KitchenTableSwitch changed"
    when
        Item KitchenTableSwitch changed
    then
        if (KitchenTableSwitch==null) {
            logInfo("testing", "oops, the item is null")
        } else if (KitchenTableSwitch.state==ON || KitchenTableSwitch.state==OFF) {
            sendCommand(KitchenTableLight, KitchenTableSwitch.state)
        } else {
            logInfo("testing", "the item state is unexpectedly " +KitchenTableSwitch.state.toString)
        )
end

It is usual for Item states to gouninitialized after editing items files.

I had a similar problem with zwave device.

Use presistence to set a valid state of each item.

After restart of OH the items are in UNDEF or NULL state. This causes the problem on my side.

I narrowed it down more - KitchenTableSwitch exists, but KitchenTableSwitch.state does not exist (it isn’t null - the property itself is missing).

So what was the result of -

logInfo("testing", "the item state is unexpectedly " +KitchenTableSwitch.state.toString)

??

It is probably possible to accidentally create an Item and some other ‘ordinary’ variable somewhere with identical names, and mess things up.

But I still think the most likely scenario is that your Item is simply uninitialized, which is quite normal after editing files. At least we’ve got past Item magically becoming null or invisible.