Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?

Wer in der ETS ein Kommunikationsobjekt öffnet, sieht eine Reihe von Häkchen: K, L, S, Ü, A, I. Diese sechs Flags entscheiden, wie ein KNX-Gerät am Bus reagiert. Sie legen fest, ob ein Objekt überhaupt am Busverkehr teilnimmt, ob es Werte sendet, ob es auf Schreibbefehle reagiert und ob es beim Start des Systems einen Wert anfordert. Wer diese Flags versteht, kann Statusrückmeldungen, Visualisierungen und Gateway-Kopplungen sauber projektieren. Wer sie falsch setzt, baut Fehler ein, die sich erst im Betrieb zeigen und dann schwer zu lokalisieren sind.

Dieser Teil der Serie erklärt die Flags einzeln, zeigt ihr Zusammenspiel und beschreibt die typischen Fehlerbilder, die wir in der Praxis immer wieder antreffen. Wie Gruppenadressen aufgebaut sind und wie Objekte damit verknüpft werden, erklärt Teil 5 der Serie «KNX Grundlagen: die Schulungsreihe» mit dem Titel «Gruppenadressen: So sprechen KNX-Geräte miteinander». Hier bauen wir direkt darauf auf.

Was ein Kommunikationsobjekt ist

Jedes KNX-Gerät stellt eine Anzahl von Kommunikationsobjekten bereit. Ein Taster hat beispielsweise Objekte für die Schalttelegramme seiner Tasten, ein Aktor hat Objekte für die Schaltbefehle und die Statusrückmeldungen seiner Ausgänge, ein Raumthermostat hat Objekte für den Sollwert, den Istwert und den Betriebsmodus.

Ein Kommunikationsobjekt ist der Ankerpunkt, über den ein Gerät mit dem Bus kommuniziert. Es hat einen Datenpunkttyp, der festlegt, welches Format der Wert hat. DPT 1.001 steht für einen einfachen Schaltbefehl, DPT 9.001 für einen Temperaturwert im Gleitkommaformat. Mehr zu den Datenpunkttypen erklärt Teil 7 der Serie «KNX Grundlagen: die Schulungsreihe» mit dem Titel «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht».

Das Kommunikationsobjekt wird in der ETS mit einer oder mehreren Gruppenadressen verknüpft. Über diese Verknüpfung empfängt es Telegramme, die an diese Gruppenadresse gerichtet sind, oder sendet Telegramme mit dieser Gruppenadresse als Ziel. Welche dieser Möglichkeiten tatsächlich aktiv sind, bestimmen die Flags.

Die sechs Flags im Einzelnen

Flag K: Kommunikation

Das Flag K ist die Grundvoraussetzung. Ist es nicht gesetzt, nimmt das Objekt überhaupt nicht am Busverkehr teil. Es sendet keine Telegramme und reagiert auf keine eingehenden Telegramme, auch wenn alle anderen Flags gesetzt sind. In der Praxis ist K fast immer gesetzt. Ausnahmen gibt es bei Objekten, die nur intern im Gerät verwendet werden und bewusst vom Bus abgekoppelt bleiben sollen.

Flag L: Lesen

Das Flag L erlaubt es anderen Busteilnehmern, den aktuellen Wert dieses Objekts per Leseanforderung abzufragen. Ein Gerät, das eine Leseanforderung an eine Gruppenadresse sendet, erhält daraufhin eine Leseantwort von jedem Objekt, das diese Gruppenadresse trägt und das Flag L gesetzt hat.

Typisch ist L bei Statusobjekten: Ein Aktorausgang hat einen Status, den eine Visualisierung beim Start abfragen kann. Ist L nicht gesetzt, bleibt die Leseanforderung ohne Antwort, und die Visualisierung zeigt einen unbekannten Zustand.

Flag S: Schreiben

Das Flag S erlaubt es, den Wert des Objekts durch ein eingehendes Schreibtelegramm zu setzen. Empfänger, die auf Schaltbefehle reagieren sollen, brauchen S. Ein Aktorausgang, der auf einen Schaltbefehl reagieren soll, muss S gesetzt haben. Fehlt S, kommt das Telegramm zwar am Gerät an, wird aber ignoriert.

Flag Ü: Übertragen

