rule "Test if postUpdate triggers binding"
when
Item Light_Alice received command
then
Light_Bob.postUpdate(ON)
end
file.sitemap
Switch item=Light_Alice
Switch item=Light_Bob
When I toggle ‘Light_Alice’, the above rule is triggered, however instead of the behaviour I was expecting, the ‘Light_Bob’ is turned on, and a KNX message is sent (I’ve checked on the bus).
Looking to the log, it looks likes that ‘Light_Bob’ received command instead of an update!
21:43:59.668 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Light_Alice' received command ON
21:43:59.670 [INFO ] [marthome.event.ItemStateChangedEvent] - Light_Alice changed from OFF to ON
21:43:59.813 [INFO ] [smarthome.event.ItemCommandEvent ] - Item 'Light_Bob' received command ON
Is there anything wrong with this setup. Shouldn’t a postUpdate not send a command, but only update the state?
I’m using the latest openHAB 2.0 snapshot.
KNX 1.x is one of a few bindings that responds to bound item’s state being updated as well as responding to receiving a command. There are use cases where this is desirable; for example, openHAB can act like a gateway between different technologies by having multiple bindings associated with a single item. The only argument against providing this functionality that I have seen is that it is not consistent across all bindings and thus causes surprise.
Thank you for your quick reply!
Could we say that the usual distinction between sendCommand vs postUpdate, as described in the following link, doesn’t apply to KNX?
Yes, except that the wording in that section could perhaps be improved to be more precise. I think of items’ states are not really being “owned” by any source that can change them – zero or more bindings can change items’ states, the REST API, rules, and maybe others. But it’s fair game that bindings can monitor the state of an item and pass along that state change to the remote system (KNX in this case). To make a gateway between KNX and a Nest thermostat, reporting out to an MQTT broker, would be as simple as
Number MyComfort { knx="...", nest="...", mqtt="..." }
It would take some effort to compile the list to be sure it was accurate and therefore useful, and at this point things are changing with OH2 bindings. Not to discourage anyone from the effort!
Thank you for your clarification.
By any chance, do you know if that semantics will remain on the KNX 2.0 binding, or if there will be a chance to configure that behaviour?