Gruppenadressen: So sprechen KNX-Geräte miteinander

Wer KNX zum ersten Mal in der ETS öffnet, stösst schnell auf eine lange Liste von Adressen, die auf den ersten Blick wie eine zweite Geräteverwaltung wirken. Doch Gruppenadressen haben mit der Frage, wo ein Gerät sitzt, nichts zu tun. Sie beschreiben, was ein Gerät tun soll und mit wem es dabei zusammenarbeitet. Diesen Unterschied zu verstehen ist der Schlüssel zu einer KNX-Anlage, die sich im Betrieb noch erklären lässt.

In diesem fünften Teil der Serie «KNX Grundlagen: die Schulungsreihe» erklären wir, wie Gruppenadressen aufgebaut sind, welche Darstellungsformen es gibt und wie man eine Struktur anlegt, die auch nach Jahren noch verständlich ist. Die physikalische Adresse, die jeden Teilnehmer eindeutig im Netz verortet, haben wir in Teil 4 «Physikalische Adressen: Jeder Teilnehmer hat seinen Platz» behandelt. Hier geht es um die logische Ebene.

Was eine Gruppenadresse ist und was sie nicht ist

Eine Gruppenadresse ist eine logische Adresse. Sie verbindet Kommunikationsobjekte verschiedener Geräte miteinander, unabhängig davon, in welcher Linie oder in welchem Bereich diese Geräte installiert sind. Ein Taster in Linie 1.1 kann über eine Gruppenadresse einen Aktor in Linie 1.3 schalten, ohne dass dafür eine direkte Verbindung zwischen den Geräten konfiguriert wird.

Das Prinzip ist einfach: Ein Kommunikationsobjekt sendet ein Telegramm mit einer bestimmten Gruppenadresse auf den Bus. Alle Kommunikationsobjekte, denen dieselbe Gruppenadresse zugewiesen ist und die auf Empfang konfiguriert sind, reagieren darauf. Es gibt also einen Sender und beliebig viele Empfänger. Dieses Modell nennt man Multicast auf Anwendungsebene.

Wichtig ist, was eine Gruppenadresse nicht leistet: Sie enthält keine Information darüber, welches Gerät gesendet hat. Sie beschreibt auch nicht, was das Telegramm bedeutet. Das ist Aufgabe des Datenpunkttyps, den wir in Teil 7 «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht» behandeln. Die Gruppenadresse ist der Kanal, der DPT ist die Sprache.

Wie Gruppenadressen aufgebaut sind

KNX-Gruppenadressen bestehen aus 16 Bit. Wie diese 16 Bit aufgeteilt und dargestellt werden, hängt von der gewählten Darstellungsform ab. Die ETS unterstützt drei Varianten: die zweistufige, die dreistufige und die freie Darstellung.

Dreistufige Darstellung

Die dreistufige Darstellung ist in der Praxis am weitesten verbreitet. Sie teilt die 16 Bit in drei Felder auf:

• Hauptgruppe: 5 Bit, Werte 0 bis 31
• Mittelgruppe: 3 Bit, Werte 0 bis 7
• Untergruppe: 8 Bit, Werte 0 bis 255

Eine typische Adresse sieht so aus: 1/2/10. Das bedeutet Hauptgruppe 1, Mittelgruppe 2, Untergruppe 10. Die drei Felder ergeben zusammen 32 × 8 × 256 = 65 536 mögliche Adressen. In der Praxis wird nie der gesamte Adressraum ausgeschöpft, aber die Struktur erlaubt eine klare Hierarchie.

Die Hauptgruppe steht typischerweise für ein Gewerk oder eine Funktion, zum Beispiel Beleuchtung, Beschattung oder Heizung. Die Mittelgruppe kann einen Bereich oder ein Stockwerk bezeichnen. Die Untergruppe schliesslich benennt die einzelne Funktion oder den Datenpunkt.

Zweistufige Darstellung

Bei der zweistufigen Darstellung werden die 16 Bit in zwei Felder aufgeteilt: eine Hauptgruppe mit 5 Bit (0 bis 31) und eine Untergruppe mit 11 Bit (0 bis 2047). Eine Adresse sieht dann so aus: 1/10. Diese Darstellung ist einfacher, bietet aber weniger Strukturierungsmöglichkeiten. Sie eignet sich für kleinere Anlagen, bei denen eine zweite Hierarchieebene nicht nötig ist.

Freie Darstellung

Die freie Darstellung zeigt die Gruppenadresse als einfache Dezimalzahl zwischen 0 und 65 535. Sie bietet keine Hierarchie und ist für die Projektierung in der Regel ungeeignet. Wir verwenden sie allenfalls zur Diagnose oder wenn ein externes System eine numerische Adresse erwartet.

Warum die dreistufige Struktur die bessere Wahl ist

Aus unserer Erfahrung in der Projektierung und Inbetriebnahme ist die dreistufige Darstellung fast immer die richtige Wahl. Der Grund ist nicht die grössere Anzahl möglicher Adressen, sondern die Möglichkeit, eine lesbare Logik abzubilden.

Eine gut aufgebaute dreistufige Struktur erlaubt es, allein aus der Gruppenadresse zu erkennen, um welches Gewerk, welchen Bereich und welche Funktion es geht. Das ist bei der Inbetriebnahme hilfreich, bei der Fehlersuche entscheidend und bei einer Erweiterung nach Jahren noch nachvollziehbar.

Eine zweistufige Struktur kann bei kleinen Projekten ausreichen, wird aber schnell unübersichtlich, sobald mehrere Gewerke und Stockwerke hinzukommen. Wir empfehlen deshalb, auch bei kleinen Projekten von Anfang an dreistufig zu arbeiten, damit eine spätere Erweiterung keine Umstrukturierung erfordert.

Eine Beispielstruktur für ein Bürogebäude

Um das Prinzip greifbar zu machen, zeigen wir eine vereinfachte Struktur für ein mehrgeschossiges Bürogebäude. Wir verwenden dabei keine Projektnamen oder Kundendaten, sondern ein allgemeines Muster.

Hauptgruppen nach Gewerk:

Mittelgruppen nach Stockwerk oder Zone:

Untergruppen für einzelne Funktionen:

Innerhalb von Hauptgruppe 0 (Beleuchtung Schalten) und Mittelgruppe 1 (1. Obergeschoss) könnten die Untergruppen so aussehen:

• 0/1/1: Büro 101 Licht schalten
• 0/1/2: Büro 102 Licht schalten
• 0/1/10: Korridor OG1 Licht schalten
• 0/1/20: Besprechungsraum OG1 Licht schalten

Diese Struktur lässt sich direkt lesen. Wer im Busmonitor ein Telegramm auf 0/1/10 sieht, weiss sofort: Es geht um Beleuchtung schalten im ersten Obergeschoss, Korridor.

Sender und Empfänger: das Kommunikationsmodell

Das Kommunikationsmodell von KNX ist asymmetrisch. Ein Kommunikationsobjekt kann als Sender konfiguriert sein, als Empfänger oder als beides. In der ETS wird das über die Flags des Kommunikationsobjekts gesteuert. Wir gehen auf Flags im Detail in Teil 6 «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?» ein.

Für das Verständnis der Gruppenadressen ist folgendes wichtig: Einer Gruppenadresse können mehrere Kommunikationsobjekte zugewiesen sein. Typischerweise sendet ein Objekt (zum Beispiel der Taster) und mehrere Objekte empfangen (zum Beispiel mehrere Leuchtenaktoren). Es ist aber auch möglich, dass mehrere Objekte auf dieselbe Adresse senden, zum Beispiel wenn zwei Taster dasselbe Licht schalten sollen.

Dieses Modell hat eine wichtige Konsequenz: Die Gruppenadresse ist der gemeinsame Nenner. Wenn ein Gerät ausgetauscht wird, muss nur sichergestellt werden, dass das neue Gerät dieselbe Gruppenadresse erhält. Die anderen Geräte im selben Verbund müssen nicht angefasst werden.

Statusrückmeldungen und Rücklese-Adressen

In der Praxis arbeiten viele Funktionen mit zwei Gruppenadressen: einer Schaltadresse und einer Statusadresse. Der Taster sendet auf die Schaltadresse, der Aktor schaltet und sendet seinen aktuellen Zustand auf die Statusadresse zurück. Eine Visualisierung oder ein Bedientableau liest die Statusadresse aus.

