Gruppenadressen und Namenskonvention als Fundament

Wer eine KNX-Anlage plant, denkt zuerst an Topologie, Linien und Geräte. Die Gruppenadressstruktur kommt oft erst später, manchmal erst in der Inbetriebnahme. Das ist ein Fehler, der sich durch den gesamten Lebenszyklus zieht. Denn die Gruppenadressstruktur ist nicht nur eine technische Hilfsgrösse. Sie ist das Ordnungssystem, das bestimmt, wie gut eine Anlage betrieben, erweitert und an übergeordnete Systeme angebunden werden kann.

Dieser dritte Teil der Serie «KNX richtig planen» zeigt, warum die Gruppenadress- und Namensstruktur bereits im Pflichtenheft festgelegt sein muss, wie eine praxistaugliche Struktur aufgebaut wird und warum sie die Voraussetzung für jede spätere Schnittstelle zu BACnet, DALI oder MQTT ist. Die technischen Grundlagen der Gruppenadressen, also wie sie aufgebaut sind und wie Kommunikationsobjekte damit verknüpft werden, erklärt Teil 5 der Serie «KNX Grundlagen: die Schulungsreihe» unter dem Titel «Gruppenadressen: So sprechen KNX-Geräte miteinander».

Was eine Gruppenadresse wirklich ist

Eine Gruppenadresse verbindet Kommunikationsobjekte verschiedener Geräte miteinander. Ein Taster sendet auf eine Gruppenadresse, ein Aktor empfängt auf dieselbe Adresse und schaltet. So weit ist das bekannt. Was dabei leicht übersehen wird: Die Gruppenadresse ist gleichzeitig ein Datenpunkt. Sie hat einen Namen, einen Datenpunkttyp und eine Bedeutung im Kontext des Gebäudes.

In der Praxis sehen wir KNX-Projekte, in denen Gruppenadressen nach dem Prinzip «nächste freie Adresse» vergeben wurden. Die Namen lauten dann «GA 1», «Licht 3» oder «Test». Solche Strukturen funktionieren, solange die Person, die sie angelegt hat, noch im Projekt ist. Sobald jemand anderes die Anlage übernimmt, einen Fehler sucht oder eine Schnittstelle aufbauen will, beginnt die eigentliche Arbeit erst. Jede Adresse muss einzeln nachvollzogen werden, weil die Struktur keine Information trägt.

Eine durchdachte Gruppenadressstruktur macht genau das überflüssig. Sie trägt die Information direkt im Namen und in der Anordnung. Wer die Struktur kennt, kann eine beliebige Gruppenadresse lesen und sofort verstehen, welches Gewerk, welchen Bereich und welche Funktion sie betrifft. Das ist kein Komfort, das ist eine Betriebsvoraussetzung.

Die dreistufige Struktur als Standard

KNX erlaubt Gruppenadressen in verschiedenen Formaten. Am verbreitetsten ist die dreistufige Struktur mit Hauptgruppe, Mittelgruppe und Untergruppe. Die Hauptgruppe hat 5 Bit (Werte 0 bis 31), die Mittelgruppe 3 Bit (0 bis 7) und die Untergruppe 8 Bit (0 bis 255). Das ergibt insgesamt 65'536 mögliche Adressen, was für praktisch jedes Projekt mehr als ausreicht.

Die dreistufige Struktur bietet sich an, weil sie drei Ordnungsebenen abbildet. In unserer Projekterfahrung hat sich eine Gliederung nach Gewerk, Geschoss und Funktion bewährt. Die Hauptgruppe bezeichnet das Gewerk, die Mittelgruppe das Geschoss oder den Bereich, die Untergruppe die konkrete Funktion oder den Datenpunkt.

Ein Beispiel: Hauptgruppe 1 steht für Beleuchtung, Mittelgruppe 2 für das zweite Obergeschoss, Untergruppe 10 für den Schaltbefehl der Leuchtengruppe A im Korridor. Die Adresse 1/2/10 ist damit eindeutig lesbar, ohne dass man das ETS-Projekt öffnen muss. Wer die Konvention kennt, weiss sofort, worum es geht.

