KNX 2: Received command rule trigger does not work

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?

Trying to figure out the same Question currently.

I was using this rule with KNX1 which worked fine

rule "Message if Blinds UP"
		Item RLHausAlle received command UP
		sendTelegram("bot1","Rolläden im ganzen Haus am "+ Date.state.format("%1$td.%1$tm.%1$tY") +" um " + Date.state.format("%1$tH:%1$tM") + " geöffnet")

rule "Message if Blinds DOWN"
		Item RLHausAlle received command DOWN
		sendTelegram("bot1","Rolläden im ganzen Haus am "+ Date.state.format("%1$td.%1$tm.%1$tY") +" um " + Date.state.format("%1$tH:%1$tM") + " geschlossen")

As with KNX2, the “received command” is not supported by the non-Control-items, so am not sure how to work around that. If my logic triggers the blinds, it uses the RLHausAlles item. In case I needed to define something like RLHausAlles-Control-Item then I would Need an additional rule to modify the Control-item, as it would not get fired by the RLHausAlles command, as far as I understand this. Can somebody give a hint how to deal with this?

Hm, it get’s even more confusing

this WORKS

rule "Test ON"
		Item LichtUnterschrankNord received update ON
		LichtKueche.sendCommand (ON)

rule "Test OFF"
		Item LichtUnterschrankNord received update OFF
		LichtKueche.sendCommand (OFF)

this DOESN’T…

rule "Message if Blinds UP"
		Item RLHausAlle received update UP
		sendTelegram("bot1","Rolläden im ganzen Haus am "+ Date.state.format("%1$td.%1$tm.%1$tY") +" um " + Date.state.format("%1$tH:%1$tM") + " geöffnet")

According to the documentation, RECEIVED UPDATE can use an Attribute (UP or ON/OFF in These cases). Why does it work with the light, but not the rollershutter?

UP is a command you can send to a rollershutter, but not a state a rollershutter Item can take.
Maybe you want to use trigger
Item received command UP

Understood, that clarifies the behavior. Thanks!

Probably I am not the only one using “-control” type things to be able to trigger on up/down & stop commands. In the past I noticed, that openHAB resends telegrams received for these items to the bus.

This can be prevented by adding autoupdate=“false” to these items, as suggested by Kai Kreuzer: