Allow running the KNX IP communication in a separate thread

[marvin-w]

Proposed change

Allow the users to run the communication with the KNX IP Interface to run in a separate thread in order to avoid #59170.

This is an experimental feature.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @Julius2342, @farmio, mind taking a look at this pull request as it has been labeled with an integration (knx) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[farmio]

Nice! Tested locally, works perfectly fine.

[frenck]

I honestly wonder if we should even expose such "complex" features in the UI (or at all). 99% of the users won't have a clue what this even means.

[farmio]

That's why we hide it under advanced options.

[frenck]

That's why we hide it under advanced options.

I don't even agree with that. This is not a feature, this is internal logic, that should not be exposed to end-user at all (regardless of their knowledge level).

[marvin-w]

I don't even agree with that. This is not a feature, this is internal logic, that should not be exposed to end-user at all (regardless of their knowledge level).

It's an attempt to fix #59170. We do not want to roll this out to all users because the logic is quite complex and may have side effects that we were unable to test during our own test (as we also don't experience the mentioned error on our systems). Also, not all users experience the issue in mentioned ticket. If we can confirm that this logic works we can remove this again entirely and make it default. At least, so the plan.

[frenck]

I see your point, but IMHO, these are options we should never expose.

[marvin-w]

I see your point, but IMHO, these are options we should never expose.

I got your point as well, but I don't see any alternative, IMHO it's not an option to roll out changes that might break stuff, especially if it's a fundamental change like this one that requires field testing with multiple devices - not only the two that @farmio and I have. Do you have a better idea? I'm open for it.

[marvin-w]

@frenck I'll close this PR. We will revert the changes in the library. As spoken with bdraco we will focus on fixing the event loop blocks instead of just spawning a new thread for the connection logic. This will make this PR invalid anyway.