Unit-Support, KNX 2, Karaf 4.1.5 Upgrade and more!

Is localIp the IP address of your openHAB?
Does changing the configuration of the deviceto localSourceAddr="0.0.0" change anything?

[EDIT]: Your issue actually might be the same as above, related to the device pinging. We are tracking this in https://github.com/openhab/openhab2-addons/issues/3364.

There is a breaking change in behavior of knx when migrating from knx1 to knx2.
In knx1 there was no difference between incoming and outgoing items. For example, if defining a rollershutter

Rollershutter MyShutter "My Shutter [%d %%]" {knx="1/1/1,1/1/2,1/1/3+<1/1/4"}

I received a command when pressing the knx rocker associated to the roller shutter.
With knx2 I have to define at least two channels (one as -control) for a similar result:

Type rollershutter-control : MyShutterControl [upDown="1/1/1",stopMove="1/1/2"]
Type rollershutter         : MyShutterChannel [upDown="1/1/1",stopMove="1/1/2",position="1/1/3+<1/1/4"]

So an item linked to MyShutterChannel will only receive state updates of the rollershutter, while MyShutterControl will receive commands UP/DOWN/STOP.
If sending a command through MyShutterChannel there is no received command for MyShutterControl.

1 Like

Most probably I am too dumb…but I don‘t get it. Why would I want to have two items in this case? Or to be more precise: which of these items would I use for the sitemap to show? The -control Item I‘d guess, as the actuator is not OH2. But what would I the do with the other one…? Honestly, I don‘t understand the possible usecases for this construction.


I believe that @Udo_Hartmann wants to be able to be able to have the Item [...] received command in OH2 when he presses the knx rocker.

In KNX1, such an action produced a command in OH2.
In KNX2, such an action produces a state update (I prefer this personally and as a result, I only use 1 “regular/non-control” Channel) :slight_smile:

To “replicate” KNX1 behavior, he is using the -control version of the Channel.

The -control version is useful when you have the Item bound to more than 1 bindings (e.g. knx + zwave)
You need the received command in such a scenario in order for OH2 to trigger the other binding also.

Thanks for your explanation. Maybe I need to run into a “matching” problem first, before I really understand this :slight_smile:

In fact, the knx2 state update will be totally different to knx1 received command.

  • knx1: if switching a rocker, you will receive the command (UP/DOWN/STOP for roller shutter).
    When the roller shutter reached the new position, the actuator will send the new state (0 to 100 for roller shutter).
  • knx1: If sending a command from openHAB, you will get a received command plus immediate state update to 100 (DOWN) respectively 0 (UP). If sending Stop, there is no state update other than the one from the actuator. Of course it’s possible to switch off this autoupdate.
  • knx2: if switching a rocker, you won’t receive any command.
    When the roller shutter reached the new position, the actuator will send the new state (0 to 100 for roller shutter). So you only will receive a Number. For 0 and 100 it’s easy which command was sent…
  • knx2: If sending a command from openHAB, as far as I remember, the behavior will be like knx1.

It’s ok for me, as there are only few items for which I need this information.

1 Like

Thanks for the explanation. Testet it and undertstood what you are saying. Not sure why it is implemented this way, so why commands from sensors (rockers etc) are no longer transmittet?

I have noticed, that with the new binding a lot of states are reflected wrong. So lights which are on are shown as off in OH2. Or when using a slider for a dimmer, it shows a strange behavior as well: I slide to 70% or so and let go, then the slider jumps to 100% and stays there, still the light is set to the correct 70%. Have seen this on my Theben dimmer on ONE channel repeatedly, whereas on the other channels everything is fine.

.state seems to work differently as well. I have a rule that should only run the rollershutter when a cron expression fires AND it is NOT on 85% . Until 2.2 and KNX 1 it worked as expected; since 2.3 / KNX 2 it obviously seems to ignore the .state and runs the rule every time the cron expression fires.

Where did you get all the detail information about the new binding from? The official binding documentation is not very specific on such details and why which change was introduced.