ElabNET Technik Forum

Hallo zusammen,

ich beobachte seit kurzem (so um Weihnachten herum) ein seltsames Phänomen. Das hatte ich auch schon vor dem Umstieg auf Version 4.0, also auch schon mit der Version 3.5.1.

Im Wesentlichen sieht mein Setup so aus:

KNX Welt im Haus ist nur über den Timberwolf Server mit dem Netzwerk verbunden und wird auch über diesen parametriert. Dann habe ich noch weitere Systeme im Netzwerk, die über die Timberwolf Schnittstelle mit der KNX Welt kommunizieren. Diese Systeme sind die folgenden:

Timberwolf -> Docker -> NodeRed mit KNX Ultimate (IP: 172.17.0.3 mit bridge network / IP: 192.168.1.202 mit macvlan network)
Linux PC -> ProxMox -> LXC Container mit Docker/Portainer -> NodeRed mit KNX Ultimate (IP: 192.168.1.196)
Linux PC -> ProxMox -> LXC Container mit Home Assistant -> KNX Frontend (IP: 192.168.1.165)

Den NodeRed Container auf dem Timberwolf habe ich einmal im Bridge Modus betrieben und seit einem Tag habe ich das System auf Macvlan umgestellt und betreibe es seit dem so.

Prinzipiell kann ich auf meine KNX Welt zugreifen und Telegramme empfangen sowie Telegramme senden. Soweit so gut, was mir allerdings aufgefallen ist: Die Verbindungen dieser unterschiedlichen Systeme (beide NodeReds und Home Assistant) zu der KNX Schnittstelle des Timberwolfs werden sehr oft getrennt und neu aufgebaut (siehe Screenshot).



Im NodeRed habe ich solch einen Neuaufbau mal mitbekommen und diesen Screenshot mitgebracht:
Fehlermeldung: Disconnected by error Invalid Connection ID



Im Home Assistant schaue ich ins Log und finde folgende Einträge passend zum Zeitpunkt der Neustarts:



Beim Neuaufbau ist es dann so, dass die Systeme (NodeRed und Home Assistant) erstmal wieder ganz viele Lese Anfragen stellen, um den Status auf dem KNX Bus abzufragen. Das belastet den Bus in soweit, dass ich den Timberwolf Server aus der ETS heraus eigentlich gar nicht parametrieren kann. Dieser Vorgang an sich dauert ja schon lange und wenn man sich die Zeitabstände im 1. Screenshot anschaut (KNX LOG auf dem Timberwolf) dann wird klar, dass man hier kaum noch durchkommt. Auch bei anderen KNX Teilnehmern ist es mir schon aufgefallen, dass ich den Download Vorgang aus der ETS teilweise mehrfach anstoßen muss.

Die Frage ist nun: Hat jemand eine Idee, was das Problem hier sein kann? Für mich sieht es im Moment so aus, als läge es irgendwie am Timberwolf Server und der KNX Schnittstelle. Ich hoffe ihr könnt mir helfen.

Vielen Dank im voraus und viele Grüße,
Tarek

Das ist relativ unabhängig vom TWS, da gibt es im KNX-UF auch im Zusammenhang mit anderen IP-Intertaces einige Beiträge. Dort gab es dann meist auch gleich blockierte Schnittstellen, da diese dort die Tunnel immer.nich was länger frei halten und dann mit 4-5 Tunnel die Kapazitäten schnell erschöpft sind.

Ursache waren Einstellungen im KNX-Adapter aber auch mal im Netzwerk selbst. Ich bin aber kein Netzwerkspezialist, um das genauer erklären zu können.

Ich habe das gleiche Problem seit damals der Port von 3671 auf 3700 vom Interface geändert wurde.

Ich kenne NR und HA nicht: Kann man dort die Keep-Alive Intervalle einstellen und diese mal verkürzen (wenn möglich) ?
Man könnte zudem auch mal schauen, ob vor den Fehlern einige Zeit wenig/keine Kommunikation stattgefunden hat.

Und dann wäre noch die Frage, ob sich beeinflussen lässt, UDP (normaler Weise beim Routing) oder TCP (normaler Weise beim Tunneling) zu verwenden.

Kurzes Feedback: Ich habe heute endlich mal Zeit gefunden das noch mal durchzuspielen und wollte das LOG vom iobroker KNX Adapter mit hochladen. Scheinbar haben sich bei mir die Probleme mit Update auf die [V4.0 IP7] der TWS-Software erledigt.

Moderation: Nach Austausch mit sfrit, habe ich die Versionsinformation entsprechend konkretisiert.

Hallo @sfrit,

eine V4.0 ist schlicht noch nicht existent!

Beste Grüße
Jens

@Civlo
Besteht das Problem bei dir immer noch oder kann ich es auf gelöst setzen?