Gebäudedaten per Schnittstelle: Raumklima- und Energiedaten in CAFM und eigene Software bringen

Das Wichtigste in Kürze

• Eine Gebäudedaten Schnittstelle verbindet Gebäudeautomation, Zähler, Raumsensoren und Fachsoftware wie CAFM, ERP oder BI so, dass Messwerte dort ankommen, wo Entscheidungen fallen. Für Softwarehersteller, Systemintegratoren und Facility Management ist sie die Voraussetzung, um Raumklima- und Energiedaten im eigenen Produkt oder Prozess zu nutzen.
• Das Protokoll ist selten das größte Problem. Aufwand entsteht vor allem bei Datenmodell und Bedeutung der Daten (welcher Wert gehört zu welchem Raum, welcher Anlage, welcher Einheit) und bei der Datenqualität.
• Für Nichtwohngebäude verlangt § 56 Gebäudemodernisierungsgesetz (GModG) Systeme, die Daten „über eine gängige und frei konfigurierbare Schnittstelle“ herstellerunabhängig zugänglich machen [1].
• IT-Sicherheit ist Teil der Architektur, nicht ein nachträglicher Zusatz: Netztrennung, verschlüsselte Übertragung und klare Rechte sind Stand der Technik (BSI IT-Grundschutz INF.13 und INF.14, VDMA 24774, IEC 62443) [19–22].
• Raumdaten wie CO₂ oder Bewegung können Rückschlüsse auf Personen zulassen. Dann gelten DSGVO und gegebenenfalls Mitbestimmungsrechte des Betriebsrats [24–27].

Datensilos im Gebäude: warum eine Gebäudedaten Schnittstelle fehlt und was das kostet

In einem typischen Nichtwohngebäude arbeiten mehrere Systeme nebeneinander: die Gebäudeleittechnik (GLT) mit Reglern für Heizung, Lüftung und Klima, Strom- und Wärmezähler, Raumautomation für Licht und Sonnenschutz, einzelne Raumsensoren, ein CAFM-System für Flächen, Wartung und Tickets sowie ein ERP für Verträge und Kosten. Jedes dieser Systeme hat eigene Datenformate, eigene Bezeichnungen und oft einen eigenen Dienstleister.

Die Folge sind Datensilos. Die GLT kennt die Temperatur in Raum „3.14“, das CAFM kennt denselben Raum als „B-03-014“, und der Energiezähler ist einer Anlage zugeordnet, die in keinem der beiden Systeme so heißt. Wer wissen will, ob ein Besprechungsraum regelmäßig überhitzt, welche Wartung dort ansteht und welche Energiekosten dabei entstehen, muss Daten aus drei Systemen von Hand zusammenführen.

Wie teuer fehlende Interoperabilität ist, hat das US-amerikanische National Institute of Standards and Technology (NIST) untersuchen lassen. O’Connor, Dettbarn und Gilday schätzten die Kosten unzureichender Interoperabilität in der US-Bau- und Immobilienwirtschaft für das Jahr 2002 auf 15,8 Milliarden US-Dollar pro Jahr [2]. Rund zwei Drittel davon trugen Eigentümer und Betreiber, und mit etwa 9,1 Milliarden US-Dollar entfiel der größte Teil auf die Betriebs- und Instandhaltungsphase [2]. Die Zahl ist alt, bezieht sich auf die USA und umfasst nur Kosten, die sich quantifizieren ließen; die Autoren bezeichnen sie selbst als eher konservativ [2]. Sie zeigt aber, wo der Aufwand anfällt: nicht beim Bau, sondern im jahrzehntelangen Betrieb.

Auch der Gesetzgeber hat das Problem erkannt. § 56 GModG verlangt, dass Nichtwohngebäude mit Heizungs-, Klima- oder kombinierten Heizungs- bzw. Klima- und Lüftungsanlagen über 70 kW Nennleistung bis Ende 2029 mit einem System für Gebäudeautomatisierung und -steuerung ausgerüstet werden, sofern das technisch möglich und wirtschaftlich zumutbar ist [1]. Dieses System muss unter anderem die erhobenen Daten „über eine gängige und frei konfigurierbare Schnittstelle zugänglich“ machen, „sodass Auswertungen firmen- und herstellerunabhängig erfolgen können“ [1]. Für Neubauten fordert das Gesetz zusätzlich, dass das System mit anderen gebäudetechnischen Systemen zusammenarbeitet, „auch bei unterschiedlichen herstellereigenen Technologien, Geräten und Herstellern“ [1]. (Allgemeine Information, kein Rechtsrat, Stand: Oktober 2026.)

Für Softwareanbieter im Facility- und Property-Management heißt das: Betreiber brauchen Raumklima- und Energiedaten in ihrer gewohnten Software, nicht in einem weiteren Portal.

