Rule triggered by "wrong" item

  • Platform information:

    • Hardware: Synology DS716+ / Intel Celeron N3150
    • OS: DSM 6.2.4-25556 / Docker 20.10.3-0554
    • Java Runtime Environment: bundled with docker
    • openHAB version: docker “openhab/openhab:latest” (3.1)
  • Issue of the topic:
    After updating to 3.1 (from 2.5) I noticed something strange: A rule is triggered by an item that is not listed in “when”.

  • From rule file:

rule "RuleRolladenBenjaminWest"
    Item BeschattenWest changed or
    Item RolladenNacht changed or
    Item IstTemperaturOGBenjaminHigh changed
    logInfo("rollershutters.rules", "RuleRolladenBenjaminWest!!!! " + triggeringItemName)
    shade.apply(RollershutterOGBenjaminRolladenWest, RolladenNacht, BeschattenWest, IstTemperaturOGBenjaminHigh, defaultRollershutterLevels)
  • From openhab.log:
    2021-08-26 11:00:37.493 [INFO ] [re.model.script.rollershutters.rules] - RuleRolladenBenjaminWest!!!! IstTemperaturOGSchlafenHeizungNone

  • From items file:
    Number IstTemperaturOGSchlafenHeizungNone "OG Schlafen [%.1f°C]" <temperature> (IstTemperaturZimmerOG, HomeKitThermostatOGSchlafen) {channel="knx:device:IPIF:OTHER:IstTemperaturOGSchlafenHeizungNone", homekit="Thermostat.CurrentTemperature"}

Any idea what could cause this?
Thanks a lot!

I’d first have a close look at similar rules; in my experience it’s very easy to copy-paste rules and miss making changes. In particular, change the log of your suspect rule in some unique way so that you are sure it is the culprit.

Are there Groups involved here? triggeringItemName should give you the Group here, not the member, but might be messing up.

Thanks for your suggestions @rossko57!

A really good idea, C&P errors are a common source for errors.
But I added the log especially to trace down what happens here - I do not use this amount of exclamation marks in normal logging :wink:

The three items are simple ones - not groups. But those are set by other rules. But triggeringItemName should not fire through another rule?

Only other thing I can think of is that this needs to be unique. If you made a rule with a duplicate name, only one or other version was active in OH2.
This might be managed a bit differently in OH3 and result in a mashed-together version?
Again, quickest proof is to make it different and assuredly unique, adding “99” on the end or something.

Nope, should not. Funny things could happen with the implicit variables when a rule has mixed trigger types, but yours are straightforward Item triggers and triggeringItemName should always match.

If your shade() lambda function were going wrong I would not be at all surprised, they are not thread safe and you can get variables shared across threads. But not in the rule body.

You are actually allowing this rule to trigger from Item changes, and not poking the “run” button in the GUI?

I’d make another complete new rule alongside, for an experiment

rule "just testing"
    Item BeschattenWest changed or
    Item RolladenNacht changed or
    Item IstTemperaturOGBenjaminHigh changed
    logInfo("testing", "Triggered by " + triggeringItemName)
1 Like

Actually, I didn’t even know this was possible in the user interface. :grin:

This is interesting, the test rule does behave correctly. Thanks for the hint.

After fiddling around with my rollershutters rule file for some hours trying to find the error, I guess it’s time to do some refactoring. Thanks for your help! :sunglasses:

Humm, very weird. Like an old rule image stuck somewhere.

maybe both items linked to the same channel?

That would be fine; no reason for a rule to confuse Item names.

Sounds very much to me that items are linked to wrong channels. That’s where I wanted to guide the OP to.

But the rule doesn’t know anything about channels. It got triggered by Item xx changing, has no care about who changed it, and announced a different Item name.