KNX IoT

KNX trifft Internet der Dinge

KNX ist seit über 30 Jahren der weltweit führende Standard für Gebäudeautomation. Das Internet der Dinge (IoT) revolutioniert seit einem Jahrzehnt, wie Geräte miteinander kommunizieren — über die Cloud, per REST-API, mit Smartphone und Sprachassistent. Lange galten diese beiden Welten als getrennt: KNX war robust, lokal und zuverlässig, IoT war flexibel, vernetzt und cloudbasiert.

Seit 2020 bringt die KNX IoT Third Party API diese Welten zusammen. Sie gibt dem KNX-System eine standardisierte Schnittstelle zur Außenwelt — und macht KNX-Installationen zum vollwertigen Teil des IoT-Ökosystems, ohne die Zuverlässigkeit des TP-Busses zu opfern.

In diesem Artikel erfahren Sie, was KNX IoT technisch bedeutet, welche Möglichkeiten es eröffnet und wie ein erfahrener KNX Systemintegrator diese Technologie in der Praxis einsetzt.

Was KNX IoT ist — und was nicht

KNX IoT ist kein neues Bussystem und kein Ersatz für den bewährten KNX-TP-Bus. Es ist eine Ergänzung: eine standardisierte Schnittstelle, die KNX-Installationen für die Welt der IP-basierten Dienste öffnet.

Konkret umfasst KNX IoT drei Bausteine:

1. KNX IoT Third Party API: Eine RESTful API, die auf dem KNX/IP-Interface oder einem dedizierten IoT-Gateway läuft. Über sie können externe Anwendungen — vom Smartphone-App bis zum Cloud-Service — KNX-Datenpunkte lesen und schreiben. Die API nutzt IPv6 über Thread oder Wi-Fi und kommuniziert per CoAP (Constrained Application Protocol) oder HTTP/REST.

2. KNX IoT Point API: Die interne Schnittstelle, über die KNX-IoT-Geräte direkt im IP-Netzwerk kommunizieren — ohne den Umweg über den TP-Bus. Diese Geräte sprechen nativ IPv6 und werden über Thread-Mesh-Netzwerke verbunden.

3. KNX Classic TP/RF: Der bewährte Bus bleibt das Rückgrat der Installation. KNX IoT ersetzt ihn nicht, sondern ergänzt ihn um IP-basierte Kommunikationskanäle.

Der entscheidende Unterschied zu proprietären Smart-Home-APIs: KNX IoT ist herstellerübergreifend standardisiert. Jedes KNX-IoT-fähige Gerät — egal ob von ABB, Gira, MDT, Schneider Electric oder Weinzierl — spricht die gleiche API-Sprache. Das verhindert Vendor-Lock-in und garantiert Interoperabilität.

Die KNX IoT Third Party API im Detail

Die Third Party API ist das Herzstück der KNX-IoT-Integration. Sie macht jeden KNX-Datenpunkt über eine REST-Schnittstelle zugänglich — lesbar und schreibbar, mit Authentifizierung und Autorisierung.

Architektur

Die API folgt einem Gateway-Modell: Ein KNX/IP-Gateway (z. B. Weinzierl KNX IoT Interface, ABB IoT Gateway oder Gira X1) verbindet den KNX-TP-Bus mit dem IP-Netzwerk. Das Gateway übersetzt zwischen den KNX-Telegrammen auf dem Bus und den REST-Anfragen aus dem IP-Netzwerk.

Der Datenfluss:

• Lesen: Externe App → REST GET → IoT Gateway → KNX-Bus → Aktor antwortet mit aktuellem Status → Gateway → REST Response → App
• Schreiben: Externe App → REST PUT/POST → IoT Gateway → KNX-Telegramm auf den Bus → Aktor führt Befehl aus
• Events: Aktor ändert Status → KNX-Telegramm → IoT Gateway → WebSocket/SSE → App wird in Echtzeit benachrichtigt

Datenpunkte und Ressourcen

Jeder KNX-Datenpunkt wird als REST-Ressource abgebildet. Die URL-Struktur folgt dem Schema:

/api/v1/datapoints/{groupAddress}

Ein Beispiel: Die Gruppenadresse 1/2/1 (Beleuchtung Küche, Schalten) wird erreichbar unter:

GET /api/v1/datapoints/1/2/1 → Liefert den aktuellen Status (an/aus)

PUT /api/v1/datapoints/1/2/1 mit Body {"value": true} → Schaltet das Licht ein