Abbildung 1: Eine Integrationsschicht ersetzt viele Punkt-zu-Punkt-Verbindungen zwischen Datensilos. Eigene Darstellung.

Ursachen: Protokolle, Bedeutung und Qualität der Daten

Hinter dem Begriff „Schnittstelle“ stecken drei Ebenen, die oft vermischt werden. Wer sie trennt, plant Integrationsprojekte realistischer.

Ebene 1: Protokolle und Transport

Die erste Ebene ist die technische Verbindung: Wie gelangen Bits von einem Gerät zur Software? In der Gebäudetechnik haben sich dafür über Jahrzehnte unterschiedliche Protokolle entwickelt, jedes mit eigenem Zweck.

BACnet ist als ISO 16484-5 international genormt. Die Norm definiert Kommunikationsdienste und Protokolle für Geräte, die Heizung, Lüftung, Klima, Kälte und andere Gebäudesysteme überwachen und steuern, und liefert dazu ein objektorientiertes Modell der ausgetauschten Informationen [8]. Ein Temperaturfühler erscheint in BACnet zum Beispiel als Objekt mit Eigenschaften wie aktuellem Wert und Einheit. Mit BACnet Secure Connect (BACnet/SC) gibt es eine Variante, die Nachrichten über WebSockets und TLS mit gegenseitiger Authentifizierung und Verschlüsselung überträgt [9].

Modbus stammt aus dem Jahr 1979 und wurde von Modicon für die Kommunikation zwischen Steuerungen entwickelt; seit 1999 gibt es eine offene Spezifikation für Modbus TCP/IP [10]. In Gebäuden findet man Modbus häufig bei Zählern, Wärmepumpen oder Wechselrichtern. Das Protokoll überträgt Registerwerte; was ein Register bedeutet, steht in der Dokumentation des Herstellers. Seit 2018 beschreibt die Modbus Organization mit „Modbus Security“ eine Variante, die Modbus-Pakete in TLS einbettet und X.509-Zertifikate zur Authentifizierung nutzt [11].

KNX ist als EN 50090 und ISO/IEC 14543-3 genormt und wird vor allem für Raum- und Elektroinstallation genutzt: Licht, Jalousien, Heizung und Klima [12].

MQTT ist ein schlankes Publish-Subscribe-Protokoll. Die OASIS-Spezifikation beschreibt es als Client-Server-Nachrichtenprotokoll, das für Geräte und Netze mit begrenzten Ressourcen gedacht ist, etwa im Internet der Dinge [13]. Sensoren veröffentlichen Werte unter einem Thema, und beliebig viele Empfänger können dieses Thema abonnieren.

OPC UA (IEC 62541) ist eine plattformunabhängige, serviceorientierte Architektur aus der Industrieautomation. Sie bringt ein eigenes Informationsmodell mit und unterstützt Verschlüsselung, Signaturen und Zertifikate [14].

REST/JSON-APIs und Webhooks sind die übliche Sprache von Web- und Cloud-Software. Eine REST-API wird abgefragt („Gib mir die Werte von Raum X seit gestern“), ein Webhook meldet sich von selbst, wenn ein Ereignis eintritt. Mit der OpenAPI-Spezifikation lassen sich solche HTTP-Schnittstellen programmiersprachenunabhängig beschreiben, sodass Entwickler und Werkzeuge verstehen, was ein Dienst anbietet [15].

Tabelle 1: Protokolle und Schnittstellenarten in Gebäuden im Vergleich. Die Sicherheitsfunktionen müssen von Geräten und Installation tatsächlich unterstützt und genutzt werden.

Die Tabelle zeigt ein Muster: Die Feldprotokolle (BACnet, Modbus, KNX) sind für das lokale Gebäudenetz gemacht. Für Software, die außerhalb des Gebäudes läuft, ist meist eine API die bessere Schnittstelle. Dazwischen sitzt ein Gateway oder eine Plattform, die übersetzt.

Ebene 2: Datenmodell und Semantik

Die zweite Ebene ist die Bedeutung der Daten. Ein Wert „21,4“ ist ohne Kontext wertlos. Erst die Information „Raumtemperatur, Raum B-03-014, Grad Celsius, gemessen um 10:05 Uhr, gehört zur Lüftungsanlage RLT 2“ macht ihn nutzbar. In bestehenden Gebäuden steckt diese Information oft nur in Datenpunktnamen, die jeder Errichter anders bildet.

Dafür gibt es offene Ansätze:

• Brick Schema ist ein Open-Source-Projekt, das physische, logische und virtuelle Bestandteile von Gebäuden und deren Beziehungen semantisch beschreibt [6]. In der Ursprungsarbeit von Balaji und Kollegen (2016) wurden die Sensormetadaten von sechs Gebäuden mit rund 17.700 Datenpunkten in Brick abgebildet; acht Anwendungen liefen danach ohne Anpassung auf allen sechs Gebäuden [5]. Das ist ein Machbarkeitsnachweis an wenigen Gebäuden, kein Beleg für beliebige Bestände.
• Project Haystack ist eine Open-Source-Initiative für standardisierte semantische Datenmodelle und Webdienste für Daten aus Gebäuden und anderen vernetzten Systemen [7].
• BACnet-Objekte liefern bereits ein Grundgerüst (Objekttyp, Wert, Einheit), beschreiben aber nicht vollständig, wie Räume, Anlagen und Sensoren zusammenhängen [8].
• IFC (Industry Foundation Classes) ist der offene, herstellerneutrale Standard für die digitale Beschreibung von Bauwerken; die aktuelle Version IFC 4.3 ist als ISO 16739-1:2024 veröffentlicht [16]. IFC beschreibt vor allem Gebäude, Räume und Bauteile aus Planung und Bau und kann als Quelle für Raum-IDs und Flächen dienen, enthält aber keine laufenden Messwerte.

Wie anspruchsvoll diese Ebene ist, zeigt eine Übersichtsarbeit von Pritoni und Kollegen (2021) im Fachjournal Energies. Die Autoren fanden 40 Metadatenschemata und Ontologien für Gebäude, untersuchten fünf verbreitete davon genauer anhand von drei Anwendungsfällen und kamen zu dem Schluss, dass es mit den vorhandenen Ansätzen „schwierig, arbeitsintensiv und teuer“ sei, semantische Modelle zu erstellen und zu pflegen [4].

Für das Facility Management gibt es eigene Regelwerke. Die GEFMA-Richtlinienreihe 400 behandelt unter anderem CAFM-Begriffe und Leistungsmerkmale (GEFMA 400), „Schnittstellen zur IT-Integration von CAFM-Software“ (GEFMA 410), Datenbasis und Datenmanagement (GEFMA 430) und Datenaustausch im Facility Management (GEFMA 470); die Schnittstelle zwischen Gebäudeautomation und FM ist Gegenstand von VDI/GEFMA 3814 Blatt 3.1 [3]. Schon die Titel zeigen: Schnittstellen sind im FM ein eigenes Planungsthema.

Ebene 3: Datenqualität

Die dritte Ebene ist die Qualität der Werte selbst. Gwerder und Kollegen (2022) beschreiben, dass Daten aus Gebäudeautomationssystemen häufig mangelhaft sind, weil Fehler bei Installation, Inbetriebnahme, Datenaufzeichnung oder Metainformationen auftreten; Teams in Planung und Service konzentrieren sich meist auf die Regelfunktion, nicht auf die Datenerfassung [17]. Die Autoren schlagen deshalb Plausibilitätsprüfungen vor, bevor Daten ausgewertet werden [17].

Lin und Kollegen (2024) haben Zeitreihen aus einem australischen Gebäude mit 731 Datenströmen untersucht und typische Probleme benannt: unterschiedliche Abtastintervalle (zum Beispiel 1, 5 oder 10 Minuten oder täglich), Lücken durch Netzwerkverzögerungen oder Sensorausfälle, schwierige Synchronisierung von Zeitstempeln und uneinheitliche Bezeichnungen zwischen Gebäuden und sogar zwischen Softwareversionen [18]. Es handelt sich um ein Preprint mit einem einzelnen Gebäude als Fallstudie.

Typische Prüfpunkte für die Datenqualität sind:

• Zeitstempel: Zeitzone und Sommerzeit eindeutig (zum Beispiel immer UTC mit Offset), Zeitpunkt der Messung statt Zeitpunkt des Empfangs, synchronisierte Uhren.
• Einheiten: Grad Celsius oder Kelvin, kWh oder Wh, ppm, µg/m³ – ausdrücklich mitgeliefert, nicht nur dokumentiert.
• Lücken: Fehlende Werte als fehlend kennzeichnen, nicht stillschweigend mit null oder dem letzten Wert füllen.
• Metadaten: Raum, Anlage, Messgröße und Gerät eindeutig zugeordnet; Änderungen (Umzug eines Sensors, Tausch eines Zählers) mit Datum dokumentiert.
• Plausibilität: Werte außerhalb physikalisch sinnvoller Bereiche oder eingefrorene Werte erkennen.

Folgen und typische Fehler

Wer die drei Ebenen nicht trennt, landet häufig bei einem der folgenden Fehler.

