[knx] Telegrams of -control type items repeated

Expected Behavior

openHAB should not automatically resend any received KNX telegram to the KNX bus.

Current Behavior

I need some rules to trigger on “received command” events of my rollershutters, they can not be changed to “changed” events, this was not working with the “rollershutter” type items after migrating to KNX2. The suggested workaround was to use an additional “rullershutter-control” item, which I did:

`Thing device knx-1_1_76 [ … ] { Type rollershutter-control : Rollaeden_EG_Taster “Taster Rolläden EG” [ upDown=“0/4/20”, stopMove=“0/4/21” ] … }

Thing device generic [ ] { … Type rollershutter : Rollaeden_EG “Rolläden EG” [ upDown=“0/4/20”, stopMove=“0/4/21”, position=“0/4/22” ] …`

and

`Rollershutter Rollaeden_EG “Rolläden EG” (gZentral_Rollaeden) { channel=“knx:device:bridge:generic:Rollaeden_EG” }

Rollershutter Rollaeden_EG_Taster “Rolläden EG” { channel=“knx:device:bridge:knx-1_1_76:Rollaeden_EG_Taster” }`

With this setup I observe repeated telegrams, even after deactivating all rules:

`|27.10.2018 19:17:50 |3674 |low |0 |SF |6 |1.1.76 (Tastsensor 4fach Universal TSM) |0/4/20 GA (Rolläden EG (auf/ab)) |Down|

|27.10.2018 19:17:50 |3674 |low |0 |SF |6 |1.1.241 |0/4/20 GA (Rolläden EG (auf/ab)) |Down|`

Steps to Reproduce (for Bugs)

See above: Create a rollershutter and a rollershutter-control item with the same KNX GA and send this GA to the KNX bus.

Context

This may cause problems with other the KNX devices or logic engines on the bus.

I also had a huge problem, when two openHAB instances where active at the same time (production and testing). These two instances send those telegrams with maximum rate to each other.

Your Environment

This was tested with the KNX2 binding of the Milestone 4 release of openHAB 2.4 on macOS 10.13 (High Sierra) Java version: openjdk version “1.8.0_181” OpenJDK Runtime Environment (Zulu 8.31.0.1-macosx) (build 1.8.0_181-b02) OpenJDK 64-Bit Server VM (Zulu 8.31.0.1-macosx) (build 25.181-b02, mixed mode)

[kaikreuzer]

In fact, a command sent by openHAB to knx should result in a status update for the channel by knx, not by openHAB itself

That’s wrong in that case. -control channels mean that the state is maintained in openHAB, not KNX (i.e. the device is somewhere else, NOT in KNX). So if there’s a command in openHAB, the device (e.g. a hue bulb) will change state, which is sent in openHAB and needs to be pushed out to KNX, so that a wallswitch can show the updated state (e.g. by LEDs in the wallswitch).

[jo47011]

Hi Anton, thanks for the feedback. Yes seems to work now on Unix, Mac and Windows. Already helped another Windows users to get it run. Great if it can help others…