Die API unterstützt alle KNX-Datenpunkttypen (DPT): Boolean (Schalten), Prozentwerte (Dimmen), Temperatur, Szenennummern, RGB-Farbwerte und viele mehr. Das Gateway übersetzt automatisch zwischen dem KNX-eigenen Datenformat und JSON.

Authentifizierung und Sicherheit

Die Third Party API implementiert OAuth 2.0 für die Authentifizierung. Jede Drittanbieter-App muss sich mit Client-Credentials authentifizieren und erhält ein zeitlich begrenztes Access-Token. Zusätzlich können Berechtigungen granular vergeben werden: App A darf nur die Beleuchtung steuern, App B hat Zugriff auf alle Datenpunkte.

Die Kommunikation erfolgt verschlüsselt über TLS 1.3. In Kombination mit KNX IP Secure entsteht eine durchgängig geschützte Kommunikationskette — vom Smartphone über das Internet, durch das lokale Netzwerk bis zum KNX-Bus.

KNX IoT-Geräte und Thread

Neben der Third Party API für die Anbindung externer Dienste gibt es eine zweite Entwicklung: native KNX-IoT-Geräte, die direkt im IP-Netzwerk kommunizieren — ohne den Umweg über den TP-Bus.

Thread als Übertragungsmedium

Thread ist ein IPv6-basiertes Mesh-Netzwerk-Protokoll, das speziell für IoT-Geräte entwickelt wurde. Es bietet:

• Selbstheilendes Mesh: Fällt ein Knoten aus, finden die anderen automatisch einen alternativen Pfad. Das macht Thread-Netzwerke extrem robust.
• Geringe Latenz: Typische Reaktionszeiten unter 100 ms — schnell genug für Lichtsteuerung und andere Echtzeit-Anwendungen.
• Energieeffizienz: Thread-Geräte können batteriebetrieben sein und trotzdem jederzeit erreichbar bleiben (Sleepy End Devices).
• IPv6 nativ: Jedes Gerät hat eine eigene IPv6-Adresse und ist direkt über das IP-Netzwerk adressierbar — ohne proprietäres Gateway.

KNX-IoT-Geräte mit Thread-Unterstützung können in bestehende KNX-Installationen integriert werden. Ein KNX-IoT/TP-Gateway verbindet die Thread-Welt mit dem klassischen TP-Bus. Für den Endanwender ist der Unterschied unsichtbar: Die Lichtsteuerung funktioniert identisch, egal ob der Tastensensor über TP-Kabel oder Thread-Funk kommuniziert.

Matter und KNX IoT

Die Verbindung zwischen KNX und Matter wird durch KNX IoT noch enger. Matter nutzt Thread als eines seiner primären Übertragungsmedien. KNX-IoT-Geräte, die über Thread kommunizieren, können theoretisch auch als Matter-Geräte sichtbar werden — was die Integration mit Apple HomeKit, Google Home und Amazon Alexa vereinfacht.

In der Praxis ist diese Bridge-Funktion noch in Entwicklung, aber die technische Grundlage steht: Beide Standards sprechen IPv6, beide unterstützen Thread, und die KNX Association arbeitet aktiv an der Interoperabilität.

Cloud-Anbindung — Möglichkeiten und Grenzen

Die KNX IoT API ermöglicht erstmals eine standardisierte Cloud-Anbindung für KNX-Installationen. Das eröffnet Szenarien, die mit dem klassischen TP-Bus allein nicht möglich waren:

Energiemonitoring und Analyse

KNX-Zähler und Sensoren liefern kontinuierlich Daten über Stromverbrauch, Raumtemperatur, Luftqualität und Sonneneinstrahlung. Über die IoT-API können diese Daten an Cloud-Plattformen gestreamt werden, die sie speichern, analysieren und visualisieren.

Ein typisches Szenario: Der Energiemanager eines Bürogebäudes sieht auf einem Dashboard in Echtzeit, welches Stockwerk wie viel Strom verbraucht. Machine-Learning-Algorithmen erkennen Muster und schlagen Optimierungen vor — etwa eine angepasste Heizungsregelung, die 15 % Energie spart.

Fernsteuerung und Benachrichtigung

Die Cloud-Anbindung ermöglicht echte Fernsteuerung — nicht über proprietäre Hersteller-Apps, sondern über eine standardisierte API. Das bedeutet:

• Eigene Apps oder Web-Interfaces können KNX-Datenpunkte steuern — ohne herstellerspezifische SDKs
• Push-Benachrichtigungen bei Ereignissen: Fenster offen bei Regen, Bewegung bei Abwesenheit, Temperaturalarm
• Geofencing: Das Smart Home erkennt via Smartphone-GPS, dass die Bewohner sich nähern, und startet die Begrüßungsszene — Licht an, Heizung hoch, Musik an

Integration mit Sprachassistenten

Die REST-API macht die Integration mit Amazon Alexa, Google Home und Apple Siri deutlich einfacher als der klassische Weg über proprietäre Gateways. Cloud-to-Cloud-Integrationen können direkt gegen die IoT-API entwickelt werden.

In der Praxis nutzen die meisten Bauherren heute allerdings den Weg über Home Assistant oder ioBroker als lokale Middleware — mit optionaler Cloud-Anbindung für den Fernzugriff. Das bietet den Vorteil, dass die Kernfunktionen auch ohne Internetverbindung arbeiten.

Grenzen der Cloud-Anbindung

Bei aller Begeisterung für Cloud-Funktionen gilt ein fundamentaler Grundsatz: Die Kernfunktionen eines KNX-Systems müssen lokal funktionieren. Licht, Heizung, Jalousien und Sicherheit dürfen niemals von einer Internetverbindung oder einem Cloud-Dienst abhängen.

Die IoT-API ist für Komfortfunktionen, Monitoring und Analyse gedacht — nicht als primärer Steuerungskanal. Das KNX-TP-Telegramm bleibt der verlässliche Pfad für zeitkritische Schaltbefehle. Fällt die Cloud oder das Internet aus, muss das Gebäude vollständig funktionsfähig bleiben.

Als KNX Systemintegrator rate ich dringend, diese Trennung in der Planung konsequent umzusetzen. Cloud-Optimierung ja, Cloud-Abhängigkeit nein.

Praxisszenarien: KNX IoT im Einsatz

Szenario 1: Villa mit Energieautarkie

Eine Villa in München mit 20 kWp Photovoltaikanlage, 15 kWh Batteriespeicher und Wärmepumpe. Die KNX-Installation steuert Beleuchtung, Beschattung und Heizung. Über die IoT-API werden die Energiedaten in eine Cloud-Plattform gestreamt:

• Eigenverbrauchsoptimierung: Wenn die PV-Anlage Überschuss produziert, erhöht die Cloud-Logik automatisch die Ladeleistung der Wallbox und senkt die Heizungs-Solltemperatur leicht ab, um Wärme zu speichern.
• Prognose: Wetterdaten werden mit historischen Verbrauchsmustern kombiniert. Am Vorabend berechnet das System, ob morgen genug Solarertrag zu erwarten ist — und entscheidet, ob der Batteriespeicher über Nacht aus dem Netz geladen werden muss.
• Reporting: Der Bauherr erhält monatliche Energieberichte mit Autarkiegrad, Einspeisung und Optimierungsvorschlägen.

Szenario 2: Bürogebäude mit Belegungsanalyse

Ein Bürogebäude mit 200 KNX-Präsenzmeldern in Einzelbüros und Besprechungsräumen. Die IoT-API streamt die Belegungsdaten in eine Analyseplattform:

• Raumauslastung: Das Facility Management sieht in Echtzeit, welche Räume belegt sind. Über Wochen und Monate entstehen Muster, die zeigen: Besprechungsraum 3 ist nur zu 15 % ausgelastet — er könnte in Einzelbüros umgewandelt werden.
• Bedarfsgerechte Reinigung: Reinigungsteams erhalten nur die Räume, die tatsächlich genutzt wurden. Das spart 30–40 % Reinigungskosten.
• Klimaoptimierung: Unbelegte Räume werden automatisch in den Energiesparmodus versetzt — Heizung runter, Licht aus, Lüftung auf Minimum.

Szenario 3: Hotelkette mit zentralem Management

Eine Hotelkette mit KNX-Installationen in 12 Häusern. Jedes Hotel hat ein IoT-Gateway, das die lokalen KNX-Daten an eine zentrale Cloud-Plattform sendet:

• Zentrale Konfiguration: Neue Szenen oder Logiken werden einmal definiert und auf alle Häuser ausgerollt. Der „Gute-Nacht-Modus" (alle Lichter aus, Jalousien runter, Heizung auf 18°C) wird zentral programmiert.
• Energiebenchmarking: Vergleich des Energieverbrauchs pro Zimmer über alle Hotels hinweg. Ausreißer werden identifiziert und optimiert.
• Predictive Maintenance: Wenn ein Dimmaktor ungewöhnlich viele Fehlertelegramme sendet, wird automatisch ein Wartungsticket erstellt — bevor der Gast ein Problem bemerkt.

