KNX und BACnet: Raumautomation an die Gebäudeleittechnik

Wer eine KNX-Raumautomation plant, denkt zuerst an Gruppenadressen, Datenpunkttypen und Liniensegmente. Wer dieselbe Anlage an eine BACnet-Gebäudeleittechnik anbinden muss, denkt plötzlich an Objekttypen, Device IDs und COV-Subscriptions. Beides ist richtig, und beides muss zusammenpassen. Die Verbindung zwischen den beiden Welten ist technisch lösbar, aber sie scheitert in der Praxis fast nie am Gateway selbst, sondern an der fehlenden Vorbereitung davor.

Dieser Beitrag zeigt, wie die Kopplung zwischen KNX und BACnet funktioniert, welche Entscheide früh getroffen werden müssen und warum die Datenpunktliste mit ihrem Mapping ins Pflichtenheft gehört, nicht in die Inbetriebnahme.

Zwei Protokollwelten mit unterschiedlicher Logik

KNX und BACnet sind beide offene, normierte Standards. KNX ist genormt in EN 50090 und ISO/IEC 14543-3 und arbeitet auf der Feldebene: Sensoren, Aktoren und Raumgeräte kommunizieren über Gruppenadressen. Ein Temperatursensor sendet einen Wert auf eine Gruppenadresse, ein Raumregler liest ihn. Die Kommunikation ist ereignisgesteuert, der Buszugriff erfolgt nach CSMA/CA, und die Datenpunkttypen (DPT) definieren, wie ein Wert zu interpretieren ist.

BACnet nach SN EN ISO 16484-5 (SIA 386.155) arbeitet auf der Automations- und Managementebene. Hier gibt es keine Gruppenadressen, sondern Objekte mit Eigenschaften. Ein Analogeingang hat eine Present-Value-Eigenschaft, ein Binärausgang hat seinen eigenen Objekttyp, und ein Zeitprogramm ist ein Schedule-Objekt mit Kalenderreferenz. BACnet kennt Dienste wie COV (Change of Value), Polling, Alarming und Trending, die alle auf Objektebene konfiguriert werden.

Die beiden Protokolle teilen das Ziel, nicht aber die Sprache. Wer sie verbinden will, braucht eine Übersetzung. Diese Übersetzung leistet ein Gateway, aber das Gateway kann nur das umsetzen, was ihm vorgegeben wird.

Gateway oder native Integration?

In der Praxis gibt es zwei Wege, KNX mit BACnet zu verbinden.

Gateway

Der häufigste Weg ist ein dediziertes Gateway, das auf der einen Seite als KNX-Teilnehmer am Bus hängt und auf der anderen Seite als BACnet-Device im IP-Netz erscheint. Das Gateway liest Gruppenadressen aus, ordnet jedem Wert ein BACnet-Objekt zu und macht diesen Wert für die Managementebene lesbar. Umgekehrt kann es Schreibzugriffe von der Managementebene in KNX-Telegramme übersetzen.

Gateways verschiedener Hersteller unterscheiden sich erheblich in der Konfigurationstiefe. Manche erlauben nur einfaches Mapping von Gruppenadresse auf Analogeingang oder Binärausgang. Andere unterstützen Multi-State-Objekte, COV-Subscriptions, Prioritäten und sogar Trending. Welche Funktionen ein Gateway tatsächlich braucht, muss vor der Beschaffung feststehen, nicht danach.

Native Integration

Einige KNX-Automationsstationen oder Raumcontroller können direkt als BACnet-Device auftreten, ohne separates Gateway. In diesem Fall ist die KNX-Logik im Gerät integriert, und das Gerät meldet sich im BACnet-Netz mit einer eigenen Device ID. Das reduziert die Anzahl der Geräte, setzt aber voraus, dass das Gerät beide Protokolle vollständig und korrekt implementiert. Die Prüfung dieser Konformität ist Teil der Abnahme.

Für die Planung ist der Unterschied relevant: Bei einem Gateway liegt die Konfigurationsverantwortung klar beim Integrator, der das Gateway einrichtet. Bei nativer Integration liegt sie beim Hersteller des Geräts und beim Integrator, der es parametriert. In beiden Fällen muss die Mapping-Vorgabe aus dem Pflichtenheft kommen, nicht aus dem Gerät selbst.

Das Mapping: Gruppenadresse trifft BACnet-Objekt

