Issues with KNX connection (closed connections)

sheppard · May 29, 2022, 6:33pm

Since today I face a lot of issues with my KNX connection. I haven’t changed anything on the KNX configuration or on the device setup, so I really don’t know what may have caused this. Hope someone can help as other threads here point to the same/similar issue but the provided solutions didn’t help.

Setup:

openHAB 3.2 via Docker on Synology NAS
Enertex KNXnet/IP Router with PoE

Settings:

UID: knx:ip:bridge
label: KNX IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: true
  readRetriesLimit: 3
  ipAddress: 10.0.0.10
  autoReconnectPeriod: 60
  localIp: 10.0.0.20
  localSourceAddr: 0.0.0
  readingPause: 50
  type: TUNNEL
  portNumber: 3671
  responseTimeout: 60

Error from log file
there have been multiple but I just have this last one as the log got lost after some restarts :-/

[ERROR] [p.KNXnet/IP Tunneling 10.0.0.10:3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received

WARN ] [calimero.mgmt.TL 10.0.0.10:3671 ] - disconnected not gracefully (timeout)
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received

Sometimes the device is shown as ONLINE, sometimes the other KNX devices are shown as ONLINE or some as UNKOWN.

What I tried so far

restarting the docker container → helps a view seconds
switching to ROUTER mode → didn’t work (don’t have log files atm)
increasing the responseTimeout to 120
setting useNAT to false
stopping the docker container and starting it a few minutes later → helps a view minutes
disconnecting the KNX router from the network (PoE powered)
checking my firewall if it blocks any requests from the NAS to the interface → no it does not
connecting via ETS to the KNX bus → works
reinstalling the KNX binding → did not help
disabling the bridge and reenable it again → did not help
disabling bridge, restarting container, enabling after a few minutes → did only help for a view minutes (I could send one request to turn on a light but afterwards the bridge went to ERROR:COMM again)

Is it possible that openHAB “saves” the tunneled connections? There is a limit of 5 on the device but atm I only run openHAB and nothing more. Connection from the ETS works without any issues, but to be sure I closed the connection again of course.

Could it be a network issue as I’m facing some connection issues with a Fronius bridge as well (only a few ms)? As for the Fronius bridge it may be a bad WiFi connection or an issue with the Inverter itself - wanted to take a look in the next few weeks.

There has also been some power fluctuations (just a few ms) yesterday/today in my area. But actually the interface and NAS are behind a USP - so those should not have been effected.

I addition it seems openHAB has issues to save changes on the thing from time to time. Especially when the device had some connection issues, I could not save changes on the thing. openHAB sent the PUT request, but there has not been any response. The log just states:

[ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/knx:ip:bridge/config’
java.lang.IllegalStateException: Thing with UID knx:ip:bridge has no handler attached.

As you can see, I’m running out of ideas. And I did not had this issues back when I’ve used openHAB 2.4 a few weeks ago.

Hope someone has a glue/idea and can help.

sheppard · May 29, 2022, 7:22pm

I just setup a new docker container and created a new KNX bridge, device + channel.
The bridge is configured in the same way as in the other container.
At least for the moment I don’t have any connection issue in the log.
I can turn on/off the only item (light) I configured.

What I don’t have here are multiple KNX devices configured.
Is there maybe an issue with this Fetch option for KNX devices? I have this enabled for all of them (> 15).

sheppard · May 29, 2022, 7:51pm

Ok, I set the Fetch option to false for all KNX devices, but that didn’t help.

Next try is to remove the cache + tmp folder and restart the container again.

sheppard · May 29, 2022, 9:13pm

It seems removing the cache + tmp folder did the trick (where I assume the tmp is not important here).
After restarting the container the bindings got reinstalled automatically and at least for now the connection to the KNX interface is stable.
Hope it stays this way

sheppard · May 30, 2022, 5:38am

Bad news, an hour after I posted this and went to bed the same issues appeared again

[ERROR] [p.KNXnet/IP Tunneling 10.0.0.10:3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received

the error is repeated every 1-2 hours in the log file.

And there is a new one in the log:

[ERROR] [p.KNXnet/IP Tunneling 10.0.0.10:3671] - establishing connection failed, InterruptedException
2022-05-30 04:41:54.026 [WARN ] [p.KNXnet/IP Tunneling 10.0.0.10:3671] - received invalid frame
tuwien.auto.calimero.KnxRuntimeException: parsing cEMI
at tuwien.auto.calimero.knxnetip.servicetype.ServiceRequest.lambda$static$0(ServiceRequest.java:75) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.servicetype.ServiceRequest.lambda$new$3(ServiceRequest.java:144) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.servicetype.ServiceRequest.service(ServiceRequest.java:207) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.handleServiceType(KNXnetIPTunnel.java:380) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.handleServiceType(ConnectionBase.java:373) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.onReceive(ReceiverLoop.java:93) [bundleFile:?]
at tuwien.auto.calimero.internal.UdpSocketLooper.receive(UdpSocketLooper.java:177) [bundleFile:?]
at tuwien.auto.calimero.internal.UdpSocketLooper.loop(UdpSocketLooper.java:134) [bundleFile:?]
at tuwien.auto.calimero.knxnetip.ReceiverLoop.run(ReceiverLoop.java:75) [bundleFile:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Caused by: tuwien.auto.calimero.KNXFormatException: unsupported cEMI msg code: 0xc5
at tuwien.auto.calimero.cemi.CEMIFactory.create(CEMIFactory.java:104) ~[bundleFile:?]
at tuwien.auto.calimero.knxnetip.servicetype.ServiceRequest.lambda$static$0(ServiceRequest.java:72) ~[bundleFile:?]
… 9 more

4u2fast · May 31, 2022, 2:38pm

have the same issue !

2022-05-30 17:30:44.186 [WARN ] [KNXnet/IP Tunneling 192.168.1.2:3671] - received disconnect response status 0x21 (no active data connection with that ID)
2022-05-30 17:30:44.190 [ERROR] [KNXnet/IP Tunneling 192.168.1.2:3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received
        at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:253) ~[bundleFile:?]
        at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:213) ~[bundleFile:?]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:423) ~[bundleFile:?]
        at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:385) ~[bundleFile:?]
        at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:402) ~[bundleFile:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.send(ProcessCommunicatorImpl.java:461) ~[bundleFile:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:410) ~[bundleFile:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:365) ~[bundleFile:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:473) ~[bundleFile:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:433) ~[bundleFile:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$7(DeviceThingHandler.java:253) ~[bundleFile:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:148) [bundleFile:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:142) [bundleFile:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:248) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor160.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy2495.handleCommand(Unknown Source) [?:?]
        at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
        at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor225.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]
2022-05-30 17:30:44.214 [ERROR] [KNXnet/IP Tunneling 192.168.1.2:3671] - establishing connection failed, InterruptedException
2022-05-30 17:30:44.225 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.handleCommand()' on 'org.openhab.binding.knx.internal.handler.Devic
eThingHandler@677316a6': process communicator detached
java.lang.IllegalStateException: process communicator detached
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:408) ~[?:?]
        at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:365) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.sendToKNX(AbstractKNXClient.java:473) ~[?:?]
        at org.openhab.binding.knx.internal.client.AbstractKNXClient.writeToKNX(AbstractKNXClient.java:433) ~[?:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.lambda$7(DeviceThingHandler.java:253) ~[?:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:148) ~[?:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.withKNXType(DeviceThingHandler.java:142) ~[?:?]
        at org.openhab.binding.knx.internal.handler.DeviceThingHandler.handleCommand(DeviceThingHandler.java:248) ~[?:?]
        at jdk.internal.reflect.GeneratedMethodAccessor160.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy2495.handleCommand(Unknown Source) [?:?]
        at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
        at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at jdk.internal.reflect.GeneratedMethodAccessor225.invoke(Unknown Source) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]

sheppard · May 31, 2022, 3:56pm

Just lately or are there older ones as well in your log?
I tried yesterday evening and night again to get it running.

Created another docker container and just added the bridge + one device but after some time I got the same issues.
I also tried doing the same on another machine via docker to see if the issue is with my NAS but seems not.
had a look at the KNX ip interface and sometimes tunnels are created, sometimes multiple and they are not closed automatically if I e.g. shutdown the container. so don’t know what that can mean :-/

I ordered now another KNX IP interface to check if the hardware is the issue, so will see.

Just half an hour ago I changed the setting of the bridge now from TUNNEL to ROUTER. At least it connects and I have no error messages so far. Let’s see in a few hours.
Issues now are that the bridge is shown as ONLINE but all KNX devices are shown as OFFLINE but they are actually working.

Is it possible that the binding has some new bugs? but I assume it won’t get updated automatically or?

zaizuney · July 7, 2022, 4:37pm

Hi,

having similar issue, openhab seems to take all the tunnel connections available on MDT KNX router, I have no idea why it takes more then one tunnel

these are my settings used:

Bridge knx:ip:bridge [ 
    ipAddress="192.168.0.10", 
    portNumber=3671, 
    localIp="192.168.0.169", 
    type="TUNNEL", 
    readingPause=50, 
    responseTimeout=10, 
    readRetriesLimit=3, 
    autoReconnectPeriod=30,
    localSourceAddr="15.15.239",
    usenat=false
]

2022-07-07 18:35:40.273 [ERROR] [NXnet/IP Tunneling 192.168.0.10:3671] - establishing connection failed, error response from control endpoint 192.168.0.10:3671: could not accept new connection (maximum reached)

2022-07-07 18:35:40.274 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler IPBridgeThingHandler tried updating the thing status although the handler was already disposed.

rdm · October 8, 2022, 2:19pm

I have the same issue on a Weinzierl tunnel configured interface. Openhab 3.x o the KNX Binding saturates all connections to the device and I can’t use other things like ETS to configure the bus unless I temporarily quit openhab.

ByteBandito · December 3, 2022, 9:37am

Is there any new solution found?

Since the last openhab update or since adding 3 new actors I have the same issue (again).

2022-12-03 01:02:23.075 [ERROR] [net/IP Tunneling 3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received

New is the following in log - or maybe I did not see it yet:

2022-12-02 23:21:38.688 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 54, expected 48
2022-12-02 23:21:38.691 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 55, expected 48
2022-12-02 23:21:39.709 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 55, expected 48
2022-12-02 23:21:39.712 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 56, expected 48
2022-12-02 23:21:40.669 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 56, expected 48
2022-12-02 23:21:40.672 [WARN ] [net/IP Tunneling :3671] - tunneling request with invalid rcv-seq 57, expected 48

Anyone any idea??

sheppard · December 5, 2022, 7:48am

Unfortunately not from my side - I changed the Mode from TUNNEL to ROUTER and it is at least working for now (most of the time - it seems some commands are lost from time to time though) :-/

Vakisc · December 6, 2022, 10:06am

I have been having the same problem since August 2022. “Close connection - maximum send attempts”. Approximatly once every week. Sometimes it could be a few weeks or a few days.
I using Raspbian on Pi4 with 8GB RAM and have been updating to each Milestone of 3.4.
I have approximatly 55 KNX devices (things).
I am using an MDT IP Router (tunneling mode) which is updated to the last firmware available from MDT and noticed that most of the people complaining about this issue are using the same MDT router.
The last time this happened I checked the webserver of the IP Router and there were no tunneling connections active. The KNX IP Router thing stays online/green in Openhab.
Could it be a compatibility issue of this router?

sheppard · December 6, 2022, 10:18am

I have an Enertex KNXnet/IP Router with PoE - so I do not think it is specifically the MDT router.

stamate_viorel · December 6, 2022, 9:56pm

just for reference this interface has been working for a year already without any hiccup

UID: knx:ip:knx_zennio
label: knx zennio
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.0.181
  autoReconnectPeriod: 60
  localIp: 192.168.0.116
  type: TUNNEL
  localSourceAddr: 3.0.2
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

keep in mind the traffic it has to handle is small this comes from a allinbox device sold by zennio.
Now most of these IP stuff runs embedded chips that don’t have leave to much space for buffering or error correction.
So long story short 50 telegrams per second per interface make sure also that tunnel number is not taken by something else and stable network path from openhab to it.
oh and make sure the localsourceadress is the address of the tunnel you want to use

Arabeske · February 2, 2023, 4:59pm

Hello,

I have the same problem. I also use Docker and an Enertex KNXnet/IP router.

The error came with Release 3.4.
And 3.4.1 didn’t solve it.

Regards
Simon

stamate_viorel · February 2, 2023, 5:55pm

routing cannot go offline it’s a broadcast so maybe post more information

Arabeske · February 8, 2023, 8:29am

Detailed info here…

Setup:

• openHAB 3.4.1 via Docker on RaspberryPi
• WEINZIERL 731 KNX IP Interface 731
• LAN cable connection (no wifi issue)

Settings:

UID: knx:ip:Bridge
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.178.22
  autoReconnectPeriod: 60
  localIp: 192.168.178.63
  localSourceAddr: 1.1.15
  readingPause: 50
  type: TUNNEL
  portNumber: 3671
  responseTimeout: 10

Error from log file:

2023-02-02 17:41:22.000 [TRACE] [.internal.handler.DeviceThingHandler] - Handling command '2.7 °C' for channel 'knx:device:bridge:GenericTemp:Aussentemperatur'
2023-02-02 17:41:21.975 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: send attempt on closed connection
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:198) ~[?:?]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:213) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:423) ~[?:?]
	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:385) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:402) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendData(TransportLayerImpl.java:351) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:1275) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:1259) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.sendWait2(ManagementClientImpl.java:1295) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.readDeviceDesc(ManagementClientImpl.java:595) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:391) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:435) ~[?:?]
	at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:148) ~[?:?]
	at org.openhab.binding.knx.internal.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:190) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
