Probleme nach Erhöhung Anzahl Linien in KNX-Anlage

[Sturmhardt]

Dank guter Hilfe hier im Forum ist die KNX-Anlage meines EFH seit Beitritt hier von 2015 bis heute auf nun rund 250 Geräte angewachsen. Ich nutze ETS6 Pro. Bisher hatte mein Projekt 3 Linien: TP, RF und PL. Mit jeder Renovierung der letzten Jahre habe ich TP Verkabelung nachgerüstet, so dass auf PN/ RL nur noch sehr wenige Geräte sind, gut 200 sind auf einer Linie TP.

Ich habe habe daher die TP-Linie 1.1 nun auf 2 Linien aufgeteilt (1.1 und 1.5); die Verkabelung hatte ich seit 2015 dafür vorbereitet. Seit der Umstellung funktioniert die Anlage im Alltagsbetrieb normal und gefühlt fehlerfrei. Aber: Ich kann keine neuen Geräte mehr programmieren. Auch stundenlanges Geschreibe mit ChatGPT, Google und Co. halfen nicht, daher nun hier die Bitte um Hilfe. Details:

- 2 KNX Netzteile Meanwell KNX-40E-1280D verbaut
- Linien 1.1/ 1.5 mit je einem Weinzierl "KNX-IP Router 751" angeschlossen; die Router sind lt. Fritzbox normal funktionierend und können via ETS6 schnell & fehlerfrei programmiert werden; Geräteeinstellungen siehe Anhänge
- Visu: 5 iOS/ Android Tablets und diverse Smartphones greifen mit Software "ayControl" und dem IP-Gateway "Arcus IP-Gateway II" auf KNX zu
- Einstellungen KNX IP-Gateway II Einstellungen siehe Anhang; es ist nicht als Koppler im ETS Projekt eingefügt
- Topologie-Ansicht aus ETS6 siehe Anhang

- vor Topologie-Anpassung (alle 200 TP-Geräte auf Linie 1.1) war Buszugriff fehlerfrei möglich, keine farbigen Telegramme im Gruppenmonitor
- Buslast laut Messung der Netzteile < 30%; im Programmierbetrieb < 60% => kein Telegrammverlust spürbar;
- Programmierungen in 100% der Fälle erfolgreich

- seit Topologie-Anpassung Auslesen "Geräteinfo mit Gruppenkommunikation" via Arcus Gateway möglich, aber langsamer (Telegrammwiederholungen), via Weinzierl Router in > 50% der Fälle nicht erfolgreich; sehr viele gelb markierte Telegramme, Disconnects der auszulesenden Geräte mit automatischen Reconnect, Dauer statt rund 5-15 Sekunden mit Arcus nun 40-60 Sekunden
- Programmierung der Applikation funktioniert nicht mehr; nach Schreiben der PA bricht Applikationsdownload nach 5-20 Sekunden, vielen Retrys und wenig Fortschritt ab
- Programmierversuche mit Arcus kommen bis rund 80% Fortschritt; mit den Weinzierl bis 30% Fortschritt
- Exporte Gruppenmonitor "schnell und fehlerfrei" mit Arcus und "lahm, fehlerträchtig" mit Weinzierl siehe pdf Anhang
- bei Programmier-Versuchen via ETS auf KNX blinkt die KNX-LED der Weinzierl Router rot/ grün; sie tut das auch, wenn ich mit dem Arcus Gateway programmiere (!)
- Versand/ Abfrage von GA aus dem Gruppenmonitor der ETS funktioniert fehlerfrei, dabei blinken diese LED nicht rot
- Lese-/ Schreibzugriffe der Visu auf beide Segmente 1.1/ 1.5 problemlos, LED blinkt nur grün

Versuchte Maßnahmen ohne Erfolg:
- Änderung der Tunneling-Adressen in den Routern
- Prüfung, dass keine Tunneling Adressen doppelt belegt sind
- Änderung der Einstellungen in den Weinzierl 751 bezüglich der Bestätigung physikalisch adressierten Telegramme ("immer", "nur bei Weiterleitung")

Wer kann sich einen Reim darauf machen?

Hinweis zur Filter-Einstellung der Weinzierl: Die stehen auf "Weiterleiten", da die Visu mit dem Arcus IP-Gateway II zugreift, das topologisch an der Linie 1.1 angeschlossen ist. Über 500 GA des Segments 1.5 müssen aber für die Visu zugänglich sein. Meines Erachtens ist die Filterung daher nicht möglich/ erforderlich. Siehe oben: Ich habe kein Buslast-Problem.

DANKE!

[FRELS]

Bei mir war das Problem das ich nicht Segmentiert hatte, probier es mal damit, ich sehe auf deinen Linien kein Segment. Wichtig das muss den Linienkopplern dann auch mitgeteilt werden.

[Beleuchtfix]

Es könnte auch an den SVs liegen. Mit ca 100 Geräten bist du schon sehr nah an der maximalen Leistung der SVs und programmieren ist Stress für den Bus. Wenn dann noch viele Wiederholungen kommen, weil durch die Weiterleitung etliche Signale auf der Linie nicht bestätigt werden, kann es zu Fehlern kommen.
Gruß Florian

[Sturmhardt]

Es könnte auch an den SVs liegen. Mit ca 100 Geräten bist du schon sehr nah an der maximalen Leistung der SVs und programmieren ist Stress für den Bus. Wenn dann noch viele Wiederholungen kommen, weil durch die Weiterleitung etliche Signale auf der Linie nicht bestätigt werden, kann es zu Fehlern kommen.
Gruß Florian

Die Spannungsversorgungen messen einen Verbrauch von rund 500mA im Normalbetrieb und 850mA beim programmieren. Die Netzteile sind diagnosefähig; weder die KO für "80% Maximalstrom erreicht" senden "1", noch die KO für "Überlast". Die Busspannung beträgt am entferntesten Ende der Topologie 28 Volt. Würde ich daher ausschließen. Danke trotzdem für die Idee.

[Klaus Gütter]

Ich tippe mal auf diese Einstellung der IP-Router
image.png
Diese Einstellung sollte eigentlich immer auf "Filtern" stehen.

Hintergrund: Wenn du z.B. in der Linie 1.1 arbeitest, also ETS ist mit einem Tunnel des IP-Routers 1.1.0 verbunden und schickt ein Telegramm an ein Gerät der Linie 1.1, werden mit dieser Einstellung die IP-Router das Telegramm trotzdem auch sinnloserweise an die Linie 1.5 weiterleiten. Dort hört aber niemand auf die Adresse, so dass das Telegramm in der Linie 1.5 dreimal wiederholt wird. Das passiert dann beim Programmieren oder Geräteinfo bei jedem einzelnen Telegramm so, bis die Telegrammbuffer der IP-Router vollgelaufen sind.

Wenn die Einstellung auf "Filtern" steht, schaut der IP-Router auf die Zieladresse des Telegramms und leitet es nur weiter, wenn nötig.

Unabhängig davon: dein PL und RF-Linien hängen absolut in der Luft. Mit dieser Topologie bräuchte es noch eine TP-Linie 2.0 mit Spannungsversorgung und IP-Router, damit das funktioniert. Oder du machst eine der beiden Linien 1.1/1.5 zur Hauptlinie 1.0 und hängst die PL und RF-Linien da dran.

[oezi]

Ich hatte irgendwann ähnliche Probleme und habe dann eine Bereinigung umgesetzt.

Alle Linien sind geblieben, jedoch gibt es jetzt für die Übergeordneten Komponenten wie IP-Controller usw. eine 1.0.x, da hängen die anderen Linien dran, und seit dem ist alles ok.
1.0x - 1.1x - 1.2x - 1.3x - 1.4x - 1.5x TP-RF - 1.6x Außen

[Sturmhardt]

Ich tippe mal auf diese Einstellung der IP-Router
image.png
Diese Einstellung sollte eigentlich immer auf "Filtern" stehen.

Hintergrund: Wenn du z.B. in der Linie 1.1 arbeitest, also ETS ist mit einem Tunnel des IP-Routers 1.1.0 verbunden und schickt ein Telegramm an ein Gerät der Linie 1.1, werden mit dieser Einstellung die IP-Router das Telegramm trotzdem auch sinnloserweise an die Linie 1.5 weiterleiten. Dort hört aber niemand auf die Adresse, so dass das Telegramm in der Linie 1.5 dreimal wiederholt wird. Das passiert dann beim Programmieren oder Geräteinfo bei jedem einzelnen Telegramm so, bis die Telegrammbuffer der IP-Router vollgelaufen sind.

Wenn die Einstellung auf "Filtern" steht, schaut der IP-Router auf die Zieladresse des Telegramms und leitet es nur weiter, wenn nötig.