Dieses Muster ist wichtig, weil es verhindert, dass die Visualisierung einen falschen Zustand anzeigt. Wenn der Aktor aus irgendeinem Grund nicht schaltet, bleibt die Statusadresse auf dem alten Wert und die Visualisierung zeigt das korrekt an.

In unserer Beispielstruktur würden wir die Statusrückmeldungen in einer eigenen Hauptgruppe führen, zum Beispiel Hauptgruppe 6. Die Statusadresse für Büro 101 wäre dann 6/1/1, die Schaltadresse 0/1/1. Diese Trennung macht die Struktur klarer und erleichtert die Fehlersuche erheblich.

Für Dimmbefehle kommt oft eine dritte Adresse hinzu: eine für den Schaltbefehl (ein/aus), eine für den Dimmbefehl (heller/dunkler) und eine für den Helligkeitswert (absoluter Prozentwert). Alle drei Adressen gehören zur selben Funktion und sollten in der Benennung erkennbar zusammengehören.

Namensgebung und Konsistenz

Eine Gruppenadresse ist nur so gut wie ihre Beschriftung in der ETS. Wir haben erlebt, dass Anlagen mit korrekter Verdrahtung und richtiger Adressierung trotzdem schwer zu warten sind, weil die Gruppenadressen Namen wie «GA_001» oder «Licht 1» tragen. Solche Namen sagen nichts über Funktion, Ort oder Gewerk aus.

Eine bewährte Konvention ist die Kombination aus Ort und Funktion: «OG1 Büro 101 Licht schalten» oder «EG Korridor Beschattung Auf». Diese Namen sind länger, aber sie sind selbsterklärend. Wer sechs Monate nach der Inbetriebnahme eine Änderung vornimmt, findet sich sofort zurecht.

Die Namenskonvention und die Planungsvorgaben für Gruppenadressen vertiefen wir in Teil 3 der Serie «KNX richtig planen»: «Gruppenadressen und Namenskonvention als Fundament». Dort geht es um die Vorgaben, die bereits im Lastenheft festgelegt werden sollten, damit alle Beteiligten dieselbe Sprache sprechen.

Häufige Fehler und wie man sie vermeidet

Aus unserer Projekterfahrung sehen wir immer wieder dieselben Muster, die später Probleme verursachen.

Keine Struktur von Anfang an. Wenn Gruppenadressen projektbegleitend vergeben werden, ohne dass eine Struktur definiert ist, entsteht ein Flickenteppich. Neue Gewerke werden irgendwo eingehängt, Statusadressen fehlen oder sind mit Schaltadressen vermischt. Eine spätere Bereinigung ist aufwendig und fehleranfällig.

Zu viele Adressen für eine Funktion. Manchmal werden für eine einfache Schaltfunktion vier oder fünf Adressen angelegt, weil verschiedene Personen unabhängig voneinander Adressen vergeben haben. Das führt zu Redundanzen und macht die Anlage schwer nachvollziehbar.

Fehlende Statusadressen. Wenn eine Visualisierung eingebunden ist, aber keine Statusrückmeldungen projektiert wurden, zeigt die Visualisierung nur den zuletzt gesendeten Befehl, nicht den tatsächlichen Zustand. Das ist besonders bei Beschattungen und Heizungsventilen ein häufiges Problem.

Adressraum nicht reserviert. Wenn alle Untergruppen einer Mittelgruppe von Anfang an belegt sind, ist eine Erweiterung nur möglich, indem man in eine andere Mittelgruppe ausweicht. Das bricht die Logik. Wir empfehlen, den Adressraum bewusst zu planen und Lücken für Erweiterungen zu lassen.

Hauptgruppen nach Gewerk und nach Ort gemischt. Wenn Hauptgruppe 0 «Beleuchtung» bedeutet und Hauptgruppe 1 «Erdgeschoss», ist die Struktur inkonsistent. Man weiss nie, ob man zuerst nach Gewerk oder nach Ort suchen soll. Eine klare Entscheidung zu Beginn verhindert dieses Problem.

Gruppenadressen in der ETS anlegen

In der ETS6 werden Gruppenadressen im Bereich «Gruppenadressen» verwaltet. Man kann dort Ordner anlegen, die den Hauptgruppen und Mittelgruppen entsprechen, und die einzelnen Adressen als Untereinträge führen. Die ETS zeigt dabei immer die vollständige Adresse und den zugewiesenen Namen an.

