How to evaluate an Item change based on source of change

Setup, Configuration and Use Scripts & Rules
1

Hi,

How can I evaluate an Item change based on the source of the change? I have a Switch Item that can be changed either by a rule or manually in the sitemap. Is there an Item property that can be used as a condition in a rule? E.g. do not change the switch when it was switched manually.

Thanks!

2

I can just provide an example for python

from openhab import rule, Registry
from openhab.triggers import ItemStateChangeTrigger

import scope

@rule(
    triggers = [
        ItemStateChangeTrigger("pOutdoor_Light_Automatic_Main_Switch")
    ]
)
class AutomaticMainSwitch:
    def execute(self, module, input):
        if input["event"].getSource() == "my_custom_source":
            # manual change by postUpdate
            return
            
        # changed by anything else

Registry.getItem("pOutdoor_Light_Automatic_Main_Switch").postUpdate(scope.ON, "my_custom_source")
3

The source of the event is on the event. In JS it’s event.source. Look in events.log to see what the source will look like. Sometimes the source will be a chain as an event goes from one part of the system to anotheeer (e.g. Thing → Item → rule → Item). So you may need to do some parsing of the source.

if(event.eventSource == 'org.openhab.ui=>org.openhab.core.io.rest$rich') {
  // Item event came from a UI/REST API from user rich
}
4

is this useable in RulesDSL?

Greets

5

Sadly, the PR that makes this possible wasn’t merged in time for 5.2.0:

Once that PR is merged and part of a release, it will be possible. As of today, it isn’t.

6

… yeah, this is what I figured and my favorite LLM confirms:

Can I inspect the event source?

Not in Rule DSL.

The event bus internally knows whether an event came from REST, UI, a binding, etc., but that information is not exposed to Rule DSL triggers.

The LLM suggested solution is to work with postUpdate() vs. sendCommand() while the sitemap (manual) change triggers a sendCommand(). So in the RuleDSL trigger on the Item I can use

when
    Item MySwitch received command
then

But this does not help to evaluate the state change source within a rule. So I’m supporting the PR as it addresses my needs.

Thanks!

7

The LLM is making stuff up. Changing the trigger type isn’t going to do anything for you in this context.

For now, you either need to use one of the other langauges, wait for the PR to get merged before addressing this requirement, or using ooooone of these much more complicated approaches described in Design Pattern: Manual Trigger Detection. the Proxy Item appraoch is the most full proof.

Why won’t using postUpdate help you here? Because it surves a completely different purpose. postUpdate will only update the state of the Item. But anything can update an Item so using postUpate doesn’t give you any additional information. And an update doesn’t cause the device to do anything. It only changes the Item’s state. You cannot turn on a light using postUpdate.

On the other side, sendCommand usually results in a follow on update. For example, if a command to turn on a light is sent, if the light isn’t already ON, following the command there will be an update and then a change event.

You can’t use any of this to determine where the event came from.