Warum KNX über IP läuft — und warum das alles verändert
KNX wurde 1990 als reines Zweidraht-Bussystem entwickelt. Damals reichte eine Datenrate von 9.600 Bit/s völlig aus — ein Tastendruck brauchte wenige Byte. Heute sieht die Welt anders aus: Touchpanels laden Visualisierungen, Kameras streamen Bilder, Energiemonitoring überträgt Messwerte im Sekundentakt. Der klassische Bus stößt hier an seine physischen Grenzen.
KNX IP löst dieses Problem, indem es KNX-Telegramme über das vorhandene Ethernet-Netzwerk transportiert. Keine neue Verkabelung, keine separate Infrastruktur — KNX nutzt einfach die Netzwerktechnik, die ohnehin in jedem modernen Gebäude vorhanden ist.
Der entscheidende Vorteil: Während der klassische Bus eine einzige Linie mit maximal 256 Teilnehmern bildet, verbindet KNX IP als Backbone beliebig viele Linien und Bereiche über das lokale Netzwerk. Statt physischer Bereichskoppler übernehmen IP-Router diese Aufgabe — schneller, flexibler und ohne die Beschränkungen der TP-Topologie.
IP-Routing vs. IP-Tunneling — zwei Welten
Wer „KNX über IP" sagt, meint in der Praxis zwei grundverschiedene Dinge:
| Merkmal | KNXnet/IP Routing | KNXnet/IP Tunneling |
|---|---|---|
| Zweck | Backbone zwischen Linien/Bereichen | Punkt-zu-Punkt-Zugriff (ETS, Visualisierung) |
| Protokoll | UDP Multicast (224.0.23.12, Port 3671) | UDP Unicast, verbindungsorientiert |
| Geschwindigkeit | Bis zu 10 Mbit/s statt 9,6 kBit/s | Einzeltelegramme wie TP |
| Gleichzeitige Verbindungen | Alle Geräte im Multicast | Begrenzt (meist 4–8 pro Interface) |
| Typischer Einsatz | Großprojekte, Etagen/Gebäude verbinden | Programmierung, Fernwartung, Visualisierung |
| Hardware | KNX IP-Router (z. B. Weinzierl 762) | KNX IP-Interface (z. B. MDT SCN-IP100.03) |
In der Praxis kombiniere ich fast immer beides: IP-Routing als Backbone zwischen den Etagen und IP-Tunneling als Servicezugang für ETS-Programmierung und Fernwartung. Beides läuft über dasselbe Netzwerk, aber mit unterschiedlichen Mechanismen.
IP-Backbone in der Praxis — wie ich große Projekte aufbaue
Ein typisches Villenprojekt mit KNX hat 200–400 Geräte. Im klassischen Aufbau bedeutet das: 2–3 Bereiche mit je 3–4 Linien, verbunden über Bereichskoppler und Linienkoppler. Jeder dieser Koppler ist ein Flaschenhals — er filtert Telegramme, begrenzt den Durchsatz und muss einzeln konfiguriert werden.
Mit einem IP-Backbone wird die Architektur radikal einfacher:
- Jede Linie erhält einen KNX IP-Router statt eines Linienkopplers
- Alle IP-Router kommunizieren über Multicast — kein physischer Backbone-Bus nötig
- Filterung erfolgt direkt im IP-Router: Nur die relevanten Gruppenadressen werden durchgelassen
- Geschwindigkeit: Telegramme zwischen Linien laufen mit Netzwerkgeschwindigkeit statt mit 9,6 kBit/s
Das Ergebnis: Schnellere Reaktionszeiten, weniger Verkabelung, einfachere Topologie. In einem Münchner Neubauprojekt mit vier Etagen habe ich durch den Wechsel von TP-Backbone auf IP-Backbone die Inbetriebnahmezeit um 30 % reduziert — weil die ETS-Downloads über IP in Sekunden statt Minuten laufen.
KNX Secure — warum Verschlüsselung nicht optional ist
Bis 2019 war KNX ein offenes System ohne jede Verschlüsselung. Jeder, der physischen Zugang zum Bus hatte, konnte Telegramme mitlesen, Geräte umprogrammieren und Aktoren schalten. In einem Einfamilienhaus war das selten ein Problem — aber in Hotels, Bürogebäuden und öffentlichen Gebäuden ein echtes Sicherheitsrisiko.
Seit der Einführung von KNX Secure gibt es zwei Schutzmechanismen:
KNX IP Secure
Verschlüsselt die gesamte IP-Kommunikation zwischen KNX IP-Geräten. Jedes Telegramm wird mit AES-128-CCM verschlüsselt und mit einem Message Authentication Code (MAC) gegen Manipulation geschützt. Das bedeutet:
- Niemand kann KNX-Telegramme im Netzwerk mitlesen
- Niemand kann gefälschte Telegramme einschleusen
- Die ETS-Programmierung über IP ist abgesichert
In der Praxis: IP Secure ist zwingend notwendig, sobald KNX-Telegramme über ein gemeinsames Netzwerk laufen — also in jedem modernen Projekt. Ohne IP Secure könnte theoretisch jeder im Netzwerk die Haustür öffnen oder die Alarmanlage deaktivieren.
KNX Data Secure
Verschlüsselt einzelne Telegramme direkt auf dem TP-Bus — also auf der physischen Zweidrahtleitung. Das ist der tiefgreifendere Schutz, denn er wirkt auch dann, wenn jemand physischen Zugang zum Bus hat (etwa in einem Hotelzimmer oder einem öffentlichen Bereich).
- Selektiv einsetzbar: Nur sicherheitskritische Gruppenadressen werden verschlüsselt (Türschloss, Alarmanlage, Zutritt), der Rest läuft unverschlüsselt
- Kompatibel: Data-Secure-Geräte und klassische Geräte können auf derselben Linie koexistieren
- Overhead: Verschlüsselte Telegramme sind länger (24 Byte statt 16 Byte), was die Buslast leicht erhöht
KNX Secure in der ETS — was sich ändert
Die Integration von KNX Secure in die ETS6 ist inzwischen ausgereift, erfordert aber Sorgfalt:
- Gerätezertifikate: Jedes KNX-Secure-Gerät wird mit einem individuellen Zertifikat ausgeliefert — ein QR-Code auf der Verpackung oder dem Gerät. Dieses Zertifikat muss in die ETS importiert werden, bevor das Gerät in Betrieb genommen wird.
- Backbone Key: Für IP Secure wird ein gemeinsamer Schlüssel vergeben, den alle IP-Router im Projekt teilen. Die ETS generiert diesen automatisch.
- Gruppen-Keys: Für Data Secure erhält jede geschützte Gruppenadresse einen eigenen Schlüssel. Die ETS verwaltet das transparent.
- Schlüssel-Backup: Kritisch — wenn die ETS-Projektdatei verloren geht, sind die Schlüssel weg. Ich sichere jedes Projekt dreifach: lokal, auf dem NAS und in der Cloud.
Praxis-Tipp: Ich lege bei jedem Neuprojekt sofort einen Projektordner an und scanne die Gerätezertifikate, bevor ich auch nur ein Gerät montiere. Nachträglich Zertifikate suchen ist extrem aufwändig — Verpackungen sind dann oft schon entsorgt.
Wann welchen Schutz? Meine Empfehlung
| Szenario | IP Secure | Data Secure | Begründung |
|---|---|---|---|
| Einfamilienhaus, abgeschlossenes Netz | ✅ Empfohlen | Optional | Bus ist physisch geschützt, IP-Netz kann WLAN haben |
| Villa mit Gäste-WLAN | ✅ Pflicht | ✅ Türschloss, Alarm | Gäste im selben Netz = Angriffsvektor |
| Hotel | ✅ Pflicht | ✅ Alle sicherheitskritischen GA | Gäste haben physischen Zugang zu Tastern/Dosen |
| Bürogebäude | ✅ Pflicht | ✅ Zutritt, HVAC-Steuerung | Viele Nutzer, regulatorische Anforderungen |
| Bestandsanlage ohne Secure-Geräte | — Nicht möglich | — Nicht möglich | Schrittweise Migration bei Gerätetausch |
Hardware-Empfehlungen — was ich verbaue
Bei der Auswahl von KNX-IP-Komponenten achte ich auf drei Dinge: Secure-Unterstützung, Tunneling-Verbindungen und Zuverlässigkeit.
| Gerät | Typ | Secure | Tunnels | Einsatz |
|---|---|---|---|---|
| Weinzierl KNX IP Router 762 | IP-Router | IP + Data | 8 | Backbone, Standardwahl |
| MDT SCN-IP100.03 | IP-Interface | IP Secure | 5 | Programmierzugang |
| ABB IPR/S 3.5.1 | IP-Router | IP + Data | 8 | ABB-Projekte, zuverlässig |
| JUNG IPS 300 SREG | IP-Interface | IP Secure | 4 | Kleine Projekte |
Wichtig: Nicht jedes „KNX IP"-Gerät unterstützt KNX Secure. Ältere IP-Interfaces (vor 2020) können kein Secure — diese müssen bei sicherheitskritischen Projekten ersetzt werden.
Netzwerk-Anforderungen — was die IT wissen muss
KNX IP funktioniert nur dann zuverlässig, wenn das Netzwerk richtig konfiguriert ist. Hier die häufigsten Stolperfallen:
- Multicast-Unterstützung: Managed Switches müssen IGMP Snooping unterstützen, sonst flutet der Multicast-Traffic alle Ports. Bei unmanaged Switches funktioniert es oft „irgendwie", aber die Performance leidet.
- VLAN-Empfehlung: Ich lege KNX IP immer in ein eigenes VLAN. Das trennt den Gebäudeautomations-Traffic vom restlichen Netzwerk und verhindert, dass Multicast-Pakete in das Office-Netz gelangen.
- WLAN-Router: Consumer-Router filtern oft Multicast — das führt dazu, dass IP-Routing über WLAN nicht funktioniert. IP-Tunneling über WLAN ist dagegen unproblematisch (Unicast).
- Firewall: Port 3671/UDP muss innerhalb des KNX-VLANs offen sein. Für Fernzugriff empfehle ich einen VPN-Tunnel statt einer Portfreigabe.
Bestandsanlagen auf IP migrieren
Die gute Nachricht: KNX IP ist vollständig rückwärtskompatibel. Sie müssen nicht die gesamte Anlage umbauen — ein schrittweiser Ausbau funktioniert hervorragend:
- Phase 1: Ein KNX IP-Interface einbauen → ETS-Programmierung über IP statt USB
- Phase 2: Bereichskoppler durch IP-Router ersetzen → IP-Backbone entsteht
- Phase 3: Sicherheitskritische Geräte durch Secure-Varianten ersetzen → Data Secure für Türschloss, Alarm
- Phase 4: Visualisierung und Smart-Home-Integration über IP anbinden
Die Kosten für Phase 1 liegen bei 200–400 € für das Interface plus einer Stunde Arbeitszeit. Der Effizienzgewinn bei jeder weiteren Programmierung ist enorm — Downloads, die über USB 10 Minuten dauern, laufen über IP in 30 Sekunden.
5 typische Fehler bei KNX IP — und wie Sie sie vermeiden
- Kein IGMP Snooping aktiviert → Multicast-Traffic flutet das gesamte Netzwerk, Switches werden langsam. Lösung: Managed Switch mit IGMP Snooping verwenden.
- Gerätezertifikate nicht gesichert → Bei Gerätetausch oder ETS-Neuinstallation sind die Secure-Schlüssel verloren. Lösung: Zertifikate scannen und dreifach sichern.
- IP-Adresskonflikte → KNX IP-Geräte mit DHCP betreiben. Lösung: Feste IP-Adressen im dedizierten VLAN vergeben.
- Zu viele Tunneling-Verbindungen → 3 Techniker wollen gleichzeitig programmieren, aber das Interface hat nur 4 Tunnels. Lösung: Für größere Teams einen IP-Router mit 8 Tunnels verwenden.
- Fernzugriff über Portfreigabe → Port 3671 direkt ins Internet freigeben ist ein massives Sicherheitsrisiko. Lösung: VPN verwenden — immer.
Was KNX IP kostet — eine ehrliche Kalkulation
| Komponente | Kosten | Anmerkung |
|---|---|---|
| KNX IP-Interface (1 Stück) | 200–350 € | Für Programmierzugang, jedes Projekt |
| KNX IP-Router (pro Linie) | 350–500 € | Für IP-Backbone, ersetzt Linienkoppler |
| Managed Switch (8-Port) | 100–300 € | Mit IGMP Snooping, VLAN-fähig |
| Inbetriebnahme IP-Backbone | 400–800 € | Netzwerk-Konfiguration, ETS-Setup |
| Netzwerk-Planung (VLAN, Firewall) | 200–400 € | Einmalig, bei Zusammenarbeit mit IT |
Für ein typisches Einfamilienhaus mit KNX rechne ich mit 500–800 € Mehrkosten für IP-Integration (ein Interface plus Managed Switch). Bei Villen und Gewerbe mit IP-Backbone sind es 1.500–3.000 € — die sich durch schnellere Programmierung und Fernwartungsmöglichkeit innerhalb weniger Jahre amortisieren.
Ausblick — wohin KNX IP sich entwickelt
Die KNX Association arbeitet an KNX IoT — einer komplett IP-nativen Variante, die IPv6 und Thread als Transportprotokoll nutzt. KNX IoT ist kein Ersatz für das klassische KNX, sondern eine Ergänzung: Sensoren und Aktoren kommunizieren direkt über IP, ohne den Umweg über einen IP-Router.
Bis KNX IoT marktreif ist (Stand 2026: erste Geräte verfügbar, aber noch kleines Ökosystem), bleibt KNX IP als Backbone der Standard für professionelle Installationen. Wer heute IP Secure einsetzt, ist auch für die Zukunft vorbereitet — die Verschlüsselungsmechanismen bleiben kompatibel.
Mehr zur Entwicklung von KNX in unserem Artikel Zukunft KNX und KNX IoT.
Häufig gestellte Fragen
Kann ich KNX IP nachrüsten?
Ja, problemlos. Ein KNX IP-Interface lässt sich in jede bestehende KNX-Anlage einbauen — einfach auf die TP-Linie stecken und per Netzwerkkabel verbinden. Die bestehende Programmierung bleibt erhalten.
Brauche ich ein separates Netzwerk für KNX?
Empfohlen, aber nicht zwingend. Ein eigenes VLAN ist die saubere Lösung. In einem Einfamilienhaus ohne besondere Sicherheitsanforderungen funktioniert es auch im gemeinsamen Netzwerk — dann aber unbedingt IP Secure aktivieren.
Funktioniert KNX IP über WLAN?
IP-Tunneling (Punkt-zu-Punkt) funktioniert über WLAN. IP-Routing (Multicast) funktioniert in den meisten WLAN-Setups nicht zuverlässig, weil Consumer-Router Multicast-Pakete filtern.
Was passiert, wenn das Netzwerk ausfällt?
Jede KNX-Linie funktioniert autonom weiter — Licht, Heizung, Jalousien innerhalb einer Linie laufen auch ohne IP-Backbone. Nur die linienübergreifende Kommunikation und der Fernzugriff sind betroffen.
Ist KNX Secure wirklich nötig im Einfamilienhaus?
IP Secure: Ja, sobald das KNX-Interface im selben Netzwerk wie Smartphones und Laptops hängt. Data Secure: Optional, aber empfohlen für Türschloss und Alarmanlage.