KNX 2: Received command rule trigger does not work


in my KNX 2.x testing environment I noticed, that my blinds did not move as expected. First I thought, that this was caused by not being able to send a percent value to the rollershutter item.

But further testing showed, that the rules which sends the value was not triggered.

The isolate the problem I created several test rules:

1. Blinds “received command” and "update"

rule "Test blinds command"
	Item Rolladen_Arbeiten_EG received command 
	logInfo("blinds rules", "########### Rolladen_Arbeiten_EG received command: " + receivedCommand)

	if (receivedCommand == DOWN)
		logInfo("blinds rules", "######### Rolladen_Arbeiten_EG received command down")
rule "Test blinds updated"
	Item Rolladen_Arbeiten_EG received update 
	logInfo("blinds rules", "################ Rolladen_Arbeiten_EG received update: ")

In openHAB 2.2 with KNX 1 the rule trigger “received command” works as expected. In openHAB 2.3 with KNX 2 only the “received update” rule trigger works.

1. Switch item “received command” and "update"
I noticed the same behavior for a switch item.

The following rule works for openHAB 2.2 with KNX 1.x:

rule "Received KNX Watchdog Response"
	Item KNX_Watchdog_Receive received command ON
	logInfo("system rules", "Received KNX Watchdog reply")

In openHAB 2.3 with KNX 2, the above rule is not triggered but a “received update” trigger works:

rule "Received KNX Watchdog Response Update"
	Item KNX_Watchdog_Receive received update
	logInfo("system rules", "Received KNX Watchdog reply update")

I am nut sure, if this is intended behavior or a bug in openHAB 2.3 or KNX 2

It depends on how the item is defined. :slight_smile:

Mmh, how does it depend? Do you refer to channel type switch vs. switch-control?

I am running in the same issue in my test installation. Write-messages on the KNX-Bus trigger ChangeEvents and not as in previous versions CommandEvents.

My Items are defined

Switch Light_A                "A"                <light>      (gLight)                             { channel="knx:device:bridge:1-1-72:Output_A" }
Switch Light_B                "B"                <light>      (gLight)                             { channel="knx:device:bridge:1-1-72:Output_B" }
Switch Light_C                "C"                <light>      (gLight)                             { channel="knx:device:bridge:1-1-72:Output_C" }

