Thank you both for the valuable input.
To fix a final result for this thread:
If you define a bridge to KNX bus in OH using IP as protocol, you choose between type (i) ROUTER and (ii) TUNNEL. The bridge is called IP Gateway.
All local* parameters mean local to the OH host itself. The non-local parameters ipAddress and portNumber reference the IP address of and port on the remote KNX device, which will be used as gateway.
Using type=“ROUTER” the binding docs state, that the parameter type is the only required parameter. Technically the binding is then using the local IP address of the OH host for the localIP parameter, hence it might be more explanatory to specify this parameter explicitly. It might be necessary to specify, if OH host has multiple network interfaces in different IP subnets.
Explicit specification of the other parameters - useNAT, readingPause, responseTimeout, readRetriesLimit, autoReconnectPeriod - won’t harm.
If you omit the parameter localSourceAddr, which represents the KNX-specific physical address (PA - not Group Address, GA, as the binding doc says) OH will use as sender address in packets sending to the KNX bus. Although not required and then defaulting to 0.0.0, it might be advantageous to use an (unused) PA. An Example is binding GAs to the channels (KNX terms, not OH) exposed through the PA to help ETS build filter tables. Of course, if given, the PA should fit in the KNX topology of the project.
If with type=“ROUTER” the parameter ipAddress, the remote IP address OH will talk to using multicast (type=“Router” is multicast traffic), should be specified, e.g. for reasons of explicit documentation, it has to be the multicast IP address specified for KNXnet/IP by the KNX Association: 126.96.36.199
The parameter port, the port on the remote KNX IP Gateway OH will talk to, must always be 3671, regardless of type=“ROUTER” or type=“TUNNEL”, for it is the specified port of KNXnet/IP.
Example of a type=“ROUTER” .things file:
Bridge knx:ip:EG_D2_IPR "IPR-EG KNX-Gateway" @ "EG-UV" [
Thing device EG_D5_SA "EG-D5-Schaltaktor" @ "EG-UV" [ address="1.3.11", fetch=false, pingInterval=600, readInterval=0 ]
Type switch : L_EG_AZ_Decke "AZ Licht" [ ga="2/0/37+<2/0/40" ]
The KNX topology in ETS for the example project is:
IP Backbone - Line 1
IP Main Line - Line 1.1
TP Line - Line 1.3
KNX IP Router device using PA 1.3.0 being the KNX Line Coupler (gateway) between TP line 1.3 and IP network
KNX actuator device on TP line using PA 1.3.11 (for switching Light somewhere)
OH host is on IP line 1.1 (as it’s an IP only device from KNX point of view) using PA 1.1.1
The network topology might be:
192.168.109.0/24 subnet for KNXnet/IP communications
OH host using IP address 192.168.109.100
KNX IP Router device using IP address 192.168.109.3
Putting all in the same IP-subnet, one can avoid to deal with cross-subnet multicasting.
Hope my summary is correct.