Wichtig ist, dass die Zuordnung der Hauptgruppen zu Beginn des Projekts festgelegt und dokumentiert wird. Typische Hauptgruppen in Zweckbauten sind Beleuchtung, Beschattung, Heizung und Kühlung, Lüftung, Zugangskontrolle und Energiemessung. Wie viele Hauptgruppen belegt werden, hängt vom Projekt ab. Entscheidend ist, dass die Belegung einheitlich ist und nicht projektweise variiert.

Namen als Datenpunktliste

Die Gruppenadresse allein reicht nicht. Erst der Name macht sie nutzbar. In der ETS kann jede Gruppenadresse einen Namen und eine Beschreibung erhalten. Diese Felder sind kein optionales Kommentarfeld, sie sind die Datenpunktliste der KNX-Anlage.

In der Gebäudeautomation nach SWKI BA101-01 ist die Datenpunktbezeichnung eine Planungsleistung. Jeder Datenpunkt hat einen eindeutigen Namen, der Anlage, Funktion und Signalart beschreibt. Das gleiche Prinzip gilt für KNX-Gruppenadressen. Der Name einer Gruppenadresse sollte dieselbe Information tragen: Gewerk, Bereich, Funktion und Signalart.

Eine bewährte Namenskonvention folgt dem Muster: Gewerk.Bereich.Funktion.Signalart. Beispiele aus der Praxis sind «BEL.OG2.KOR-A.Schalten», «BEL.OG2.KOR-A.Status» oder «HZG.UG.HK1.Sollwert». Diese Namen sind sprechend, sortierbar und maschinenlesbar. Sie lassen sich direkt in eine Datenpunktliste exportieren und als Grundlage für Gateways und Schnittstellen verwenden.

Die Konsistenz der Namenskonvention ist dabei genauso wichtig wie die Struktur selbst. Wenn in einem Projekt mal «Schalten», mal «EIN-AUS», mal «SW» für denselben Signaltyp verwendet wird, verliert die Konvention ihren Wert. Deshalb gehört die Namenskonvention in das Pflichtenheft, nicht in die Köpfe der Inbetriebnahmetechniker.

Datenpunkttypen konsequent zuweisen

Jede Gruppenadresse hat in der ETS einen Datenpunkttyp (DPT). Der DPT legt fest, wie der Wert kodiert ist und was er bedeutet. DPT 1.001 steht für einen Schaltbefehl (Ein/Aus), DPT 5.001 für einen Prozentwert (0 bis 100 %), DPT 9.001 für eine Temperatur in Grad Celsius. Diese Zuordnung ist nicht optional, sie ist die Voraussetzung dafür, dass Gateways und übergeordnete Systeme die Werte korrekt interpretieren können.

In der Praxis sehen wir immer wieder Projekte, in denen DPTs nicht oder falsch zugewiesen sind. Das fällt oft erst auf, wenn ein Gateway zu BACnet oder MQTT aufgebaut wird und die Werte auf der anderen Seite keinen Sinn ergeben. Ein Temperaturwert, der als rohe 2-Byte-Zahl übertragen wird, weil der DPT fehlt, ist für ein übergeordnetes System wertlos.

Die konsequente DPT-Zuweisung ist deshalb Teil der Planungsleistung, nicht der Inbetriebnahme. Im ETS-Projekt sollte jede Gruppenadresse einen DPT haben, bevor die erste Geräteapplikation verknüpft wird. Das verhindert Fehler und spart Zeit bei der späteren Integration.

Die Struktur als Pflichtenheftvorgabe

Eine Gruppenadressstruktur, die erst in der Ausführung entsteht, ist keine Struktur. Sie ist das Ergebnis von Einzelentscheiden unter Zeitdruck. Das Resultat ist in der Regel eine Anlage, die funktioniert, aber nicht dokumentiert ist und nicht skaliert.

