Issues with KNX connection (closed connections)

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

  1. restarting the docker container → helps a view seconds
  2. switching to ROUTER mode → didn’t work (don’t have log files atm)
  3. increasing the responseTimeout to 120
  4. setting useNAT to false
  5. stopping the docker container and starting it a few minutes later → helps a view minutes
  6. disconnecting the KNX router from the network (PoE powered)
  7. checking my firewall if it blocks any requests from the NAS to the interface → no it does not
  8. connecting via ETS to the KNX bus → works
  9. reinstalling the KNX binding → did not help
  10. disabling the bridge and reenable it again → did not help
  11. 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.

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).

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.

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

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

[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

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) [?:?]

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?

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.

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.

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??

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) :-/

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?

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

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