Das Flag Ü erlaubt dem Objekt, selbst ein Telegramm auf den Bus zu senden, wenn sich sein Wert ändert. Ein Taster sendet beim Drücken ein Telegramm, weil sein Schaltobjekt das Flag Ü trägt. Ein Aktorausgang, der eine Statusrückmeldung senden soll, braucht ebenfalls Ü, damit er nach einer Schaltung den neuen Zustand auf den Bus schreibt.

Ü ist das Flag, das einen Sender macht. Ohne Ü bleibt ein Objekt passiv und sendet nie von sich aus.

Flag A: Aktualisieren

Das Flag A ist eng mit dem Lesemechanismus verbunden. Ist A gesetzt, aktualisiert das Gerät den internen Wert des Objekts, wenn es eine Leseantwort auf dem Bus empfängt, die zur verknüpften Gruppenadresse gehört. Das klingt zunächst ungewöhnlich, ist aber in bestimmten Konstellationen wichtig.

Ein typischer Anwendungsfall: Zwei Aktoren teilen sich eine Gruppenadresse für den Status. Sendet einer seine Statusrückmeldung, kann der andere seinen internen Wert damit synchronisieren, wenn A gesetzt ist. Auch Gateways und Logikmodule nutzen A, um ihren internen Zustand auf dem aktuellen Stand zu halten, ohne selbst senden zu müssen.

Flag I: Lesen bei Initialisierung

Das Flag I, in manchen ETS-Versionen auch als «Init» bezeichnet, veranlasst das Gerät, beim Start oder nach einem Busspannungsausfall automatisch eine Leseanforderung für dieses Objekt zu senden. Das Gerät fragt damit aktiv nach dem aktuellen Wert, bevor es selbst in den normalen Betrieb übergeht.

I ist besonders wichtig für Geräte, die nach einem Neustart einen definierten Ausgangszustand brauchen. Ein Logikmodul, das mit einem Temperaturwert rechnet, sollte diesen Wert beim Start kennen. Ohne I wartet es, bis der nächste Temperaturwert zyklisch gesendet wird, und arbeitet in der Zwischenzeit mit einem undefinierten oder gespeicherten Wert.

Das Zusammenspiel: Sender, Empfänger und Statusrückmeldung

Die Flags entfalten ihre Wirkung im Zusammenspiel. Ein einfaches Schaltbeispiel zeigt das gut.

Ein Taster hat ein Schaltobjekt mit den Flags K und Ü. Er sendet beim Drücken ein Telegramm mit dem Schaltbefehl. Ein Schaltaktor hat ein Eingangs-Schaltobjekt mit K und S. Er empfängt das Telegramm und schaltet den Ausgang. Soweit ist das die einfachste Konstellation.

Soll der Aktor zusätzlich eine Statusrückmeldung senden, braucht sein Statusobjekt die Flags K und Ü. Damit sendet er nach der Schaltung den neuen Zustand auf den Bus. Eine Visualisierung, die diesen Status empfangen soll, hat ein Objekt mit K und S, damit sie den Wert übernimmt. Will die Visualisierung beim Start den aktuellen Zustand abfragen, braucht ihr Objekt zusätzlich I, und das Statusobjekt des Aktors braucht L, damit es auf die Leseanforderung antwortet.

Diese Kette, Taster sendet, Aktor schaltet und meldet zurück, Visualisierung empfängt und fragt beim Start ab, ist in der Praxis der häufigste Aufbau. Jeder Schritt setzt voraus, dass die Flags auf beiden Seiten korrekt gesetzt sind.

Typische Fehler und ihre Ursachen

Falsch gesetzte Flags sind eine der häufigsten Ursachen für Fehler, die sich erst im Betrieb zeigen. Wir beschreiben die Fehlerbilder, die uns in der Praxis am häufigsten begegnen.

Statusrückmeldung fehlt in der Visualisierung

Die Visualisierung zeigt den Schaltzustand nicht oder zeigt ihn falsch an. Häufige Ursache: Das Statusobjekt des Aktors hat das Flag Ü nicht gesetzt. Der Aktor schaltet, sendet aber keinen Status auf den Bus. Die Visualisierung empfängt nichts und bleibt auf dem letzten bekannten Wert oder zeigt einen Fragezeichen-Zustand.

