[SOLVED] Knx (version 2.x) binding losing its connection almost every day

Setup, Configuration and Use Runtime
1

Hi all,

Platform information: Raspberry PI 3 running openhabian. Openhab version 2.4.0.1 (release build),

I’ve been running Openhab with knx for 3 years now. Previously used the knx 1.x binding, but I have recently moved to the knx 2 binding. The 1.x binding was running without any issues, but since moving to 2.x, I am facing connection drops almost every day.

My openhab.log:

2019-05-27 04:29:43.283 [ERROR] [calimero.link.192.168.2.5:3671      ] - send error, closing link
tuwien.auto.calimero.knxnetip.KNXConnectionClosedException: waiting for service ack
	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:246) ~[?:?]
	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]
	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[?:?]
	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[?:?]
	at tuwien.auto.calimero.mgmt.TransportLayerImpl.sendData(TransportLayerImpl.java:372) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:797) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.sendWait2(ManagementClientImpl.java:824) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementClientImpl.readDeviceDesc(ManagementClientImpl.java:447) ~[?:?]
	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:310) ~[?:?]
	at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:338) ~[?:?]
	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:144) ~[?:?]
	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:184) ~[?:?]
	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-05-27 04:29:43.485 [ERROR] [KNXnet/IP Tunneling 192.168.2.5:3671] - establishing connection failed, null

My events.log:

2019-05-27 04:29:43.427 [hingStatusInfoChangedEvent] - 'knx:device:BAOS771:4072_nachthal' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): link closed, waiting for service ack
2019-05-27 04:29:43.449 [hingStatusInfoChangedEvent] - 'knx:ip:BAOS771' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): server request
2019-05-27 04:29:43.485 [hingStatusInfoChangedEvent] - 'knx:device:BAOS771:dummy' changed from ONLINE to OFFLINE (BRIDGE_OFFLINE)
etc... (all devices going to OFFLINE)

My knx.things file:

Bridge knx:ip:BAOS771 [
	type="TUNNEL",
	ipAddress="192.168.2.5", // IP of my knx Ip interface
	portNumber=3671,
	localIp="192.168.2.20", // IP of my RPI
	readingPause=50,
	responseTimeout=10,
	readRetriesLimit=5,
	autoReconnectPeriod=1
]	{
...
}

Some additional information:

  • My KNX IP interface is a Weinzierl 771 KNX
  • When openhab (+knx) is running, it is running fine. Everything works well, there are no errors
  • No issues with knx 1.x binding
  • The connection errors occur at a random period, sometimes even in the middle of the night (e.g. example above was at 4.30am)
  • Sometimes knx is able to reconnect automatically, but sometimes the connection remains lost and I need to restart openhab (or only the knx binding) in order to reconnect
  • I have configured all things with fetch=true and pinginterval=600. Also tried switching to fetch=false, but that didn’t make any difference
  • I’ve tried disabling all rules and have now disabled all other bindings, but no avail.

I really don’t understand what goes wrong here. Any help would be appreciated. Should I change the configuration parameters in the knx.things file?

1 Like
2

For those facing this issue, the below post from @lewie solved this problem for me:
(see also https://github.com/openhab/openhab2-addons/issues/5281)

in many versions, configurations and environments I use the KNX binding almost daily.

The KNX 2 binding is not yet perfect and has a few pitfalls, but it can run stable in almost all cases. In any case, it is similarly robust as the KNX 1.x binding was!

The following rules of conduct have led most constellations to success:

1.) In principle, the query of the actuator parameters should be omitted if possible. This feature is in no case necessary in any configuration, it is currently not used at all to tune GAs with openHAB.

After many discussions and hundreds of tests, it turns out that some actuators do not like to be queried regularly. If such a device is in the KNX bus, its unruly behaviour disturbs the whole bus and the openHAB KNX binding can be forced to reconnect or even give up after (usually 3) attempts. So comment out the parameter “address”, “fetch” and “pingInterval” in the Thing configuration if possible! It is best to omit this parameter from the beginning.

For orientation, if you absolutely want to arrange your GAs by actuators instead of by functionality or place of use, the value can remain there. (It should be mentioned here, but basically the KNX bus is organized via the GAs and abstracted from the actuator. This is one of the core concepts of the KNX bus and of such a bus in general.)

My opinion is: The query of the actuators is extremely confusing for most users, because they think that the logic of the KNX bus is structured like this, but this is wrong. The order by actuator is detrimental at this point because it is basically only a feature for absolute special applications. Or later used to make autodiscovery of the KNX bus possible in the background.

2.) The connection problem is aggravated with the parameter “autoReconnectPeriod” . If this parameter is set too short (<60 sec, depending on the number of addresses to be read out), the binding starts with a new loop and gets entangled, regardless of whether it is still being read out or not. An unfavorable but often observed misconfiguration then leads to the binding breaking off and no longer connecting. (We may have to investigate this and catch it in newer versions)

3.) Do not set “ipAddress” in ROUTER mode and only set “localIp” if two network cards are present and only if problems occur. Both are very special parameters which the normal user does not need.

I’m also writing this for the many users who might get a little too much respect for the KNX binding as a result of the discussion. The following configuration pattern should be sufficient for almost all users:

//PATTERN ROUTER DEFAULT
Bridge knx:ip:bridge [ 
    type="ROUTER",
    autoReconnectPeriod=60 //optional I would set always
] {
    Thing device knx_device "knx_device_name" @ "knx_device_group_in_paperui" [ 
        //readInterval=3600 //optional only used if reading values are present
    ] {
        ...
    }
}

//PATTERN TUNNEL DEFAULT
Bridge knx:ip:bridge [ 
    type="TUNNEL",
    ipAddress="192.168.0.111",
    autoReconnectPeriod=60 //optional I would set always
] {
    Thing device knx_device "knx_device_name" @ "knx_device_group_in_paperui" [ 
        //readInterval=3600 //optional only used if reading values are present
    ] {
        ...
    }
}

That’s it, less is more!

Because the topic is close to my heart, I am of course debugging and working out improvements for further versions. If you want you can send me a private message and we will do a remote session.

3 Likes
3

Thx