KNX network link was detached from the process communicator

I switched to OH2 somewhen in Dec/January and since then I face problems with the stability of the KNX connection which ultimately can only be resolved by a Debian restart (at least I do not know a better solution).

OH2 is running on Debian in a virtual machine. An update to the latest stable release of Debian and OH2 did not solve the problem. KNX is connected via IP network with a Gira router on the KNX side.
On OH1.8 / OH1.9 the KNX connection did not face any issue for more than 2,5 years. The network and KNX setup itself did not change, thus I assume it does not contribute to the issue.

My entire house and garden is controlled via KNX but a lot of the “intelligent” stuff like controlling the shutters to avoid heating up the house in summer or sprinkling the lawn is done in OH with timers and rules. So I really need a stable and reliable OH. I fear I need to switch back to OH 1.9 before summer vacation…

Highly appreciate your help!

So what happens?

Summary:

  • “The KNX network link was detached from the process communicator” occurs frequently, but getting re-established after some minutes.
  • After some days re-establishing fails and the KNX link is permanent down

Details:

As per log the KNX network link seem to go down frequently:

2019-06-08 06:40:44.317 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-08 07:42:26.368 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 00:02:08.477 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 01:01:44.715 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 01:32:00.346 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 01:41:03.386 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 03:02:09.104 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 03:11:17.135 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-09 05:42:05.555 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-10 04:32:51.859 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-10 05:51:13.594 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-10 06:21:16.235 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-10 06:38:16.733 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator

Details what happens then from log.
Hint: the Gira router does only allow one connection at a time and locks incoming connections. If connection one is getting silent it is being kicked out after some time and a new connection is accepted.

2019-06-08 07:42:26.368 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-08 07:42:26.426 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:26.431 [DEBUG] [nx.internal.client.AbstractKNXClient] - KNX link has been lost (reason: server request on object tunneling link (closed) 192.168.2.100:3671 TP1 medium, device 0.0.0, hopcount 6)
2019-06-08 07:42:26.486 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-06-08 07:42:26.486 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-08 07:42:26.495 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - establishing connection failed, null
2019-06-08 07:42:26.496 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: null
2019-06-08 07:42:26.523 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:26.538 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus

This repeats now every second until this happens:

2019-06-08 07:42:50.029 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-08 07:42:50.034 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - could not accept new connection (maximum reached)
2019-06-08 07:42:50.035 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - establishing connection failed, error response from control endpoint /192.168.2.100:3671: could not accept new connection (maximum reached)
2019-06-08 07:42:50.035 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: error response from control endpoint /192.168.2.100:3671: could not accept new connection (maximum reached)
2019-06-08 07:42:50.041 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:51.042 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:51.042 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-06-08 07:42:51.043 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-08 07:42:51.047 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - could not accept new connection (maximum reached)
2019-06-08 07:42:51.047 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - establishing connection failed, error response from control endpoint /192.168.2.100:3671: could not accept new connection (maximum reached)
2019-06-08 07:42:51.047 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: error response from control endpoint /192.168.2.100:3671: could not accept new connection (maximum reached)
2019-06-08 07:42:51.058 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:52.059 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-08 07:42:52.060 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-06-08 07:42:52.060 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-08 07:42:52.071 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - ‘knx:device:bridge:Schaltausgang_1_1_2’ will be polled every 600s
2019-06-08 07:42:52.073 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - ‘knx:device:bridge:Schaltausgang_1_1_3’ will be polled every 600s
2019-06-08 07:42:52.079 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - ‘knx:device:bridge:Schaltausgang_1_1_4’ will be polled every 600s
2019-06-08 07:42:52.081 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - ‘knx:device:bridge:Dimmer_1_1_13’ will be polled every 600s

That is already scary cause it means KNX is disconnected for a while and maybe my “sprinkling OFF” command will not go through, thus my garden gets flooded.

But sometimes (every couple of days) this happens:

2019-06-10 06:38:16.733 [DEBUG] [nx.internal.client.AbstractKNXClient] - The KNX network link was detached from the process communicator
2019-06-10 06:38:16.735 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus
2019-06-10 06:38:16.748 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is connecting to the KNX bus
2019-06-10 06:38:16.749 [DEBUG] [binding.knx.internal.client.IPClient] - Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-10 06:38:16.763 [ERROR] [Xnet/IP Tunneling 192.168.2.100:3671] - establishing connection failed, null
2019-06-10 06:38:16.764 [DEBUG] [nx.internal.client.AbstractKNXClient] - Error connecting to the bus: null
java.lang.InterruptedException: null
at java.lang.Object.wait(Native Method) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.waitForStateChange(ConnectionBase.java:541) ~[?:?]
at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:190) ~[?:?]
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.(KNXnetIPTunnel.java:159) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.getConnection(IPClient.java:107) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.createKNXNetworkLinkIP(IPClient.java:90) ~[?:?]
at org.openhab.binding.knx.internal.client.IPClient.establishConnection(IPClient.java:77) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.connect(AbstractKNXClient.java:178) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.connectIfNotAutomatic(AbstractKNXClient.java:164) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.readNextQueuedDatapoint(AbstractKNXClient.java:272) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.lambda$1(AbstractKNXClient.java:199) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-06-10 06:38:16.783 [DEBUG] [nx.internal.client.AbstractKNXClient] - Bridge knx:ip:bridge is disconnecting from the KNX bus

