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

Add-ons Bindings
, ,
1

Hey… :slight_smile:
I have got a instable binding since some days, maybe one week or something. Before that it ran completely stable. I am not sure if i updated openhab in that time; maybe I updated from 2.5.4 to 2.5.10 … But i am not sure.

After some time - mostly half an hour, sometimes some hours, the connection is closed.

2020-11-18 16:39:44.776 [ERROR] [net/IP Tunneling XXX.XXX.XXX.XXX:3671] - close connection - maximum send attempts
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received

After that only the restart of my openhab helps reviving it.

I did not change anything on my knx-side or network-side.

The knx-binding runs as TUNNEL with minimal settings; mostly I removed all of them while trying to find the problem.
The knx.things-file is about 103 kb of size, so its quite a big setup.

On KNX-Side I use a MDT Ip KNX Router.

Any ideas?! :frowning:

Thanks,
Patrick

2

No hints? :’-(… it is a bit frustrating — I am close to setup openhab completly fresh … but I am not sure, if this helps.

KNX stops working after minutes or at least hours.

All hints I ll find via google are quite old and do not help …

snief.

3

I tried to complete reinstall openhab on a fresh installed ubuntu 20.04… I only added the knx-binding and not other bindings.
I used the knx.things file and NOTHING ELSE. No items. No rules.

It also crashes after something 30 seconds.

Any ideas now?

4

Update:
since reinstall did not help… I tried to replace my MDT KNX IP ROUTER to a brand new Enertex KNX Secure IP Router (well - since Openhab does not support the secure part I disabled that feature).

It seems to run more stable, but that specific error-message still appears:

2020-12-08 02:18:49.541 [ERROR] [net/IP Tunneling [my routers ip]: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:250) ~[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.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:627) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.checkSendDisconnect(TransportLayerImpl.java:619) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:527) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$0(AbstractLink.java:145) ~[bundleFile:?]
	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:127) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:171) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [bundleFile:?]
2020-12-08 02:18:49.542 [WARN ] [calimero.mgmt.TL [my routers ip]:3671] - disconnected not gracefully (timeout)
tuwien.auto.calimero.KNXAckTimeoutException: maximum send attempts, no service acknowledgment received
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:250) ~[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.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:627) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.checkSendDisconnect(TransportLayerImpl.java:619) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:527) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$0(AbstractLink.java:145) ~[bundleFile:?]
	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:127) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:171) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [bundleFile:?]

But something new are the following errors … maybe they have something in common with my problem. Most interesting: In my things-file i dont find anything with 1.0.2 … wonder

2020-12-07 19:29:15.020 [WARN ] [calimero.mgmt.TL [my routers ip]: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
	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.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:627) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.checkSendDisconnect(TransportLayerImpl.java:619) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:500) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$0(AbstractLink.java:145) ~[bundleFile:?]
	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:127) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:171) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [bundleFile:?]
2020-12-07 19:29:18.040 [WARN ] [net/IP Tunneling 195.114.11.156: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
	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.mgmt.TransportLayerImpl.sendDisconnect(TransportLayerImpl.java:627) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.checkSendDisconnect(TransportLayerImpl.java:619) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.handleConnected(TransportLayerImpl.java:509) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.access$400(TransportLayerImpl.java:87) ~[bundleFile:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl$NLListener.indication(TransportLayerImpl.java:127) ~[bundleFile:?]
	at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$0(AbstractLink.java:145) ~[bundleFile:?]
	at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:127) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:171) [bundleFile:?]
	at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:101) [bundleFile:?]
5

Is device or group adres available 1.0.2 on the KNX bus ? Are you using other devices on the IP interface ?
Something similar once happend to me when I made a change in the KNX setup and had the read flag from a group adres removed.

Eg. I have a Thinka to have interface to Apple Homekit and Openhab and Thinka was polling an unexisting group adres.

6

My knx.things-file - I dont think there are problems in it.
The Problem also appears, when i follow the “less is more” and reduce the bridge-part to 1 or 2 lines (at least the ip).

