KNX Binding ignores autoupdate on received bus commands

[JoWuTal (Jo)]

Hi community,

I’m struggeling with the autoupdate=“false” on items linked to the KNX binding.

This is the channel definition:

Type rollershutter :    eg_arbeitszimmer_rollladen_links        "Rollladen Arbeitszimmer links"         [ upDown="1/1/20", stopMove="1/1/21", position="1/1/22+<1/1/23" ]

and this is the item definition:

Rollershutter                   EG_Arbeitszimmer_Rollladen_links        "Rollladen Arbeitszimmer links [%d %%]"                                 <rollershutter>     (gEG_Rollos, gEG_Arbeitszimmer)                         ["Setpoint"]                                    { channel="knx:device:interface:rollladen_eg:eg_arbeitszimmer_rollladen_links", autoupdate="false" }

The autoupdate is disabled so that commands given by the UI (MainUI, BasicUI, App) will not result in a predicted state. This is the desired behaviour.
But if the binding receives a command from the KNX bus (wall switch) the autoupdate=“false” is ignored resulting in the state becoming the predicted state.

Is this by desgin or is it possible to force the binding to ignore autoupdate on bus commands?

Any hint is appreciated.
Thanks in advance

Jo

[rossko57]

@JoWuTal

But if the binding receives a command from the KNX bus (wall switch) the autoupdate=“false” is ignored resulting in the state becoming the predicted state.

Demonstration please? (e.g. events log)
I guess this about some other Item, linked to a xxx-control type KNX channel.

Autoupdate operates on an Item and has no idea where commands arriving at an Item come from.

[JoWuTal (Jo)]

Hi rossko,

thanks for the quick response.
Here are the log lines:
Full down/up cycle from MainUI:

2022-01-17 15:25:29.630 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EG_Arbeitszimmer_Rollladen_links' received command DOWN
2022-01-17 15:25:34.769 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 0 to 31
2022-01-17 15:25:46.570 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 31 to 100
2022-01-17 15:25:49.964 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'EG_Arbeitszimmer_Rollladen_links' received command UP
2022-01-17 15:25:55.096 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 100 to 69
2022-01-17 15:26:06.899 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 69 to 0

Full down/up cycle from wall switch:

2022-01-17 15:26:09.267 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 0 to 100
2022-01-17 15:26:14.319 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 100 to 31
2022-01-17 15:26:26.116 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 31 to 100
2022-01-17 15:26:26.408 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 100 to 0
2022-01-17 15:26:31.620 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 0 to 69
2022-01-17 15:26:43.419 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 69 to 0

I have a rollershutter locked by logic in KNX so an issued down command will be ignored. But if I send the down command from the wall switch the item state gets updated immediately to “100”. If I then read out the actual position from the acutator with ETS the GA responds with the correct “0”. And with this telegram the items gets updated to the correct value.

I neither have other links to this channel nor any corresponding *-control item as there are just a few (~20).

@rossko57

Autoupdate operates on an Item and has no idea where commands arriving at an Item come from.

That is what I was thinking. But somehow it behaves like this

Hope this helps.
Again thanks in advance.

Regards,
Jo

[rossko57]

@JoWuTal

Full down/up cycle from wall switch

There no commands there at all. Autoupdate is not involved an any way.

Look to your KNX config, this is coming from outside of openHAB. You could use binding DEBUG logging to learn more.

[JoWuTal (Jo)]

@rossko57

There no commands there at all. Autoupdate is not involved an any way.

Here is the binding debug. After pushing the wall switch (PA 1.1.28 writing “down” to GA 1/1/20) the Item gets updates immediately:

