How-To Linienkoppler

[GLT]

Deine Topologie erscheint mir aktuell eher suspekt, aber so ohne weiteres aus der Ferne will ich mich dazu nicht wirklich äußern.

je eine Linie für Sensorik und eine für Aktorik

Sind das wirklich Linien oder Segmente mit Linienverstärker?
Das Gerät sieht gleich aus, hätte allerdings eine andere Funktion.

die automatische Konfiguration der Filtertabellen scheint bisher nicht zuverlässig zu funktionieren, daher steht mindestens der Linienkoppler in der HV an dem der Homeserver hängt auf alles weiterleiten

Für den Homeserver muss man der ETS für die Filtertabellen unter die Arme greifen, indem man eine Dummy-Applikation einsetzt u. darauf verknüpft - schon stimmen die Tabellen.
Natürlich sollte der Rest kein Murks sein.

[Beleuchtfix]

Poste doch mal ein Bild mit der komplett ausgeklappten Topologie, dann kann man dir Tipps geben, wie man es besser machen könnte.
Aber so wie ist es, können die Filtertabellen nicht richtig sein, also alles auf Durchzug damit es geht, ist aber eben nicht die richtige Lösung.
Gruß Florian

[BstefanB]

Danke für die zahreichen Antworten, auch wenn der Thread jetzt etwas driftet...

Wenn Dein ETS Projekt ein physisch am Bus installiertes Gerät nicht enthält, dann wird das auch niemals von der ETS programmiert weder um es besser noch um es schlechter/ leer zu machen.

Tatsächlich doch, wenn im Projekt nur das Gerät mit der korrekten physikalischen Adresse ist, aber mit veralteten oder gar keinen Parametern vorhanden ist, dann schreibt man sich zurück in die Steinzeit, ist mir am Anfang zum Glück nur einmal passiert aber dafür mit einem Dali Controller damit es sich gleich richtig lohnt...
Aber die MDT Dali Controller mit Verschiedenen Applikationsprogrammen sind noch ein ganz anderes Thema...

Ein Bild sagt mehr als tausend Worte, ich hab mal exemplarisch ein Bereich/Geschoss aufgeklappt, Liste ist aber etwas eingedampft wegen der Länge, die anderen Bereiche sehen ähnlich aus.

Topologie	Gebäudeansicht
Topologie.jpg	Gebäudeansicht.jpg

[knxPaul]

Super, das ist sehr aufschlussreich!
Unter "3.2 TP Linie" sitzt auf der PA = 3.2.0 ein LK, wie es sein soll.
Unter "3.1 TP Linie" fehlt dieser LK, er fehlt im Projekt, und wie oben erwähnt fehlt er auch in den Schaltschränken. Jede Linie braucht einen LK, der die Telegramme aus der übergeordenten Linie/Bereich überträgt vergleichbar zu einem Gateway.

Pragmatisch würde ich auf die Teilung in die beiden Linien 3.1 und 3.2 verzichten, wie weiter oben schon empfohlen, und

1. das Projekt exportieren als Archivierung,
2. eine Kopie des Projekts anlegen zur Sicherung,
3. die beiden Linien 3.2 und 3.1 zusammenfassen durch Verschieben aller Komponenten in der ETS.
   * Alle nach 3.1 Verschieben bedeutet, auch den LK zu verschieben, die PA = 3.1.0 dafür ist ja frei;
   * alle nach 3.2 Verschieben bedeutet, 110 PAs zu zu programmieren.
4. Die leere Linie kann in der Topologie gelöscht werden.

EDIT: Vorher bitte die gesamte Topologie überprüfen, denn drei Bereiche mit je einer Linie sind nicht optimal

[Beleuchtfix]

Eigentlich hängen alle Geräte der Linie 3.1 im Bereich 3.0! Und wie die Bereiche untereinander verbunden sind ist auch noch sehr fraglich.
Gruß Florian

[mumpf]

Ich stimme Beleuchtfix zu, es gehört alles auf die 3.0. Da es alles LK sind, werden die über TP verbunden sein (Backbone = TP).

