Ein Lichtmanagement binden Sie an die Gebäudeleittechnik (GLT) über eine standardisierte Schnittstelle an: BACnet/IP ist im deutschen Nichtwohngebäude der verbreitetste Weg, Modbus eignet sich für einfache Zustands- und Zählerwerte, eine API für die Integration in IT-Plattformen, Energiemanagement- oder Workplace-Software. Entscheidend ist nicht nur das Protokoll, sondern die saubere Definition der Datenpunkte: welche Werte die GLT lesen soll, welche Befehle sie senden darf und wo die Lichtsteuerung autonom bleibt. Dieser Ratgeber erklärt Architektur, Datenpunkte, Protokollwahl und die typischen Stolpersteine bei der Integration.
Warum Licht in die GLT gehört
Die Beleuchtung ist in vielen Nichtwohngebäuden einer der großen Stromverbraucher, wird aber häufig als Insellösung betrieben. Eine Anbindung an die GLT bringt mehrere Vorteile:
- Zentrale Übersicht: Störungen, Betriebszustände und Verbräuche erscheinen in derselben Oberfläche wie Heizung, Lüftung und Klima.
- Gewerkeübergreifende Funktionen: Präsenzinformationen der Lichtsensoren können Lüftung oder Heizung raumweise absenken.
- Energiemonitoring: Verbrauchsdaten der Beleuchtung fließen in das Energiemanagement und in Berichte ein.
- Rechtliche Anforderungen: Mit dem Gebäudemodernisierungsgesetz (GModG) werden die Anforderungen an Gebäudeautomation, Monitoring und automatische Beleuchtungssteuerung in Nichtwohngebäuden ausgeweitet. Laut BBSR-Infoportal verlangt § 56 Abs. 2 GModG für Monitoringtechnik unter anderem Datenzugänglichkeit über eine gängige und frei konfigurierbare Schnittstelle (Stand: September 2026, keine Rechtsberatung). Einzelheiten im Ratgeber GEG, EnEfG & EPBD.
Architektur: Drei Ebenen
Eine funkbasierte Lichtsteuerung mit GLT-Anbindung ist typischerweise in drei Ebenen aufgebaut:
| Ebene | Aufgabe | Komponenten Keilton+autani |
|---|---|---|
| Feldebene | Präsenz- und Tageslichterfassung, Dimmen, Schalten | Sensoren wie IFS105SE oder EFS106, Node FA102, Wandschalter WP108E |
| Zonen- bzw. Automationsebene | Bündelung einer Bluetooth-Mesh-Zone, Zeitsynchronisation | Gateway CR05 mit RTR (bis 100 Knoten je Zone), Echtzeituhr CR01 |
| Managementebene | Zentrale Verwaltung, Datenhaltung, Schnittstelle zur GLT | AU-Manager mit EnergyCenter-Software |
Die Sensoren arbeiten in ihrer Bluetooth-Mesh-Zone autonom: Präsenz- und Tageslichtregelung laufen lokal, auch wenn die Verbindung zur Managementebene unterbrochen ist. Der AU-Manager integriert laut Datenblatt mehrere Protokolle, darunter Bluetooth, Zigbee (autaniNet), EnOcean und BACnet/IP, und verbindet sich über Ethernet mit dem lokalen Netzwerk oder über einen 4G-Router. Er speichert Systemereignisse über ein Jahr und bietet eine grafische Einrichtung auf Grundrissplänen. Mehr zur Funktechnik lesen Sie im Beitrag Bluetooth Mesh in der Lichtsteuerung.
Die Protokolle im Vergleich
BACnet/IP
BACnet (Building Automation and Control Networks) ist ein herstellerunabhängiger Standard (ISO 16484-5) für die Gebäudeautomation. Er bildet Datenpunkte als Objekte ab, etwa binäre Werte für Zustände, analoge Werte für Messgrößen oder Mehrstufenwerte für Betriebsarten. Vorteile sind die semantische Beschreibung der Datenpunkte, Alarm- und Ereignisfunktionen sowie die breite Unterstützung durch GLT-Hersteller. Für die Keilton+autani-Plattform ist BACnet/IP über den AU-Manager verfügbar.
Modbus
Modbus ist ein einfaches, weit verbreitetes Protokoll, das Werte in nummerierten Registern überträgt. Es eignet sich gut für Zählerwerte und einfache Zustände. Nachteil: Die Bedeutung eines Registers ist nicht im Protokoll hinterlegt, sondern muss über eine Registerliste dokumentiert und in der GLT manuell zugeordnet werden.
API
Eine programmierbare Schnittstelle (API) ist der richtige Weg, wenn Daten nicht in eine klassische GLT, sondern in IT-Systeme fließen sollen: Energiemanagement-Software, CAFM, Workplace- und Raumbuchungssysteme oder Data-Warehouse-Lösungen. APIs eignen sich besonders für größere Datenmengen und historische Auswertungen.
| Kriterium | BACnet/IP | Modbus | API |
|---|---|---|---|
| Typische Gegenstelle | GLT, Automationsstationen | GLT, Energiezähler-Systeme | IT-Plattformen, Analytics, CAFM |
| Datenmodell | Objekte mit Eigenschaften | Register ohne Semantik | Frei definierbar, meist strukturiert |
| Alarme und Ereignisse | Integriert | Nur über Polling | Je nach Implementierung |
| Aufwand Datenpunktzuordnung | Mittel | Hoch bei vielen Punkten | Programmieraufwand |
| Stärke | Standard in der Gebäudeautomation | Einfachheit | Flexibilität, historische Daten |
Building Robotics Europe unterstützt die Anbindung an die GLT über BACnet, Modbus oder API. Welcher Weg im Projekt sinnvoll ist, hängt von der vorhandenen Leittechnik und den Zielen der Integration ab.
Datenpunkte richtig definieren
Der häufigste Fehler bei GLT-Projekten ist eine unklare Datenpunktliste. Legen Sie früh fest, welche Informationen auf welcher Ebene benötigt werden. Eine Übertragung jeder einzelnen Leuchte ist selten sinnvoll; meist genügen Zonen oder Gruppen.
Typische Lese-Datenpunkte
- Präsenzstatus je Zone oder Raum (belegt / frei)
- Beleuchtungszustand und Dimmwert je Gruppe
- Energieverbrauch je Zone, zum Beispiel aus dem Energiemonitoring des CR01-ETC
- Störmeldungen, etwa Kommunikationsverlust einzelner Geräte (Umfang je nach Systemstand im Projekt klären)
- Betriebsart (Automatik, Hand, Zeitplan)
Typische Schreib-Datenpunkte
- Übergeordnete Freigabe oder Sperre einer Zone, zum Beispiel außerhalb der Betriebszeit
- Szenen- oder Profilumschaltung (Normalbetrieb, Reinigung, Veranstaltung)
- Zentral-AUS bei Gebäudeschließung
- Lastabwurf im Rahmen des Lastmanagements
Beispiel: Auszug aus einer Datenpunktliste
Die folgende Tabelle zeigt beispielhaft, wie eine Zone in der Datenpunktliste beschrieben werden kann. Bezeichnungen und Intervalle sind Beispielwerte und werden im Projekt mit dem GLT-Errichter abgestimmt.
| Bezeichnung | Richtung | Datentyp | Einheit | Intervall / Auslöser |
|---|---|---|---|---|
| OG2_Zone03_Praesenz | lesen | binär | belegt/frei | bei Änderung |
| OG2_Zone03_Dimmwert | lesen | analog | % | bei Änderung |
| OG2_Zone03_Energie | lesen | analog | kWh | 15 min |
| OG2_Zone03_Stoerung | lesen | binär | – | bei Änderung, Alarm |
| OG2_Zone03_Profil | schreiben | mehrstufig | Normal/Reinigung/Event | bei Bedarf |
| OG2_Zone03_Freigabe | schreiben | binär | frei/gesperrt | Zeitprogramm GLT |
Präsenzdaten gewerkeübergreifend nutzen
Der größte Mehrwert einer Integration entsteht, wenn die Präsenzinformation der Lichtsensoren auch anderen Gewerken zur Verfügung steht. Beispiele:
- Lüftung: Bedarfsgerechte Absenkung des Volumenstroms in nicht belegten Besprechungsräumen.
- Heizung und Kühlung: Absenkung der Solltemperatur in länger ungenutzten Zonen.
- Sonnenschutz: Abgestimmte Strategie zwischen Tageslichtnutzung und Blendschutz.
- Reinigung und Facility Services: Reinigung nach tatsächlicher Nutzung statt nach festem Plan.
Da ein Präsenzsensor ohnehin in jedem Raum oder sogar in jeder Leuchte sitzt, entsteht so ein feinmaschiges Belegungsbild ohne zusätzliche Sensorik. Mehr dazu im Ratgeber Energiemonitoring & Belegungsdaten.
IT-Sicherheit und Netzwerk
Mit der Anbindung wird die Lichtsteuerung Teil des Gebäudenetzwerks. Beachten Sie:
- Netzwerksegmentierung: Gebäudeautomation gehört in ein eigenes, vom Büro-IT-Netz getrenntes Segment (VLAN).
- Zugriffsrechte: Schreibrechte der GLT auf die Lichtsteuerung auf das Notwendige beschränken.
- Fernzugriff: Nur über gesicherte Verbindungen. Der AU-Manager ermöglicht laut Datenblatt einen sicheren Fernzugriff über LAN oder 4G-Router; die 4G-Anbindung kann das Büro-IT-Netz ganz aus dem Spiel lassen.
- Firmware-Pflege: Updates planen und dokumentieren, idealerweise im Rahmen eines Supportvertrags.
Vorgehen im Projekt
- Ziele klären: Nur Visualisierung, gewerkeübergreifende Funktionen oder Energiemonitoring?
- Bestand prüfen: Vorhandene GLT, unterstützte Protokolle, Lizenzmodell für Datenpunkte.
- Protokoll wählen: BACnet/IP als Standard, Modbus für einfache Anforderungen, API für IT-Integration.
- Datenpunktliste erstellen und mit allen Gewerken abstimmen.
- Lichtsteuerung zonenweise in Betrieb nehmen, zunächst autonom.
- Anbindung testen: Lesen, Schreiben, Alarme, Verhalten bei Verbindungsverlust.
- Gemeinsame Abnahme und Dokumentation.
Für die Systemauswahl hilft der Produktvergleich. Bei Fragen zu bestehenden Anlagen unterstützt Sie unser Support.
Fazit
Die GLT-Anbindung macht aus einer Lichtsteuerung einen Datenlieferanten für das gesamte Gebäude. BACnet/IP ist der Standardweg in die Gebäudeleittechnik, Modbus reicht für einfache Werte, eine API öffnet die Daten für IT-Plattformen. Der Projekterfolg hängt vor allem an einer früh abgestimmten Datenpunktliste, an der klaren Rollenverteilung zwischen autonomer Feldebene und übergeordneter GLT sowie an einer sauberen Netzwerkplanung. Wenn Sie eine Integration planen, sprechen Sie uns über die Kontaktseite an.
Häufige Fragen
Wie wird eine Lichtsteuerung an die GLT angebunden?
Über eine Managementebene, die die Daten der Lichtsteuerung bündelt und über ein Standardprotokoll bereitstellt. Im Keilton+autani-System übernimmt das der AU-Manager, der unter anderem BACnet/IP unterstützt. Die Sensoren regeln Präsenz und Tageslicht weiterhin lokal.
Was ist besser für die Lichtsteuerung: BACnet oder Modbus?
BACnet/IP ist der Standard in der Gebäudeautomation und bietet ein Objektmodell mit Alarmen und Ereignissen. Modbus ist einfacher, überträgt aber nur Registerwerte ohne Bedeutung, die manuell zugeordnet werden müssen. Für umfangreiche Integrationen ist BACnet meist die bessere Wahl.
Welche Datenpunkte sollte eine Lichtsteuerung an die GLT liefern?
Typisch sind Präsenzstatus, Beleuchtungszustand und Dimmwert je Zone, Energieverbrauch, Störmeldungen und Betriebsart. Schreibend werden meist Freigaben, Szenen- oder Profilumschaltungen und Zentral-AUS übergeben. Übertragen Sie Zonen statt einzelner Leuchten.
Funktioniert das Licht weiter, wenn die GLT ausfällt?
Bei einer sauber geplanten Architektur ja. Die Sensoren in der Bluetooth-Mesh-Zone treffen Präsenz- und Tageslichtentscheidungen lokal. Die GLT überwacht und beeinflusst übergeordnet, ist aber für den Grundbetrieb nicht erforderlich.
Wann ist eine API sinnvoller als BACnet?
Wenn die Daten nicht in eine klassische Gebäudeleittechnik, sondern in IT-Systeme fließen sollen, etwa Energiemanagement-Software, CAFM oder Raumbuchungssysteme. APIs eignen sich besonders für größere Datenmengen und historische Auswertungen.
