KNX bridge goes offline randomly

Setup, Configuration and Use Beginners
1

Hi dear all,

i have OH 4.1.0 running on my pi4. Sometimes i see the knx-thing go offline and back online after a few seconds. I am not really able to identify the problem. Maybe you can help me?
I wrote a rule to get a notification when bridge goes offline.
I managed to get the log entry at the moment the thing went off.

2024-01-02 14:17:59.545 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/3'
2024-01-02 14:18:00.128 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/12'
2024-01-02 14:18:00.195 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/14'
2024-01-02 14:18:00.262 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/11'
2024-01-02 14:18:00.446 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/2'
2024-01-02 14:18:03.592 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/15'
2024-01-02 14:18:03.678 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f is disconnecting from KNX bus
2024-01-02 14:18:03.692 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f is disconnecting from KNX bus
2024-01-02 14:18:03.716 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f scheduling connect in 60s
2024-01-02 14:18:03.778 [DEBUG] [nx.internal.client.AbstractKNXClient] - KNX link has been lost (reason: server request on object tunneling link (closed) 192.168.178.47:3671 TP1 medium, device 0.0.0, hopcount 6)
2024-01-02 14:18:03.783 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f scheduling connect in 60s
2024-01-02 14:19:03.743 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f is disconnecting from KNX bus
2024-01-02 14:19:04.745 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f is connecting to KNX bus
2024-01-02 14:19:04.746 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.178.47:3671 in mode TUNNEL.
2024-01-02 14:19:04.755 [INFO ] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:d49019977f connected to KNX bus
2024-01-02 14:19:04.757 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:6a2c708015' will be polled every 600s
2024-01-02 14:19:04.758 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:f973f10a01' will be polled every 600s
2024-01-02 14:19:04.760 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:d95632081a' will be polled every 30s
2024-01-02 14:19:04.760 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:c2762653aa' will be polled every 10s
2024-01-02 14:19:04.761 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:8ead813050' will be polled every 10s
2024-01-02 14:19:04.762 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:77c6faf39f' will be polled every 600s
2024-01-02 14:19:04.762 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:7a7119f4f2' will be polled every 60s
2024-01-02 14:19:04.761 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:dc7c21498e' will be polled every 600s
2024-01-02 14:19:04.763 [DEBUG] [.internal.handler.DeviceThingHandler] - 'knx:device:d49019977f:c58e3dd35b' will be polled every 600s
2024-01-02 14:19:04.764 [DEBUG] [.internal.handler.DeviceThingHandler] - Polling individual address '3.1.1'
2024-01-02 14:19:04.881 [DEBUG] [.internal.handler.DeviceThingHandler] - Polling individual address '4.1.1'
2024-01-02 14:19:04.958 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/6'
2024-01-02 14:19:05.036 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:d49019977f:f973f10a01' received a GroupValueWrite telegram from '2.1.3' for destination '2/0/0'
2024-01-02 14:19:05.194 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:d49019977f:77c6faf39f' received a GroupValueWrite telegram from '1.1.2' for destination '5/0/5'
2024-01-02 14:19:05.218 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:c2762653aa' received a GroupValueWrite telegram from '1.1.4' for destination '3/1/3'
2024-01-02 14:19:05.239 [DEBUG] [.internal.handler.DeviceThingHandler] - onGroupWrite Thing 'knx:device:d49019977f:f973f10a01' received a GroupValueWrite telegram from '2.1.3' for destination '2/5/0'

And here my thing config:

UID: knx:ip:d49019977f
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
  useNAT: false
  readRetriesLimit: 3
  ipAddress: 192.168.178.47
  autoReconnectPeriod: 60
  localSourceAddr: 0.0.0
  readingPause: 50
  type: TUNNEL
  portNumber: 3671
  responseTimeout: 10
2

Have you tried restarting your knx ip interface ? Try it and monitor it for some time. Make sure your are not using all the tunnels that the interface can handle.
There are a lot of topics related to this very issue read about but generally if you don’t want to be bothered about connections the best is tu use a knx router.

3

Hey stamate,
I restarted the KNX power-supply. Checked the log within ETS6 (the Group-Monitor-Log). Right before the Thing in OH goes offline, I don’t see any errors there. Only bus-traffic as usual.
But after the Binding restarts, I see some logs in ETS where it seems like OH is polling some states.

How do I know about the maximum Number of Tunnels?
Edit: It’s a MDT SCN-IP000.02 IP Interface

Ty so much :wink:

4

The KNX IP router / KNX IP interface supports up to 4 simultaneous connections. The first physical
address is adjusted as described under 3.3 in the ETS connections. In the Web-Interface, the further
physical addresses can be assigned automaticaly
͞Prog.Mode͟:
Figure 11: Set Tunneling Addresses in “Prog.Mode”
Now the 3 following physical addresses are assigned. If, for example, the IP Interface has got the first
tunneling address assigned to the physical address 15.15.241, so the device provides further
tunneling addresses automatically to 15.15.242, 15.15.243 and 15.15.244. When the first address
was assigned to x.x.255, so the further tunneling addresses are not assigned automatically!

That is from the manual I hope its self explanatory make sure instead of address 0.0.0 you used the assigned address of one of the 4 tunnels assigned in ets

5

I had the same problem for weeks and I think I found the solution, at least for my setup!

  • Every now and then, my KNX Bridge went offline and immediately back online again. This was a big problem e.g. during script execution, as telegrams were missed and several things went wrong
  • I tried everything: restarting openhab, reboot, even reinstallation of the whole system: nothing worked
  • I created a rule that sent me a mail when the KNX bridge came back online, so I could check the exact times in the log
  • at some point, after I installed and used another binding (modbus) I saw in the logs, that there was a diconnect to my modbus device at the same time the KNX bridge went offline - even though they didn’t interact. And once, at the very same time OpenHAB did a re-login on my FritzBox (Router) which I use for polling phone call numbers.
  • I came to the conclusion that the Ethernet connection to my router itself might be the problem!
  • So I connected my Raspberry Pi (Model 4) to my Gigabit Ethernet Switch instead of directly to the FritzBox
  • And since more than a week: not a single disconnect / dropout! So checking your Ethernet connection stability might be a good idea