Szenario 4: Nachrüstung Bestandsgebäude

Ein Bestandsgebäude mit klassischer KNX-TP-Installation aus 2008 soll IoT-fähig werden. Der Aufwand ist überschaubar:

• IoT-Gateway installieren: Ein KNX/IP-Router mit IoT-Funktion wird in den Schaltschrank eingebaut und an das bestehende KNX-System angeschlossen.
• Konfiguration: In der ETS werden die Datenpunkte definiert, die über die API zugänglich sein sollen. Nicht jeder Datenpunkt muss exponiert werden — das erhöht die Sicherheit.
• Integration: Die API ist sofort nutzbar. Home Assistant, ioBroker oder eigene Anwendungen können sich verbinden.

Die bestehende KNX-Installation wird dabei nicht verändert. Alle bisherigen Funktionen arbeiten weiter wie gewohnt. Die IoT-Anbindung ist eine reine Erweiterung — ein zusätzlicher Kommunikationskanal, kein Umbau.

Gerade bei Altbau-Nachrüstungen ist KNX IoT ein starkes Argument: Das bestehende System wird nicht nur modernisiert, sondern zukunftsfähig gemacht.

KNX IoT vs. proprietäre Smart-Home-Systeme

Der Markt für Smart-Home-Lösungen ist voll von proprietären Systemen, die ebenfalls IoT-Fähigkeiten bieten. Wie positioniert sich KNX IoT im Vergleich?

Der Vergleich mit Loxone oder anderen proprietären Systemen fällt bei den IoT-Fähigkeiten besonders deutlich aus: Während Loxone eine eigene, geschlossene API bietet, setzt KNX IoT auf einen offenen Standard, der von der gesamten Branche getragen wird.

Implementierung: Best Practices

Wer KNX IoT in ein Projekt integriert, sollte folgende Grundsätze beachten:

1. Security-by-Design: Die IoT-API öffnet das KNX-System nach außen. Das erfordert ein durchdachtes Sicherheitskonzept: OAuth-Tokens mit kurzer Gültigkeit, granulare Berechtigungen, TLS-Verschlüsselung, Firewall-Regeln. Kein Datenpunkt sollte ohne explizite Freigabe über die API erreichbar sein.

2. Lokale Intelligenz zuerst: Die Kernlogik gehört auf den KNX-Bus — nicht in die Cloud. Szenen, Zeitschaltuhren und Sicherheitsfunktionen müssen lokal laufen. Die Cloud ergänzt um Analyse, Optimierung und Komfort.

3. Datensparsamkeit: Nicht jeden Datenpunkt in die Cloud streamen. Ein Temperatursensor, der alle 30 Sekunden misst, erzeugt 2.880 Datenpunkte pro Tag — pro Sensor. Intelligentes Filtern (nur bei Änderung senden, Intervalle reduzieren) hält das Datenvolumen und die Kosten im Rahmen.

4. Redundanz planen: Was passiert, wenn das IoT-Gateway ausfällt? Wenn die Internetverbindung abreißt? Wenn der Cloud-Dienst nicht erreichbar ist? Jedes dieser Szenarien muss durchgespielt und abgesichert werden — die Antwort ist immer: Der KNX-Bus arbeitet weiter.

5. Dokumentation: Welche Datenpunkte sind über die API exponiert? Welche Apps haben Zugriff? Welche Berechtigungen gelten? Die Projektdokumentation muss die IoT-Integration vollständig abbilden.

Aktuelle Produkte und Hersteller

Der Markt für KNX-IoT-Geräte wächst schnell. Stand 2025 bieten diese Hersteller IoT-fähige KNX-Produkte an:

Die Preise für IoT-Gateways liegen zwischen 400 und 1.200 €, je nach Funktionsumfang. Für ein Einfamilienhaus reicht ein einfaches IoT-Interface. Für Gewerbebauten mit Cloud-Anbindung und Analyse empfiehlt sich ein dedizierter IoT-Server.

Die Zukunft von KNX IoT

Die Zukunft von KNX ist untrennbar mit IoT verbunden. Die KNX Association treibt die Entwicklung mit klaren Meilensteinen voran:

Thread als zweites Übertragungsmedium: Neben TP und RF wird Thread zum dritten offiziell unterstützten KNX-Medium. Das macht KNX-Installationen funkbasiert erweiterbar — ohne neue Kabel.

