Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast

Wer eine KNX-Anlage plant oder betreibt, denkt zuerst an Geräte, Adressen und Funktionen. Was dabei im Hintergrund abläuft, nämlich wie Geräte auf den Bus zugreifen, wie sie sich gegenseitig bestätigen und was passiert, wenn zu viele Telegramme gleichzeitig unterwegs sind, bleibt oft unsichtbar. Genau dieses Unsichtbare entscheidet aber darüber, ob eine Anlage zuverlässig funktioniert oder ob Befehle verloren gehen und Reaktionszeiten steigen.

Dieser achte Teil der Serie «KNX Grundlagen: die Schulungsreihe» erklärt, wie das Buszugriffsverfahren auf KNX TP funktioniert, was ein Telegramm enthält, wie Bestätigung und Wiederholung geregelt sind und wann die Buslast zum Problem wird. Wir zeigen auch, mit welchen Werkzeugen man die Situation sichtbar macht und was sich dagegen tun lässt.

Wie KNX TP den Buszugriff regelt

KNX TP überträgt Daten mit 9600 bit/s. Das ist eine feste, vergleichsweise niedrige Übertragungsrate, die sich aus den Anforderungen an Leitungslänge, Störfestigkeit und Einfachheit der Verkabelung ergibt. Auf dieser gemeinsamen Leitung können viele Geräte gleichzeitig senden wollen. Damit das geordnet abläuft, verwendet KNX das Verfahren CSMA/CA, was für Carrier Sense Multiple Access with Collision Avoidance steht.

Das Prinzip: Bevor ein Gerät sendet, hört es zunächst, ob der Bus frei ist. Ist er belegt, wartet das Gerät. Ist er frei, beginnt es mit der Übertragung. Trotzdem kann es vorkommen, dass zwei Geräte fast gleichzeitig mit dem Senden beginnen. In diesem Fall löst das Buszugriffsverfahren den Konflikt durch bitweise Arbitrierung: Jedes Gerät vergleicht während der Übertragung der Prioritätsbits, was es selbst sendet, mit dem, was es auf dem Bus sieht. Das Gerät mit der niedrigeren Priorität erkennt den Konflikt und zieht sich zurück. Es wartet und versucht es später erneut. Das Gerät mit der höheren Priorität sendet weiter, ohne es zu merken.

KNX kennt vier Prioritätsstufen: System, Alarm, Hoch und Normal. Die meisten Geräte senden mit normaler Priorität. Sicherheitsrelevante Funktionen wie Rauchmelder oder Notlicht können mit höherer Priorität konfiguriert werden, damit ihre Telegramme bevorzugt übertragen werden.

Dieses Verfahren funktioniert gut, solange die Buslast im normalen Bereich bleibt. Wenn viele Geräte gleichzeitig senden wollen, steigt die Wartezeit, und die Reaktionszeiten der Anlage werden spürbar länger.

Was ein KNX-Telegramm enthält

Ein KNX-Telegramm ist eine strukturierte Nachricht, die alle Informationen enthält, die für die Übertragung und Verarbeitung nötig sind. Für das Verständnis der Buslast ist es hilfreich, die wichtigsten Bestandteile zu kennen.

Am Anfang steht ein Steuerfeld, das unter anderem die Priorität und Wiederholungsinformation enthält. Es folgen die Quelladresse, also die physikalische Adresse des sendenden Geräts, und die Zieladresse. Die Zieladresse ist entweder eine Gruppenadresse für Gruppentelegrammkommunikation oder eine physikalische Adresse für direkte Kommunikation, etwa bei der Inbetriebnahme. Ein Längenfeld gibt an, wie viele Nutzdatenbytes folgen. Die eigentlichen Nutzdaten enthalten den Datenpunkttyp und den Wert, zum Beispiel ein Schaltbefehl nach DPT 1.001 oder ein Temperaturwert nach DPT 9.001. Am Ende steht eine Prüfsumme, mit der der Empfänger die Integrität des Telegramms überprüft.