Eine zweite häufige Ursache: Das Objekt in der Visualisierung hat das Flag S nicht gesetzt. Der Aktor sendet zwar den Status, aber die Visualisierung übernimmt den Wert nicht.

Visualisierung zeigt nach Neustart falschen Zustand

Nach einem Neustart der Visualisierung oder nach einem Busspannungsausfall zeigt die Visualisierung einen falschen oder unbekannten Zustand, obwohl die Anlage korrekt funktioniert. Ursache: Das Objekt in der Visualisierung hat das Flag I nicht gesetzt, oder das Statusobjekt des Aktors hat das Flag L nicht gesetzt. Die Leseanforderung beim Start bleibt ohne Antwort.

Dieser Fehler fällt im normalen Betrieb kaum auf, weil die Visualisierung nach der nächsten Schaltung den richtigen Wert empfängt. Er zeigt sich erst nach einem Neustart, einem Stromausfall oder einer Wartungsunterbrechung.

Gateway überträgt Werte nicht korrekt

Bei Gateways, zum Beispiel zwischen KNX und BACnet oder zwischen KNX und DALI, treten Flag-Fehler besonders häufig auf. Das Gateway hat auf der KNX-Seite eigene Kommunikationsobjekte, und diese müssen korrekt konfiguriert sein.

Ein Gateway, das einen Wert von KNX nach BACnet weiterleiten soll, braucht auf der KNX-Seite ein Objekt mit K und S, damit es den Wert empfängt. Soll es den Wert auch aktiv abfragen können, braucht es zusätzlich L und I. Soll es selbst Werte auf den KNX-Bus schreiben, braucht es Ü.

Fehlt eines dieser Flags, funktioniert die Kopplung nur teilweise. Der häufigste Fehler: Das Gateway empfängt Werte, fragt aber beim Start nicht ab. Nach einem Neustart des Gateways arbeitet es mit veralteten Werten, bis der nächste Telegramm eintrifft.

Mehr zu den Schnittstellen zwischen KNX und anderen Protokollen erklärt die Serie «Schnittstellen rund um KNX», insbesondere «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» (Teil 4 von 6) und «KNX und DALI: Beleuchtung sauber koppeln» (Teil 1 von 6).

Mehrere Sender auf einer Gruppenadresse

Sind mehrere Objekte mit Ü auf derselben Gruppenadresse verknüpft, senden alle, wenn sich ihr Wert ändert. Das ist in manchen Fällen gewollt, zum Beispiel bei Zentralbefehlen. In anderen Fällen führt es zu Konflikten: Zwei Geräte senden unterschiedliche Werte auf dieselbe Adresse, und das empfangende Gerät reagiert auf beide, was zu unerwünschten Schaltfolgen führt.

Dieser Fehler ist schwer zu lokalisieren, weil er im Busmonitor als normale Telegramme erscheint. Erst die Analyse der Absenderadressen zeigt, dass zwei verschiedene Geräte auf derselben Gruppenadresse senden.

Flag K fehlt

Ist das Flag K nicht gesetzt, nimmt das Objekt nicht am Busverkehr teil. Das ist selten ein Versehen bei manuell konfigurierten Objekten, kommt aber vor, wenn Geräteparameter importiert oder kopiert werden und dabei Standardwerte übernommen werden, die für den jeweiligen Einsatz nicht passen.

Flags in der ETS richtig prüfen

Die ETS zeigt die Flags jedes Kommunikationsobjekts in der Objektliste des Geräts. Dort lassen sich die Flags direkt setzen und ändern. Viele Hersteller liefern in ihren Applikationen sinnvolle Standardwerte, aber diese Standardwerte sind nicht immer für jeden Einsatzfall korrekt.

Wir empfehlen, die Flags im Rahmen der Projektierung systematisch zu prüfen, besonders bei Statusobjekten, bei Objekten, die mit Visualisierungen oder Gateways verknüpft sind, und bei Objekten, die beim Start einen definierten Wert brauchen.

Die ETS bietet dafür die Möglichkeit, alle Kommunikationsobjekte eines Projekts in einer Listenansicht zu sehen. So lassen sich Objekte mit unvollständigen Flag-Kombinationen schnell identifizieren. Eine systematische Prüfung vor der Inbetriebnahme spart erheblich Zeit bei der Fehlersuche im Betrieb.