Punkt-zu-Punkt-Verbindungen ohne Plan. Jede neue Anforderung bekommt eine eigene Schnittstelle: GLT an CAFM, Zähler an BI, Sensoren an ein Dashboard. Bei fünf Systemen sind theoretisch bis zu zehn Verbindungen möglich, jede mit eigenem Mapping. Ändert sich ein System, brechen mehrere Verbindungen gleichzeitig.

Protokoll gewählt, Bedeutung vergessen. Ein Projekt beschließt „wir nehmen MQTT“ und stellt später fest, dass jeder Lieferant Themen und Nutzlasten anders aufbaut. MQTT legt den Inhalt der Nachricht nicht fest [13]; das Datenmodell muss das Projekt selbst definieren.

Rohdaten ins CAFM. Ein CAFM-System ist für Objekte, Flächen, Aufträge und Verträge gebaut, nicht für Millionen Messwerte. Wer jede Minute jeden Sensorwert hineinschreibt, belastet die Datenbank und die Nutzer. Sinnvoller ist es, dort nur Zustände, Kennzahlen oder Auffälligkeiten zu speichern und für Zeitreihen auf eine spezialisierte Plattform zu verweisen.

Rechenbeispiel Datenmenge. Annahmen: 200 Räume, je sechs Messgrößen (zum Beispiel CO₂, Temperatur, Feuchte, Feinstaub, VOC, Licht), ein Wert alle fünf Minuten. Das ergibt 200 × 6 × 288 = 345.600 Werte pro Tag und rund 126 Millionen Werte pro Jahr. Die Zahl hängt stark von Raumzahl und Messintervall ab; sie zeigt aber, warum Zeitreihen und Stammdaten getrennt gehalten werden sollten.

Gebäudenetz direkt ins Internet. Ein BACnet- oder Modbus-Gerät per Portweiterleitung aus dem Internet erreichbar zu machen, ist schnell eingerichtet. Die gesicherten Varianten BACnet/SC und Modbus Security (2018) sind jüngere Ergänzungen [9][11] und in älteren Anlagen nicht unbedingt vorhanden. Ohne Netztrennung wird das Gebäudenetz Teil der Angriffsfläche.

Datenschutz am Ende. Werden Präsenz- oder CO₂-Werte pro Einzelbüro ausgewertet, sind Rückschlüsse auf einzelne Beschäftigte möglich. Fällt das erst nach dem Go-live auf, ist ein Umbau teuer.

Lösungen: Architektur, Datenmodell, Sicherheit und Entscheidung

Integrationsschritte im Überblick

Integrationsprojekte sollten mit dem Zweck beginnen, nicht mit dem Protokoll. Abbildung 2 zeigt eine bewährte Reihenfolge.

Abbildung 2: Typische Schritte eines Integrationsprojekts für Gebäudedaten. Eigene Darstellung.

1. Ziele klären: Welche Frage soll die Software beantworten? „Welche Räume sind dauerhaft schlecht belüftet?“ braucht andere Daten und Taktungen als „Wie hoch war der Wärmeverbrauch je Liegenschaft im Monat?“.
2. Bestand erfassen: Welche Systeme, Protokolle und Datenpunkte gibt es? Wer ist Ansprechpartner (Errichter, Wartungsfirma, IT)? Eine Datenpunktliste ist die Grundlage für alles Weitere.
3. Datenmodell festlegen: Einheitliche Raum- und Anlagen-IDs, Einheiten, Zeitformat. Ob ein offenes Schema wie Brick oder Haystack genutzt wird oder ein eigenes, schlankes Modell, hängt vom Umfang ab. Wichtig ist, dass die Zuordnung zu den CAFM-Stammdaten eindeutig ist.
4. Anbindung und Sicherheit: Gateway vor Ort oder direkte Cloud-Anbindung, Netztrennung, Zugriffsrechte, Verschlüsselung.
5. Datenqualität prüfen: Zeitstempel, Lücken, Plausibilität, stichprobenartiger Abgleich mit der Situation vor Ort.
6. Betrieb: Überwachung der Datenflüsse, Versionierung der API, Dokumentation von Änderungen.

Die CAFM Schnittstelle: was gehört wohin?

Für Hersteller von CAFM- und Property-Management-Software ist die zentrale Frage nicht, ob Messwerte angebunden werden, sondern wie viel davon. Eine bewährte Aufteilung ist:

• Im CAFM: Stammdaten (Gebäude, Geschosse, Räume, Anlagen), Zuordnung von Sensoren zu Räumen, Zustände und Auffälligkeiten (zum Beispiel „CO₂ in Raum X an fünf Tagen über einem vereinbarten Schwellenwert“), daraus entstehende Aufträge.
• In der Datenplattform: Zeitreihen in voller Auflösung, Trends, Auswertungen, Vergleiche über Liegenschaften.
• Über die Schnittstelle: Abfragen von Kennzahlen und Verläufen bei Bedarf, Ereignismeldungen per Webhook bei Auffälligkeiten, Rücklesen der Raumstammdaten aus dem CAFM.

