Das Herzstück jeder KNX-Anlage
Wenn Sie einen Lichtschalter drücken und die Deckenleuchte angeht, passiert in einer KNX-Anlage etwas Unsichtbares: Der Taster sendet ein Telegramm auf eine Gruppenadresse. Der Schaltaktor empfängt dieses Telegramm und schaltet den Ausgang. Kein Draht zwischen Taster und Leuchte — nur eine logische Verknüpfung über den Bus.
Gruppenadressen sind das Nervensystem einer KNX-Anlage. Sie definieren, wer mit wem kommuniziert, welche Daten fließen und wie das Gebäude auf Befehle reagiert. Wer Gruppenadressen nicht versteht, kann eine KNX-Anlage nicht programmieren, nicht warten und nicht sinnvoll erweitern.
Dieser Artikel erklärt das Konzept von Grund auf — die dreistufige Struktur, Nomenklatur-Systeme, Datenpunkttypen, Flags und die häufigsten Fehler. Geschrieben aus der Praxis eines KNX Systemintegrators in München, der hunderte von Gruppenadress-Strukturen entworfen hat.
Physische Adressen vs. Gruppenadressen
In KNX gibt es zwei Adress-Typen, die völlig unterschiedliche Zwecke erfüllen:
Physische Adressen
Die physische Adresse identifiziert ein Gerät eindeutig im System. Format: Bereich.Linie.Teilnehmer (z.B. 1.1.15). Sie wird bei der Inbetriebnahme in das Gerät geschrieben und dient der Verwaltung in der ETS.
Physische Adressen spielen im Alltagsbetrieb der Anlage keine Rolle — sie werden nur für Diagnose, Firmware-Updates und die Konfiguration benötigt.
Gruppenadressen
Die Gruppenadresse ist eine logische Verknüpfung. Sie verbindet ein oder mehrere sendende Objekte (z.B. Taster, Sensoren) mit ein oder mehreren empfangenden Objekten (z.B. Aktoren). Format: Hauptgruppe/Mittelgruppe/Untergruppe (z.B. 1/2/3).
Gruppenadressen sind Multicast: Ein Telegramm auf Gruppenadresse 1/2/3 erreicht alle Geräte, deren Kommunikationsobjekte mit dieser Adresse verknüpft sind. Das ermöglicht Szenarien wie: Ein Taster schaltet gleichzeitig Licht, fährt die Jalousie und setzt die Heizung auf Absenkbetrieb — über drei verschiedene Gruppenadressen.
Die dreistufige Gruppenadress-Struktur
Die KNX-Spezifikation erlaubt zwei Formate:
- Zweistufig: Hauptgruppe / Untergruppe (z.B. 1/3)
- Dreistufig: Hauptgruppe / Mittelgruppe / Untergruppe (z.B. 1/2/3)
In der Praxis verwendet jeder professionelle Integrator die dreistufige Struktur. Die zweistufige ist ein Relikt aus den Anfangsjahren von KNX und bietet zu wenig Gliederungstiefe für reale Projekte.
Hauptgruppe (0-31)
Die Hauptgruppe definiert die Funktion. Typische Zuordnung:
| Hauptgruppe | Funktion | Beispiel |
|---|---|---|
| 0 | Zentral / System | Zentralfunktionen, Betriebsarten |
| 1 | Beleuchtung | Schalten, Dimmen, Szenen |
| 2 | Beschattung | Jalousie, Raffstore, Markise |
| 3 | Heizung / Klima | Sollwerte, Ventile, Betriebsarten |
| 4 | Lüftung | Stufen, Bypass, CO₂ |
| 5 | Sicherheit | Fenster, Alarm, Rauchmelder |
| 6 | Energie | Zähler, PV, Wallbox |
| 7 | Multimedia | Multiroom, TV, Szenen |
| 8-9 | Reserve | Für spätere Erweiterungen |
Mittelgruppe (0-7)
Die Mittelgruppe definiert den Ort. Typische Zuordnung:
| Mittelgruppe | Ort |
|---|---|
| 0 | Zentral / alle Räume |
| 1 | Erdgeschoss |
| 2 | Obergeschoss |
| 3 | Dachgeschoss |
| 4 | Keller |
| 5 | Außenbereich |
| 6 | Technikraum |
| 7 | Garage |
Untergruppe (0-255)
Die Untergruppe identifiziert den konkreten Datenpunkt: Welcher Raum, welche Funktion.
Beispiel-Schema für Beleuchtung (Hauptgruppe 1), Erdgeschoss (Mittelgruppe 1):
| Adresse | Beschreibung | DPT |
|---|---|---|
| 1/1/1 | EG Flur — Licht schalten | 1.001 |
| 1/1/2 | EG Flur — Licht Status | 1.001 |
| 1/1/10 | EG Wohnen — Licht schalten | 1.001 |
| 1/1/11 | EG Wohnen — Licht Status | 1.001 |
| 1/1/12 | EG Wohnen — Licht dimmen | 3.007 |
| 1/1/13 | EG Wohnen — Licht Dimmwert | 5.001 |
| 1/1/20 | EG Küche — Licht schalten | 1.001 |
| 1/1/21 | EG Küche — Licht Status | 1.001 |
Beachten Sie die Lücken in der Nummerierung (1→10→20). Das ist kein Zufall — es reserviert Platz für spätere Ergänzungen, ohne die bestehende Struktur umbauen zu müssen.
Bewährte Nomenklatur-Systeme
Es gibt kein offizielles „richtiges" Schema — aber einige Ansätze haben sich in der Praxis durchgesetzt:
System 1: Funktion → Ort → Datenpunkt (empfohlen)
Hauptgruppe = Funktion, Mittelgruppe = Etage/Bereich, Untergruppe = Raum+Datenpunkt.
Das ist das in Deutschland am weitesten verbreitete Schema. Vorteil: Wenn Sie alle Lichtfunktionen sehen wollen, öffnen Sie Hauptgruppe 1 — fertig. Nachteil: Wenn Sie alle Funktionen eines Raumes sehen wollen, müssen Sie durch alle Hauptgruppen scrollen.
System 2: Ort → Funktion → Datenpunkt
Hauptgruppe = Etage, Mittelgruppe = Funktion, Untergruppe = Raum+Datenpunkt.
Vorteil: Raumweise Übersicht. Nachteil: Bei Zentralfunktionen (z.B. „Alles aus") wird es unübersichtlich, weil die Funktion über mehrere Hauptgruppen verteilt ist.
System 3: Rein funktional (für große Projekte)
Hauptgruppe = Gewerk (Elektro, HVAC, Sicherheit), Mittelgruppe = Funktion, Untergruppe = Datenpunkt. Wird bei Gewerbeprojekten mit mehreren Planungsbeteiligten verwendet, weil es sich an der Gewerke-Trennung orientiert.
Meine Empfehlung als Systemintegrator: System 1 für Wohnbauprojekte, System 3 für Gewerbegebäude. System 2 verwende ich nie — die Vorteile sind zu gering, die Nachteile bei Zentralfunktionen zu groß.
Datenpunkttypen (DPT) — das Typsystem von KNX
Jede Gruppenadresse transportiert Daten — aber nicht beliebige. Der Datenpunkttyp (DPT) legt fest, welches Format die Daten haben. Wenn zwei Geräte auf derselben Gruppenadresse unterschiedliche DPTs erwarten, kommunizieren sie aneinander vorbei.
Die wichtigsten Datenpunkttypen
| DPT | Größe | Wertebereich | Verwendung |
|---|---|---|---|
| 1.001 | 1 Bit | 0/1 | Schalten (Ein/Aus) |
| 1.002 | 1 Bit | 0/1 | Boolean (Wahr/Falsch) |
| 1.003 | 1 Bit | 0/1 | Enable/Disable |
| 3.007 | 4 Bit | Richtung + Schritt | Dimmen relativ |
| 5.001 | 8 Bit | 0-100 % | Dimmwert absolut, Jalousieposition |
| 5.010 | 8 Bit | 0-255 | Zählwert ohne Einheit |
| 9.001 | 16 Bit | -273...+670.760 | Temperatur (°C) |
| 9.004 | 16 Bit | 0...670.760 | Beleuchtungsstärke (Lux) |
| 13.001 | 32 Bit | -2.147.483.648...+2.147.483.647 | Zählwert (Wh, Pulse) |
| 14.056 | 32 Bit | Float | Leistung (W) |
| 16.001 | 14 Byte | ASCII-Text | Textnachrichten |
| 17.001 | 8 Bit | 0-63 | Szenen-Nummer |
DPT-Konflikte erkennen
Ein typischer Fehler: Ein Dimmaktor erwartet auf der Gruppenadresse „Helligkeit" den DPT 5.001 (0-100 %), aber ein Taster sendet DPT 3.007 (relatives Dimmen). Das sind zwei verschiedene Datentypen — das Licht reagiert nicht wie erwartet.
In der ETS können Sie den DPT einer Gruppenadresse festlegen. Die Software warnt dann, wenn ein Kommunikationsobjekt mit einem abweichenden DPT verknüpft wird. Diese Warnung niemals ignorieren.
Kommunikationsobjekte und Flags
Jedes KNX-Gerät stellt Kommunikationsobjekte (KO) bereit — das sind die Schnittstellen, über die es mit dem Bus kommuniziert. Ein Schaltaktor hat z.B. ein KO „Schalten" (empfängt Schaltbefehle) und ein KO „Status" (sendet den aktuellen Zustand).
Kommunikationsobjekte werden mit Gruppenadressen verknüpft. Ein KO kann mit mehreren Gruppenadressen verbunden sein — das ermöglicht Szenarien wie: Der Licht-Status wird sowohl an die Visualisierung als auch an den Logikbaustein für die Abwesenheitsszene gesendet.
Die Flags im Detail
| Flag | Kürzel | Bedeutung |
|---|---|---|
| Kommunikation | K | Objekt nimmt am Busverkehr teil. Ohne K passiert gar nichts. |
| Lesen | L | Objekt antwortet auf Lese-Anfragen (GroupValueRead) |
| Schreiben | S | Objekt empfängt Schreibbefehle (GroupValueWrite) |
| Übertragen | Ü | Objekt sendet bei Wertänderung automatisch (GroupValueWrite) |
| Aktualisieren | A | Objekt übernimmt empfangene Werte als eigenen Status |
Typische Flag-Kombinationen
| Objekt-Typ | Flags | Erklärung |
|---|---|---|
| Taster — Schalten | K, Ü | Sendet bei Tastendruck, empfängt nichts |
| Aktor — Schalten | K, S | Empfängt Schaltbefehle |
| Aktor — Status | K, L, Ü | Sendet bei Änderung, antwortet auf Lese-Anfragen |
| Visualisierung — Anzeige | K, S, A | Empfängt Status-Updates, übernimmt Wert |
| Logik — Eingang | K, S | Empfängt Werte als Eingangssignal |
Goldene Regel: Flags nicht manuell ändern, wenn man den Grund nicht genau benennen kann. Die ETS setzt die Flags des Herstellers — und die sind in 95 % der Fälle korrekt.
Zentral- und Statusadressen
Zentraladressen
Eine Zentraladresse ist eine Gruppenadresse, auf die viele Aktoren gleichzeitig hören. Beispiel: 0/0/1 = „Alle Lichter aus". Jeder Schaltaktor im Gebäude ist mit dieser Adresse verknüpft. Ein einziges Telegramm schaltet alles aus.
Typische Zentraladressen:
- 0/0/1 — Alles Licht aus
- 0/0/2 — Alle Jalousien auf
- 0/0/3 — Heizung Absenkbetrieb
- 0/0/10 — Panik (alles Licht an, Jalousien auf)
- 0/0/20 — Abwesenheit (alles aus, Sicherheit aktiv)
Vorsicht: Zentraladressen erzeugen Buslast. Wenn 50 Aktoren gleichzeitig reagieren, dauert das bei KNX-TP (9.600 Bit/s) merklich lang. Bei sehr großen Anlagen (>100 Aktoren pro Zentralbefehl) kann es sinnvoll sein, die Befehle zeitversetzt über einen Logikbaustein auszulösen.
Status-Rückmeldungen
Jeder Aktor sollte seinen Status auf einer separaten Gruppenadresse zurückmelden. Warum separat? Weil die Schaltadresse (Befehl) und der Status (Rückmeldung) zwei verschiedene Dinge sind:
- Schaltadresse 1/1/10: „Wohnzimmer Licht — EIN" (Befehl vom Taster)
- Statusadresse 1/1/11: „Wohnzimmer Licht — Zustand" (Rückmeldung vom Aktor)
Die Statusadresse ist entscheidend für die Visualisierung: Ohne Status weiß das Display nicht, ob das Licht wirklich an ist. Und sie ist entscheidend für Logikbausteine: Ohne Status kann eine Abwesenheitsszene nicht prüfen, ob noch Lichter brennen.
Gruppenadress-Planung in der Praxis
Schritt 1: Funktionen sammeln
Listen Sie alle Funktionen auf, die das Gebäude können soll. Nutzen Sie dafür die Funktionsliste. Beispiel Einfamilienhaus:
- 17 Lichtkreise (davon 8 dimmbar)
- 12 Jalousien
- 9 Heizkreise (Einzelraumregelung)
- 4 Lüftungsstufen (zentral)
- Präsenzmelder Flur, Bad, Garage
- Szenen: Ankommen, Gehen, Nacht, Kino
Schritt 2: Schema festlegen
Wählen Sie das Nomenklatur-System (ich empfehle System 1: Funktion→Ort→Datenpunkt). Definieren Sie die Hauptgruppen und Mittelgruppen.
Schritt 3: Untergruppen systematisch vergeben
Mein bewährtes Schema für die Untergruppen:
- 1-9: Flur/Diele
- 10-19: Wohnzimmer
- 20-29: Küche
- 30-39: Esszimmer
- 40-49: Schlafzimmer
- 50-59: Bad
- 60-69: Kinderzimmer 1
- 70-79: Kinderzimmer 2
- 80-89: Arbeitszimmer
- 200-209: Außenbereich
- 250-255: Zentralfunktionen
Innerhalb eines Raums vergebe ich die Untergruppen paarweise: gerade Nummer = Befehl, ungerade Nummer = Status. Also 10 = Wohnzimmer Licht schalten, 11 = Wohnzimmer Licht Status.
Schritt 4: Dokumentieren
Eine Excel-Tabelle oder die ETS-eigene Dokumentationsfunktion. Jede Gruppenadresse mit:
- Adresse (z.B. 1/1/10)
- Beschreibung (z.B. EG Wohnzimmer — Licht schalten)
- DPT (z.B. 1.001)
- Sendende Geräte (z.B. Taster Wohnzimmer links)
- Empfangende Geräte (z.B. Schaltaktor Ch. 3)
Diese Dokumentation ist überlebenswichtig. Ohne sie wird jede spätere Wartung zum Blindflug.
Die 7 häufigsten Fehler bei Gruppenadressen
- Keine Struktur: Gruppenadressen „wie sie kommen" vergeben, ohne System. Ab 50 Adressen unbeherrschbar.
- Status fehlt: Keine separaten Statusadressen. Visualisierung und Logik funktionieren nicht zuverlässig.
- DPT-Mix: Verschiedene Datentypen auf derselben Gruppenadresse. Geräte interpretieren Telegramme falsch.
- Keine Lücken: Fortlaufend nummeriert (1, 2, 3...). Bei der ersten Erweiterung muss alles umgebaut werden.
- Zu viele Verknüpfungen: Ein Aktor auf 20 Gruppenadressen. Buslast steigt, Übersicht sinkt.
- Zentraladressen vergessen: Keine „Alles aus"- oder Szenenfunktion eingeplant. Nachrüsten ist aufwändig.
- Keine Dokumentation: Gruppenadressen existieren nur in der ETS-Datei. Wenn die verloren geht, muss die Anlage rekonstruiert werden.
Erweiterte Konzepte
Szenen über Gruppenadressen
KNX-Szenen nutzen den DPT 17.001 (Szenen-Nummer). Ein Taster sendet z.B. „Szene 5 aufrufen" auf eine Szenen-Gruppenadresse. Jeder beteiligte Aktor speichert intern, was er bei Szene 5 tun soll (Licht 40 %, Jalousie 60 % zu etc.).
Die Alternative: Logikbausteine, die bei einem Trigger mehrere Einzelbefehle senden. Vorteil: Mehr Flexibilität. Nachteil: Mehr Buslast, mehr Konfigurationsaufwand.
Multicast-Telegramme und Buslast
Jedes Telegramm auf dem KNX-TP-Bus belegt den Bus für ca. 25 ms (bei 1 Bit Nutzdaten). Bei 1 Linie mit 64 Geräten und normaler Nutzung liegt die Buslast unter 5 %. Problematisch wird es bei:
- Zyklischen Sendern (Wetterstation alle 2 Sekunden, Energiezähler jede Sekunde)
- Vielen Präsenzmeldern mit kurzen Intervallen
- Zentralbefehlen an sehr viele Aktoren gleichzeitig
ETS6 zeigt die theoretische Buslast pro Linie an. Über 30 % sollte man die Topologie überdenken — z.B. Geräte auf eine zweite Linie verteilen.
Häufige Fragen zu KNX Gruppenadressen
Wie viele Gruppenadressen hat ein typisches Einfamilienhaus?
Ein gut ausgestattetes Einfamilienhaus hat zwischen 200 und 500 Gruppenadressen. Das klingt viel, aber mit einer sauberen Struktur bleibt es übersichtlich. Ein Gewerbeprojekt kann leicht 2.000+ Adressen haben.
Kann ich Gruppenadressen nachträglich ändern?
Ja, aber nur in der ETS. Sie müssen die Verknüpfungen ändern und die betroffenen Geräte neu programmieren (Download). Bei einer durchdachten Planung ist das selten nötig.
Was passiert, wenn zwei Geräte auf dieselbe Adresse senden?
Beide Telegramme werden gesendet. Wenn sie gleichzeitig auftreten, gibt es eine Buskollision — KNX löst das über ein Prioritäts- und Wiederholungsverfahren (CSMA/CA). In der Praxis funktioniert das zuverlässig, solange die Buslast nicht zu hoch ist.
Brauche ich für jede Funktion eine eigene Gruppenadresse?
Ja. Schalten, Dimmen, Status — das sind drei verschiedene Gruppenadressen für eine Leuchte. Das ist beabsichtigt: Die Trennung ermöglicht flexible Verknüpfungen.
Eine durchdachte Gruppenadress-Struktur ist die Basis jeder wartbaren KNX-Anlage. Ich entwerfe Ihre KNX-Programmierung so, dass Erweiterungen jederzeit möglich bleiben. Lassen Sie uns Ihr Projekt besprechen.