New Problem with KNX-Binding: close connection - maximum send attemps

Please post the bridge-part of your things-knx-file - I may have a look :slight_smile:

Thanks @ByteBandito
This is how it looks - copied from front-end as I’ve configured it thru Web

UID: knx:ip:f460c0e705
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 5
  ipAddress: 224.0.23.12
  autoReconnectPeriod: 30
  localIp: 192.168.10.101
  type: ROUTER
  localSourceAddr: 1.1.0
  readingPause: 50
  responseTimeout: 10
  portNumber: 3671

This is mine… maybe you should try to run it as TUNNEL instead of ROUTER…

And ResponseTimeout of 10 seems to be quite brutal to me.

Bridge knx:ip:KNXROUTER “KNX/IP Router” @ “KNX” [
ipAddress="[ip]",
localIp="[ip]",
type=“TUNNEL”,
portNumber=“3671”,
responseTimeout=60,
readingPause=250,
readRetriesLimit=3,
autoReconnectPeriod=30,
localSourceAddress=“1.0.250”,
ignorelocalevents=true

I thought I already tried everything, but what you have suggested actually helped and since last 20+ minutes connection is stable and everything works perfectly fine.

Thank you very much for your help, I’ve spent on this issue HOURS searching internet and was not able to resolve it. You have really calmed my spirit (spent a lot of $$$ on ‘intelligent’ house that doesn’t work) and now I’m able to move forward with the development of my imagined dashboard.

Have a great day!

I’ve also had this issue for the longest time (at least a year), however with OpenHab 3.1.0 the issue seems to have almost fully disappeared.

For me it the issue started appearing at some point with version 2.4 (I think), before that it was stable. It happened every few days. Within an hour or so the number of errors increase in frequency and a bit later the entire system comes to a halt.

Because I’ve tried literally all the things suggested in other threads (except replace the IP interface) and nothing fixed it I eventually resorted to an automatic restart as soon as “tuwien.auto.calimero.KNXTimeoutException” appears in the log. I know, it’s a terrible workaround, but it’s better than a frequently crashed system.

My IP interface is a fairly common GIRA 216800 (so not an IP router). Because I’m not sure what eventually fixed it I’m hoping the issue will not resurface at some point.

I currently facing a lot of issues with my KNX IP bridge as well - see Issues with KNX connection (openhab 3.2)

So I stumbled over this thread here. For me switching to ROUTER seems to work (at least for now).

But I’m curios why a ResponseTimout of 10 is brutal? what does it exactly do and why is 10 then the default?

My thoughts are: 10 seconds timeout mean: if there is no answer her waits 10 seconds.
So if on the bus are too many tickets, with a timeout of 10 seconds even more stuff waits for an answer and floods the bus.
Just a theory.

After restarting my host server Windows Server 2016 and the openHAB 3.1 server, openHAB can no longer connect my GIRA IP interface.
The restart was necessary because of a Windows update. But nothing has changed with centOS and openHAB.

My openHAB ran on Hyper-V virtual centOS 8 for several months without any problems.

I only have one GIRA KNX IP interface.
The IP interface can connect 4 tunnels, but I use maximum three systems to connect to the bus. (ETS, Tobit David and openHAB).

If I enable the thing I get the following log:

16:46:01.695 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:KNXGateway’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
16:46:01.722 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:KNXGateway’ changed from INITIALIZING to UNKNOWN

16:47:01.691 [DEBUG] [knx.internal.client.AbstractKNXClient] - Bridge knx:ip:KNXGateway is disconnecting from the KNX bus
16:47:01.693 [DEBUG] [knx.internal.client.AbstractKNXClient] - Bridge knx:ip:KNXGateway is connecting to the KNX bus
16:47:01.693 [DEBUG] [.binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.10.112:3671 in mode TUNNEL.
16:47:01.698 [ERROR] [Xnet/IP Tunneling 192.168.10.112:3671] - could not accept new connection (maximum reached)
16:47:01.699 [ERROR] [Xnet/IP Tunneling 192.168.10.112:3671] - establishing connection failed, error response from control endpoint /192.168.10.112:3671: could not accept new connection (maximum reached)
16:47:01.700 [DEBUG] [knx.internal.client.AbstractKNXClient] - Error connecting to the bus: error response from control endpoint /192.168.10.112:3671: could not accept new connection (maximum reached)
tuwien.auto.calimero.KNXRemoteException: error response from control endpoint /192.168.10.112:3671: could not accept new connection (maximum reached)

  •    at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:201) ~[?:?]*
    
  •    at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:158) ~[?:?]*
    
  •    at org.openhab.binding.knx.internal.client.IPClient.getConnection(IPClient.java:110) ~[?:?]*
    
  •    at org.openhab.binding.knx.internal.client.IPClient.createKNXNetworkLinkIP(IPClient.java:93) ~[?:?]*
    
  •    at org.openhab.binding.knx.internal.client.IPClient.establishConnection(IPClient.java:80) ~[?:?]*
    
  •    at org.openhab.binding.knx.internal.client.AbstractKNXClient.connect(AbstractKNXClient.java:178) ~[?:?]*
    
  •    at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]*
    
  •    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]*
    
  •    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) [?:?]*
    