And from then on OH is useless.

Extract THINGS
Bridge knx:ip:bridge [
ipAddress=“192.168.2.100”,
portType=3671,
localIp=“192.168.2.167”,
type=“TUNNEL”,
readingPause=50,
responseTimeout=10,
readRetriesLimit=3,
autoReconnectPeriod=1,
localSourceAddr=“0.0.0”
] {

// GENERISCHE GAs

Thing device GenericGAs  
{
    Type number          : Rollo_Szenen                     [ ga = "17.001:0/4/0" ]
}

// TECHNIKRAUM SCHALTSCHRANK
// Technikraum Schaltschrank Schaltausgang_1_1_2

Thing device Schaltausgang_1_1_2 [address="1.1.2" ] 
{
    Type switch         : Steckdose_Wohnzimmer_Sued         [ ga = "2/1/8" ]    
    Type switch         : Steckdose_Esszimmer_Boden         [ ga = "2/1/9" ]
    Type switch         : Licht_Wohnzimmer_Mitte            [ ga = "2/1/10"]
    Type switch         : Licht_Kueche                      [ ga = "2/1/11"]
    Type switch         : Licht_Windfang                    [ ga = "2/1/14"]
    Type switch         : Licht_Windfang_Wand               "Ungenutzt"                         [ ga = "2/1/15"]
    Type switch         : Licht_WC                          [ ga = "2/1/16"]
    Type switch         : Licht_WC_Spiegel                  [ ga = "2/1/17"]
    Type switch         : Licht_Treppe_EG_OG                [ ga = "2/1/18"]
}

@claus.angermeier, eventually this helps:

Definitively, “autoReconnectPeriod=1” can be ab connection killer.
Please set to:

autoReconnectPeriod=60

Please can you tell me your KNX IP-Interface type?

TY. Changed the configuration, let’s see :slightly_smiling_face:

Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="192.168.2.100", 
    autoReconnectPeriod=60
] 

KNX IP-Interface type us TUNNEL.

In the LOG i found this:

Establishing connection to KNX bus on 192.168.2.100:3671 in mode TUNNEL.
2019-06-16 12:30:32.104 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - 'knx:device:bridge:Schaltausgang_1_1_2' will be polled every 600s
2019-06-16 12:30:32.113 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - 'knx:device:bridge:Dimmer_1_1_13' will be polled every 600s
2019-06-16 12:30:32.114 [DEBUG] [.knx.handler.AbstractKNXThingHandler] - 'knx:device:bridge:Schaltausgang_1_1_5' will be polled every 600s

This seems to be done for all KNX things. Seems to be the default “pingInterval”.

What is the purpose of this? I can only think on getting the initial setting and after a KNX bus shutdown/restart. But why has this polling to be done all 10 minutes? But maybe it does not harm.

Your TUNNEL configuration is perfect.

'knx:device:bridge:Schaltausgang_1_1_5' will be polled every 600s

Here the binding is polling the internal configuration of your actuator. This is just for later more specific functions.

“What is the purpose of this?” None! (simplify your configuration and it will stop: https://www.openhab.org/addons/bindings/knx/#examples)
Delete or comment the parameters address, fetch, pingInterval in your things configurations, you do not need it. They are counterproductive and damage the connection stability.

“But why has this polling to be done all 10 minutes?”
Don’t be!

“But maybe it does not harm.”
However, some actuators crash or cause the knx binding to crash on a static TCP TUNNEL connection. UDP ROUTER connections are much more robust in general.

Thank you for your help so far!

The change of configuration did not mitigate the issue. Still the connection is lost frequently, is self-healing several times but ultimately stops working and only a reboot is helping.

As next step I will now re-establishing OH 1.9 to see if there is an underlaying issue with the VM/Debian/network. I need a stable OH before I go on vacation in August to be sure that all is fine at home while I’m away.

Hi,
Same problem here since the upgrade.
I have running 1.9 and 2.4 in parallel.
Only the 2.4 has to be rebooted.

OK, now I struggle to get OH1.9 up and running again (I really hate setting up Linux).

Some more questions on the getting KNX up and running on OH2.

USB

I have an USB interface on the KNX bus too. Use it for ETS programming. Will it solve to use this for OH2 or are there the same known issues?
Can someone point me to good guide how this can be used on Debian instead of IP?

Working IP interfaces
Seems there are KNX IP interfaces out there where you folks have no issues with OH2.
Considering the amount of time I spent with this issues and my desire to focus on the home automation instead, I lean towards solving the issue by buying a new one. Can you provide me some product recommendations?

UDP

I assume this is a feature of the IP KNX gateway? Or is this a configuration of the KNX binding?
Sorry if this is a stupid question, but my times to be on this IT technical level are long over…

I have no more experience with USB interfaces.

There are IP Interfaces which only can connect via a fixed TCP TUNNEL mode and there are Interfaces which can connect via TCP TUNNEL or UDP ROUTER mode.

ROUTER mode is a communication based on UDP. In general, it is more robust because there is no fixed connection that can break.

@J-N-K kindly provided an update that fixed the bug for TUNNEL mode.
At least that’s what users report.