Bridge	knx:ip:KNXROUTER "KNX/IP Router" @ "KNX" [
	ipAddress="[my routers ip]",
	localIp="[the ip of my openhab server]",
	type="TUNNEL",
	portNumber="3671",
	responseTimeout=30,
    readingPause=50,
	readRetriesLimit=50,
    autoReconnectPeriod=60,
    localSourceAddress="1.0.250"
]
{
    Thing device generic [
		readInterval=0
	] {
		Type switch : licht_alles_aus     "Licht aus" [ ga="1/0/0+<1/0/0" ]
		Type switch : licht_szene_schlafen_aus  "Szene: Schlafen, Lichter aus" [ ga="1/0/10+<1/0/10" ]
		Type switch 		: Raffstore_komplett		"Raffstore Komplett"  	 	 		[ ga="1/1/10+<3/0/55" ]
		Type rollershutter 	: Lamellen_Komplett   		"Lamellen Komplett"   		 		[ upDown="1/1/10+<3/0/55", stopMove="1/1/11+1/1/11", position="1/1/5+<3/0/76" ]
	}

	Thing device dimmaktor_1_2_25 [
		address="1.2.25",
		fetch=false,
		pingInterval=300,
		readInterval=3600
	] {
			Type dimmer : Channel_A "Dimmer, EG, 108-30 / Wohnen //Hifi-Rack" 		[ switch="2/0/40+<2/3/40", position="2/2/40+<2/4/40", increaseDecrease="2/1/40" ]
			Type dimmer : Channel_B "Dimmer, EG, 108-31 / Arbeiten // Hinten" 		[ switch="2/0/41+<2/3/41", position="2/2/41+<2/4/41", increaseDecrease="2/1/41" ]
			Type dimmer : Channel_C "Dimmer, EG, 109-30 / Küche // Arbeitsfläche" 	[ switch="2/0/53+<2/3/53", position="2/2/53+<2/4/53", increaseDecrease="2/1/53" ]
			Type dimmer : Channel_D "Dimmer, EG, 108-32 / Wohnen // Couch" 			[ switch="2/0/42+<2/3/42", position="2/2/42+<2/4/42", increaseDecrease="2/1/42" ]
			Type switch : Error		"Gerätefehler Dimmaktor 1.2.25"   				[ ga="0/1/9+<0/1/9" ]
	}

	Thing device dimmaktor_1_2_26 [
		address="1.2.26",
		fetch=false,
		pingInterval=300,
		readInterval=3600
	] {
			Type dimmer : Channel_A "Dimmer, EG, 107-30 / Speisekammer"				[ switch="2/0/35+<2/3/35", position="2/2/35+<2/4/35", increaseDecrease="2/1/35" ]
			Type dimmer : Channel_B "Dimmer, EG, 106-30 / Kämmerchen // Licht" 		[ switch="2/0/31+<2/3/31", position="2/2/31+<2/4/31", increaseDecrease="2/1/31" ]
			Type dimmer : Channel_C "Dimmer, EG, 104-30 / Flur // Eingang 2" 		[ switch="2/0/19+<2/3/19", position="2/2/19+<2/4/19", increaseDecrease="2/1/19" ]
			Type dimmer : Channel_D "Dimmer, EG, 104-31 / Flur // Eingang 1" 		[ switch="2/0/20+<2/3/20", position="2/2/20+<2/4/20", increaseDecrease="2/1/20" ]
			Type switch : Error		"Gerätefehler Dimmaktor 1.2.26"   				[ ga="0/1/18+<0/1/18" ]
	}

	Thing device dimmaktor_1_2_27 [
		address="1.2.27",
		fetch=false,
		pingInterval=300,
		readInterval=3600
	] {
			Type dimmer : Channel_A "Dimmer, EG, 101-30 / Windfang // Licht 1"		[ switch="2/0/0+<2/3/0", position="2/2/0+<2/4/0", increaseDecrease="2/1/0" ]
			Type dimmer : Channel_B "Dimmer, EG, 101-31 / Windfang // Licht 2" 		[ switch="2/0/1+<2/3/1", position="2/2/1+<2/4/1", increaseDecrease="2/1/1" ]
			Type dimmer : Channel_C "Dimmer, EG, 103-30 / HWR // Licht" 			[ switch="2/0/13+<2/3/13", position="2/2/13+<2/4/13", increaseDecrease="2/1/13" ]
			Type switch : Channel_D "Dimmer, EG, 102-30 / Garage // Licht"			[ ga="2/0/7+<2/3/7" ]
			Type switch : Error		"Gerätefehler Dimmaktor 1.2.27"   				[ ga="0/1/27+<0/1/27" ]
	}

	Thing device dimmaktor_1_2_28 [
		address="1.2.28",
		fetch=false,
		pingInterval=300,
		readInterval=3600
	] {
			Type dimmer : Channel_A "Dimmer, EG, 105-30 / Bad // Licht"				[ switch="2/0/26+<2/3/26", position="2/2/26+<2/4/26", increaseDecrease="2/1/26" ]
			Type dimmer : Channel_B "Dimmer, EG, 105-30 / Bad // Licht" 			[ switch="2/0/26+<2/3/26", position="2/2/26+<2/4/26", increaseDecrease="2/1/26" ]
			Type dimmer : Channel_C "Dimmer, EG, 109-31 / Küche // Essen" 			[ switch="2/0/54+<2/3/54", position="2/2/13+<2/4/13", increaseDecrease="2/1/13" ]
			Type dimmer : Channel_D "Dimmer, OG, 203-30 / Ankleide // Licht"		[ switch="2/0/79+<2/3/79", position="2/2/79+<2/4/79", increaseDecrease="2/1/79" ]
			Type switch : Error		"Gerätefehler Dimmaktor 1.2.28" 				[ ga="0/1/36+<0/1/36" ]
	}

	Thing device dimmaktor_1_3_25 [
		address="1.3.25",
		fetch=false,
		pingInterval=300,
		readInterval=3600
	] {
			Type dimmer : Channel_A "Dimmer, OG, 201-30 / Flur // Pendel"			[ switch="2/0/62+<2/3/62", position="2/2/62+<2/4/62", increaseDecrease="2/1/62" ]
			Type dimmer : Channel_B "Dimmer, EG, 108-33 / Essen // Luftraum"		[ switch="2/0/43+<2/3/43", position="2/2/43+<2/4/43", increaseDecrease="2/1/43" ]
			Type dimmer : Channel_C "Dimmer, EG, 108-34 / Fensterfront" 			[ switch="2/0/44+<2/3/44", position="2/2/44+<2/4/44", increaseDecrease="2/1/44" ]
			Type dimmer : Channel_D "Dimmer, OG, 201-31 / Flur // Licht"			[ switch="2/0/63+<2/3/63", position="2/2/63+<2/4/63", increaseDecrease="2/1/63" ]
			Type switch : Error		"Gerätefehler Dimmaktor 1.3.25" 				[ ga="0/1/45+<0/1/45" ]
	}

[… and much much more… to big to insert here…]
}Preformatted text