BstefanB: Das driftet nicht wirklich ab, denn die Topologie ist nichts, was man sich in der ETS aussucht. Man modelliert die Verkabelung. Es sollte somit ein Abbild der Realität sein. Ohne diesem Abbild ist die ETS nicht in der Lage, die Filtertabellen der LK korrekt zu beschreiben. Deine anfangs erwähnten Probleme mit den LK sind ein Resultat dieser Fehlmodellierung.

Was mich bei Deiner Topologie noch wundert, ist 1 IP-Bereich. Sollte so nicht gehen... was für Geräte liegen dort?

Gruß, Waldemar

[DerStandart]

Das könnte spannend werden.

[BstefanB]

Ich stimme Beleuchtfix zu, es gehört alles auf die 3.0. Da es alles LK sind, werden die über TP verbunden sein (Backbone = TP).

BstefanB: Das driftet nicht wirklich ab, denn die Topologie ist nichts, was man sich in der ETS aussucht. Man modelliert die Verkabelung. Es sollte somit ein Abbild der Realität sein. Ohne diesem Abbild ist die ETS nicht in der Lage, die Filtertabellen der LK korrekt zu beschreiben. Deine anfangs erwähnten Probleme mit den LK sind ein Resultat dieser Fehlmodellierung.

Was mich bei Deiner Topologie noch wundert, ist 1 IP-Bereich. Sollte so nicht gehen... was für Geräte liegen dort?

Gruß, Waldemar

Die Verkabelung scheint in der geprüften UV Bereich 4 korrekt, Backbone geht zum Main und von Sub dann zur STV und dann weiter zu den Aktoren und weiter hinten zu den Sensoren (andere Linie).
Also sollte ich tatsächlich alles auf eine Linie pro Bereich/Geschoss ordnen 🤬

Ich vermute der Bereich ist fehlerhafter Weise als IP Bereich deklariert, IP ist da nur der KNX/IP Router der die Verbindung zum Homeserver herstellt, Screenshot im Anhang. Ich sehe jetzt schon einige Fragen die dieser Bereich aufwirft. 🙄


Topologie2.jpg

Edit: Tatsächlich scheint die Verkabelung im Bereich 1 erheblich chaotischer, es hängen KNX/IP router und Gira S1 an der Main Seite des LK, könnte ja noch Sinn ergeben, aber ebenso geht die Main Linie weiter zu einigen Aktoren 🤦♂️

[knxPaul]

Ich vermute der Bereich ist fehlerhafter Weise als IP Bereich deklariert...

Nein, nicht zwingend. "1 IP Bereich" kann man so machen: Der KNX/IP Router ist ein Medienkoppler und gleichzeitig Linien-Koppler - er tauscht Telegramme zwischen einer IP-Bereich und einem TP-Bereich aus.

Der vermutete Fehler liegt bei den Grundlagen KNX Topologie : Für jeden Übergang braucht es eine Kopplung!

Die "2 TP Bereich", "3 TP Bereich" und "4 TP Bereich" sind inkonsistent zum "1 IP Bereich". Ich würde sie topologisch unterhalb vom "KNX/IP Router" anordnen, sowohl die Verkabelung als auch die ETS-Topologie, die mit den vergebenen PAs modelliert wird.

Wenn ich das Bild IP-Router als Bereichs- oder Linienkoppler betrachte, wird die momentane Topologie umgebaut werden müssen:

• Der "KNX/IP Router" sollte eine Ebene hochgezogen werden, direkt unter den "1 IP Bereich" und die PA = 1.0.0 bekommen, so dass er als Bereichskoppler arbeitet.
• Alle Geräte, deren PA jetzt mit 1. beginnt (also 1.x.y) sollten in die "Hauptlinie 1" umgezogen werden, also PAs = 1.0.y erhalten.
• Die drei Geschosse, die mit "TP Bereich" bezeichnet sind, müssen über LKs an diese "Hauptlinie 1" angebunden werden.
• Die im "2 TP Bereich" können PAs = 1.2.a bekommen,
• die im "3 TP Bereich" können PAs = 1.3.b bekommen,
• die im "4 TP Bereich" können PAs = 1.4.c bekommen.

Das setzt voraus, dass nicht nur ein LK, sondern alle LKs mit ihrer Main Seite am KNX/IP Router hängen.

[knxPaul]

aber ebenso geht die Main Linie weiter zu einigen Aktoren

