[KNX] missing status updates for "ROLLERSHUTTERPOSITION" channels

[curlyel]

Hi mates,
my KNX controlled rollershutters do only support UP/DOWN and STOP, so no POSITION GA. Fine so far as we have the pretty handy ROLLERSHUTTERPOSITION link profile which retrofits the direct positioning feature. This works pretty well even for groups of rollershutters (in that case “KNX-Groups” consisting of all rollershutter actors of a facade) presented/controlled by a single KNX group address/GA for UP/DOWN and STOP like this:

  Thing device rolladen-gruppen "KNX Rollladengruppen" @ "Zentral"
    {
        Type rollershutter : all  "Alle Rollläden"                   [upDown="1/3/1", stopMove="1/3/2"]
        Type rollershutter : sued "Rollläden Südfassade"             [upDown="1/5/16", stopMove="1/5/17"]
        Type rollershutter : west "Rollläden Westfassade"            [upDown="1/5/19", stopMove="1/5/18"]
        Type rollershutter : ost  "Rollläden Ostfassade"             [upDown="1/5/21", stopMove="1/5/20"]
    }

These channels are linked using the ROLLERSHUTTERPOSITION profile like this:

Problem Description

As long as the control is happening just from openHAB side by sending UP/DOWN/STOP/POSITION commands - everything is fine. The status (more precisely the calculated position represented by the rollershutter item state) is correct.

BUT: When the control is done by some KNX sensor (e.g. a KNX wall switch) sending an UP/DOWN/STOP to the group adresses mentioned above, the openHAB item does not get updated. It keeps the state which resulted from the last openHAB-initiated command.

It appears to me, that the ROLLERSHUTTERPOSITION link profile is only converting from item to channel and not vice versa.

Expectation

I’d would have expected, that the ROLLERSHUTTERPOSITION profile is “listening” the UP/DOWN/STOP-commands coming from the channel as well and emulates (updates) the position state as well.

Is that understanding correct or did I something wrong?

Setup

openHAB 4.3.5
OS Debian Linux/5.10.0-9-amd64 (amd64)
Java 17.0.15 (Zulu17.58+21-CA)

[curlyel]

Mmmh, I guess I can answer to myself meanwhile …

Even though I was playing with the “*-control” channel type in KNX binding already for other requirements - but also for solving the issue here… I now tried with additional rollershutter-control channels just for healing the non-listening behaviour when using the ROLLERSHUTTERPOSITION profile.

My changed setup looks now:

  Thing device rolladen-gruppen "KNX Rollladengruppen" @ "Zentral"
    {
        Type rollershutter : all  "Alle Rollläden"                              [upDown="1/3/1", stopMove="1/3/2"]
        Type rollershutter : sued "Rollläden Südfassade"                        [upDown="1/5/16", stopMove="1/5/17"]
        Type rollershutter-control : sued-control "KNX-Control Südfassade"      [upDown="<1/5/16+<1/3/1", stopMove="<1/5/17+<1/3/2"]
        Type rollershutter : west "Rollläden Westfassade"                       [upDown="1/5/19", stopMove="1/5/18"]
        Type rollershutter-control : west-control "KNX-Control Westfassade"     [upDown="<1/5/19+^1/3/1", stopMove="<1/5/18+^1/3/2"]
        Type rollershutter : ost  "Rollläden Ostfassade"                        [upDown="1/5/21", stopMove="1/5/20"]
        Type rollershutter-control : ost-contol  "KNX-Control Ostfassade"       [upDown="<1/5/21+<1/3/1", stopMove="<1/5/20+<1/3/2"]
    }

So every rollershutter-channel for the three facades got a supporting “*-control” channel where the associated GA’s are set just for listening e.g. ga="<..."

Doing so, I was able to connect both channels for a single facade to the the rollershutter item:

• the common channel using the ROLLERSHUTTERPOSITION profile and the
• “rollershutter-control”-channel using the standard profile:

Doing so, the item states get updated even in cases when the movement is triggered from KNX side.

Still not sure, it the observerd behaviour without the second channel is intended or a flaw of the ROLLERSHUTTERPOSITION profile.

Happy, if somebody can share some insight or advise to raise an issue on Github.

Anyway, I’m happy for now as it solves my issue I had

[Larsen (Locke)]

afaik the rollershutter-profile was created for controlling rollershutter with a one-way communication like rf-433 Mhz. Direct calls to the device with e.g. a remote control cannot be received by openhab (e.g. due to rolling code). That’s why the profile only covers one direction.
I think your solution is nice for the purpose.

[curlyel]

FTR: I just raised an issue to propose a change in the profiles behavior:

[ROLLERSHUTTERPOSITION] commands/updates FROM channel TO the item are not honored for updating the state