Wie Raumklimadaten konkret im CAFM nutzbar werden, beschreibt Nebatic auf der Seite Raumklimadaten im CAFM. Die Richtlinie GEFMA 410 behandelt die IT-Integration von CAFM-Software grundsätzlich [3].

Eine Sensordaten API richtig gestalten

Wer selbst eine Sensordaten API anbietet oder eine fremde nutzt, sollte auf einige Eigenschaften achten:

• Struktur nach Gebäude, Geschoss und Raum, nicht nur nach Gerät, damit Daten auch nach einem Gerätetausch zusammenpassen.
• Einheiten und Zeitzonen im Datensatz, nicht nur in der Dokumentation.
• Abfrage und Push kombiniert: REST für Verläufe und Berichte, Webhooks für Ereignisse.
• Beschreibung als OpenAPI-Dokument, damit Entwickler Clients erzeugen und Änderungen nachvollziehen können [15].
• Versionierung und Abkündigungsfristen, damit Integrationen nicht unangekündigt brechen.
• Feingranulare Rechte: Ein Dienstleister sieht nur seine Liegenschaften, ein Mieter nur seine Flächen.

Diese Punkte gelten unabhängig davon, ob man von einer „Smart Building API“ oder einer „Open API“ spricht. Entscheidend ist, dass die Schnittstelle dokumentiert, stabil und für Dritte nutzbar ist – genau das, was § 56 GModG mit „gängig und frei konfigurierbar“ für Gebäudeautomationssysteme verlangt [1].

Gateway vor Ort oder Cloud? BACnet und Modbus in der Cloud nutzen

Begriffe wie „BACnet Cloud“ oder „Modbus Cloud“ beschreiben meist kein neues Protokoll, sondern eine Architektur: Ein Gateway im Gebäude liest die Feldprotokolle lokal und überträgt die Werte verschlüsselt an eine Plattform, die sie über eine API bereitstellt. Die Feldprotokolle selbst bleiben im Gebäudenetz.

Abbildung 3: Beispielarchitektur mit getrennten Netzzonen nach dem Zonenprinzip. Eigene Darstellung in Anlehnung an IEC 62443-3-2 [22].

Tabelle 2: Zwei Anbindungswege im Vergleich. In vielen Gebäuden werden beide kombiniert.

Wie bestehende Anlagen und neue Sensoren in einer Datenbasis zusammenkommen, beschreibt die Seite Umfassende Datenintegration. Für Sensornetze, die per MQTT oder ähnlichen Protokollen Daten liefern, ist die Seite IoT-Sensorik für Gebäude der passende Einstieg. MQTT im Gebäude eignet sich vor allem als Transport zwischen Gateway oder Sensor und Plattform; als Schnittstelle zur Fachsoftware ist eine dokumentierte API meist einfacher zu nutzen.

IT-Sicherheit für Gebäudetechnik

Gebäudeautomation ist Betriebstechnik, und ihre Absicherung folgt eigenen Regelwerken:

• Das BSI IT-Grundschutz-Kompendium enthält zwei Bausteine für Gebäude: INF.13 Technisches Gebäudemanagement und INF.14 Gebäudeautomation [19][20]. Ziel beider Bausteine ist es, Informationssicherheit als festen Bestandteil von Planung, Umsetzung und Betrieb zu verankern [19][20].
• Das VDMA-Einheitsblatt 24774 „IT-Sicherheit in der Gebäudeautomation“ beschreibt einen praxisnahen Ansatz: Risikoanalyse, Sicherheitskonzept über den gesamten Lebenszyklus, Trennung des GA-Netzes von anderen Netzen, Firewalls an Segmentgrenzen, gesicherter Fernzugriff, verschlüsselte Web- und Konfigurationsschnittstellen, Protokollierung, Updates und Datensicherung [21].
• Die Normenreihe IEC 62443 wurde für industrielle Automatisierungs- und Steuerungssysteme entwickelt. Ihr Konzept von Zonen und Kommunikationskanälen („zones and conduits“) gruppiert Anlagenteile nach Risiko und regelt die Kommunikation zwischen ihnen [22]. Es lässt sich als Denkmodell auf Gebäudenetze übertragen; die Norm selbst nennt Gebäudeautomation nicht ausdrücklich als Anwendungsbereich.

Für die Praxis bedeutet das: Gateways stehen in einem eigenen Netzsegment, bauen Verbindungen nur nach außen auf, übertragen verschlüsselt und haben nur Leserechte, solange keine Steuerung vereinbart ist. Schreibende Zugriffe auf Regler sollten bewusst entschieden, dokumentiert und mit dem Errichter abgestimmt werden.