Matter-Bridge: KNX-Geräte werden als Matter-Devices sichtbar. Das öffnet den direkten Weg zu Apple HomeKit, Google Home und Amazon Alexa — ohne Middleware.

Digital Twin: KNX IoT ermöglicht die Erstellung digitaler Zwillinge von Gebäuden. Jeder Datenpunkt wird kontinuierlich in ein Cloud-Modell gespiegelt. Architekten und Facility Manager können Szenarien durchspielen, bevor sie real umgesetzt werden.

Edge Computing: Intelligente IoT-Gateways werden mehr Rechenleistung erhalten. Machine-Learning-Modelle laufen direkt am Gateway und optimieren die Gebäudesteuerung lokal — ohne Cloud-Latenz und ohne Datenschutz-Bedenken.

Standardisierte Cloud-Plattform: Die KNX Association arbeitet an einer herstellerübergreifenden Cloud-Infrastruktur. Ziel: Ein einheitliches Portal, über das KNX-Installationen weltweit verwaltet, überwacht und optimiert werden können — mit dem gleichen Interoperabilitätsversprechen, das KNX seit 30 Jahren auf dem Bus einlöst.

Was bedeutet KNX IoT für Bauherren?

Wenn Sie ein KNX-System planen oder bereits eines besitzen, was bedeutet IoT konkret für Sie?

Für Neubauten: Planen Sie von Anfang an mit einem IoT-fähigen KNX/IP-Router. Die Mehrkosten gegenüber einem einfachen IP-Interface sind gering (100–300 €), der Mehrwert ist enorm. Auch wenn Sie die IoT-Funktionen nicht sofort nutzen, ist die Hardware für die Zukunft vorbereitet.

Für Bestandsanlagen: Die Nachrüstung eines IoT-Gateways ist der einfachste und wirkungsvollste Modernisierungsschritt für eine bestehende KNX-Installation. Kein Kabel muss gezogen, kein Gerät getauscht werden. Das Gateway wird in den Schaltschrank eingebaut, an den Bus angeschlossen und konfiguriert. In wenigen Stunden ist die Anlage IoT-fähig.

Für Gewerbebauten: KNX IoT ist für die Gebäudeautomation im Gewerbe ein Game-Changer. Energiemonitoring, Belegungsanalyse und vorausschauende Wartung amortisieren die Investition oft innerhalb eines Jahres.

Häufig gestellte Fragen

Brauche ich für KNX IoT neue Geräte?

Nein. Die Third Party API läuft auf dem IoT-Gateway — Ihre bestehenden KNX-Geräte auf dem TP-Bus bleiben unverändert. Sie benötigen lediglich ein IoT-fähiges Gateway oder IP-Interface.

Ist KNX IoT sicher?

Ja — wenn es richtig konfiguriert wird. OAuth 2.0, TLS 1.3, granulare Berechtigungen und KNX Secure bilden eine mehrschichtige Sicherheitsarchitektur. Entscheidend ist, dass nur die tatsächlich benötigten Datenpunkte über die API exponiert werden.

Funktioniert mein KNX-System noch, wenn das Internet ausfällt?

Unbedingt. Die Kernfunktionen (Licht, Heizung, Jalousien, Sicherheit) laufen auf dem lokalen KNX-Bus — unabhängig von Internet und Cloud. Nur die IoT-Zusatzfunktionen (Fernzugriff, Cloud-Analyse) sind betroffen.

Was kostet die IoT-Anbindung?

Ein IoT-Gateway kostet 400–1.200 €. Die Konfiguration durch einen KNX Systemintegrator liegt bei 2–4 Stunden. Laufende Cloud-Kosten hängen vom Anbieter ab — Home Assistant als lokale Lösung ist kostenlos, kommerzielle Cloud-Plattformen kosten 5–20 €/Monat.

Kann ich KNX IoT selbst einrichten?

Die Installation des Gateways und die Basiskonfiguration sollte ein zertifizierter KNX-Programmierer übernehmen. Die anschließende Nutzung — Apps einrichten, Automatisierungen konfigurieren, Dashboards bauen — können technisch versierte Bauherren selbst erledigen.

KNX IoT oder Home Assistant?

Beides — sie ergänzen sich. Home Assistant ist eine lokale Middleware, die KNX (über die IoT-API oder klassisch per KNX/IP) mit anderen Systemen verbindet. Die Visualisierung über Home Assistant ist für viele Bauherren der einfachste Einstieg in die IoT-Welt.