Die Länge eines Telegramms hängt vom Datenpunkttyp ab. Ein einfacher Schaltbefehl ist sehr kurz, weil der Wert bereits im Längenfeld kodiert werden kann. Ein Farbwert oder ein Datum braucht mehr Nutzdatenbytes und damit mehr Übertragungszeit. Auf einem Bus mit 9600 bit/s dauert die Übertragung eines typischen Telegramms einige Millisekunden. Hinzu kommen Pausen zwischen den Telegrammen, die das Verfahren vorschreibt.

Physikalische Adressen folgen dem Schema Bereich.Linie.Teilnehmer, zum Beispiel 1.1.10. Gruppenadressen sind üblicherweise dreistufig aufgebaut, mit Hauptgruppe, Mittelgruppe und Untergruppe. Wie diese Adressen vergeben und strukturiert werden, erklären wir ausführlich in Teil 4 und Teil 5 der Serie «KNX Grundlagen: die Schulungsreihe», nämlich in «Physikalische Adressen: Jeder Teilnehmer hat seinen Platz» und «Gruppenadressen: So sprechen KNX-Geräte miteinander».

Bestätigung und Wiederholung

Jedes KNX-Telegramm wird vom Empfänger quittiert. Das ist ein wesentlicher Unterschied zu Protokollen, die ohne Bestätigung arbeiten. Nach dem Empfang eines Telegramms sendet der Empfänger eine kurze Quittung auf den Bus. Diese Quittung kann drei Zustände haben: ACK bedeutet, das Telegramm wurde korrekt empfangen und akzeptiert. NAK bedeutet, das Telegramm wurde empfangen, aber der Empfänger konnte es nicht verarbeiten, zum Beispiel wegen eines Fehlers in der Prüfsumme. BUSY bedeutet, der Empfänger ist gerade beschäftigt und kann das Telegramm im Moment nicht entgegennehmen.

Erhält der Sender keine ACK-Quittung, wiederholt er das Telegramm. KNX sieht bis zu drei Wiederholungsversuche vor. Erst wenn nach allen Versuchen keine positive Quittung eingegangen ist, gibt der Sender auf. In der ETS und im Busmonitor ist das Wiederholungsflag im Steuerfeld sichtbar, was bei der Fehlersuche ein wichtiger Hinweis ist.

Wiederholungen sind ein normaler Teil des Protokolls und kein Zeichen für eine defekte Anlage. Wenn Wiederholungen aber häufig auftreten, deutet das auf ein Problem hin: ein Gerät mit schlechter Busankopplung, eine zu lange Leitung, eine Spannungsversorgung am Limit oder eine zu hohe Buslast, die dazu führt, dass Empfänger regelmässig BUSY melden.

Wichtig zu verstehen ist, dass die Quittung auf der physikalischen Ebene stattfindet, also zwischen Sender und Empfänger auf dem Liniensegment. Koppler leiten Telegramme weiter, quittieren aber auf ihrer Seite selbst. Das bedeutet: Ein Sender auf Linie 1.1 erhält die Quittung vom Koppler, nicht vom eigentlichen Empfänger auf Linie 1.2. Ob das Telegramm auf der anderen Seite des Kopplers tatsächlich ankam, ist für den ursprünglichen Sender nicht direkt sichtbar.

Filtertabellen der Koppler

Koppler verbinden Liniensegmente, Linien und Bereiche miteinander. Sie leiten aber nicht einfach alle Telegramme weiter. Stattdessen enthalten sie Filtertabellen, die festlegen, welche Gruppenadressen von einer Seite auf die andere weitergeleitet werden.

Diese Filtertabellen werden von der ETS automatisch berechnet und in die Koppler geladen. Sie basieren auf den Gruppenadressen, die in der Anlage verwendet werden, und auf den Geräten, die auf welcher Linie sitzen. Wenn ein Gerät auf Linie 1.1 eine Gruppenadresse sendet, die nur von Geräten auf derselben Linie empfangen werden soll, dann blockiert der Linienkoppler dieses Telegramm und leitet es nicht auf den Bereichsbus weiter. Das entlastet alle anderen Linien.

Filtertabellen sind ein zentrales Werkzeug zur Kontrolle der Buslast. Eine schlecht konfigurierte oder veraltete Filtertabelle kann dazu führen, dass Telegramme auf Linien weitergeleitet werden, auf denen keine Empfänger vorhanden sind. Das erzeugt unnötige Last, ohne dass ein Gerät davon profitiert. Umgekehrt kann eine fehlerhafte Filtertabelle dazu führen, dass Telegramme nicht weitergeleitet werden, obwohl Empfänger auf der anderen Seite des Kopplers vorhanden sind. Dann funktionieren Funktionen scheinbar willkürlich.

In der Praxis sehen wir Filtertabellen als häufige Fehlerquelle, besonders wenn Geräte nachträglich verschoben, Gruppenadressen geändert oder neue Linien hinzugefügt wurden, ohne die Koppler neu zu programmieren. Die Lösung ist einfach: Die ETS neu berechnen lassen und die Koppler aktualisieren. Aber dafür muss man wissen, dass das Problem dort liegt.

Buslast: Wann wird es eng?

Die Buslast beschreibt, wie stark der Bus ausgelastet ist. Sie ergibt sich aus der Anzahl der Telegramme pro Zeiteinheit und ihrer jeweiligen Länge. Auf einem KNX TP-Liniensegment mit 9600 bit/s ist die verfügbare Kapazität begrenzt. In der Praxis können je nach Telegrammlänge und Pausen zwischen den Telegrammen einige Dutzend Telegramme pro Sekunde übertragen werden.

Die KNX Association gibt in ihren Schulungsunterlagen Richtwerte zur Buslast an. Als Faustregel gilt, dass eine Buslast von mehr als etwa 40 bis 50 Prozent der theoretischen Kapazität auf einem Liniensegment kritisch werden kann, weil Wartezeiten und Kollisionen zunehmen. Wir nennen hier bewusst keine exakten Zahlen aus eigener Berechnung, weil die tatsächliche Grenze von der Telegrammstruktur, den Prioritäten und der Verteilung der Geräte abhängt. Massgebend sind die Angaben der KNX Association und die Norm ISO/IEC 14543-3.

Was die Buslast in der Praxis treibt, sind vor allem zwei Muster. Das erste ist zyklisches Senden: Geräte, die regelmässig ihren Zustand auf den Bus schreiben, auch wenn sich nichts geändert hat. Viele Geräte erlauben es, einen Sendezyklus zu konfigurieren, zum Beispiel alle 30 Sekunden. Das ist sinnvoll für Überwachungsfunktionen, aber wenn viele Geräte kurze Zyklen haben, summiert sich die Last schnell. Das zweite Muster sind fehlende oder falsche Filtertabellen, die dazu führen, dass Telegramme auf Linien weitergeleitet werden, auf denen sie nichts zu suchen haben.

Weitere Quellen unnötiger Last sind Geräte, die bei Initialisierung alle ihre Kommunikationsobjekte lesen, Geräte mit aktiviertem Lesen-Flag auf Objekten, die häufig abgefragt werden, und Szenen oder Zentralbefehle, die viele Telegramme auf einmal auslösen. Kommunikationsobjekte und ihre Flags sind Thema von Teil 6 der Serie «KNX Grundlagen: die Schulungsreihe», «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?».

Buslast sichtbar machen mit dem Busmonitor

Der Busmonitor ist das wichtigste Werkzeug, um die Kommunikation auf dem KNX-Bus zu beobachten. Er zeichnet alle Telegramme auf, die auf dem Bus übertragen werden, mit Zeitstempel, Quelladresse, Zieladresse, Datenpunkttyp und Wert. Damit lässt sich die Buslast direkt messen: Wie viele Telegramme pro Sekunde werden übertragen? Welche Geräte senden am häufigsten? Gibt es viele Wiederholungen?

Die ETS enthält einen integrierten Busmonitor. Daneben gibt es spezialisierte Werkzeuge, die eine komfortablere Auswertung ermöglichen, zum Beispiel Filterung nach Adressen, Darstellung der Telegrammrate über die Zeit oder automatische Erkennung von Wiederholungen.

In der Praxis empfehlen wir, den Busmonitor bei der Inbetriebnahme und bei der Abnahme einzusetzen, um eine Basismessung zu haben. Wenn später Probleme auftreten, hat man einen Vergleichswert. Wir setzen den Busmonitor auch gezielt ein, wenn Anwender über langsame Reaktionen oder sporadisch nicht ausgeführte Befehle klagen. Sehr oft findet sich dabei ein Gerät, das in einem kurzen Zyklus sendet und den Bus unnötig belastet, oder ein Koppler mit veralteter Filtertabelle, der Telegramme auf Linien weiterleitet, auf denen keine Empfänger vorhanden sind.

Wie man den Busmonitor bei der Fehlersuche systematisch einsetzt, beschreiben wir ausführlich in Teil 2 der Serie «KNX in Betrieb und Bestand», «Fehlersuche im KNX-Bestand mit Busmonitor und Telegrammanalyse».

Massnahmen gegen hohe Buslast

Wenn die Buslast zu hoch ist, gibt es mehrere Ansätze. Der erste und wirksamste ist die Überprüfung der Sendezyklen. Jedes Gerät, das zyklisch sendet, sollte daraufhin geprüft werden, ob der Zyklus wirklich nötig ist und ob er nicht verlängert werden kann. Viele Geräte senden standardmässig alle 30 oder 60 Sekunden, obwohl die Funktion nur eine Änderungsmeldung braucht. Das Umstellen auf ereignisgesteuertes Senden, also nur bei Änderung, reduziert die Last erheblich.

Der zweite Ansatz ist die Überprüfung und Aktualisierung der Filtertabellen. Wenn Koppler Telegramme weiterleiten, die auf der Zielseite keine Empfänger haben, ist das reine Verschwendung. Die ETS berechnet die Filtertabellen korrekt, wenn das Projekt vollständig und aktuell ist. Veraltete Projekte führen zu veralteten Filtertabellen.

Der dritte Ansatz ist die topologische Entlastung. Wenn eine Linie dauerhaft überlastet ist, weil zu viele Geräte mit hoher Sendefrequenz auf ihr sitzen, kann es sinnvoll sein, die Linie aufzuteilen. Durch das Einfügen eines Linienverstärkers entstehen zwei Segmente, die jeweils ihre eigene Kapazität haben. Alternativ können Geräte auf andere Linien verschoben werden, was aber eine Umprogrammierung der physikalischen Adressen erfordert.

Ein vierter Ansatz, der oft unterschätzt wird, ist die Überprüfung der Initialisierungsverhalten. Wenn viele Geräte beim Einschalten alle ihre Kommunikationsobjekte lesen, entsteht kurz nach einem Netzausfall eine Spitzenlast, die den Bus für einige Sekunden blockieren kann. Das Lesen-bei-Initialisierung-Flag sollte nur dort gesetzt sein, wo es wirklich nötig ist.

Zusammenspiel mit Topologie und Kopplern

Buslast und Topologie sind eng miteinander verknüpft. Eine gut geplante Topologie verteilt die Last auf mehrere Linien und nutzt Koppler als natürliche Filter. Eine schlecht geplante Topologie, bei der alle Geräte auf einer einzigen Linie sitzen oder bei der Koppler keine wirksamen Filter haben, konzentriert die Last und macht das System anfällig.

KNX TP erlaubt bis zu 64 Teilnehmer pro Liniensegment, bis zu vier Segmente pro Linie mit Linienverstärkern, bis zu 15 Linien pro Bereich und bis zu 15 Bereiche. Diese Struktur ist nicht nur für die Adressierung gedacht, sondern auch für die Lastverteilung. Wenn jede Linie ihre eigenen Geräte hat und die Koppler nur die Telegramme weiterleiten, die wirklich gebraucht werden, bleibt die Last auf jeder Linie überschaubar.

Der IP-Backbone mit IP-Kopplern erlaubt es, Bereiche über das IP-Netz zu verbinden. Das entlastet den TP-Bus, weil Telegramme zwischen Bereichen über IP übertragen werden und nicht über den TP-Bus. Gleichzeitig bringt das neue Anforderungen an die IP-Infrastruktur und an die Sicherheit. Wie die Topologie sauber aufgebaut wird, ist Thema von Teil 2 der Serie «KNX Grundlagen: die Schulungsreihe», «KNX-Topologie: Liniensegment, Linie, Bereich und Backbone».

Der rote Faden zu unseren Fachbeiträgen

Die Grundlagen der KNX-Kommunikation bauen aufeinander auf. Wer verstehen will, warum Telegramme bestimmte Adressen tragen, findet die Erklärung in Teil 4 der Serie «KNX Grundlagen: die Schulungsreihe», «Physikalische Adressen: Jeder Teilnehmer hat seinen Platz», und in Teil 5, «Gruppenadressen: So sprechen KNX-Geräte miteinander». Wer wissen will, welche Flags steuern, wer sendet und wer zuhört, liest Teil 6, «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?». Und wer verstehen will, warum ein Wert nicht nur eine Zahl ist, findet das in Teil 7, «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht».

Für die praktische Arbeit mit dem Busmonitor und die systematische Fehlersuche empfehlen wir Teil 2 der Serie «KNX in Betrieb und Bestand», «Fehlersuche im KNX-Bestand mit Busmonitor und Telegrammanalyse». Wer eine bestehende Anlage modernisieren will, ohne sie zu ersetzen, findet Orientierung in Teil 3 derselben Serie, «KNX-Bestandsanlagen modernisieren statt ersetzen».

Die ETS-Projektierung, in der Filtertabellen berechnet und Sendezyklen konfiguriert werden, ist Thema von Teil 9 der Serie «KNX Grundlagen: die Schulungsreihe», «ETS-Projektierung Schritt für Schritt».

Fazit

KNX TP ist ein geregeltes, robustes Bussystem. Das Buszugriffsverfahren CSMA/CA sorgt dafür, dass Geräte geordnet auf den Bus zugreifen. Bestätigung und Wiederholung stellen sicher, dass Telegramme ankommen. Filtertabellen in den Kopplern halten die Last auf jeder Linie in Grenzen, wenn sie korrekt konfiguriert sind.

Probleme entstehen nicht durch das Protokoll selbst, sondern durch falsche Konfiguration: zu kurze Sendezyklen, veraltete Filtertabellen und unnötige Initialisierungsabfragen. Diese Probleme sind mit dem Busmonitor sichtbar zu machen und in der ETS zu beheben. Wer die Buslast im Griff hat, hat eine Anlage, die zuverlässig und schnell reagiert, auch wenn sie über Jahre gewachsen ist.

Sie haben Fragen dazu?

Sie beobachten langsame Reaktionen oder sporadische Ausfälle in Ihrer KNX-Anlage und vermuten ein Problem mit der Buslast? Oder Sie planen eine neue Anlage und wollen die Topologie von Anfang an richtig aufbauen? Wir helfen Ihnen weiter. Schreiben Sie uns unter info@wenget.ch oder besuchen Sie wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specifications, insbesondere Teil 3 (Communication), Abschnitte zu CSMA/CA, Telegrammaufbau, Quittierung und Wiederholung; KNX Association, Brüssel (eingetragene Marke: KNX, ETS)
• ISO/IEC 14543-3: Information technology, Home Electronic Systems (HES), Part 3: Communication layers of HES Class 1 (KNX)
• EN 50090: Home and Building Electronic Systems (HBES)
• EN ISO 22510 (KNXnet/IP): Kommunikation über IP-Netzwerke
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Inbetriebnahme, Busmonitor-Analysen und Bestandsanlagen-Beurteilungen