Wenn Raumdaten personenbezogen werden: DSGVO

Personenbezogene Daten sind nach Art. 4 Nr. 1 DSGVO alle Informationen über eine identifizierte oder identifizierbare natürliche Person; identifizierbar ist eine Person auch, wenn sie indirekt bestimmt werden kann, zum Beispiel über Standortdaten [24]. CO₂-, Präsenz- oder Lärmwerte eines Einzelbüros können damit personenbezogen werden, wenn bekannt ist, wer dort sitzt. In Großraumflächen oder bei zusammengefassten Werten ist das seltener der Fall.

Daraus folgen einige Gestaltungsregeln:

• Datenschutz durch Technikgestaltung (Art. 25 DSGVO): nur die nötigen Daten erfassen, Zeitauflösung und räumliche Zuordnung so grob wie möglich wählen, Pseudonymisierung nutzen [25].
• Datenschutz-Folgenabschätzung (Art. 35 DSGVO): Sie ist nötig, wenn eine Verarbeitung, insbesondere mit neuen Technologien, voraussichtlich ein hohes Risiko für Betroffene hat [26].
• Mitbestimmung: Nach § 87 Abs. 1 Nr. 6 Betriebsverfassungsgesetz hat der Betriebsrat bei der Einführung technischer Einrichtungen mitzubestimmen, die dazu bestimmt sind, Verhalten oder Leistung der Beschäftigten zu überwachen [27]. Ob Raumsensoren darunterfallen, hängt von der konkreten Gestaltung ab und sollte früh geklärt werden.
• Auftragsverarbeitung: Verarbeitet ein Plattformanbieter Daten im Auftrag, braucht es einen Vertrag oder ein anderes Rechtsinstrument nach Art. 28 DSGVO [23].

(Allgemeine Information, kein Rechtsrat, Stand: Oktober 2026. Im Einzelfall sind Datenschutzbeauftragte und Rechtsberatung die richtigen Ansprechpartner.)

Selbst bauen oder einkaufen?

Softwarehersteller stehen vor der Wahl, die Anbindung an Gebäudetechnik selbst zu entwickeln oder eine bestehende Plattform per API zu nutzen. Beide Wege sind legitim; die Entscheidung hängt weniger von der Technik als von Kernkompetenz und Betriebsaufwand ab.

Tabelle 3: Entscheidungskriterien für Eigenentwicklung oder Plattformnutzung.

Bei einer Plattformlösung sollten Vertrag und Technik sicherstellen, dass Daten jederzeit in einem offenen Format exportiert werden können. Das schützt vor Abhängigkeit und entspricht dem Gedanken herstellerunabhängiger Auswertung, den auch § 56 GModG formuliert [1].

Wie Nebatic dabei unterstützt

Nebatic stellt die Daten seiner eigenen Geräte (Raumklima, Luftqualität, Licht, Schall) und angebundener Systeme über APIs bereit, damit sie in CAFM-, BI- oder ESG-Software und eigene Anwendungen fließen können. Zugang, Umfang und Datenstruktur werden je Projekt vereinbart. Bestehende Sensoren, Zähler und Gebäudesysteme bindet Nebatic je nach Projekt über passende Schnittstellen an, in Zusammenarbeit mit den zuständigen Errichtern und Integratoren. Details beschreibt die Seite Gebäudedaten-API.

Für Dienstleister, die Monitoring unter eigener Marke anbieten möchten, ist auch ein White-Label-Betrieb möglich. Wie die Zusammenarbeit mit Integratoren und Fachbetrieben aussieht, steht unter Technik- und Servicepartner; Angebote für Betreiber und Dienstleister finden sich unter Facility Management.

Nebatic ersetzt keine Gebäudeautomation, keine sicherheitsrelevanten Alarmsysteme und keine Herstellerwartung. Die Installation klassischer Gebäudeautomation bleibt Aufgabe der Fachbetriebe.

Grenzen und Risiken

Eine gute Schnittstelle macht Daten verfügbar; sie macht sie nicht automatisch richtig. Falsch montierte oder falsch zugeordnete Sensoren liefern auch über eine perfekte API falsche Aussagen. Plausibilitätsprüfungen und Stichproben vor Ort bleiben nötig [17].

Offene Schemata wie Brick oder Haystack erleichtern die Wiederverwendung, verursachen aber selbst Aufwand für Modellierung und Pflege [4]. Für kleine Bestände kann ein schlankes eigenes Datenmodell wirtschaftlicher sein, solange es dokumentiert ist.