Unabhängig davon: dein PL und RF-Linien hängen absolut in der Luft. Mit dieser Topologie bräuchte es noch eine TP-Linie 2.0 mit Spannungsversorgung und IP-Router, damit das funktioniert. Oder du machst eine der beiden Linien 1.1/1.5 zur Hauptlinie 1.0 und hängst die PL und RF-Linien da dran.

Ich habe in beiden Routern folgendes geändert:

Routing KNX->IP: Physikalisch adressierte Telegramme: Von "Weiterleiten" auf "Filtern".
Bestätigung (ACK) von p.a.T.: Von "immer" auf "Nur bei Weiterleitung".

Routing IP->KNX: Physikalisch adressierte Telegramme: Von "Weiterleiten" auf "Filtern".

Ergebnis: Keine Änderung, KNX-LED flackert im Normalbetrieb grün, bei Schreibversuchen rot/ grün. Ich habe testweise die Einstellung "Antwort mit NACK" getestet, erwartungsgemäß keine Änderung.

Ich habe dann Stück für Stück die Router "zugemacht":

- Wiederholung Broadcast-Telegrammen ausgeschaltet,
- Bestätigung Gruppentelegramme auf "nur bei Weiterleitung" eingeschränkt,
- die Wiederholung von Gruppentelegrammen ausgeschaltet
- die Gruppentelegramme auf "filtern" eingeschränkt

aber: half leider nicht. Ich habe subjektiv den Eindruck, dass es im Gruppenmonitor nun flotter geht mit den Telegrammen; es bleiben aber viele gelbe dabei und alle Schreibvorgänge oder Entladevorgänge schlagen fehlt. Nur die PA können geändert werden.

Ich kam dann auf die Idee, die Gruppentelegramme von KNX -> IP komplett zu sperren. Und siehe da: Es "hakt" weiterhin; im Gruppenmonitor sieht man unzählige gelbe Diagramme, Connects/ Disconnects aber: Es geht wieder etwas flotter und ich habe tatsächlich erfolgreiche Schreibvorgänge. Dauer > 60 Sekunden, also völlig atypisch, aber: reproduzierbar, funktioniert.

Nur funktioniert die Anlage nach diesen viele Sperren natürlich nicht mehr ;0). Ich bin daher erstmal zurück auf den Initialstand, außer Klaus´ Tipp der Filterung physikalisch adressierter Telegramme (siehe Anhänge). Anlage läuft wieder im Normalbetrieb, aber ich kann nicht programmieren.

Es wirkt so, als ob "unsichtbar für den Gruppenmonitor" andere Telegramme den Bus zumüllen, die Buffer der Router füllen und die dann cutten => das zu programmierende Gerät bricht ab.

[gbglace]

Also als erstes würde ich auch die Topologie gerade ziehen.

Im Screenshot im ersten Beitrag wäre der Bereich 2 mit der RF und der PL Linie quasi nicht verbunden mit dem IP-Bereich und den TP-Linien.

Wenn Du elektrisch aber doch eine Verbindung hergestellt hast sind alle Arten von Kuriositäten erwartbar und können Ursache Deiner Probleme sein.

[Sturmhardt]

Hey zusammen ... DANKE!!!!!!! Ich hatte auf den 2. Tipp von Klaus Gütter bisher nicht reagiert, weil dessen Umsetzung eine Änderung aller PA der Linie 1.1 bedeutet hätte - also > 200 Geräte bei massiv wackeligem Schreibzugriff auf KNX. Das war mir zu heiß. Aber nachdem auch Oezi und gbglace in dieses Horn bliesen, hatte ich die Idee: Ich trenne die Router zu Powernet und RF zum Test physisch; die Segmente funktionieren ja trotzdem erstmal weiterhin.

Und dann Schreibversuch via Weinzierl 751 auf Linie 1.1.x und 1.5.x => UND ES FUNKTIONIERT WIEDER!!!!!!!

Verdächtig war schon: Nach dem einfachen Löschen der beiden Linien (natürlich vor Backup gemacht) haben bei den beiden IP-Routern die grünen Haken für "Cfg" gefehlt ... eigentlich unlogisch. Also die beiden Router geflasht ... und erstmals wieder full speed Applikationsdownload auf diversen Aktoren und Sensoren.

Darauf trinke in ein Gläschen und überlege mir, wie ich minimalinvasiv die PN/ RF Linien in den Bereich 1.0 bekomme. Ich möchte nicht > 200 Programmiertaster drücken . Aber erstmal bin ich happy.

DANKE!