KNX/EIB instabile Kommunikation über Segmentkoppler

[Biks]

Hallo zusammen,

dieses Forum hat mir schon vielfach weitergeholfen, aber jetzt fehlt mir dann doch der richtige Ansatz.
Ich sitze an einem größeren Projekt: mehrere Etagen welche eigene Linien bilden und innerhalb der Linien jeweils eine Segmenterweiterung um alle 110 Geräte pro Etage unterbringen zu können. Im erweiterten Segment (L1/S1) befinden sich einige Präsenzsensoren, die über eine Logik einen Einschaltbefehl geben. Das DALI-Modul befindet sich dagegen im ursprünglichen Segment (L1).

1. Die Lampen schalten nicht wie gewünscht bei einer Bewegung das Licht an. Manchmal schalten sie dann doch zu, aber schalten dann wiederum zu früh ab.
2. Die Fehlersuche ist für mich schwierig, weil ich am Gruppenmonitor keine Rückmeldung sehe, wenn ich GAs lese (oder schreibe), die sich in L1/S1 befinden. Hier beispielhaft die GAs 4/4/5 und 4/5/5:

Screenshot 2026-08-11 155923.png
Ich befinde mich mit meiner ETS in L1 (mittels Weinzierl KNX USB Interface 332), weil ich so die gesamte Linie bespielen kann. Denn von L1/S1 kann ich nicht auf Geräte in L1 zugreifen.
Bei GA, die innerhalb des Segmentes bleiben, funktioniert die DALI-Ansteuerung wie gewünscht.

Was könnte ich noch prüfen oder anders machen, um die beiden oben stehenden Probleme einzugrenzen oder noch besser zu lösen?

Jetzt wird's etwas kompliziert: Kann es sein, dass wenn an einem DALI-Objekt (siehe unten) eine Helligkeits-Vorgabe verknüpft ist (die von einem einzelnen BWM kommt), dass dann der Einschaltbefehl aus der Gruppe nicht wirkt, wenn nicht auch dieser BWM eine Präsenz erkannt hat? Wobei dagegen spricht, dass es beispielsweise in der DALI-Gruppe 2 auch nicht funktioniert, wo nur ein einzelner Sensor abgefragt wird.


Ich hoffe, ihr könnte meinen Gedankengängen folgen. 🙈


Schonmal danke fürs Lesen, wenn ihr bis hierher Viele Grüße!

---

Es folgen nun noch einige Screenshots und Angaben zu dem Projekt:

Topologie:




Ich hoffe die Screenshots sind ausreichend um ein Bild über die Topologie zu bekommen.

---

Als Segmentkoppler nutze ich einen Hager TYFS130 mit deaktivierter sicherer Inbetriebnahme. Die Parametrierung sieht so aus:
1. Weiterleitung: alles gefiltert, nur Broadcast wird ungefiltert weitergeleitet
2. Bestätigung:

3. Wiederholungen: alles wiederholen, Anzahl = 3

Die die Parametrierung sind vollständig geladen, alles grün.

---

Die Präsenzsensoren sind von Steinel, es werden zwei Modelle genutzt (HF 360 und True Presence). Die Logikgatter eines BWMs sehen so aus:

image.png
image.png

Und ein zweiter so:
image.png

---

Die GA 15/0/6 werden beim DALI (Hager TYFS672D) im anderen Segment "abgefragt":

image.png

[Beleuchtfix]

Fang doch erst einmal an und nimm alle Filter raus. Der Busverkehr innerhalb einer Linie sollte eigentlich problemlos zu bewältigen sein. Dann solltest du den kompletten Busverkehr sehen können und dann den Fehler genauer einkreisen können.
Viel Erfolg, Florian

[gbglace]

Topologie:




Ich hoffe die Screenshots sind ausreichend um ein Bild über die Topologie zu bekommen.

Da ist ne diensthabende Lücke...


Also ein Segmentkoppler/Linienverstärker hat ja schonmal keine Filtertabellen, sofern er richtig eingestellt ist.

Wenn im DALI Gateway nix eingestellt ist was irgendwie Treppenlicht usw. als Logik kennt, dann bedeutet ein zu frühes ausschalten durch BWM/PM, dass dieser wohl ein AUS sendet weil er die Bewegung/Anwesenheit nicht mehr erkennt. Wenn das Licht aus geht ohne AUS Telegramm dann stimmen Parameter im DALI GW nicht.

Funktioniert diese Gruppen-Logik mit Ergebnis 15/0/24 bei Auslösung durch 15/0/17? Wenn das die Problemlogik ist, dann ignoriert der PM seine selbst gesendeten Telegramme als Eingangssignal.