Das Herzstück der Integration ist das Mapping. Für jeden Datenpunkt, der von KNX nach BACnet übertragen werden soll, muss festgelegt sein:

• Welche Gruppenadresse auf der KNX-Seite ist massgebend?
• Welcher BACnet-Objekttyp wird verwendet (Analog Input, Analog Value, Binary Input, Binary Output, Multi-State Value und so weiter)?
• Welche Objektinstanz erhält das Objekt?
• Wie lautet der Object Name, der im BACnet-Netz eindeutig sein muss?
• Welche Einheit trägt der Wert (Units-Eigenschaft)?
• Ist der Datenpunkt lesbar, schreibbar oder beides?
• Welcher DPT liegt auf der KNX-Seite vor, und wie wird er auf den BACnet-Wert abgebildet?

Diese Liste klingt nach Detailarbeit, und das ist sie auch. Aber sie ist keine Arbeit, die der Integrator beim Einrichten des Gateways erfinden soll. Sie ist eine Planungsleistung, die aus dem Pflichtenheft kommt und in der Datenpunktliste dokumentiert ist.

In der Praxis sehen wir häufig, dass das Mapping erst während der Inbetriebnahme entsteht, weil niemand vorher festgelegt hat, welche Punkte überhaupt übertragen werden sollen. Das führt zu unvollständigen Datenpunktlisten, willkürlichen Objektnamen und Objektinstanzen, die mit dem Rest des BACnet-Netzes kollidieren.

Objekttypen richtig wählen

Die Wahl des BACnet-Objekttyps ist keine rein technische Frage. Sie hat Konsequenzen für Alarming, Trending und die Bedienbarkeit auf der Managementebene.

Ein Raumtemperaturistwert gehört als Analog Input oder Analog Value, mit der Einheit Grad Celsius und einer sinnvollen COV-Increment-Einstellung. Ein Präsenzmelder liefert einen Binärwert und gehört als Binary Input. Ein Betriebsmodus mit mehreren Zuständen (Komfort, Standby, Nacht, Frost) gehört als Multi-State Value, nicht als Analogwert mit Zahlen von 1 bis 4, auch wenn das technisch funktionieren würde.

Warum ist das wichtig? Weil die Managementebene auf Basis der Objekttypen arbeitet. Ein Alarmierungsobjekt (Event Enrollment) kann auf einen Analog Input mit Grenzwerten reagieren. Ein Schedule-Objekt kann einen Multi-State Value direkt beschreiben. Wer falsche Objekttypen wählt, muss auf der Managementebene Workarounds programmieren, die bei jedem Software-Update oder Gerätetausch neu geprüft werden müssen.

Für die Planung empfehlen wir, die Objekttypen in der Datenpunktliste verbindlich vorzugeben und nicht dem Gateway-Hersteller zu überlassen. Welche Objekttypen BACnet kennt und wie sie strukturiert sind, beschreiben wir ausführlich in der Serie «BACnet Objekte verstehen».

COV oder Polling?

Sobald das Mapping steht, stellt sich die Frage, wie die Werte von der KNX-Seite zur Managementebene gelangen.

COV (Change of Value)

BACnet kennt den COV-Dienst: Ein Client abonniert einen Datenpunkt, und das Gerät sendet automatisch eine Meldung, wenn sich der Wert um mehr als ein definiertes Inkrement ändert. Das ist effizient, weil nur tatsächliche Änderungen übertragen werden, und es ist nah an der ereignisgesteuerten Logik von KNX.

Damit COV funktioniert, muss das Gateway COV-Subscriptions unterstützen und die KNX-Seite aktiv überwachen. Das COV-Inkrement muss sinnvoll gewählt sein: Zu gross, und die Managementebene sieht Änderungen zu spät. Zu klein, und der Datenverkehr im BACnet-Netz steigt unnötig.

Polling

Alternativ fragt die Managementebene den Wert periodisch ab. Das ist einfacher zu konfigurieren, erzeugt aber eine konstante Last im Netz und liefert Werte nur mit der Polling-Frequenz als Auflösung. Für Alarme, die schnell reagieren müssen, ist Polling oft zu langsam.

In der Praxis empfehlen wir COV für alle Datenpunkte, die für Alarming oder Trending relevant sind, und Polling nur dort, wo COV nicht unterstützt wird oder die Anforderungen es erlauben. Diese Entscheidung gehört in die Planungsunterlagen, nicht in die Inbetriebnahme.