16:47:01.703 [DEBUG] [knx.internal.client.AbstractKNXClient] - Bridge knx:ip:KNXGateway is disconnecting from the KNX bus
16:47:01.706 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing ‘knx:ip:KNXGateway’ changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): error response from control endpoint /192.168.10.112:3671: could not accept new connection (maximum reached)

My thin is configuratet as follow:

label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.10.112
  autoReconnectPeriod: 60
  localIp: 192.168.10.113
  type: TUNNEL
  localSourceAddr: 0.0.0
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

localIp is the IP adress of the openHAB server
In the KNX project, the localSourceAddr is actually 1.1.1 but I tried this too

I tried the following:

  • switch the IP interface off and on again
  • reprogram the IP interface
  • Changed the switch port and switched it off and on
  • restart all server
  • binding and thing deleted and reinstalled
  • booted old clean saved image
  • try router mode
  • closed all other software (tunnels)
  • searched the whole internet :wink:

But openHAB still cannot connect. My ETS can almost always connect. Only sometimes I get the message that no more tunnels are available.
But when I stop ETS there must be a free tunnel.

How can I see more than in the log? Can I display the existing connections? What else can I try.
A new IP interface cannot be the solution, it works perfectly with ETS and Tobit David.

Thank you for ideas and hlep…

I have exactly the same issue! It worked for Years with Windows Server 2019 / Hyper-V / Debian VM.

Just suddenly at 13:09 it stopped working…
MDT IP Interface without Routing…

I tried everything! I imported my monthly Hyper-V export Backup back, and even this untouched Export of the VM also can not connect.
I created a Brand new VM and got it not working…

I have now determined that the KNX binding can establish and maintain a connection if I deactivate all KNX devices.
But as soon as I activate one device again, the communication breaks off directly:

> KNX link has been lost (reason: server request on object tunneling link (closed)

If I deactivate the devices again, the connection of the binding to the KNX interface is restored and online.

Guys, am I correct that all of the people with connection problems are running their OH Instance either directly on Windows or as a Linux VM within Hyper-V?

this will mostly be a networking problem on the virtual switch of the VM host … also don’t understand some configuration here why people still use devices topology address is like working with channels instead of items … also my config is

Bridge	knx:ip:tunnel "Knx tunnel" [
	ipAddress="[my tunnel ip]",
	type="TUNNEL"
]
Bridge	knx:ip:router "Knx router" [
	type="ROUTER"
]

I already suspect the network because the problems only occurred after the update and restart of the host server.

also don’t understand some configuration here why people still use devices topology address is like working with channels instead of items … also my config is

I do not understand that.
My configuration is

UID: knx:ip:KNXGateway
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.10.112
  autoReconnectPeriod: 60
  localIp: 192.168.10.113
  type: TUNNEL
  readingPause: 50
  localSourceAddr: 0.0.0
  portNumber: 3671
  responseTimeout: 15
location: RD-KG-Verteiler

What is that for a syntax - also in the manuals. Is this the configuration syntax for openHAB before version 3?

well i was pointing to this below
please read https://www.openhab.org/addons/bindings/knx/#device-things

Thing device dimmaktor_1_2_25 [
		address="1.2.25",
		fetch=false,
		pingInterval=300,
		readInterval=3600

then your config should look like this for UI config

UID: knx:ip:6e68bf5e4d
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.1.blabla
  autoReconnectPeriod: 60
  type: TUNNEL
  localSourceAddr: 0.0.1
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

Do not out set Network address of the local host ip address.
I just made a test on a debian running openhabian script with ooenhab 3.3 with the config trough UI listed above and the VM is running on xcp-ng and no disconnect.

I believe there was an update to hyper-v that broke some stuff try reverting to a previous update of the windows server to check

that is still file based configuration Wich i still prefer

Check if the Windows NIC is allowed to go to sleep. Also check the Firewall-Log of Windows.
I would suspect something along those lines…
What NIC (Vendor & Model) do you use in the Windows machine?

Ok, which file? My thing.json looks different.

Check if the Windows NIC is allowed to go to sleep.

Ok, I changed the settings. But a server may not switch off its NICs.

Also check the Firewall-Log of Windows.

The local firewall is switched of.

What NIC (Vendor & Model) do you use in the Windows machine?

two Intel I350 Gigabit Network Connection paired as NIC team

what are you running as VM ?