Kann es sein, dass wenn an einem DALI-Objekt (siehe unten) eine Helligkeits-Vorgabe verknüpft ist (die von einem einzelnen BWM kommt), dass dann der Einschaltbefehl aus der Gruppe nicht wirkt, wenn nicht auch dieser BWM eine Präsenz erkannt hat?

Wie ich das Vokabular vom Hager mag. Da werden absolute Dimmwerte als Eingang erwartet und keine Helligkeitswerte, das wären bei mir irgendwie LUX nicht %.
Und es wäre sehr von Vorteil wenn die Screenshots KO's mit GA Verknüpfungen es so zeigen, das die Problem-Lichtgruppe gesamthaft dargestellt ist und nicht irgendwelche exemplarisch.

Ansonsten wenn es für den Dimmwert keine Aggregationslogik gibt, dann kommt da natürlich auch nie etwas am DALI-GW an wenn nicht der Melder das sendet der auch die Bewegung erkennt. Ansonsten musst halt eine Logik bauen die die veroderten Präsenzsignale als Auslöser zum senden es Dimmwertes nimmt. Die Frage ist nur wie tickt das DALI GW da, würde das auch funktionieren wenn da nur Dimmwerte ankommen 0-100% oder muss das Ding ein AN/AUS bekommen und wenn AN dann einen Wert x% um die Dimmstufe einzustellen?
letzteres fände ich ja doch irgendwie komisch.

Eine KLR aus BWMs heraus gruppiert kannst eigentlich nur im PM via Master Slave Schaltung machen. Und der Master muss jener sein der am sinnvollsten die notwendige Helligkeit messen kann. Dann spielen die Slave-Melder ihr stupides Präsenzsignal an den Master und der sendet dann einen Soll-Dimmwert x% an das DALI GW. Das sollte dann alles ohne ODER-Logiken gehen.

Und gewöhne Dir gar nicht erst an zu denken/schreiben das da ein Gerät etwas abfragt.

[Klaus Gütter]

Also ein Segmentkoppler/Linienverstärker hat ja schonmal keine Filtertabellen, sofern er richtig eingestellt ist.

Doch, im Gegensatz zum Linienverstärker hat ein Segmentkoppler eine Filtertabelle.

[Beleuchtfix]

Klaus, ich dachte immer, das Segment wäre der Linienabschnitt hinter dem Koppler, nur dass es jetzt auch RF Segmente innerhalb einer TP Linie gibt. Was ist den der genau Unterschied und wann benutzt man einen LV und wann einen Segmentkoppler?
Gruß Florian

[Klaus Gütter]

Hallo Florian, mit der Bedeutung von "Segment" hast du recht.

Aber "Segmentkoppler" ist in AN195 genau definiert und dazu gehört eben eine Filtertabelle.
Bei TP-TP kann der Koppler entweder ein primitiver Linienverstärker (ohne Filter) oder eben ein moderner Segmentkoppler (mit Filter) sein.

Linienverstärker haben in meinen Augen mit den verfügbaren stärkeren Spannungsversorgungen und TP256 kaum noch eine Bedeutung. Und ich habe schon viele Fälle gesehen, wo die fehlende Filterung hohe Buslast und heftige Kommunikationsprobleme verursacht hat.

Ein gewisser Nachteil von Segmentkopplern ist die Notwendigkeit, diesen nach Änderungen an den phys. Adressen im Subsegment neu zu programmieren.

[Biks]

Bisher brauchte ich noch keine Segmentkoppler einsetzen. So wie ich das verstanden habe, wurden die Begriffe Linienverstärker und Segmentkoppler erst neuerlich (ETS 6 ?) ersetzt. Ehrlich gesagt, habe ich mir über den Unterschied keine Gedanken gemacht: Ich brauchte eine Linienverstärkung, habe einen Linienkoppler genommen, der durch die Adresse ungleich 0 zum Segmentkoppler wurde. Sieht so aus, als ob ich mir die Differenzierung nochmal ansehen sollte.

Fang doch erst einmal an und nimm alle Filter raus.

Die Filter auszuschalten habe ich mich noch nicht getraut. Ich habe einige Sensoren mit Licht- und CO2-Werten im Einsatz, die den Bus ganz schön belasten. Aber gut, ich werde das austesten. Filter ein- und auszuschalten ist das kleinere Übel.

Wenn das Licht aus geht ohne AUS Telegramm dann stimmen Parameter im DALI GW nicht.
Funktioniert diese Gruppen-Logik mit Ergebnis 15/0/24 bei Auslösung durch 15/0/17? Wenn das die Problemlogik ist, dann ignoriert der PM seine selbst gesendeten Telegramme als Eingangssignal.