Prioritäten: Wer darf schreiben?

BACnet kennt ein Prioritätensystem mit 16 Stufen für Schreibzugriffe auf steuerbare Objekte. Priorität 1 ist die höchste (Notfall), Priorität 16 die niedrigste (manuelle Bedienung ohne Vorrang). Dieses System ist in SN EN ISO 16484-5 definiert und ermöglicht es, dass mehrere Quellen auf denselben Datenpunkt schreiben können, ohne sich gegenseitig unkontrolliert zu überschreiben.

Wenn eine KNX-Raumautomation über ein Gateway in BACnet eingebunden ist, muss festgelegt sein, mit welcher Priorität das Gateway schreibt. Schreibt es mit Priorität 8 (manuelle Bedienung), kann die Managementebene mit Priorität 7 jederzeit übersteuern. Schreibt es mit Priorität 3, ist das kaum mehr möglich, ausser durch Notfallbefehle.

Typische Konflikte entstehen, wenn:

• Das Gateway mit einer zu hohen Priorität schreibt und manuelle Übersteuerungen von der Managementebene nicht wirken.
• Zeitprogramme auf der Managementebene mit falscher Priorität laufen und von der KNX-Logik ignoriert werden.
• Alarmbefehle nicht die erwartete Wirkung haben, weil ein anderer Schreiber mit höherer Priorität aktiv ist.

Die Prioritätenvergabe muss im Pflichtenheft stehen. Sie ist keine Konfigurationsdetail, die der Integrator nach Gefühl wählt.

Device IDs und BACnet-Administration

Jedes BACnet-Device braucht eine eindeutige Device ID im Netz. Das gilt auch für das Gateway oder den nativen KNX-BACnet-Controller. Wer die Device IDs vergibt und wie sie strukturiert sind, ist eine Frage der BACnet-Administration.

In Projekten, in denen keine zentrale BACnet-Administration besteht, vergeben Integratoren die Device IDs projektweise nach eigenem Ermessen. Das führt früher oder später zu Kollisionen, besonders wenn mehrere Integratoren am selben Standort arbeiten oder eine bestehende Anlage erweitert wird.

Die KBOB-Empfehlung BACnet beschreibt die Rolle des BACnet-Administrators und die Notwendigkeit einer zentralen Vergabe von Device IDs und Netzwerknummern. Für die KNX-BACnet-Integration bedeutet das konkret: Bevor das Gateway konfiguriert wird, muss die Device ID aus dem zentralen Register der Bauherrschaft kommen. Wie diese Administration organisiert wird, beschreiben wir in der Serie «Managed BACnet Administration», insbesondere im Beitrag «Wer vergibt Ihre BACnet Device IDs? Warum ein BACnet-Netz eine verantwortliche Stelle braucht».

Alarme, Zeitprogramme und Trending

Die Integration beschränkt sich selten auf das reine Durchreichen von Messwerten. In einer vollständigen Raumautomation gibt es Alarme, Zeitprogramme und Trendaufzeichnungen, die ebenfalls über die Schnittstelle koordiniert werden müssen.

Alarme

KNX kennt keine native Alarmierungslogik im Sinne von BACnet. Alarme entstehen auf der Managementebene, indem BACnet-Objekte mit Event-Enrollment-Objekten verknüpft werden. Dafür muss der Datenpunkt als BACnet-Objekt vorhanden sein, und das Event-Enrollment-Objekt muss korrekt konfiguriert sein, mit Grenzwerten, Hysterese, Notification-Class und Empfänger.

Wer Alarme aus der KNX-Raumautomation auf der Managementebene sehen will, muss diese Konfiguration planen. Sie entsteht nicht automatisch, wenn das Gateway den Wert überträgt. Die Planung von Alarmierungsobjekten beschreiben wir im Beitrag «BACnet Objekte verstehen, Teil 5: Event Enrollment & Notification Class. Alarmmanagement richtig planen».

Zeitprogramme

Zeitprogramme können auf der KNX-Seite, auf der BACnet-Managementebene oder auf beiden liegen. Wenn beide Seiten Zeitprogramme haben, die auf denselben Datenpunkt wirken, entstehen Konflikte, die nur über das Prioritätensystem auflösbar sind. Die sauberste Lösung ist eine klare Zuweisung: Entweder liegt das Zeitprogramm auf der KNX-Seite und wird über das Gateway als Istzustand sichtbar, oder es liegt auf der BACnet-Seite und schreibt über das Gateway auf die KNX-Aktoren. Beides gleichzeitig, ohne Prioritätsregelung, führt zu unvorhersehbarem Verhalten.

