Correct parameters for KNX Bridge of type ROUTER

Add-ons Bindings
1

Hi there,

I’m a bit confused about the correct parameters for a bridge declaration in a things file. The bridge should be of type=“ROUTER”, not TUNNEL.

  1. Which parameters are required, which optional, which should be omitted?

From here I get, that required are:

type = "ROUTER"
localIp="<IP-address>"

Optional are:

localSourceAddr
useNat
readingPause
responseTimeout
readRetriesLimit
autoReconnectPeriod
  1. the localIP (and localSourceAddr) parameter
    From the same post I read, that localIP is an IP address, which is bound to a KNX IP-Router?!
    You can get this from posts no. 6 & 7 in the thread as well as from replies from Dim and Udo.

But this sounds weird. First, we are doing multicast with type=“ROUTER”, so there should be no need for a destination IP. Second the wording: “local”-something - shouldn’t it be local to the place of declaration, execution or use? Hence the openHAB system?!

I feel my thoughts are backed up by older posts, pre-time to the new KNX2 binding, as here and here.

I assume, and feel that’s also being said here, that localSourceAddr is a KNX PA for the openHAB system, that is a dummy PA (and connected GAs) for e.g. helping ETS to build filter tables.

If I am correct, then it leads to the question, which local* parameter is required and what for?

  • If my openHAB server were to have only one NIC with only one IP…
  • as far as I know, KNX/IP Routing doesn’t need a sending PA, but maybe I misunderstood

Is one of my assumed to be optional parameters required? Or a parameter not mentioned here?

Sorry, I’ve been asking so many questions :confused:

2

The bridge can be: (a) IP or (b) Serial
The (a) IP bridge can be of type: (i) Router or (ii) Tunnel

Correct. The KNX Binding on your OH2 host will “broadcast” to the multicast IP Address: 224.0.23.12 in order to communicate with your KNX/IP Router on the network. You can explicitly set ipAddress="224.0.23.12" if you would like (but this is optional since it is the default for type="ROUTER")

None. Both (localIp & localSourceAddr) are optional. Source: Docs

localSourceAddr if not set, will default to 0.0.0
localIp if not set, will be detected from your OH2 host NIC

From what I know, you need a sending PA (localSourceAddr=“0.0.0” or another PA value that you define) even in Routing mode.

Correct.

@george.erhan

1 Like
3

As far as I know, localIp is not optional when using ROUTER mode, because you have to define the interface which shall subscribe to multicast. This is done through the IP address because… well… I don’t know, but I guess it’s easy to use this (and it’s OS independent).

1 Like
4

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: 224.0.23.12
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" [
	type="ROUTER",
	localIp="192.168.109.100",
	localSourceAddr="1.1.1",
	useNAT=false,
	readingPause=50,
	responseTimeout=10,
	readRetriesLimit=3,
	autoReconnectPeriod=60
]	{
			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" ]
			}
	}

Explanation:

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.

1 Like
5

:ok_hand::+1::metal:

Correct. The docs have a mistake in this aspect.

6

In fact it’s possible to change both parameters, but you have to change them at all devices to fit.

Port 3671 is reserved for EIBnet/IP, but it’s possible that you have to change the port. For instance, knxd/eibd are using 6720 as default)

The Multicast Address 224.0.23.12 is reserved for EIBnet/IP as well, but it’s not that you must use this address, it’s only reserved and per default the correct Multicast Address.
In fact, it’s possible (though very rare :wink: ) to run multiple knx universes at one LAN, only by dividing them by different Multicast Addresses. openHAB could subscribe to multiple knx universes, and that’s a really nice feature (I could join another knx network by using a VPN Tunnel to forward Multicast…)

1 Like