Why a postUpdate triggers a binding!?

Add-ons Bindings
1

I’ve this behaviour somewhere else, but for testing, I’ve used the following configuration:

file.items

Switch Light_Alice 	“sends postUpdate” 	
Switch Light_Bob	“receives postUpdate” 	{ autoupdate="false", knx="1.001:1/1/14" }

file.rules

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.

2

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.

3

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?

https://github.com/openhab/openhab/wiki/Actions#event-bus-related-actions.

Are there any other bindings, where it really doesn’t matter if we use sendCommand or postUpdate!?
Is there any list?

How could I circumvent this behaviour? Should I use a proxy Item and apply rules?

4

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!

That is what I would suggest.

1 Like
5

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?