Wie die Inbetriebnahme und Abnahme einer KNX-Anlage strukturiert ablaufen sollte, beschreibt «KNX Inbetriebnahme und Abnahme einer KNX-Anlage» (Teil 1 von 4 der Serie «KNX in Betrieb und Bestand»). Wie man Fehler im Betrieb mit dem Busmonitor lokalisiert, erklärt «Fehlersuche im KNX-Bestand mit Busmonitor und Telegrammanalyse» (Teil 2 von 4 derselben Serie).

Flags und Leseanforderungen beim Start

Das Flag I und das dazugehörige Flag L auf der Gegenseite sind in der Praxis oft unterschätzt. Viele Anlagen funktionieren im normalen Betrieb einwandfrei, zeigen aber nach jedem Neustart oder Busspannungsausfall kurzzeitig falsche Zustände in der Visualisierung.

Das liegt daran, dass die Initialisierungsphase beim Start des Systems einen kurzen Zeitraum dauert. Alle Geräte, die I gesetzt haben, senden gleichzeitig Leseanforderungen. Die antwortenden Geräte müssen diese Anfragen nacheinander beantworten. In grossen Anlagen mit vielen Objekten kann dieser Vorgang mehrere Sekunden dauern.

Wir empfehlen, die Initialisierungsphase bei der Inbetriebnahme bewusst zu testen: Busspannung kurz unterbrechen, dann beobachten, wie schnell die Visualisierung einen konsistenten Zustand zeigt. Dauert das zu lange oder bleiben einzelne Werte dauerhaft unbekannt, liegt meist ein fehlendes L auf der Senderseite vor.

Ein weiterer Punkt: Nicht jedes Objekt braucht I. Zyklisch gesendete Werte, zum Beispiel Temperaturmesswerte, die ohnehin alle paar Minuten gesendet werden, brauchen kein I. Das Flag ist sinnvoll bei Objekten, deren Wert sich selten ändert und die nach einem Neustart sofort bekannt sein müssen, zum Beispiel Betriebsmodi, Sollwerte oder Schaltzustände von Aktoren.

Besonderheiten bei Gateways und Visualisierungen

Gateways und Visualisierungen sind die Stellen, an denen Flag-Fehler die grösste Wirkung haben. Beide Systeme haben eigene Kommunikationsobjekte auf der KNX-Seite, und diese müssen zum jeweiligen Einsatzzweck passen.

Bei Visualisierungen gilt: Objekte, die nur anzeigen, brauchen S, damit sie Werte empfangen. Objekte, die auch steuern sollen, brauchen zusätzlich Ü, damit sie Telegramme senden. Objekte, die beim Start den aktuellen Zustand abfragen sollen, brauchen I.

Bei Gateways ist die Richtung entscheidend. Ein Gateway, das Werte von KNX nach aussen weiterleitet, muss auf der KNX-Seite empfangen, also S setzen. Ein Gateway, das Werte von aussen nach KNX schreibt, muss auf der KNX-Seite senden, also Ü setzen. Viele Gateways müssen in beide Richtungen arbeiten, und dann brauchen sie beides.

Ein häufiger Fehler bei Gateways: Das Gateway ist so konfiguriert, dass es Werte empfängt und weiterleitet, aber beim Start nicht abfragt. Nach einem Neustart des Gateways, zum Beispiel nach einem Firmware-Update oder einem Stromausfall, arbeitet es mit dem letzten gespeicherten Wert oder mit einem Standardwert. Ist I nicht gesetzt, fragt es nicht nach, und der Fehler bleibt unbemerkt, bis der nächste Telegramm eintrifft.

Die Schnittstelle zwischen KNX und anderen Systemen, insbesondere die Verantwortung für die korrekte Konfiguration auf beiden Seiten, ist ein eigenes Thema. Die Serie «Schnittstellen rund um KNX» behandelt das für die wichtigsten Protokolle im Detail.

Flags dokumentieren und übergeben

