Any way to isolate events from UI vs Hardware

Setup, Configuration and Use Scripts & Rules
2

There is not an easy way, but there is a way. But first your questions:

Any time an Item is updated, even if it is with the same state, the Item will receive an update. Commands also cause updates. Pretty much any time anything (rules, UI, binding) touches an Item an update event is generated. When posting an update from a Rule, only the OH Item state activates. Updates are not forwarded to the binding and therefore are not sent to the device.

Any time an Item is commanded, even if it is with the same state, the Item will receive a command. Commands are typically generated from the UI, Rules, or the Binding. All interactions from the UIs are commands. A commands are forwarded on to the binding and on to the device.

Any time an Item changes state, whether it is from the system (e.g. restoreOnStartup), from an update, or from a command there is a changed event.

None of these make any distinction between the sources of the command or update or change.

So the challenge is there is not a way to tell where commands or updates or changes come from in a Rule. We can only know that they happened.

There are three ways I can think of to achieve this, all three of which are a little complex. Two of them are documented in Design Pattern: Manual Trigger Detection. The third I’ll describe below.

For your dimmer, you need to define two Items, your original Item and a Design Pattern: Proxy Item. Put the Proxy on your sitemap and when you send a command to the light in your Rules use the Proxy Item.

You will need two rules:

rule "My Dimmer changed"
when
    Item MyDimmer received command // you might need received update here, changed could work, depends on how your binding reports changes made at the device itself
then
    // This was a change caused by manual interaction at the dimmer itself

    MyDimmerProxy.postUpdate(MyDimmer.state) // update the Proxy
end

rule "MyDimmerProxy received a command"
when
    Item MyDimmerProxy received command
then
    // This was a command that came from the UI or a Rule

    MyDimmer.sendCommand(MyDimmerProxy.state) // update the device
end

Notice the careful use of postUpdate in the first rule. By using postUpdate and triggering the second rule with received command we avoid getting into an infinite loop. The second rule will not trigger from the postUpdate.

1 Like