KNX/IP Interface Individual Address ignored

  • Platform information:
    • Hardware: Raspberry PI 4 / 8GB
    • OS: Raspbian
    • openHAB version: 3.1.0 Docker image

I configured my KNX IP Interface (Weinzierl 731) in OpenHab using those settings:

UID: knx:ip:c6aa14dc5d
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.66.xxx
  autoReconnectPeriod: 60
  type: TUNNEL
  localSourceAddr: 15.15.251
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

The localSourceAddr setting, however, seems to be ignored. When OH sends telegrams to the KNX bus, they are coming from 15.15.250, which, as I assume, is the default and first available address assigned by the KNX/IP interface. The interface is configured to allow the following addresses to be used:

image

What’s more, the logs contain then the following warnings, even if the telegrams are properly delivered to KNX bus:

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 15.15.251->0/4/0 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 79 08 0a 17 13 04 24 00
        at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[bundleFile:?]
        at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[bundleFile:?]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:177) ~[bundleFile:?]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:264) ~[bundleFile:?]
        at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:332) ~[bundleFile:?]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:243) ~[bundleFile:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:397) ~[bundleFile:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:354) ~[bundleFile:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:459) ~[bundleFile:?]
...

I’m suspecting that this happens, because OH “thinks” that its Individual Address is 15.15.251, while the KNX responds to the actually used address 15.15.250.

Am I missing something or there is sth wrong with the KNX library used (Calimero)?
I’ll just note that when I tried similar “client” (Home Assistant using xknx library), there were no such issues (ie. the telegrams are sourced from the Individual Address specified in config).

localSourceAddress is NOT an individual address of an existing device. Instead, this is an unused individual address.
You can setup a fake device with this individual address to identify it as openHAB, but the individual address must not be used by any real device.

Hi Udo,

There is no existing device with 15.15.251 address on my bus.
Maybe the screenshot I pasted is a little bit confusing. The screenshot just shows the addresses available for clients connecting over the KNX/IP interface. I wanted OH to use 15.15.251 by setting the localSourceAddress. Unfortunately it doesn’t work. The telegrams sent by OH to the KNX bus are still coming from 15.15.250 (which, as I guess, is the first available address assigned by the KNX/IP interface).

Yes, it is. See you own screenshot :slight_smile: It’s part of your Weinzierl knx IP Interface :wink:
Once more: die individual Address must not be used by any hardware.

For testing I’ve changed the localSourceAddr to something not configured for Weinzierl interface:

UID: knx:ip:c6aa14dc5d
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.66.xxx
  autoReconnectPeriod: 60
  type: TUNNEL
  localSourceAddr: 15.15.245
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

But the result is the same, telegrams are coming from different address (which I can’t explain fully now):

and OH logs still contain the exception:

23:12:58.153 [WARN ] [.internal.handler.DeviceThingHandler] - An error occurred on channel knx:device:c6aa14dc5d:KNXDateTime:DateTime: no confirmation reply received for 15.15.245->0/4/0 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 79 08 10 17 0c 33 24 00
tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 15.15.245->0/4/0 L_Data.req, low priority hop count 6 repeat, tpdu 00 80 79 08 10 17 0c 33 24 00

And if the screenshot of the Weinzierl interface doesn’t show addresses that the IP-side clients should use, then I probably don’t get their manual at all:

For the interface function the device contains additional individual addresses that can be set in the ETS (ETS 4.2 or higher).
When a client (e.g. ETS) sends via the KNX IP Interface telegrams to the bus, they contain a sender address as one from the
additional addresses
. Each address is associated with a connection. Thus response telegrams can be clearly transmitted to the
respective client.
The additional individual addresses must be selected from the
address range of the bus line in which the interface is installed
and may not be used by another device.
Example:
Device address 1.1.10 (address within ETS topology)
Connection 1 1.1.250 (1. additional address)
Connection 2 1.1.251 (2. additional address)
Connection 3 1.1.252 (3. additional address)
Connection 4 1.1.253 (4. additional address)
Connection 5 1.1.254 (5. additional address)
Section “Individual Address” enables you to change the individual KNX address of the currently used KNXnet/IP Tunneling
connection.

How would you interpret that?
The configuration on my screetshot shows that addresses starting with 15.15.250 are the additional addresses (note the indentation).

Please don’t use third party documentation to set openHAB parameters if you did not fully understand the parameter. Once more: localSourceAddress is NOT the individual address. It’s completely unrelated, although it’s listed in the bus/group monitor.
Please leave the localSourceAddress empty or set it to 0.0.0.

Leaving localSourceAddr empty results in NullPointerExceptions from the binding.
Setting it to 0.0.0 indeed solves the problem of the no confirmation reply received exception (thanks for that) and the KNX connection works fine. But now the individual address from which the KNX telegrams are coming is undetermined (although it’s still one of the “Additional Individual Addresses” configured for the Weinzierl KNX/IP interface, which is 15.15.251 right now). If I would like to create the “fake” device in ETS representing OH, I’m not able to do that. In my opinion, this “fake” device is already part of the Weinzierl interface configuration.
Irrespective of that, I’m not fully getting what the localSourceAddr setting is for. If it’s NOT an individual address, @Udo_Hartmann can you please explain what is the purpose of it? Otherwise the current hints in the UI are, at best, confusing:

The binding’s documentation doesn’t say much more.

Hey 15.15.255 is a bad physical adress for knx this is a standard adress for initial the device maybe is this the problem

@Marc.pol I am aware of that. Unfortunately because of some “incompatibility” with another device on my KNX bus (from Hager) I had to leave it as 15.15.255. There were no issues so far. And, as I wrote earlier, when tested with HomeAssistant and its xknx lib, the “source address” setting is properly taken into account.