[knx] Binding keeps sending T_Disconnect telegrams to ETS5 causing device upgrade failures

[JoveToo]

I am using ETS5 to manage my KNX home automation and OpenHAB2 to allow me to turn everything on or off using the Android app and my computer.

However, if OpenHAB2 is running while I am performing a device upgrade, it keeps sending T_Disconnect telegrams to my ETS5 and the device in question, making everything slower and eventually even failing the device upgrade.

Expected Behavior

OpenHAB2 KNX binding does not interfere with traffic that doesn't concern it.

Current Behavior

OpenHAB keeps sending T_Disconnect messages to ETS5 and the device in question, slowing everything down and failing the device upgrade.

Possible Solution

Ignore traffic that doesn't make sense.

Steps to Reproduce (for Bugs)

1. Perform an Application download in ETS5

Context

These are telegram logs made with ETS5, unless you read bus telegrams, they may not be useful.

This is a normal communication cycle:

<CommunicationLog xmlns="http://knx.org/xml/telegrams/01">

<Telegram Timestamp="2018-11-17T18:08:10.0223791Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B05011100001064E437A5CA70281"/>

<Telegram Timestamp="2018-11-17T18:08:10.0228001Z" Service="L_Data.con" FrameFormat="CommonEmi" RawData="2E00B0600001111000CE"/>

<Telegram Timestamp="2018-11-17T18:08:10.0232449Z" Service="L_Data.con" FrameFormat="CommonEmi" RawData="2E00B06000011110037E0A7B97"/>

<Telegram Timestamp="2018-11-17T18:08:10.0845369Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B0501110000100FE"/>

</CommunicationLog>

While this is one when OpenHAB2 is active:

<CommunicationLog xmlns="http://knx.org/xml/telegrams/01">

<Telegram Timestamp="2018-11-17T18:01:45.3223658Z" Service="L_Data.con" FrameFormat="CommonEmi" RawData="2E00B06000011110036E0C5578"/>

<Telegram Timestamp="2018-11-17T18:01:45.3452345Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000200010081"/>

<Telegram Timestamp="2018-11-17T18:01:45.3452982Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000200010081"/>

<Telegram Timestamp="2018-11-17T18:01:45.6530256Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B0501110000100EE"/>

<Telegram Timestamp="2018-11-17T18:01:45.6540195Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000211100081"/>

<Telegram Timestamp="2018-11-17T18:01:45.6541099Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000211100081"/>

<Telegram Timestamp="2018-11-17T18:01:45.7566596Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B050111000010F424C55780FA1042603C7023AC6031B27"/>

<Telegram Timestamp="2018-11-17T18:01:45.756963Z" Service="L_Data.con" FrameFormat="CommonEmi" RawData="2E00B0600001111000C2"/>

<Telegram Timestamp="2018-11-17T18:01:45.7579076Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000211100081"/>

<Telegram Timestamp="2018-11-17T18:01:45.757972Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000211100081"/>

<Telegram Timestamp="2018-11-17T18:01:45.7580272Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000200010081"/>

<Telegram Timestamp="2018-11-17T18:01:45.7580837Z" Service="L_Data.ind" FrameFormat="CommonEmi" RawData="2900B060000200010081"/>

</CommunicationLog>

Your Environment

OpenHAB 2.3 running on CentOS 7

[lewie]

@JoveToo, need more about your environment!

• KNX Interface/Router/Eibd/serial/combination?
• Programming with ETS5 in Router-Mode (Broadcasting with 224.0.23.12) or Tunnel-Mode (direct fixed connection to your named Interface/Router)
• Settings (if IP Interface), especially if addresses above 14/15 are blocked or not.

But it is definitive no Bug! The limits are set by the quality of the used Interface/Router.
Normally this behavior happens, while ETS works in Tunnel-Mode AND another Actor like openHAB holds a Tunnel-Mode connection to the IP-Interfacs/Router too. The Interface has to filter AND resent to second connection too much telegrams at same time.

Especially older ABB and Siemens IP Interfaces could handle only badly two Tunneling connections while programming with ETS.

Therefore Routing-Mode should be always the preferred connection. Routing needs no feedback and is much more scalable. This effect is similar to blocking or non-blocking web servers. Routing-Mode is none Blocking and can handle a lot more requests at the same time.

To prevent brutally, unplug the cable of openHAB for the time of programming.
Better, if you have a Router, switch openHAB to Routing-Mode.
Best/most modern, always use Routing-Mode.

If you only have a Interface-Hardware, simply switch EIBD/KNXD as a Router between the KNX bus and openHAB. Over this Software-Router, ETS AND openHAB can work at same time without any competition to each other.

