KNX Timeout happen periodically (response timeout waiting for confirmation)

Scylla · May 5, 2019, 7:49am

Hello everybody,
whilst I was able to sort out the weird behaviour of the OH2 KNX Binding by omitting the local address, I still see some errors occur every two hours.

Yesterday 20:36 (full log)…

2019-05-04 20:36:05.184 [WARN ] [Xnet/IP Tunneling 192.168.20.27:3671] - response timeout waiting for confirmation

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.0.9 L_Data.req, system priority hop count 6 repeat, tpdu 81

	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:510) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$1(AbstractLink.java:159) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) [240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:164) [240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [240:org.openhab.binding.knx:2.4.0]

2019-05-04 20:36:05.192 [WARN ] [calimero.mgmt.TL 192.168.20.27:3671 ] - disconnected not gracefully (timeout)

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.0.9 L_Data.req, system priority hop count 6 repeat, tpdu 81

	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:612) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:510) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$1(AbstractLink.java:159) ~[240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) [240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:164) [240:org.openhab.binding.knx:2.4.0]

	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [240:org.openhab.binding.knx:2.4.0]

Then again at 23:56 (I leave out all the “at tuwin.auto.calimero…” lines from here onward)

2019-05-04 23:56:11.917 [WARN ] [Xnet/IP Tunneling 192.168.20.27:3671] - response timeout waiting for confirmation

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.0.2 L_Data.req, system priority hop count 6 repeat, tpdu 81
2019-05-04 23:56:11.925 [WARN ] [calimero.mgmt.TL 192.168.20.27:3671 ] - disconnected not gracefully (timeout)

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 0.0.0->1.0.2 L_Data.req, system priority hop count 6 repeat, tpdu 81

And finally at 01:36 and 03:36 (compressed now to only the WARN lines)

2019-05-05 01:36:14.967 [WARN ] [Xnet/IP Tunneling 192.168.20.27:3671] - response timeout waiting for confirmation

2019-05-05 01:36:14.973 [WARN ] [calimero.mgmt.TL 192.168.20.27:3671 ] - disconnected not gracefully (timeout)

2019-05-05 03:36:22.823 [WARN ] [Xnet/IP Tunneling 192.168.20.27:3671] - response timeout waiting for confirmation

2019-05-05 03:36:22.832 [WARN ] [calimero.mgmt.TL 192.168.20.27:3671 ] - disconnected not gracefully (timeout)

This is my knx config:

Bridge knx:ip:bridge [
    ipAddress="192.168.20.27",
    portNumber=3671,
    localIp="192.168.20.13",
    type="TUNNEL",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1
     //localSourceAddr="15.15.254"
]

localSourceAddr is commented out as it caused a lot of trouble when the local address has been taken by any other component (the Weinzierl Gateway provisions them on a first come-first served basis).

Any Idea how to get rid of these warnings?

Best
Hans

JosefLe · January 11, 2020, 3:11pm

Hi all,

had the same problem with my installation.
After setting up the system on a Raspberry Pi and collecting some experience on configuration the system was running well and stable. I use a Weinzierl IP-Interface to connect to the KNX-Bus, with assigned KNX-adresses 1.1.100 to 1.1.104 for the five communication channels.

After some days I made a little change and rebooted the Raspberry Pi. From then on I had this same behaviou with the “respons timeout”.
After some investigation I think I found the rootcause now:

When initially setting up the system I first started the ETS-Software for KNX to monitor what happens on the bus. As the Weinzierl interface assigns its communication channels on a first come-first served basis, the ETS Software got the 1.1.100 as “local adress”.
The KNX-Binding of Openhab2 therefore got the adress 1.1.101 at that time.
In the knx.things I assigned localSourceAddr=“1.1.101”.

After rebooting the Raspberry Pi some days later, I got the behaviour as also described in other threads, that after issuing a command via basic UI or the android app reaction followed strongly delayed.
In the LOGs I had the telegrams, as described in the beginning of the thread:
" …reply received for 1.1.101->0.0.7 L_Data.req, …".
On each read request of openhab such a read timeout was the result - allways 3 times, which I think tesults from “readRetriesLimit=3,”.

After connecting again with the ETS software and checking the bus traffic I saw the root cause. After the recent reboot, the openhab System got the local adress 1.1.100 assigned from the Weinzierl interface. So all the requests from openhab to the KNX-Bus with the configured localSourceAddr=“1.1.101” in knx.things got no reaction from the bus!

The same happend in the Installation of “Scylla Haka Keller”. As in the knx configuration the locaSourceAddr is not user defined (commented) the KNX-adress 0.0.0 is used - which can be seen in his logfile “…received for 0.0.0->1.0.9 L_Data.req, system…”.

Actually I solve the problem by configuring the “localSourceAddr” to “1.1.100” and have the ETS software stopped when starting openhab, so openhab gets the 1.1.100 assinged from the Weinzierl interface.

But do not know, how to serve this “for long term”. Since the plan is to connect further systems to the KNX-IP-Interface, it would be allways importand in which sequence dte different systems boot.

Any Ideas how to solve this?
Is there a possibility to retract the “localSourceAddr” dynamically from the IP-Interface?

Bagunda · May 30, 2021, 11:24am

Thanx @JosefLe for this research!
I have same issue.
Has anyone found a solution?
What should I do to make everything work at least until the reboot?
In what order should I proceed?

JosefLe · May 30, 2021, 12:33pm

My things-configuration looks like this:

Bridge knx:ip:bridge [
type=“TUNNEL”,
ipAddress=“192.168.222.92”,
portNumber=“3671”,
localIp=“192.168.222.79”,
readingPause=“50”,
responseTimeout=“10”,
readRetriesLimit=“1”,
autoReconnectPeriod=“60”,
strong textlocalSourceAddr=“0.0.0” //IMPORTANT: enforce automatic assignment of KNX-adress, so that KNX-IP-Tunnel gets correct assignment (next free adress)!!
] {
Thing device bus [
address=“1.1.20”,
fetch=false,
pingInterval=300,
readInterval=0
] {
Type switch …

With this my installation runs since 2019 without any problems.