KNX crashes OpenHab after some days

Add-ons Bindings
1

I have a problem with the KNX connection. (MDT IP Interface)

It’s present since OH 3.4.? and is still there in 3.4.3 (Synology Docker)

After round about 3-4 days i see disconnects in the log:

openhab.log

2023-05-10 14:25:29.443 [INFO ] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge connected to KNX bus

events.log

2023-05-10 13:10:58.110 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'knx:ip:bridge' changed from OFFLINE (COMMUNICATION_ERROR): InterruptedException, sleep interrupted to ONLINE

The messages accumulate and after a day or so, openhab stops working.

2023-05-07 07:04:32.372 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@4cb30f88' takes more than 5000ms.
2023-05-07 07:05:28.166 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.internal.items.ItemUpdater@4cb30f88' takes more than 5000ms.
2023-05-07 07:05:33.437 [INFO ] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge connected to KNX bus

2023-05-07 07:05:40.471 [ERROR] [calimero.link.192.168.1.211:3671    ] - send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: waiting for service ack
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:249) ~[?:?]
	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.connect(TransportLayerImpl.java:314) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendData(TransportLayerImpl.java:333) ~[?:?]
	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-05-07 07:06:29.424 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@544c9684' takes more than 5000ms.
2023-05-07 07:06:47.087 [INFO ] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge connected to KNX bus

UID: knx:ip:bridge
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.1.211
  localIp: 192.168.1.218
  autoReconnectPeriod: 60
  type: TUNNEL
  localSourceAddr: 1.1.1
  readingPause: 50
  portNumber: 3671
  responseTimeout: 10

UID: knx:device:0eb601a74b
label: KNX Binäreingang 16
thingTypeUID: knx:device
configuration:
  pingInterval: 600
  address: 1.1.14
  readInterval: 0
  fetch: false
bridgeUID: knx:ip:bridge
location: HWR
channels:
  - id: LeckagesensorKueche
    channelTypeUID: knx:number
    label: LeckagesensorKueche
    description: null
    configuration:
      ga: 1.001:<6/2/17

Any ideas? Thanks!

2

Can you actually read that group adress in ets? Is that adress even behind that tunnel? Do you have lines in your installations or just one ?

3

There is only one line. The group address is probably not the problem. I have more Things which work. The above is one example. Problems occur after some days with the bridge or/and with the IP Interface.

4

Today it happened again. Aber round about 4 days the messages in the log accumulate.

Any ideas anyone :slight_smile:

Thanks :pray:

5 
UID: knx:ip:bridge
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  ipAddress: 192.168.1.211
  type: TUNNEL

UID: knx:device:0eb601a74b
label: KNX Binäreingang 16
thingTypeUID: knx:device
configuration:
bridgeUID: knx:ip:bridge
location: HWR
channels:
  - id: LeckagesensorKueche
    channelTypeUID: knx:number
    label: LeckagesensorKueche
    description: null
    configuration:
      ga: 1.001:<6/2/17

Use defaults as much as possible when starting out then let’s make sure that IP tunnel device doesn’t have other connections going like ets nodered also very important is your network. Imagine like this there are two guys talking if one of them doesn’t respond withing a certain time the conversation ends abruptly that is why you want multicast router send and forget you might loose some messages if there is a network problem. Read this some developers also agree https://community.openhab.org/t/knx-tunnel-vs-router/118891. But can also be a configuration problem on openhab side check again your config remove any entry like 1.1.1 that corespond with ets topology Knox devices and leave most things default and change your logging to debug for a while more info can pop out https://www.openhab.org/docs/administration/logging.html. In the end it’s going to take time to figure out what’s wrong but keep posting here maybe another guy sees the error