Kommunikationsobjekte werden per Drag-and-drop oder über das Kontextmenü mit Gruppenadressen verknüpft. Die ETS prüft dabei nicht automatisch, ob die Datenpunkttypen der verknüpften Objekte zueinander passen. Das ist Aufgabe des Projektierenden. Ein Taster mit DPT 1.001 (Schalten) sollte nur mit einem Aktor-Objekt verknüpft werden, das denselben DPT erwartet. Andernfalls kann das Gerät das Telegramm zwar empfangen, aber nicht korrekt interpretieren.

Die ETS bietet auch die Möglichkeit, Gruppenadressen aus einer externen Liste zu importieren. Das ist besonders bei grossen Projekten sinnvoll, wo die Adressstruktur bereits in einem Planungsdokument definiert wurde. So wird sichergestellt, dass die Adressen in der ETS mit den Planungsunterlagen übereinstimmen.

Der rote Faden zu unseren Fachbeiträgen

Dieser Beitrag baut auf Teil 4 der Serie «KNX Grundlagen: die Schulungsreihe» auf: «Physikalische Adressen: Jeder Teilnehmer hat seinen Platz». Dort haben wir erklärt, wie die physikalische Adresse im Format Bereich.Linie.Teilnehmer aufgebaut ist und was sie von der Gruppenadresse unterscheidet.

Im nächsten Schritt geht es in Teil 6 «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?» darum, wie die Kommunikationsobjekte konfiguriert werden und welche Flags bestimmen, ob ein Objekt sendet, empfängt oder beides tut.

Wer die Planungsseite vertiefen möchte, findet in der Serie «KNX richtig planen» weiterführende Inhalte. Teil 3 «Gruppenadressen und Namenskonvention als Fundament» behandelt die Vorgaben, die bereits im Lastenheft verankert werden sollten. Teil 2 «Topologie, Linien und IP-Backbone sauber aufbauen» erklärt, wie die physikalische Struktur mit der logischen Adressierung zusammenspielt.

Für alle, die KNX im Kontext der Gebäudeautomation und Energieeffizienz einordnen möchten, empfehlen wir unsere Beiträge «GA verstehen, Teil 1: Was ist Gebäudeautomation, und was nicht?» sowie «Raumautomation mit KNX nach EN ISO 52120», der als Teil 4 der Serie «KNX in Betrieb und Bestand» erscheint.

Fazit

Gruppenadressen verbinden Funktionen, nicht Geräte. Das ist der zentrale Gedanke, der alles andere erklärt. Ein Taster und ein Aktor kennen sich nicht. Sie teilen sich eine Adresse, und das reicht.

Die dreistufige Darstellung mit Hauptgruppe, Mittelgruppe und Untergruppe ist die Grundlage jeder wartbaren Anlage. Sie erlaubt es, Gewerk, Bereich und Funktion direkt aus der Adresse abzulesen. Eine klare Struktur, konsequente Namensgebung und reservierter Adressraum für Erweiterungen sind keine Kür, sondern Voraussetzung dafür, dass eine KNX-Anlage über ihren gesamten Lebenszyklus beherrschbar bleibt.

Wer diese Grundlage sauber legt, spart bei jeder späteren Inbetriebnahme, Fehlersuche und Erweiterung Zeit. Wer sie vernachlässigt, zahlt den Preis spätestens dann, wenn jemand anderes die Anlage übernimmt und von vorne beginnen muss.

Sie haben Fragen dazu?

Sie planen ein KNX-Projekt und möchten die Gruppenadressstruktur von Anfang an richtig aufbauen? Oder Sie haben eine bestehende Anlage, deren Adressierung Sie bereinigen möchten? Wir unterstützen Sie bei der Planung, Projektierung und Dokumentation. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specifications, Interworking (Grundlagen Gruppenadressen, Kommunikationsmodell, Datenpunkttypen); verfügbar über my.knx.org
• KNX Association: ETS6 Dokumentation und Online-Hilfe; verfügbar über support.knx.org
• EN 50090 / ISO/IEC 14543-3: Home and Building Electronic Systems (HBES); Normgrundlage KNX
• KNX Swiss: Informationen zu KNX in der Schweiz; knx.ch
• KNX® und ETS® sind eingetragene Marken der KNX Association, Brüssel
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Projektierung und Inbetriebnahme