Trending

Trendaufzeichnungen auf der Managementebene setzen voraus, dass der Datenpunkt als BACnet-Objekt vorhanden ist und COV oder Polling korrekt konfiguriert ist. Trend-Log-Objekte müssen geplant und in der Datenpunktliste ausgewiesen sein. Wer erst nach der Inbetriebnahme merkt, dass ein Datenpunkt nicht aufgezeichnet wird, muss das Gateway neu konfigurieren und die Managementebene anpassen.

Die Datenpunktliste als Pflichtenheft-Bestandteil

Alle bisher genannten Punkte laufen auf eine Erkenntnis hinaus: Die Datenpunktliste mit dem vollständigen Mapping ist kein Lieferdokument des Integrators, sondern eine Planungsleistung, die ins Pflichtenheft gehört.

Was diese Liste enthalten muss:

• Alle Datenpunkte, die von KNX nach BACnet übertragen werden (mit Gruppenadresse, DPT, Objekttyp, Instanz, Name, Einheit).
• Alle Datenpunkte, die von BACnet nach KNX geschrieben werden (mit Priorität, Objekttyp, Gruppenadresse).
• Die COV-Inkremente oder Polling-Frequenzen je Datenpunkt.
• Die Alarmierungsobjekte und ihre Konfiguration.
• Die Zeitprogramme und ihre Zuordnung (KNX-Seite oder BACnet-Seite).
• Die Trending-Anforderungen.
• Die Device ID des Gateways (aus dem zentralen Register).

Wer diese Liste erst während der Inbetriebnahme erstellt, verliert Zeit, Qualität und Nachvollziehbarkeit. Wer sie im Pflichtenheft vorgibt, schafft die Grundlage für eine prüfbare Abnahme.

Die Verantwortung für die Erstellung dieser Liste liegt beim GA-Planer, nicht beim Integrator. Der Integrator setzt um, was vorgegeben ist, und dokumentiert die tatsächliche Konfiguration. Abweichungen von der Vorgabe müssen schriftlich festgehalten und freigegeben werden.

Wie eine vollständige Datenpunktliste für BACnet aufgebaut ist und welche Beschriftungsregeln gelten, beschreiben wir im Beitrag «Datenpunktlisten & Beschriftungsregeln: Die unsichtbare Grundlage des Betriebs». Und wie die Verantwortung für Schnittstellenlisten generell geregelt werden sollte, ist Thema von Teil 6 dieser Serie: «Wer mappt was? Schnittstellenliste und Verantwortung».

Was in der Ausschreibung stehen muss

Damit das Mapping nicht erst auf der Baustelle entsteht, muss die Ausschreibung klare Anforderungen enthalten. Dazu gehören:

• Die Anforderung, dass das Gateway oder der native Controller BACnet-konform nach SN EN ISO 16484-5 implementiert ist.
• Die Vorgabe der Objekttypen, die unterstützt werden müssen (Analog Input/Output/Value, Binary Input/Output, Multi-State Value, mindestens).
• Die Anforderung, COV-Subscriptions zu unterstützen.
• Die Vorgabe, dass die Device ID aus dem zentralen Register der Bauherrschaft bezogen wird.
• Die Anforderung, dass das Mapping in der Datenpunktliste dokumentiert und vor der Inbetriebnahme freigegeben wird.
• Die Anforderung, dass Prioritäten gemäss Pflichtenheft konfiguriert werden.

Wer diese Punkte nicht in der Ausschreibung verankert, kann sie in der Abnahme nicht einfordern. Das gilt für Neubauten genauso wie für Sanierungen, wo oft ein bestehendes BACnet-Netz auf eine neue KNX-Raumautomation trifft.

Wie eine BACnet-Ausschreibung grundsätzlich aufgebaut wird und was zwingend ins Pflichtenheft gehört, beschreibt der Beitrag «BACnet Planung, Das Fundament, Teil 2: Objektvorgaben. Was man vorschreiben muss und warum».

Der rote Faden zu unseren Fachbeiträgen