Die Gruppenadress- und Namenskonvention muss deshalb im Pflichtenheft des Projekts festgelegt sein. Das Pflichtenheft beschreibt, welche Hauptgruppen für welche Gewerke reserviert sind, wie die Mittelgruppen den Bereichen zugeordnet werden, welche Namenskonvention gilt und welche DPTs für welche Signalarten zu verwenden sind. Diese Vorgaben sind verbindlich für alle Beteiligten: Planer, Integratoren und Inbetriebnahmetechniker.

In grösseren Projekten empfiehlt es sich, die Gruppenadressstruktur als eigenes Dokument zu führen, das parallel zum ETS-Projekt gepflegt wird. Dieses Dokument ist die Brücke zwischen der KNX-Welt und der übergeordneten Gebäudeautomation. Es listet alle Gruppenadressen mit Name, DPT, Funktion und Bereich und kann direkt als Grundlage für Schnittstellenlisten und Datenpunktlisten verwendet werden.

Wer das Pflichtenheft und die Abnahme einer KNX-Anlage aus Bauherrensicht verstehen will, findet dazu Hinweise in Teil 5 der Serie «KNX richtig planen» unter dem Titel «Das ETS-Projekt gehört dem Bauherrn».

Warum die Struktur Gateways erst effizient macht

Der eigentliche Wert einer durchdachten Gruppenadressstruktur zeigt sich, wenn KNX mit anderen Systemen verbunden wird. Gateways zu BACnet, DALI, Modbus oder MQTT übersetzen KNX-Gruppenadressen in die Datenpunkte des Zielsystems. Diese Übersetzung, das sogenannte Mapping, muss für jede Gruppenadresse einzeln konfiguriert werden.

Wenn die Gruppenadressstruktur keine Logik hat, ist das Mapping eine manuelle Einzelarbeit. Der Integrator öffnet das ETS-Projekt, sucht die relevanten Adressen, identifiziert den DPT und trägt alles von Hand in die Gateway-Konfiguration ein. Bei einer Anlage mit mehreren hundert Datenpunkten dauert das Tage und ist fehleranfällig.

Wenn die Gruppenadressstruktur dagegen einer klaren Konvention folgt, kann das Mapping weitgehend automatisiert oder zumindest systematisch durchgeführt werden. Die Adressen sind nach Gewerk und Bereich sortiert, die Namen sind sprechend, die DPTs sind korrekt zugewiesen. Ein Export aus der ETS liefert direkt eine strukturierte Liste, die als Grundlage für die Gateway-Konfiguration dient.

Das gilt besonders für die Anbindung an BACnet. Ein KNX-BACnet-Gateway bildet jede Gruppenadresse auf ein BACnet-Objekt ab. Wenn die KNX-Seite strukturiert ist, können die BACnet-Objektnamen direkt aus den KNX-Namen abgeleitet werden. Das spart nicht nur Zeit bei der Inbetriebnahme, es sorgt auch dafür, dass die Datenpunkte auf beiden Seiten konsistent bezeichnet sind. Mehr dazu erklärt Teil 4 der Serie «Schnittstellen rund um KNX» unter dem Titel «KNX und BACnet: Raumautomation an die Gebäudeleittechnik».

Dasselbe gilt für MQTT. Wenn KNX-Daten über einen MQTT-Broker an Dashboards oder Cloud-Dienste übertragen werden, sind die Topic-Namen direkt von den KNX-Gruppenadressen abgeleitet. Eine strukturierte Namenskonvention ergibt automatisch eine strukturierte Topic-Hierarchie. Teil 5 der Serie «Schnittstellen rund um KNX» unter dem Titel «KNX und MQTT: Gebäudedaten für Dashboards und Cloud» geht darauf ein.

Typische Fehler und wie man sie vermeidet

In unserer Projekterfahrung sehen wir immer wieder dieselben Fehler bei der Gruppenadressstruktur. Die häufigsten sind:

Keine Konvention, nur Gewohnheit. Jeder Inbetriebnahmetechniker baut die Struktur so auf, wie er es gewohnt ist. Das Ergebnis ist eine Anlage, die intern konsistent wirkt, aber von aussen nicht lesbar ist.

Hauptgruppen nach Gerät statt nach Gewerk. Wenn die Hauptgruppe den Hersteller oder den Gerätetyp bezeichnet statt das Gewerk, verliert die Struktur ihre funktionale Logik. Eine Hauptgruppe «Taster» oder «Dimmaktor» ist keine sinnvolle Ordnungsebene.

Fehlende Statusadressen. Viele Projekte haben Schaltadressen, aber keine separaten Statusadressen. Für übergeordnete Systeme und Dashboards sind Statusrückmeldungen aber oft wichtiger als die Steuerbefehle. Statusadressen müssen von Anfang an eingeplant und benannt werden.

DPTs nicht zugewiesen oder falsch. Wie oben beschrieben ist das ein häufiger Fehler, der erst bei der Integration auffällt.

Keine Reserven eingeplant. Wenn die Untergruppen einer Mittelgruppe vollständig belegt sind, gibt es keinen Platz für Erweiterungen. Eine gute Struktur lässt bewusst Lücken für spätere Ergänzungen.

Struktur nicht dokumentiert. Das ETS-Projekt ist die technische Umsetzung, aber kein Planungsdokument. Die Struktur muss separat dokumentiert sein, damit sie auch ohne ETS-Zugang nachvollzogen werden kann.

Diese Fehler lassen sich alle vermeiden, wenn die Struktur vor der Inbetriebnahme geplant und im Pflichtenheft festgelegt wird. Das kostet am Anfang etwas Zeit, spart aber vielfach mehr im Betrieb.

Struktur über den Lebenszyklus pflegen

Eine Gruppenadressstruktur ist kein einmaliges Dokument. Sie muss über den gesamten Lebenszyklus der Anlage gepflegt werden. Jede Erweiterung, jede Änderung und jede neue Funktion muss in der Struktur abgebildet und dokumentiert werden.

Das setzt voraus, dass die Struktur von Anfang an so angelegt ist, dass sie erweiterbar ist. Reserven in den Untergruppen, klare Zuordnung der Hauptgruppen und eine Namenskonvention, die auch neue Bereiche und Funktionen aufnehmen kann, sind dafür die Voraussetzungen.

In der Praxis sehen wir, dass Anlagen, die ohne Struktur gestartet wurden, nach einigen Jahren kaum noch erweiterbar sind. Neue Geräte werden irgendwo eingehängt, neue Adressen nach dem Prinzip «nächste freie» vergeben, und die Dokumentation hinkt hinterher. Das Ergebnis ist eine Anlage, die technisch funktioniert, aber niemand mehr vollständig versteht.

Eine gepflegte Struktur ist dagegen die Grundlage für eine langfristig betreibbare Anlage. Sie macht Inbetriebnahme, Fehlersuche und Erweiterungen effizienter und ist die Voraussetzung dafür, dass das ETS-Projekt als Eigentum des Bauherrn tatsächlich nutzbar bleibt. Wie das ETS-Projekt übergeben und langfristig gesichert wird, behandelt Teil 5 der Serie «KNX richtig planen» unter dem Titel «Das ETS-Projekt gehört dem Bauherrn».

Wer die Inbetriebnahme und Abnahme einer KNX-Anlage aus operativer Sicht verstehen will, findet dazu Hinweise in Teil 1 der Serie «KNX in Betrieb und Bestand» unter dem Titel «Inbetriebnahme und Abnahme einer KNX-Anlage».

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel ist Teil 3 der Serie «KNX richtig planen». Teil 1 unter dem Titel «KNX im Zweckbau: wann es passt und wann nicht» klärt, für welche Projekte KNX die richtige Wahl ist. Teil 2 unter dem Titel «Topologie, Linien und IP-Backbone sauber aufbauen» zeigt, wie die physikalische Struktur der Anlage geplant wird. Teil 4 unter dem Titel «KNX Secure im Projekt: Data Secure und IP Secure» behandelt die Absicherung der KNX-Kommunikation. Teil 5 unter dem Titel «Das ETS-Projekt gehört dem Bauherrn» erklärt, wie das ETS-Projekt übergeben und langfristig gesichert wird.