Schreibende Zugriffe auf Gebäudeautomation – also Sollwerte oder Betriebsarten aus fremder Software ändern – greifen in Regelung und gegebenenfalls in die Gewährleistung des Errichters ein. Sie gehören in die Hand von Fachplanern und Errichtern und sollten vertraglich geregelt sein.

Zu IT-Sicherheit beraten IT-Sicherheitsverantwortliche des Betreibers und spezialisierte Dienstleister; zu Datenschutz die Datenschutzbeauftragten und gegebenenfalls der Betriebsrat; zu Pflichten aus dem GModG Energieberater und Fachplaner. Verbindlich ist jeweils der Originaltext der genannten Normen und Richtlinien.

Häufige Fragen

Was ist eine Gebäudedaten Schnittstelle?

Eine Gebäudedaten Schnittstelle ist eine definierte Verbindung, über die Messwerte, Zustände und Stammdaten aus Gebäudetechnik und Sensoren an andere Software übergeben werden. Sie umfasst das technische Protokoll, ein Datenmodell (welcher Wert gehört zu welchem Raum und welcher Einheit) und Regeln für Zugriff und Sicherheit.

Wie funktioniert eine CAFM Schnittstelle für Raumklimadaten?

Üblich ist, dass eine Datenplattform die Zeitreihen speichert und das CAFM über eine API nur Kennzahlen, Zustände oder Auffälligkeiten pro Raum abruft oder per Webhook erhält. Die Raum-IDs werden dabei mit den CAFM-Stammdaten abgeglichen, damit Werte und Aufträge im richtigen Raum landen.

Was sollte eine Sensordaten API mindestens liefern?

Messwert, Einheit, Zeitstempel mit Zeitzone, eindeutige Zuordnung zu Gebäude, Geschoss und Raum sowie eine Kennzeichnung fehlender Werte. Hinzu kommen eine maschinenlesbare Beschreibung, etwa nach der OpenAPI-Spezifikation, eine Versionierung und ein Rechtekonzept.

Gibt es BACnet in der Cloud?

BACnet ist für Gebäudenetze entworfen. In der Praxis liest meist ein Gateway die BACnet-Daten lokal und überträgt sie verschlüsselt an eine Plattform. Mit BACnet/SC gibt es zudem eine Variante mit TLS-Verschlüsselung und Zertifikaten, die sich besser für IP-Netze mit IT-Sicherheitsanforderungen eignet [9].

Wofür eignet sich MQTT im Gebäude?

MQTT eignet sich für den Transport vieler kleiner Messwerte von Sensoren oder Gateways zu einer Plattform, weil es schlank ist und nach dem Publish-Subscribe-Prinzip arbeitet [13]. Inhalt und Struktur der Nachrichten legt MQTT nicht fest; dafür braucht es ein eigenes Datenmodell.

Kann ich Modbus-Zähler in die Cloud bringen?

Ja, meist über ein Gateway, das die Register der Zähler lokal abfragt, in Messwerte mit Einheiten übersetzt und verschlüsselt weitergibt. Dafür wird die Registerliste des Zählerherstellers benötigt. Modbus-Geräte direkt aus dem Internet erreichbar zu machen, ist aus Sicherheitsgründen nicht zu empfehlen.

Was bedeutet „Open API“ in der Gebäudetechnik?

Gemeint ist meist eine dokumentierte, für Dritte nutzbare Schnittstelle, nicht zwingend eine öffentlich und kostenlos zugängliche. Für Betreiber ist wichtig, dass Daten herstellerunabhängig ausgewertet werden können; § 56 GModG verlangt für Gebäudeautomationssysteme in Nichtwohngebäuden eine „gängige und frei konfigurierbare Schnittstelle“ [1].

Was unterscheidet eine Smart Building API von einem Datenexport?

Ein Export liefert einmalig Dateien, etwa CSV. Eine Smart Building API stellt Daten laufend, strukturiert und abfragbar bereit und kann bei Ereignissen von selbst melden. Für dauerhafte Prozesse im Facility Management ist eine API in der Regel die robustere Lösung.

Quellen