The Actor is defined as

    Thing device 1-1-72 [
    ] {
        Type switch:         Output_A                      [ ga="<8/3/130+8/3/0" ]
        Type switch:         Output_B                      [ ga="<8/3/60+8/3/0" ]
        Type switch:         Output_C                      [ ga="<8/3/70+8/3/0" ]
        Type switch:         Output_D                      [ ga="<8/3/190+8/3/0" ]

@Udo_Hartmann: could you illustrate a bit more, please? The documentation shows only one way to to configure the binding to a channel of an Item: Binding Configuration.

Here are my definitions for the Switch item:

Thing device knx-wg-1_1_254 [
        // address="1.1.254",
        // fetch=false,
        // pingInterval=300,
        // readInterval=3600
    ] {

Type switch                  : KNX_Watchdog_Receive                            "KNX Watchdog RX"                                 [ ga="10/2/241" ]

Type switch                  : KNX_Watchdog_Receive                            "KNX Watchdog RX"                                 [ ga="10/2/241" ]

In fact, the behavior in openHAB1 was “wrong”. openHAB receives commands, but these commands are not directed to openHAB but to the knx actuators. So the correct trigger is changed or received update but not received command.
When defining a channel as ...-control, openHAB2 will act as the actuator, so it will receive commands.

1 Like

I partly understand this logic, onnthe other hand a KNX command is directed to a GA and not any special device. So openHAB can received a KNX command like any other KNX device.

If I understand the implications correctly, it will not be possible anymore to write rules that trigger on a „up“ or „down“ command for rollershutters instead you would have to monitor the state change of a rollershutter.

This on the other hand is problematic when the KNX command moves a group of shutters, as you would have to pick on of the shutters of this group to monitor, which will not always give the desired result.

In question of a group of roller shutters, there is no actuator which is allowed to provide the real state of this GA, so, this GA should be a *-control Channel.
But you are right, UP/DOWN is not recognised for single actuators (I wasn’t aware of this issue, and I have actuators for which I need this functionality…)

I think, that the concept of a „state of a GA“ does not really work for KNX devices.

In KNX a command is send to a GA, several devices can listen to this GA and react to the command or ignore it (e.g. when the channel is blocked). So multiple actuators might react completly different to the same command.

In a lot of cases there will be no single device which holds the state of a GA, althoug there will be several devices that react to commands received on that GA.

Beside that I think, that triggering on up and down commands is an important use case, as it is not the same as reacting to the state of a device, even when the there is a 1:1 relation between tbe GA and the device.

1 Like

Yes, it does, but only for real actuators.

And the item which represents the actuator channel should receive the actual state of the channel. So, the item does not store the state of the GA which sent the command but the state of the actuator channel (which comes through another GA, exclusively sent by the actuator)

And in this case, the GA should belong to openHAB (i.e. Type *-control)

100% ACK :slight_smile:

But in these cases the „state of a GA“ is meaningless. If the GA „all rollershutters“ receives command „down“, and all except one shutters are moved, what status should be reflected by the GA?

This problem is independed from where the status is keept, in an actor or in openHAB.

After a small research, I added another channel with -control for the same group addresses:

Thing device HagerShut1_1_42 "RollGruppe 2" @ "KNX" [ address="1.1.42" ] {
    Type rollershutter         : ch4     "Tür"    [upDown="3/6/60",stopMove="3/6/61",position="3/6/63+<3/6/64"] }
Thing device GiraTSplus1_1_112 "TS2 Verandatür" @ "KNX" [ address="1.1.112" ] {
    Type rollershutter-control : rocker3 "Hoftür" [upDown="3/6/60",stopMove="3/6/61"] }


Rollershutter ShutterDoor     "Süd4 Tür" {channel="knx:device:bridge:HagerShut1_1_42:ch4"}
Rollershutter ShutterRockerDoor "Hoftür" {channel="knx:device:bridge:GiraTSplus1_1_112:rocker3"}

As result, I have now two items, one for receiving commands from knx bus, the other for receiving state changes and send commands such as UP/DOWN/STOP or percent (0 to 100)
Item ShutterRockerDoor does not receive a command if I do a ShutterDoor.sendCommand()

Thanks for testing and sharing this!

I performed a similar test today and can confirm your findings. In addition to my existing rollsershutter thing and item (Rollaeden_EG) I created a rollershutter-control thing and item (Rollaeden_EG_Taster) and for each item rules for triggering on update, change and command

When openhab sends a command to the rollersuhtter item Rollaeden_EG.sendCommand(DOWN), the following rules are triggered:

Rollaeden_EG received command. receivedCommand: DOWN
Rollaeden_EG received update. Rollaeden_EG.state: 100

When using a wall switch to move the blinds, the following rules are triggered:

Rollaeden_EG_Taster received command, receivedCommand: STOP
Rollaeden_EG received update, Rollaeden_EG.state: 0
Rollaeden_EG changed,  Rollaeden_EG.state: 0
Rollaeden_EG_Taster received command, receivedCommand: UP
Rollaeden_EG_Taster received update, Rollaeden_EG_Taster.state: 0
Rollaeden_EG_Taster changed, Rollaeden_EG_Taster.state: 0

So indeed, defining additional control items is a possible workarround for triggering on “received command” when using a wall mounted switch, assumed, that this approach has no side effects. If there is the possibility, that booth, the rollershutter and rollershutter-control item receive a command this has to be take into account when writing the rules. I am not sure, if this could happen.

But I can not say, that I really like this approach. For every affected GA two additional elements must be created and rule triggers must be adapted accordingly. This is error prone and not very easy to grasp for a beginner.

I must admit, I am not happy about the changes the new KNX2 binding introduced, either. Please understand, this is not a rant or meant negative in any way, it is just my concerned feedback as a user (not developer!).

I highly appreciate all the hard work you guys are contributing to this awesome project and for me, developing software is close to magic.

But looking at the overall development of OH2 and the stated intention to make it MORE user friendly, sometimes i am not sure this is going into the right direction. Maybe you want to stop for a second, review the development path and make sure, you do not forget the non-developers out there.

This new behaviour of the KNX2 binding might bring it in line with the OH2 logic and I understood from other posts of Udo that “this is the way OH2 is designed”. But please think about the increased complexity you just encountered by yourself - and I fully agree with the conclusion of juelicher here as well.

So my honest and concerned feedback would be: maybe you want to stop a moment and think about some details in regards to bindings like the KNX2 one to maybe find some compromises between “correct alignment to the overall concept” and “have it userfriendly and simple, not more complex”.

Again, please understand my post right, this is more of a “cry for help” and not a rant. I have seen people asking for a little bit more support for non-developers, but their feedback obviously was perceived as a personal attack by some people (developers), rather than a valuable feedback from potential users of the work that might help OH2 to become even better.

It is not always right to be right, so to say :slight_smile: Sometimes less perfection can lead to a “better” product for the user.

Just my 2 cents…

[edit] Just found this post here KNX2, how to set it up?
One needs to configure KNX physical device addresses as well now, let alone using a strange syntax with dashes instead of points? Seriously?


No, not at all.
You do not need to configure any real device aside from the bridge. But you are able to define the hardware as it is, one thing per device. As no dots are allowed in a thing name, you have to substitute them, if you wish to hold the bus address in the thing name. If defining the hardware per device with the correct bus address, openHAB is able to monitor each device.

Thanks for clarification!


I could not have worded it better! Especially including the part of „not meaning it negative or as critic“

I find it always hard to write such feedback when not activly engaged in developing but I hope, that it is appreciated nonetheless.

In my opinion the changes made are spot on. Looking at the structure of how knx projects are build the way it is now in openhab with Devices, Things and Channels (linked to items) is far more streamlined.
I can see now where it will “glue” together with eg future plan to mport a knx project.

When comparing the current behaviour of the KNX2 binding to the openhab documentation ( I am not sure, if the it is correct.

According to the documentation changes through the binding trigger booth, the received command and received update trigger.

I have some rollershutters which are controlled from with openHAB (item.sendCommand()) or via a wall mounted switch and for which I want to trigger rules when they receive a command.

Currently this works when I create two things & items for these rollershutters, one rollershutter and a rollershutter-control with the same up/down and stop GA. The rules are triggered if any of these items receive a command.

Is it really necessary to have two items or am I missing something and the same behavior can be implemented with only one item?