Die technischen Grundlagen der Gruppenadressen erklärt Teil 5 der Serie «KNX Grundlagen: die Schulungsreihe» unter dem Titel «Gruppenadressen: So sprechen KNX-Geräte miteinander». Kommunikationsobjekte und deren Flags behandelt Teil 6 derselben Serie unter dem Titel «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?». Datenpunkttypen erklärt Teil 7 unter dem Titel «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht».

Wer die Schnittstellen von KNX zu anderen Systemen verstehen will, findet in der Serie «Schnittstellen rund um KNX» die passenden Beiträge: Teil 1 «KNX und DALI: Beleuchtung sauber koppeln», Teil 4 «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» und Teil 5 «KNX und MQTT: Gebäudedaten für Dashboards und Cloud». Teil 6 der Schnittstellenserie unter dem Titel «Wer mappt was? Schnittstellenliste und Verantwortung» zeigt, wie die Verantwortung für das Mapping geregelt wird.

Wer den Zusammenhang zwischen KNX-Datenpunkten und der übergeordneten Gebäudeautomation besser verstehen will, findet in unserer Serie «GA verstehen» einen guten Einstieg, insbesondere in Teil 4 «Wie erkenne ich eine gute GA-Planung?» und Teil 5 «Übergabe & Betrieb: Was der Betreiber von der GA wissen muss». Wie ein GA-Lastenheft aufgebaut sein muss, erklärt unser Beitrag «Das GA-Lastenheft: Was wirklich drinstehen muss».

Fazit

Die Gruppenadress- und Namensstruktur ist keine nachgelagerte Detailaufgabe. Sie ist das Ordnungssystem der gesamten KNX-Anlage und entscheidet darüber, wie gut die Anlage betrieben, erweitert und integriert werden kann. Eine durchdachte Struktur nach Gewerk, Geschoss und Funktion, kombiniert mit einer konsequenten Namenskonvention und korrekten DPT-Zuweisungen, ist die Datenpunktliste der KNX-Welt.

Diese Struktur muss im Pflichtenheft festgelegt sein, bevor die Inbetriebnahme beginnt. Sie ist verbindlich für alle Beteiligten und muss über den gesamten Lebenszyklus gepflegt werden. Nur dann ist sie die Grundlage, die Gateways zu BACnet, DALI oder MQTT effizient und fehlerfrei macht.

Wer diese Arbeit am Anfang investiert, spart sie vielfach im Betrieb. Wer sie weglässt, zahlt den Preis spätestens dann, wenn die erste Schnittstelle gebaut oder die erste Erweiterung geplant wird.

Sie haben Fragen dazu?

Sie planen eine KNX-Anlage und möchten die Gruppenadressstruktur von Anfang an richtig aufbauen? Oder Sie haben eine bestehende Anlage, deren Struktur Sie bereinigen und dokumentieren möchten? Wir unterstützen Sie bei der Erarbeitung der Konvention, der Pflichtenheftvorgabe und der Umsetzung im ETS-Projekt. Nehmen Sie Kontakt auf unter wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specification, Brüssel (Grundlagen Gruppenadressen, Datenpunkttypen, ETS). KNX und ETS sind eingetragene Marken der KNX Association.
• SWKI BA101-01: Leistungen der Gebäudeautomation (Datenpunktbezeichnung als Planungsleistung, als Analogie für KNX-Gruppenadressnamen)
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden, Gebäudeautomation und Gebäudemanagement
• SN EN ISO 16484-1 (SIA 386.151): Gebäudeautomationssysteme, Projektierung
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, ETS-Projektierung und GA-Integration in Zweckbauten