Wer die Grundlagen von KNX kennen möchte, findet sie in der Serie «KNX Grundlagen: die Schulungsreihe», insbesondere in «Gruppenadressen: So sprechen KNX-Geräte miteinander» (Teil 5) und «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht» (Teil 7). Die saubere Strukturierung von Gruppenadressen, die das Mapping erleichtert, behandelt «Gruppenadressen und Namenskonvention als Fundament» aus der Serie «KNX richtig planen».

Auf der BACnet-Seite empfehlen wir die Beiträge «BACnet Objekte verstehen, Teil 2: Analoge und digitale Objekte. Das Fundament der BACnet-Datenpunktstruktur» und «BACnet Objekte verstehen, Teil 5: Event Enrollment & Notification Class. Alarmmanagement richtig planen» für die Planung von Alarmen. Zeitprogramme auf der BACnet-Seite erklärt «BACnet Objekte verstehen, Teil 6: Schedule & Calendar. Zeitsteuerung in BACnet richtig planen».

Die Frage der Device IDs und der zentralen BACnet-Administration ist Thema der Serie «Managed BACnet Administration», beginnend mit «Wer vergibt Ihre BACnet Device IDs? Warum ein BACnet-Netz eine verantwortliche Stelle braucht». Den gesamten Planungsprozess von der Ausschreibung bis zur Abnahme beschreibt «Vom Lastenheft zur Abnahme: Der BACnet-Planungsprozess in der Praxis».

Andere Schnittstellen rund um KNX behandeln die übrigen Teile dieser Serie: DALI in Teil 1 («KNX und DALI: Beleuchtung sauber koppeln»), EnOcean in Teil 2 («KNX und EnOcean: Funk für Sanierung und flexible Räume»), Modbus in Teil 3 («KNX und Modbus: Zähler, Wärmepumpen und Lüftungsgeräte einbinden») und MQTT in Teil 5 («KNX und MQTT: Gebäudedaten für Dashboards und Cloud»). Die übergreifende Frage der Schnittstellenverantwortung schliesst die Serie in Teil 6 ab: «Wer mappt was? Schnittstellenliste und Verantwortung».

Fazit

Die Kopplung von KNX und BACnet ist technisch ausgereift und in der Praxis vielfach bewährt. Das Gateway oder der native Controller ist selten das Problem. Das Problem entsteht, wenn das Mapping, die Objekttypen, die Prioritäten und die Device IDs nicht vor der Inbetriebnahme feststehen.

Wer die Datenpunktliste mit vollständigem Mapping ins Pflichtenheft aufnimmt, wer COV und Polling bewusst wählt, wer Prioritäten für Zeitprogramme und Alarme klar regelt und wer die Device ID aus einem zentralen Register bezieht, schafft eine Integration, die abnahmefähig, betreibbar und erweiterbar ist. Wer diese Entscheide dem Integrator überlässt, bekommt eine Anlage, die funktioniert, aber niemand mehr vollständig versteht.

Die Verantwortung für diese Vorgaben liegt beim GA-Planer. Sie beginnt im Pflichtenheft und endet in der Abnahmedokumentation.

Sie haben Fragen dazu?

Sie planen eine KNX-Raumautomation, die an eine bestehende oder neue BACnet-Gebäudeleittechnik angebunden werden soll? Oder Sie stehen vor einer Sanierung, bei der beide Welten aufeinandertreffen? Wir unterstützen Sie bei der Erstellung des Mappings, der Datenpunktliste und der Ausschreibungsunterlagen. Nehmen Sie mit uns Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• SN EN ISO 16484-5 (SIA 386.155): Datenkommunikationsprotokoll BACnet, insbesondere Objekttypen, Prioritätensystem, COV-Dienste und Device-Objekt
• EN 50090 / ISO/IEC 14543-3: KNX-Standard, Gruppenadressierung, Datenpunkttypen und Telegrammstruktur
• KBOB Empfehlung BACnet Anwendung, Version 2.0, Juli 2021: Rollen und Verantwortung, BACnet-Administration, Device-ID-Vergabe und bauherrenspezifische Vorgaben
• KNX Association (Brüssel): Markeninhaberin der eingetragenen Marken KNX und ETS; Landesorganisation Schweiz: KNX Swiss
• Eigene Projekterfahrung der WENGET GmbH aus KNX-BACnet-Integrationen, GA-Planung und Inbetriebnahmebegleitung