2022-01-17 15:51:21.538 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.28' for destination '1/1/20'
==> /var/log/openhab/events.log <==
2022-01-17 15:51:21.546 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 100 to 0
==> /var/log/openhab/openhab.log <==
2022-01-17 15:51:26.583 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.7' for destination '1/1/23'
==> /var/log/openhab/events.log <==
2022-01-17 15:51:26.592 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 0 to 69
==> /var/log/openhab/openhab.log <==
2022-01-17 15:51:38.385 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.7' for destination '1/1/23'
==> /var/log/openhab/events.log <==
2022-01-17 15:51:38.397 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 69 to 0

@rossko57

Look to your KNX config, this is coming from outside of openHAB.

Are you sure? The GA 1/1/23 (actual position) remains “0” until the actuator updates it with the correct position

Thanks again
Best regards
Jo

[rossko57]

@JoWuTal

Are you sure?

Well, yes. openHAB cannot know about it otherwise. Presumably you did not expect OH to “eavesdrop” on the instruction to 1/1/20

That’s the end of my KNX knowledge, but I think this discussion covers this area

[KNX] Distinguish between command and status GA in configuration

Well, I’m no developer, but… no. I think you don’t get the point. Every time, when openHAB does a sendCommand, it also performs a postUpdate. This is default behavior. The idea is to get a feedback immediately. But this isn’t desirable in case of items with real status feedback. Therefor there is a parameter autoupdate="false". Please be aware that this is only openHAB Bus. You would need to change the core to change the behavior (and this will not happen). Furthermore, there is no explicit d…

So far as I can make out, the circumvention is to create a separate GA for the wall switch to command, which OH is not listening for.

It does strike me that there is a case for “write only” config in channels, but it doesn’t exist now.

[JoWuTal (Jo)]

Thanks for you input. I really appreciate that.

@rossko57

Presumably you did not expect OH to “eavesdrop” on the instruction to 1/1/20

My best guess is that the binding ist updating the channel with the new state on receiving commands form the bus. I don’t know.

@rossko57

That’s the end of my KNX knowledge, but I think this discussion covers this area
[KNX] Distinguish between command and status GA in configuration - #2 by Udo_Hartmann

So far as I can make out, the circumvention is to create a separate GA for the wall switch to command, which OH is not listening for.

There are seperate GA for the up/down command and the position state.

But I will check all my config twice and take a log of the KNX bus. I’ll keep you informed about my progress.
Thanks for your time so far.

Best regards
Jo

[JoWuTal (Jo)]

So I checked the KNX bus config and telegrams. As you can see in the screenshot there are no additional devices writing to the actual position GA 1/1/23.

In addition I cut off the position GAs from the Channel:

Type rollershutter :    eg_arbeitszimmer_rollladen_links        "Rollladen Arbeitszimmer links"         [ upDown="1/1/20", stopMove="1/1/21" ]

And here are the openhab logs:

2022-01-17 21:16:07.563 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.28' for destination '1/1/20'
2022-01-17 21:16:07.574 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 0 to 100
2022-01-17 21:16:15.950 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.28' for destination '1/1/21'
2022-01-17 21:16:17.400 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:interface:rollladen_eg' received a GroupValueWrite telegram from '1.1.28' for destination '1/1/20'
2022-01-17 21:16:17.411 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'EG_Arbeitszimmer_Rollladen_links' changed from 100 to 0

You can see that openhab is not longer listening to the position GA 1/1/23. But in response to the up/down commands the binding updates the state.

What am I getting wrong? Any suggestions?
Again Thanks in advance
Jo

[rossko57]

@JoWuTal

You can see that openhab is not longer listening to the position GA 1/1/23. But in response to the up/down commands the binding updates the state.

Yes. It tells you right there in your DEBUG log
received a GroupValueWrite telegram from '1.1.28' for destination '1/1/20'
openHAB is listening to messages for 1/1/20, because it’s there in your config

@JoWuTal

upDown="1/1/20"

@JoWuTal

As you can see in the screenshot there are no additional devices writing to the actual position GA 1/1/23.

That’s right.

The circumvention is to have your wal switch talk to a GA that openHAB is not listening to.