Das ist ein bewährtes Vorgehen, wird im Forum so empfohlen und spart einen LK: Das würde ich so lassen: Die genannte Linie sehe ich als "Hauptlinie 1", die wie jede Linie ein KNX-Netzteil benötigt und in der Regel auch als Linie mit Aktoren und Sensoren verwendet wird.
Das Chaos könnte sich so ordnen, dass die Rekonstruktion die logische Topologie viel zu komplex erstellt hat. In der Verdrahtung = Verkabelung scheint es erheblich einfacher umgesetzt worden zu sein.
Vier einfache LK reichen nur für eine Hauptlinie und vier unterlagerte Linien:

• Eine Außenlinie für die Wetterstation
• Drei Geschosse (2 + 3 + 4)

Das vierte Geschoss (1) kommt in die Hauptlinie.

[Beleuchtfix]

Ich kann euch nur empfehlen, kauft euch einen Support ein, allein schon, weil zwischen jedem mangelndem Verständnisbei uns, Nachfragen und Antwort mindestens ein halber Tag liegt.
Wahrscheinlich geht das sogar per Teamviewer. Aber da sind viele Fehler und eben auch bei dir im Verständnis von KNX, dass sich da eine Unterstützung lohnt.
Gruß Florian

[gbglace]

wenn im Projekt nur das Gerät mit der korrekten physikalischen Adresse ist, aber mit veralteten oder gar keinen Parametern vorhanden ist, dann schreibt man sich zurück in die Steinzeit

Ja aber warum drückt man dann überhaupt auf programmieren bei einem solchen Gerät?

Ich vermute der Bereich ist fehlerhafter Weise als IP Bereich deklariert,

Nee das passt schon da der Bereich 1 = Hauptlinie 1.0.x in dem Falle eine IP-Linie ist. Interessant bzw. eigentlich unmöglich ist dann wie die Bereich 3 und 4 in Form der Hauptlinie 3.0.x und 4.0.x sich mit dieser Linie unterhalten wollen können ohne einen IP-Router zu haben. Das ginge nur wenn es je dieser Hauptlinie noch einen weiteren IP-Router geben würde als 3.0.0 bzw. 4.0.0 und diese beiden dann in einen IP-Backbone (Bereichslinie 0.0.x ) routen/koppeln würden.

Insofern alle Fehler die derzeit vorhanden sind entstehen durch den Murks in der Topologie, elektrisch wird das zwar alles noch passend verklemmt sein aber logisch in der Topologie passen die Klemmstellen der grünen Leitung nicht zueinander.

Ich würde da jetzt erstmal gröber anfangen es neu aufzusetzen.

Also eine Gebäude Struktur ohne Räume anlegen und klären welche Häuser/Gebäudeteile (Haus / Garage / Garten usw.) gibt es, wie viele Etagen je Teil gibt es. Dann klären wie sind die "Eigentums"-Verhältnisse. Was davon ist Eigennutzung was ist Gewerbe was ist vermietet was ist Allgemein-Zone.
Entlang dieser "Eigentumszonen" sollten bestenfalls auch Unterverteilungen vorhanden sein und in der logischen Topologie des KNX sollte man sich auch je einer solchen "Eigentumszone" entweder eine Hauptlinie (Bereich) oder eine Linie Anlegen. Aber beachte ein EFH z.B. mit 3 Etagen und 3 Unterverteiler (also eine "Eigentumszone") wird nur in unterschiedliche Linien geteilt, sofern wirklich Engpässe in der Anzahl Geräte je Linie zu erwarten sind (auf ebene Hauptlinie ca. 100-120, auf ebene einzelner Linie 255).

Wenn das geklärt und zugeordnet ist, dann die Topologie passend anlegen. Und dann eben vernünftig alle PA neu bespielen.

Übergeordnete Steuerung (ggf = Linie allgemeine Anlage)
Linie Allgemeine-Anlage (Treppenhaus)
Linie Außenanlagen (WS, BWM an den Fassaden)
Linie Etage/Gewerbeeinheit a)
...
Linie Etage/Gewerbeeinheit n)
Linie Etage/Wohneinheit a)
...
Linie Etage/Wohneinheit n)