The KNX bus communication is handled by calimero, the KNX library we use, not in the openHAB Binding itself. Therefore, it will be difficult to prevent this effect via the KNX binding.

[JoveToo]

I am using a KNX Router (that also supports tunneling but this is not used afaict) and programming with ETS5 in router mode (Broadcasting with 224.0.23.12). There is also an EIBD with LinKNX running on the same machine as OpenHAB, both of which are in router mode. The router is built into my powersupply (Elsner PS640-IP).

Why would OpenHAB react to traffic not addressed to it? It is sending 2 T_Disconnect messages (according to ETS5) for every message sent during the programming. This tripples bus activity for no reason whatsoever.

Perhaps there is a misconfiguration somewhere but then I'd like to understand in which cases such a T_Disconnect message is sent.

[JoveToo]

This is the configuration of my router:

And these are the translated traces:
Without openhab:

With openhab:

[lewie]

@JoveToo,
Your configuration is no source of error!
Basic behavior and the curse and blessing of such a bus is the fact that everyone can scream into it and only the receivers decide if they react.

Why would OpenHAB react to traffic not addressed to it?

Unfortunately, I do not know the deeper connections on the side of the device programming and in particular I do not know the meaning of a "T_Disconnect" telegram and when it is sent or must be.

In order to experience this, there are people who are familiar with it.

[JoveToo]

@lewie Thank you :)

[bmalinowsky]

The T_Disconnect comes from a running mgmt client/procedures in openhab. It eagerly rejects all incoming connect requests or follow-ups thereof. Which creates that weird sequence with routing.

[lewie]

@SJKA, @kgoderis, do you have an idea to stop these weird sequence?

[dmiorandi]

Same slow down behavior (very slow down when use ETS4 + openhab 2.4 via eibd tunnel. Shutting down openhab it works). Eibd connect to bus via Siemens Ip interface.
I've bought a new http://busware.de serial interface to throw away siemens module implementing
this https://github.com/knxd/knxd/wiki/Adding-a-busware-pigator-KNX-TPUART-(Raspberry)
direct on same openhab raspberry hardware.

[JoveToo]

There was a fix to Calimero for this issue, not sure when and if this will make it to OpenHAB.

[dmiorandi]

Probably @JoveToo you mean this commit

calimero-project/calimero-core@6585672

that solve this

calimero-project/calimero-core#77

isn't it?

[JoveToo]

@dmiorandi Yes, that's the one.

[lewie]

@dmiorandi, @JoveToo,
here you can find a KNX binding Version with bmalinowsky's fixes for calimero-project/calimero-core#77

Testfile_calimero-2.4-rc2-6585672

Please can you test this Version? If your feedback is positive I will start a PR.

Install Testfile:
Uninstall current running KNX binding. [optional: restart openHAB]. Then put Testfile in addons Folder.

[JoveToo]

Uninstalling the knx binding will not remove the knx data?

[lewie]

No, it doesn't! You only should uninstall knx binding itself, not your Bridge or Things:

You will see a UNINSTALL Button.

[perrin-1]

I am having the same issue - ETS5, IP Router (in my case Siemens N146/02). OPenhab is sending T_Disconnect when updating a KNX device. Is there already a PR?

[hmerk]

closed due to inactivity

[matzetronic]

Hi,
I just wanted to let you know that this issue still exists. I just discovered it with OpenHAB 3.3.0 and ETS 6.0.6. This is especially frustrating if you like me just start with ETS and you think you are doing something wrong and then find out it is a long existing bug in OpenHAB/knxd 😞

So if this is not fixable, I would at least expect that there is a note to this bug in the documentation of the knx addon. I can also add it if you want.

thanks,
Mathias

[JoveToo]

There is a fix, it should be tested. I didn't have time back then, so this issues got closed due to inactivity. Perhaps if someone can provide a fix to a more recent version of OH, I can test it? Perhaps @matzetronic would be interested in testing this too?

[JoveToo]

From what I can tell, this fix is included in calimero 2.5.1, while openhab includes 2.5.

[wborn]

From what I can tell, this fix is included in calimero 2.5.1

Where do you see this fix and 2.5.1 release?

[JoveToo]

Where do you see this fix and 2.5.1 release?

Technically, it is a tag only. It's recent, too. (13 days).

https://github.com/calimero-project/calimero-core/releases/tag/v2.5.1

Link to the fix is in this issue: #4238 (comment)

[wborn]

That fix was merged in 2018 and 2.5 was released in 2021, so I think it already has that fix.

If you open calimero-project/calimero-core@6585672 and expand the tags you'll also see it's already in 2.5:

[JoveToo]

Then there isn't a fix :(