Understanding KNX2 binding

Add-ons Bindings
1

Hello Guys, i’ve read a lot about the new KNX2 plugin, but there is still something i haven’t got any answer on yet…

At the Wiki some items is defined in the knx.items:

Switch demoSwitch “Light [%s]” { Channel=“knx:device:bridge:generic:demoSwitch” }

Is following correct understood from the Channel definition:
knx - just always knx
device - defined in the “Thing device generic”?
bridge - where from?
generic - from the “Thing device”?

Also i’ve read in many posts that @Udo says you can create items with just 2 clicks in VSCode - i really can’t see how that should be done…

2

:slight_smile:

First step is, to activate the knx2 binding by installing it.
Second step is to configure a bridge - either Paper UI or *.things file:

Bridge knx:ip:bridge1 "Weinzierl 730 IP" [
    ipAddress="192.168.178.234", 
    portNumber=3671, 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
]

This part is very much like other OH2 bindings. Its possible to use a serial interface, this would be knx:serial:bridge…
After the bridge part, you need to configure the channels. Also, this can be done via Paper UI or *.things file:

...
localSourceAddr="0.0.0"
]
{
    Thing device thebenBin1_1_1 "theben Binary 1.1.1" @ "KNX" [
        address="1.1.1",
        fetch=true,
        pingInterval=600,
        readInterval=0
    ] {
        Type switch                 : ch1 "Channel 1"         [ga="1/1/1"]
        Type switch                 : ch2 "Channel 2"            [ga="1/1/2"]
    }
}

As a result, you will get things and channels. You do not need to define one thing per device, but this way it’s possible to monitor the device(s).

In VSCode, (when configured correctly), you will get a list "OPENHAB THINGS" on the lower left side.

  • Open the *.items file and move the cursor to the line, where the item(s) shall be incorporated.
  • Search the Thing in the list and right-click the Thing (or the channel) you whish to incorporate in the *.items file. Select "Create Items from Channels".

You will get items in the form

Switch Ch1 "Channel 1" {channel="knx:device:bridge1:thebenBin1_1_1:ch1"}

when selecting single channels, or

Switch    thebenBinary111_Ch1   "Channel 1"   {channel="knx:device:bridge:thebenBin1_1_1:ch1"}
Switch    thebenBinary111_Ch2   "Channel 2"   {channel="knx:device:bridge:thebenBin1_1_1:ch2"}

when selecting things. So, it’s up to you to influence the automatically created item names by defining things and channels.

3

Hello Udo…
Thanks - tha clarified a lot of it actually :slight_smile:

How should the “thebenBin1_1_1” be grouped - should this be etc. a single dimmer, with the main GA 1/1/1 and then the object under this like brightness and so on should be under that item?

4

Tthat’s up to you :slight_smile: You can use one thing for all (of course then without the [ … ] part, address, fetch and so on), one thing per channel, one thing per hardware device (this is what I did - the channel path represents the knx hardware topology).

5

How Would the file (*.things) look like if
eg. theenBin1_1_1 have 2 channel and thebenBin1_1_2 have 2 channel
Would they be ind the same file ?

6

There are two options to configure bridged Things through a file, either configure the things as a part of the bridge, or configure the Things separated from the Bridge.

Bridge knx:ip:bridge1 "Weinzierl 730 IP" [
    ipAddress="192.168.178.234", 
    portNumber=3671, 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=60,
    localSourceAddr="0.0.0"
]

Thing knx:device:thebenBin1_1_1 (knx:ip:bridge1) "theben Binary 1.1.1" @ "KNX" [
    address="1.1.1",
    fetch=true,
    pingInterval=600,
    readInterval=0
] {
    Type switch                 : ch1 "Channel 1"         [ga="1/1/1"]
    Type switch                 : ch2 "Channel 2"            [ga="1/1/2"]
}

Thing knx:device:thebenBin1_1_2 (knx:ip:bridge1) "theben Binary 1.1.2" @ "KNX" [
    address="1.1.2",
    fetch=true,
    pingInterval=600,
    readInterval=0
] {
    Type switch                 : ch1 "Channel 1"         [ga="1/2/1"]
    Type switch                 : ch2 "Channel 2"            [ga="1/2/2"]
}

when using this form of configuration, you are also free to split the configuration to multiple files.

7

The above shows that you create once the bridge which basically is the interface KNX/IP made multiple things. Than it shows, if i get that correctly, that for each KNX device (e.g. Actors, Sensor) you create a own dedicated thing with the physical address on the KNX. Just to be sure, is this required?

I for example use the following, but have some strange behaviour with OH 2.5 that I did not have with OH 1.8. It consists of 4 different physical KNX devices, the IP/KNX interface, the switch, and 2 actors, one for light and one for roller-shutter

Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="10.1.1.2",
    portNumber=3671, 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=30
] {
    Thing device generic [ 
        // 24.03.2020 deaktiviert address="2.1.1" und ersetzt durch address="1.1.3",
        address="1.1.3",
        fetch=true,
        pingInterval=300,  
        readInterval=3600   
    ] {
Type switch	            : UG_Buero_Licht	                                "Licht Büro"	                                    [ ga="1/0/5+<1/1/0" ]
Type switch	            : UG_Buero_Bewegungsmelder_Sperre	                "Bewegungsmelder Büro Sperre"	                    [ ga="1/1/26" ]
        //
        //
        // UG Büro  Jalousien
        //
Type rollershutter      : UG_Buero_Jalousien_Nord                           "Jalousien Büro Nord"                               [ upDown="3/1/8", stopMove="3/0/8", position="3/5/8+<3/3/8" ]

So basically, i put all the channels of the different devices here. Is this approach wrong?

8

Well, it’s ok to use just one generic Thing, but it’s definitely wrong to setup an address for such a thing, as there is no individual address for a non existing (as one block of hardware) device. For the same reason you can’t use neither fetch=true nor pingInterval, both parameters belong to the hardware device with the individual address.

As a matter of fact, you should not use readInterval in a single generic device as well, as this parameter will cause frequent read requests on every readable Group Address.

Use this function with caution! In most cases, you will not need a frequent status update, as the knx device will send its status either frequently or at every change.
Frequent read requests will increase the bus load definitive.
Please be aware that all read requests are sent per Thing, so if using one big Thing with hundreds of readable GA you will get hundreds of read requests once per hour (if setting readInterval to 3600). This may destabilize the bus.
If you need the frequent pull of status for some GA, put them together in another generic thing (but use another name for this thing as thing names must be unique per bridge).