7

Hey Rob,
there is only that interface and my pc with ets 5.7 on it… nothing else uses knx ip.

There is a group adress on my bus, it does something like turn off all lights. But it is not binded into the knx.things-file… :-/

8

Hi @ByteBandito,

I have the same issue without a solution.
Did you solve it for your installation or find a workaround?

Thank you in advance,
Christian

9

@ByteBandito I suffer from the same problem - 5 minutes after KNX binding restart I’m starting getting timeouts when openhab is trying to read values from KNX MDT router

I can still trigger turning on/off lights directly from Openhab, but when I physically click the switch on the wall, I got no information about it in Openhab log. This happens after first 5 minutes where everything works perfectly fine!

13:37:44.888 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite isControl
13:37:44.889 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
13:37:44.891 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
13:37:44.893 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' witch isInstance for command 'OFF' and dpt '1.001'
13:37:44.895 [TRACE] [x.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/1/22' size '1' added 'true'
13:37:44.897 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
13:37:44.899 [TRACE] [x.internal.handler.DeviceThingHandler] - processDataReceived postCommand new value '[0]' for GA 'null'
13:37:44.904 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'GenericGroupAddress_GabinetLewyKinkiet' received command OFF
13:37:44.905 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'GenericGroupAddress_GabinetLewyKinkiet' predicted to become OFF
13:37:44.908 [TRACE] [knx.internal.client.AbstractKNXClient] - Received a Group Write telegram from '1.1.4' to '0/5/22' with value '[0]'
13:37:44.909 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'GenericGroupAddress_GabinetLewyKinkiet' changed from ON to OFF
13:37:44.919 [DEBUG] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:f460c0e705:3120d4aa7e' received a GroupValueWrite telegram from '1.1.4' for destination '0/5/22'
13:37:44.921 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:f460c0e705:3120d4aa7e' processes a GroupValueWrite telegram for destination '0/5/22' for channel 'knx:device:f460c0e705:3120d4aa7e:Gabinet_Lewy_Kinkiet'
13:37:44.922 [TRACE] [x.internal.handler.DeviceThingHandler] - onGroupWrite isControl
13:37:44.925 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
13:37:44.928 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
13:37:44.928 [TRACE] [x.internal.handler.DeviceThingHandler] - Handling command 'OFF' for channel 'knx:device:f460c0e705:3120d4aa7e:Gabinet_Lewy_Kinkiet'
13:37:44.930 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' witch isInstance for command 'OFF' and dpt '1.001'
13:37:44.931 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
13:37:44.932 [TRACE] [x.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/1/22' size '1' added 'true'
13:37:44.932 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' witch isInstance for command 'OFF' and dpt '1.001'
13:37:44.933 [TRACE] [ng.knx.internal.dpt.KNXCoreTypeMapper] - toType datapoint DPT = 1.001
13:37:44.934 [TRACE] [knx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '0/1/22', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@189738c'
13:37:44.934 [TRACE] [x.internal.handler.DeviceThingHandler] - processDataReceived postCommand new value '[0]' for GA 'null'
13:37:44.935 [TRACE] [knx.internal.client.AbstractKNXClient] - sendToKNX mappedValue: 'off' groupAddress: '0/1/22'
13:37:44.937 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'GenericGroupAddress_GabinetLewyKinkiet' received command OFF
13:37:44.938 [DEBUG] [knx.internal.client.AbstractKNXClient] - Wrote value 'OFF' to datapoint 'command DP 0/1/22 'knx:ip:f460c0e705', DPT id 1.001, low priority' (0. attempt).
13:37:44.939 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'GenericGroupAddress_GabinetLewyKinkiet' predicted to become OFF
13:37:44.940 [TRACE] [x.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/1/22' size '1' added 'true'
13:37:44.947 [TRACE] [x.internal.handler.DeviceThingHandler] - Handling command 'OFF' for channel 'knx:device:f460c0e705:3120d4aa7e:Gabinet_Lewy_Kinkiet'
13:37:44.948 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec testing Keys '[ga]' for command 'OFF'
13:37:44.949 [TRACE] [g.knx.internal.channel.KNXChannelType] - getCommandSpec key 'ga' uses expectedTypeClass 'class org.openhab.core.library.types.OnOffType' witch isInstance for command 'OFF' and dpt '1.001'
13:37:44.951 [TRACE] [knx.internal.client.AbstractKNXClient] - writeToKNX groupAddress '0/1/22', commandSpec 'org.openhab.binding.knx.internal.channel.WriteSpecImpl@17712f3'
13:37:44.952 [TRACE] [knx.internal.client.AbstractKNXClient] - sendToKNX mappedValue: 'off' groupAddress: '0/1/22'
13:37:44.953 [DEBUG] [knx.internal.client.AbstractKNXClient] - Wrote value 'OFF' to datapoint 'command DP 0/1/22 'knx:ip:f460c0e705', DPT id 1.001, low priority' (0. attempt).
13:37:44.954 [TRACE] [x.internal.handler.DeviceThingHandler] - rememberRespondingSpec handled commandSpec for '0/1/22' size '1' added 'true'
13:43:20.697 [TRACE] [knx.internal.client.AbstractKNXClient] - Sending a Group Read Request telegram for 0/5/1
13:43:30.700 [DEBUG] [knx.internal.client.AbstractKNXClient] - Could not read value for datapoint 0/5/1: timeout waiting for group read response from 0/5/1. Going to retry.
13:43:30.755 [TRACE] [knx.internal.client.AbstractKNXClient] - Sending a Group Read Request telegram for 0/5/0
13:43:40.757 [DEBUG] [knx.internal.client.AbstractKNXClient] - Could not read value for datapoint 0/5/0: timeout waiting for group read response from 0/5/0. Going to retry.
13:43:40.810 [TRACE] [knx.internal.client.AbstractKNXClient] - Sending a Group Read Request telegram for 0/5/17
13:43:50.813 [DEBUG] [knx.internal.client.AbstractKNXClient] - Could not read value for datapoint 0/5/17: timeout waiting for group read response from 0/5/17. Going to retry.
13:43:50.868 [TRACE] [knx.internal.client.AbstractKNXClient] - Sending a Group Read Request telegram for 0/5/9
13:44:00.873 [DEBUG] [knx.internal.client.AbstractKNXClient] - Could not read value for datapoint 0/5/9: timeout waiting for group read response from 0/5/9. Going to retry.
10

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

11

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
12

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

13

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!

14

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.

15

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?

16

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.

17

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…

18

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…

19

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.

20

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?