Ob dann alles je ein Bereich/Hauptlinie wird oder Alles je eine Linie in einem Bereich, kann man sich relativ beliebig aufteilen. Das hat dann nur Auswirkungen ob hier und da noch ein IP-Router fällig wird und wie neben der grünen KNX-TP-Leitung überhaupt eine LAN-Infrastruktur in dem Objekt realisiert ist.

Ich würde es auch so anlegen das in den Unterverteilern der getrennten "Eigentumszonen", nicht die Koppler selbst enthalten sind, da dies bedeuten würde das die jeweils übergeordnete Linie physisch dort ankommen würde und somit potentiell unberechtigter Zugriff durch fremde auf die Datenströme der anderen ermöglicht wird.

[DirtyHarry]

Ja aber warum drückt man dann überhaupt auf programmieren bei einem solchen Gerät?

Alle geänderten Geräte -> Programmieren -> Öhhh.. Dumm gelaufen.
Mit Sicherheit halt nicht mit Absicht.


Nach meiner Meinung sollte hier erst mal geschaut werden, wie ist genau die komplette Verkabelung und davon eine Skizze machen.
Anhand dieser Skizze können dann auch vernünftige Lösungsvorschläge erarbeitet werden.
Ohne die Skizze können wir lange diskutieren, was wir aus der wirren Programmierung machen, um dann das nächste Problem zu haben: Die Programmierung passt wieder nicht zur vorhanden Verkabelung...

[BstefanB]

Das setzt voraus, dass nicht nur ein LK, sondern alle LKs mit ihrer Main Seite am KNX/IP Router hängen.

Ich vermute das das so ist, ob das Backbone im HAR im Untergeschoss sternförmig zusammenläuft oder von Verteilung zu Verteilung weiß ich noch nicht.

Das ist ein bewährtes Vorgehen, wird im Forum so empfohlen und spart einen LK: Das würde ich so lassen: Die genannte Linie sehe ich als "Hauptlinie 1", die wie jede Linie ein KNX-Netzteil benötigt und in der Regel auch als Linie mit Aktoren und Sensoren verwendet wird.
Das Chaos könnte sich so ordnen, dass die Rekonstruktion die logische Topologie viel zu komplex erstellt hat. In der Verdrahtung = Verkabelung scheint es erheblich einfacher umgesetzt worden zu sein.

OK 👍

Die Rekonstruktion habe ich tatsächlich Geräteweise gemacht, die Topologie bestand schon im Projekt, ich habe nur geprüft welche Geräte im Projekt noch fehlen und habe diese einzeln hinzugefügt und die Parameter ausgelesen, PA's habe ich nicht verändert oder Linien umstrukturiert. Als ich die Rekonstruktion begonnen habe waren bei den meisten Geräten im Projekt kein grünes Häkchen (Adr/Prg/Par/Grp/Cfg), entsprechend nie geschrieben und bei Prüfung auch nur teilweise GA's und Parameter hinterlegt. Diese Liste habe ich im letzten halben Jahr kontinuierlich abgearbeitet um ein kosistentes Projekt zu haben.

Ich denke im ersten Anlauf werde ich wie empfohlen die zwei Linien in den Bereichen zu einer konsolidieren, danach würde ich mir die Backbone Struktur mal ansehen, könnte aber durchaus Herbst oder Winter werden bis ich dazu komme...

Alle geänderten Geräte -> Programmieren -> Öhhh.. Dumm gelaufen.
Mit Sicherheit halt nicht mit Absicht.

Ja es waren auch nur ein oder zwei Geräte, dann war klar das was nicht stimmt, aber ärgerlich war es, und man macht es weil man dem Profi glaubt was er redet wenn er sagt er hat das Projekt portiert.

[Beleuchtfix]

Ich vermute ja, dass die komplette Backboneverbindung über ein grünes Kabel geht, unter Vermeidung von LKs. Ich habe auch einmal eine Anlage gehabt, da hatte der Eli ein großes Ordnungsbedürfnis, 4 Bereiche, 4 Hauptlinien und 5 Linien, verbunden über einen Linienkoppler, der wegen eines defekten Netzteils überbrückt war.
Mach mal Linienscans und achte auf den Routingzähler.
Viel Erfolg Florian