2023-02-02 17:41:22.001 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command '2.7 °C'
2023-02-02 17:41:22.003 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge is disconnecting from KNX bus
2023-02-02 17:41:22.004 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2023-02-02 17:41:22.004 [DEBUG] [rnal.handler.AbstractKNXThingHandler] - An error occurred while testing the reachability of a thing 'knx:device:Bridge:A62': link closed, send attempt on closed connection
2023-02-02 17:41:22.004 [TRACE] [.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.DecimalType' which isInstance for command '2.7 °C' and dpt '9.001'
2023-02-02 17:41:22.012 [TRACE] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge disconnected from KNX bus
2023-02-02 17:41:22.012 [TRACE] [nx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '3/1/220', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@1c227bc'
2023-02-02 17:41:22.014 [TRACE] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge, connection interrupted
2023-02-02 17:41:22.015 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge is disconnecting from KNX bus
2023-02-02 17:41:22.017 [TRACE] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge disconnected from KNX bus
2023-02-02 17:41:22.025 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge scheduling connect in 60s
2023-02-02 17:41:22.025 [DEBUG] [nx.internal.client.AbstractKNXClient] - KNX link has been lost (reason: server request on object tunneling link (closed) 192.168.178.22:3671 TP1 medium, device 1.1.15, hopcount 6)
2023-02-02 17:41:22.028 [TRACE] [.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '3/1/220' size '1' added 'true'
2023-02-02 17:41:22.028 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:Bridge scheduling connect in 60s

I’ve been using Openhab for years and the error has existed for a few weeks.
I restarted openhab on 2/2 2023. The system ran error-free until 2/7/2023.
The error only occurs at longer intervals and ends in aborts every minute:

2023-02-07 11:40:25.249 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 12:27:57.532 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 13:07:38.497 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 14:29:27.866 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 16:13:53.202 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 18:07:22.861 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 18:45:35.182 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 19:53:35.804 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 19:55:44.060 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 20:33:59.393 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 21:48:24.917 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 21:49:24.565 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-07 22:09:54.711 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 00:00:15.551 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 00:27:04.311 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 00:28:10.718 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 01:12:15.230 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 01:14:33.392 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 01:15:37.302 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 01:17:49.909 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 01:20:21.479 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 02:29:45.950 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 03:54:27.546 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 04:16:23.054 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:03:05.167 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:04:08.667 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:07:22.311 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:18:19.236 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:19:21.160 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:20:26.278 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:26:59.430 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:30:13.297 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link
2023-02-08 05:31:18.724 [ERROR] [calimero.link.192.168.178.22:3671   ] - send error, closing link

Does anyone have an idea how to debug this further?

stamate_viorel · February 8, 2023, 7:17pm

You are using tunnel. Why not use router? Try turning off and off your knx ip a d retest

Arabeske · February 22, 2023, 8:45am

Sorry for the delay, I was on vacation.
And guess what, after a few days the connection dropped again.

There was a mistake in my system description. I use the KNX interface Weinzierl 731 which does not support routing.

Until I have a solution I will restart openhab once a day.

Pavel · March 22, 2023, 12:05pm

Try to connect diagnostic in ETS for some time and check if you will get disconnect.

I had the simular things. At few years was all OK. Then OH disconnected once at month-two. Then once at week and quickly once a day. In this time I changed swich (and it was worked normally some time).
At least the problem was in knx gateway ( ZSY-IP-INT of Zennio). It normaly works only with default individual address 15.15.255 - something broken inside of gateway.