So genau konnte ich das nicht nachvollziehen, weil manche GA keine Rückmeldung über den Gruppenmonitor lieferten.

Eine KLR aus BWMs heraus gruppiert kannst eigentlich nur im PM via Master Slave Schaltung machen.

Guter Einwand mit der Master-Slave-Schaltung! Keine Ahnung, warum ich das am Anfang verworfen hatte.


Damit habe ich erstmal ein paar gute Ansätze bekommen. Ich werde die kommenden zwei Tage an dem Projekt weitermachen und eure Vorschläge umsetzen.

Danke für euer Feedback!!!




PS:

Ein gewisser Nachteil von Segmentkopplern ist die Notwendigkeit, diesen nach Änderungen an den phys. Adressen im Subsegment neu zu programmieren.

Ja, die Nichtbeachtung der SK-Topologie in der ETS und die damit zusammenhängende stete Neuprogrammierung des SK hat mich etwas Lehrgeld gekostet. 🙈

[gbglace]

OK dann Koppler immer = Mit Filtertabelle.

Kann man sich merken.

Aber ja das Konfliktpotential wird größer, wenn jemand einfach dezentral wo im Haus nen Taster oder so ergänzt und man erstmal gar nicht weiß in welchem Segment ist das jetzt.
Und dann nicht nur neue GA Verlinkungen über den Segmentgrenzen hinweg, sondern auch ein anderes Gerät als solches muss der Koppler aktualisiert werden.

Ja echte einzelne Linien mit Multikanal Geräten und an die 100 Geräte, da kann man die Buslast schon hochtreiben. Hat da aber einer sowas wie nen HA usw. Im IP Backbone hat man aber sehr wahrscheinlich dennoch wieder alle Telegramme auf dem Hauptsegment vom Subsegment.

In jedem Segment ein IP Interface wurde seitens KNX funktionieren aber meist wollen die Software KNX-Tools ja meist nur einen Link in TP-Bus.

Da muss man doch genauer hinschauen ob nicht doch eine echte Linie besser ist.

Habe mir da noch nie TP/TP Segmentkoppler angeschaut. Ist das eine neue isolierte Kategorie von Gerät oder soweit zulässig als Parameter in jetzt in einem von drei Funktionsmodi zu betreiben? LK/LV/SK?

[gbglace]

Eine GA liefert eh nix auf dem KNX Bus.

Die GA ist als Inhalt eines Telegramms das was geliefert wird.

Wenn man mit der ETS mit einer GA eine Leseanfrage sendet, dann ist es davon abhängig ob ein KO welches diese GA dran verbunden hat das L und K Flag aktiviert haben und dann diese GA auch die erste am KO verbundene, sprich die sendende GA ist.

Und dann gibt es noch einige Geräte die zwar trotz der Gesetzen Flags nichts senden, wenn sie selbst bisher noch nie einen Wert an dem KO quasi produziert haben den man senden könnte. Gerade bei solchen Logikkanälen kann es sehr gut sein, dass da Leseanfragen bis die einmal vollständig durchgelaufen ist, denn wenn die noch nie an Ihren Eingängen Werte gesehen hat, was soll sie antworten? Weder true noch false ist richtig und null gibt es nicht als Wert im KNX-Telegramm.

Wenn man viel an den Geräten programmiert kann man da auch nicht viel erwarten. Dann musst vorher mal per ETS Telegramme mit den Input-GAs senden.

Erst wenn das erfüllt ist kann man von im Koppler blockierten Telegrammen reden.

Antworten tun dann die erwähnten KOs.

[Biks]

Ist das eine neue isolierte Kategorie von Gerät oder soweit zulässig als Parameter in jetzt in einem von drei Funktionsmodi zu betreiben? LK/LV/SK?

Hilft das bei der Antwort weiter?
image.png

[gbglace]

Ja, die mittlere Info-Box schließt die Funktion LV innerhalb des Stück Plaste aus.

Bleibt dann also nur noch LK und SK über, BK ist ja auch nur ein LK nur eben ein Level Linie höher.


Kann aber ggf bei anderen Herstellern anders sein.

[Klaus Gütter]

[QUOTE=gbglace;n2104161]Hat da aber einer sowas wie nen HA usw. Im IP Backbone hat man aber sehr wahrscheinlich dennoch wieder alle Telegramme auf dem Hauptsegment vom Subsegment./QUOTE]

Das Problem ist eher die umgekehrte Richtung. Ohne Filter landet alles vom Hauptsegment auch in allen Untersegmenten, findet dort keine Abnehmer, produziert Wiederholungen und vollgelaufen Queues im LV.