Die Flag-Konfiguration ist Teil des ETS-Projekts und damit Teil der Anlageunterlagen. Wer das ETS-Projekt sauber führt und übergibt, übergibt damit auch die Flag-Konfiguration. Wer nur die Anlage in Betrieb nimmt, ohne das Projekt zu übergeben, hinterlässt einen blinden Fleck für jeden, der später Änderungen vornehmen muss.

Wir empfehlen, im Rahmen der Projektdokumentation nicht nur die Gruppenadressliste, sondern auch die Kommunikationsobjekte mit ihren Flags zu dokumentieren, zumindest für die Objekte, die mit Visualisierungen, Gateways oder Logikmodulen verknüpft sind. Das erleichtert die Fehlersuche und die Erweiterung der Anlage erheblich.

Warum das ETS-Projekt dem Bauherrn gehört und wie die Übergabe geregelt werden sollte, erklärt «Das ETS-Projekt gehört dem Bauherrn» (Teil 5 von 5 der Serie «KNX richtig planen»).

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel steht im Kontext der Serie «KNX Grundlagen: die Schulungsreihe». Teil 5, «Gruppenadressen: So sprechen KNX-Geräte miteinander», erklärt, wie Gruppenadressen aufgebaut und verknüpft werden. Teil 7, «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht», erklärt, warum der Datenpunkttyp eines Kommunikationsobjekts stimmen muss, damit Werte korrekt interpretiert werden. Teil 8, «Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast», zeigt, wie Telegramme auf dem Bus übertragen und bestätigt werden, was für das Verständnis von Leseanforderungen und Antworten wichtig ist. Teil 9, «ETS-Projektierung Schritt für Schritt», zeigt, wie die Flag-Konfiguration in den Projektierungsablauf eingebettet ist.

Wer Fehler in einer bestehenden Anlage sucht, findet in «Fehlersuche im KNX-Bestand mit Busmonitor und Telegrammanalyse» (Teil 2 von 4 der Serie «KNX in Betrieb und Bestand») praktische Hinweise, wie Flag-Fehler mit dem Busmonitor sichtbar gemacht werden können.

Für Anlagen, die an übergeordnete Systeme angebunden sind, sind die Beiträge der Serie «Schnittstellen rund um KNX» relevant, insbesondere «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» (Teil 4 von 6) und «KNX und DALI: Beleuchtung sauber koppeln» (Teil 1 von 6). Beide behandeln die Flag-Konfiguration auf der KNX-Seite des Gateways als Teil der Schnittstellenplanung.

Fazit

Die sechs Flags eines Kommunikationsobjekts sind keine Nebensache. Sie legen fest, ob ein Objekt am Busverkehr teilnimmt, ob es sendet oder empfängt, ob es auf Leseanforderungen antwortet und ob es beim Start aktiv nach dem aktuellen Zustand fragt. Falsch gesetzte Flags erzeugen Fehler, die im normalen Betrieb oft unsichtbar bleiben und erst nach einem Neustart, einem Stromausfall oder bei der Anbindung einer Visualisierung oder eines Gateways sichtbar werden.

Wer die Flags versteht und systematisch prüft, legt den Grundstein für eine Anlage, die zuverlässig funktioniert, auch nach einem Neustart, auch mit einer Visualisierung und auch mit einem Gateway zu einem anderen System. Die Prüfung der Flags gehört zur Projektierung, nicht zur Fehlersuche.

Sie haben Fragen dazu?

Sie projektieren eine KNX-Anlage und möchten die Flag-Konfiguration systematisch prüfen lassen? Oder Sie haben eine bestehende Anlage, bei der Statusrückmeldungen oder Visualisierungswerte nicht stimmen? Wir unterstützen Sie bei der Analyse und Korrektur. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specifications, Communication System, insbesondere Abschnitte zu Kommunikationsobjekten und Flags (sinngemäss, kein wörtlicher Auszug); KNX Association, Brüssel, www.knx.org
• ETS6-Dokumentation: Beschreibung der Kommunikationsobjekte und Flag-Einstellungen in der Engineering Tool Software; KNX Association, Brüssel
• EN 50090 / ISO/IEC 14543-3: KNX-Systemstandard (Normreihe)
• KNX und ETS sind eingetragene Marken der KNX Association, Brüssel.
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Inbetriebnahme und Fehleranalyse in Zweckbauten und Sanierungsprojekten