1. Bundesministerium der Justiz / Bundesamt für Justiz (2026): Gebäudemodernisierungsgesetz (GModG), § 56 Gebäudeautomatisierung und Gebäudesteuerung. https://www.gesetze-im-internet.de/geg/__56.html
2. O’Connor, A. C.; Dettbarn, J. L.; Gilday, L. T. (2004): Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. NIST GCR 04-867. https://nvlpubs.nist.gov/nistpubs/gcr/2004/NIST.GCR.04-867.pdf
3. GEFMA – Deutscher Verband für Facility Management (2026): Gesamtverzeichnis der GEFMA-Richtlinien (Stand 14.07.2026), Reihe 400 (u. a. GEFMA 400, 410, 430, 470; VDI/GEFMA 3814 Blatt 3.1). https://www.gefma.de/fileadmin/user_upload/richtlinie/00_Gesamtverzeichnis_2026-07-14.pdf
4. Pritoni, M.; Paine, D.; Fierro, G.; Mosiman, C.; Poplawski, M.; Saha, A.; Bender, J.; Granderson, J. (2021): Metadata Schemas and Ontologies for Building Energy Applications: A Critical Review and Use Case Analysis. Energies 14(7), 2024. https://bies.lbl.gov/publications/metadata-schemas-and-ontologies
5. Balaji, B. et al. (2016): Brick: Towards a Unified Metadata Schema for Buildings. BuildSys ‘16, ACM, S. 41–50. https://par.nsf.gov/biblio/10048267
6. Brick Consortium: Brick Schema. https://brickschema.org/
7. Project Haystack: Project Haystack. https://project-haystack.org/
8. ISO (2022): ISO 16484-5:2022 Building automation and control systems (BACS) – Part 5: Data communication protocol (inzwischen ersetzt durch ISO 16484-5:2026). https://committee.iso.org/standard/84964.html
9. BACnet International: BACnet Secure Connect (BACnet/SC). https://bacnetinternational.org/bacnetsc/
10. Modbus Organization: Modbus FAQ. https://www.modbus.org/faq
11. Modbus Organization (2018): Pressemitteilung zu Modbus Security (29.10.2018). https://www.modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
12. Baunetz Wissen: KNX-Bussystem. https://www.baunetzwissen.de/elektro/fachwissen/gebaeudesystemtechnik/knx-bussystem-153108
13. OASIS (2019): MQTT Version 5.0, OASIS Standard, 7. März 2019. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
14. OPC Foundation: Unified Architecture (OPC UA). https://opcfoundation.org/about/opc-technologies/opc-ua/
15. OpenAPI Initiative (2026): OpenAPI Specification v3.2.1. https://spec.openapis.org/oas/latest.html
16. buildingSMART International: Industry Foundation Classes (IFC). https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/
17. Gwerder, M.; Marek, R.; Melillo, A.; Husmann, M. (2022): Data Integrity Checks for Building Automation and Control Systems. CLIMA 2022. https://proceedings.open.tudelft.nl/clima2022/article/view/271
18. Lin, X.; Prabowo, A.; Razzak, I.; Xue, H.; Amos, M.; Behrens, S.; Salim, F. D. (2024): A Gap in Time: The Challenge of Processing Heterogeneous IoT Data in Digitalized Buildings. arXiv-Preprint 2405.14267. https://arxiv.org/abs/2405.14267
19. Bundesamt für Sicherheit in der Informationstechnik (2023): IT-Grundschutz-Kompendium, Baustein INF.14 Gebäudeautomation (Edition 2023). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/10_INF_Infrastruktur/INF_14_Gebaeudeautomation_Edition_2023.pdf?__blob=publicationFile&v=3
20. Bundesamt für Sicherheit in der Informationstechnik (2023): IT-Grundschutz-Kompendium, Baustein INF.13 Technisches Gebäudemanagement (Edition 2023). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/10_INF_Infrastruktur/INF_13_Technisches_Gebaeudemanagement_Edition_2023.pdf?__blob=publicationFile&v=3
21. VDMA Fachverband Allgemeine Lufttechnik (2026): Empfehlung für Ausschreibungstexte basierend auf VDMA-Einheitsblatt 24774 „IT-Sicherheit in der Gebäudeautomation“. https://www.vdma.eu/documents/d/group-34568/2026-03-vdma-fv-amg-empfehlung-ausschreibungstexte-basierend-auf-eb-24774
22. IEC Systems Committee Smart Energy: IEC 62443 – Background. https://syc-se.iec.ch/deliveries/cybersecurity-guidelines/security-standards-and-best-practices/iec-62443/
23. DSGVO – Verordnung (EU) 2016/679, Art. 28 Auftragsverarbeiter (Textausgabe; amtlicher Text: https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679). https://dsgvo-gesetz.de/art-28-dsgvo/
24. DSGVO Art. 4 Begriffsbestimmungen (Textausgabe). https://dsgvo-gesetz.de/art-4-dsgvo/
25. DSGVO Art. 25 Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Textausgabe). https://dsgvo-gesetz.de/art-25-dsgvo/
26. DSGVO Art. 35 Datenschutz-Folgenabschätzung (Textausgabe). https://dsgvo-gesetz.de/art-35-dsgvo/
27. Bundesministerium der Justiz / Bundesamt für Justiz: Betriebsverfassungsgesetz, § 87 Mitbestimmungsrechte. https://www.gesetze-im-internet.de/betrvg/__87.html