Vergleich
Loxone vs KNX
Ein praxisnaher Vergleich von Loxone und KNX: wo die Logik läuft, wie Geräte verdrahtet werden, wie Änderungen erfolgen und wann ein hybrides Konzept sinnvoll ist.
Zwei Architekturen in einem Satz
KNX verteilt die Intelligenz auf die Geräte. Ein Präsenzmelder, ein Dimmaktor, ein Jalousieaktor und ein Taster verfügen jeweils über einen eigenen Busanschluss und ein eigenes Applikationsprogramm. Sie tauschen Gruppenadressen über einen Twisted-Pair-Bus aus, und jedes inbetriebgenommene Gerät kann ohne zentrale Steuerung auf ein Telegramm reagieren. Loxone zentralisiert die Logik in einer Steuerung. Der Miniserver liest Eingänge, führt das Programm aus und treibt Ausgänge; Geräte werden über Tree, Air, KNX, Modbus oder IP angebunden. Dieser Unterschied erklärt den Großteil der praktischen Abwägungen, die folgen. Er erklärt auch, warum die beiden Systeme unterschiedlich ausfallen: Eine KNX-Installation kann Gerät für Gerät weiterarbeiten, wenn eine übergeordnete Stelle ausfällt, während eine Loxone-Installation von der Steuerung und deren Backup abhängt. Keines der Modelle ist eine Glaubensfrage; jedes erzwingt eine andere Disziplin bei Planung, Prüfung und Dokumentation. Die richtige Frage ist, wo die Logik über die Lebensdauer des Gebäudes liegen soll.
- KNX: verteilte Geräte, Telegramme mit Gruppenadressen
- Loxone: zentrale Logik, lokale Steuerung, Geräte mit mehreren Protokollen
- Beide können im selben Projekt koexistieren
Verdrahtung, Topologie und Gerätegrenzen
Eine KNX-Installation ist ein Bus: Geräte werden auf demselben Adernpaar in Reihe oder sternförmig verdrahtet, mit einer Spannungsversorgung und einem Koppler zwischen Linien und Bereichen. Protokollreferenz: Eine Linie unterstützt bis zu 64 Busgeräte, ein Bereich bis zu 15 Linien; Topologie und Reserven müssen daher geplant statt improvisiert werden. Das ist berechenbar und gut geeignet für Neubauprojekte mit klarer Geräteliste. Loxone Tree verwendet ein einziges Kabel, das Strom und Kommunikation zu den Tree-Geräten führt; das reduziert Einzelanfahrten, bindet die Geräteauswahl aber an das Tree-Ökosystem. Air deckt Sanierungen und schwer verkabelbare Stellen ab. In der Praxis ist ein hybrides Konzept üblich: KNX für Beleuchtung und Sonnenschutz, Tree oder Air für Raumsteuerungen und eine Steuerung für systemübergreifende Logik. Die Topologie sollte gezeichnet sein, bevor das erste Kabel gezogen wird. Buslänge, Leistungsreserve der Versorgung, Platzierung der Koppler und Reservegeräte sind wichtiger als die Bezeichnung auf dem Kabel.
- KNX-Bus: Planung von Linien, Bereichen und Kopplern
- Tree: ein Kabel für Strom und Daten
- Air: Sanierung und schwierige Leitungswege
- Hybrid: Protokoll nach Gerät gewählt, nicht nach Ideologie
Programmierung, Änderungsmanagement und Versionierung
Das KNX-Engineering erfolgt in ETS. Jedes Gerät besitzt ein Applikationsprogramm, Parameter und Gruppenadressen; eine Änderung erfolgt durch erneutes Laden des Geräts. Das Modell ist explizit und portabel, hängt aber vom ETS-Projekt und der Disziplin bei den Gruppenadressen ab. Das Loxone-Engineering erfolgt in Loxone Config. Die Logik wird als Funktionsbausteine und Verbindungen auf der Steuerung aufgebaut, was systemübergreifende Sequenzen schneller lesbar und änderbar macht, die Logik ist jedoch an diese Steuerungskonfiguration gebunden. Keines der Modelle ist grundsätzlich besser; sie scheitern auf unterschiedliche Weise. Ein KNX-Projekt ohne ETS-Datei lässt sich kaum sicher ändern. Ein Loxone-Projekt ohne versioniertes Config-Backup ist ebenso fragil. Beide benötigen Bestandsdokumentation, ein Änderungsprotokoll und eine benannte Person, die einen Download freigeben kann. Der praktische Test ist einfach: Kann eine kompetente dritte Partei die Änderung verstehen, umsetzen und zurückrollen?
- KNX: ETS-Projekt, Geräteparameter, Gruppenadressen
- Loxone: Config-Projekt, Funktionsbausteine, Verknüpfungen
- Versionierte Backups für beide
- Benannte Freigabeperson für Downloads
Gateways und Auswahl der Schnittstelle
Gateways entscheiden, wie viel das eine System vom anderen sieht. Eine KNX-IP-Schnittstelle stellt Gruppenadressen für eine Steuerung bereit; ein KNX-IP-Router verbindet Linien und Bereiche und kann sowohl Routing als auch Tunnelling übernehmen. Die Wahl beeinflusst Kapazität, Latenz, Diagnose und die Anzahl gleichzeitiger Verbindungen. Fragen Sie, wie viele Gruppenadressen die Schnittstelle exportieren kann, ob sie Routing oder Tunnelling unterstützt, wie sie sich nach einer Netzwerkunterbrechung verhält und ob KNX Secure erforderlich ist. Ein Gateway, das bei der Übergabe bereits gesättigt ist, hat keinen Spielraum für den nächsten Mieterausbau. Dieselbe Logik gilt für andere Protokollbrücken: Zählen Sie Punkte, nicht Geräte, und halten Sie Reservekapazität für Änderungen vor, die immer kommen. Das Gateway sollte als Infrastruktur mit einem Ausfallmodus, einer Reserve und einem dokumentierten Austauschverfahren behandelt werden. Erfassen Sie IP-Adresse, Subnetz, Port und Zugangsdaten im Änderungsmanagement.
- KNX-IP-Schnittstelle vs. IP-Router
- Tunnelling vs. Routing und gleichzeitige Clients
- Kapazität, Latenz und sicheres KNX
- Reserve, feste Adresse und Austauschverfahren
Inbetriebnahme, Prüfung und Ausfallverhalten
Prüfen Sie zuerst den Bus, dann das Gateway, dann die Plattform. Am Bus bestätigen Sie Geräteversorgung, Linienkoppler, Kommunikation über Gruppenadressen und Szenenabruf. Am Gateway bestätigen Sie Erkennung, Adressexport, Lese- und Schreibverhalten sowie die Wiederverbindung nach einer Netzwerkunterbrechung. Auf der Plattform bestätigen Sie, dass jeder zugeordnete Punkt den richtigen Wert, die richtige Einheit und den richtigen Zustand zeigt und dass ein Befehl das Feldgerät erreicht. Prüfen Sie den Fehlerpfad: Trennen Sie das Gateway und kontrollieren Sie, dass lokale KNX-Funktionen weiterlaufen. Erfassen Sie das Ergebnis gegen die Punktliste, nicht in einem separaten Notizbuch. Ein Punkt, der in einem Browser-Baum erscheint, ist nicht inbetriebgenommen, bis er gelesen, geschrieben und am Feldgerät beobachtet wurde. Sequenzprüfungen sollten auch die Fälle abdecken, die nur nachts auftreten: eine ausgefallene Leuchte, ein blockierter Jalousieantrieb, ein Neustart der Steuerung während einer Szene.
- Busgesundheit, Koppler und Gruppenadressverkehr
- Gateway-Erkennung, Lesen/Schreiben und Wiederverbindung
- Wert, Einheit und Zustand pro Punkt auf der Plattform
- Lokaler Betrieb bei ausgefallenem Gateway
- Unterzeichnete Prüfprotokolle gegen die Punktliste
Ökosystem, Lebenszykluskosten und Bindung
KNX hat einen breiten Gerätemarkt: viele Hersteller, viele Bauformen und eine lange Installationsbasis, besonders in Europa. Wettbewerb kann die Gerätepreise transparent halten, doch Engineering und Inbetriebnahme sind reale Kosten. Loxone hat einen schmaleren Gerätekatalog und eine stärker integrierte Software-Umgebung; die Steuerung und ihre Programmierung werden zum Mittelpunkt des Projekts. In beiden Fällen ist das günstigere Erstangebot nicht immer die günstigere Lebenszyklusrechnung. Zählen Sie Engineering-Stunden, Ersatzteile, Schulung und künftige Änderungen, nicht nur Hardware. Zählen Sie auch die Kosten der Abgrenzung: Zwei Systeme bedeuten zwei Kompetenzsätze, zwei Dokumentationssätze und eine Zuordnung, die gepflegt werden muss. Ein hybrides Konzept ist oft die richtige Antwort, aber nicht kostenlos. Bindung ist nicht nur eine Lizenzfrage; sie ist auch eine Kompetenzfrage, und der ehrliche Vergleich schließt die Person ein, die in fünf Jahren noch verfügbar sein wird, um eine Gruppenadresse oder einen Config-Baustein zu ändern.
- KNX: Multi-Vendor-Geräte, ETS-Kenntnisse erforderlich
- Loxone: integrierter Stack, steuerungszentriert
- Lebenszykluskosten umfassen Engineering und Änderungen
- Zwei Systeme bedeuten zwei Kompetenzsätze und eine Zuordnung
Welche Lösung zu Ihrem Gebäude passt
Wählen Sie KNX, wenn die Spezifikation einen herstellerneutralen Bus verlangt, wenn der Fachplaner oder der Auftraggeber bereits über KNX-Kompetenz verfügt oder wenn die Geräteauswahl über viele Hersteller eine harte Anforderung ist. Wählen Sie Loxone, wenn das Gebäude eine Logikebene über HLK, Beleuchtung, Sonnenschutz, Energie und Zutritt benötigt und wenn lokale Steuerung mit klarer Bedienoberfläche wichtiger ist als Geräteunabhängigkeit. Viele Projekte wählen beides: KNX auf der Feldebene, Loxone auf der Integrationsebene. Das ist eine Entwurfsentscheidung, kein Kompromiss. Die Entscheidung sollte mit ihren Gründen dokumentiert werden, denn die nächste Person wird fragen, warum die Grenze dort verläuft, wo sie verläuft. Eine einfache Regel hilft: Steuerung dorthin, wo das Gerät ist; Koordination dorthin, wo das Gebäude ist. Wenn es kein Wartungsteam gibt, bevorzugen Sie die Architektur mit weniger beweglichen Teilen und klarerer Dokumentation.
- KNX-first: Multi-Vendor-Feldgeräte und ETS im Haus
- Loxone-first: integrierte Logik und eine Bedienansicht
- Hybrid: KNX-Feldbus, Loxone-Überwachung
- Grenze und Begründung dokumentieren
Loxone und KNX im Vergleich
15 rows| Kriterium | Loxone | KNX |
|---|---|---|
| Architektur | Steuerungszentriert; Logik im Miniserver | Verteilt; Logik in Busgeräten |
| Feldverdrahtung | Tree, Air, KNX, Modbus und IP | Twisted-Pair-Bus mit Linien- und Bereichskopplern |
| Topologiegrenzen | Steuerungskapazität und Segmentgrenzen von Tree oder Air | Bis zu 64 Geräte pro Linie und 15 Linien pro Bereich |
| Programmierung | Funktionsbausteine in Loxone Config | ETS mit Geräteparametern und Gruppenadressen |
| Geräteauswahl | Loxone-Ökosystem plus offene Protokolle | KNX-Katalog mit mehreren Herstellern |
| Licht und Sonnenschutz | Native Geräte und KNX- oder DALI-Integration | Native KNX-Aktoren und -Sensoren |
| HVAC | Über I/O, Modbus, BACnet oder KNX | Über KNX-Aktoren und Gateways |
| Systemübergreifende Logik | Stark; ein Steuerungsprogramm | Möglich, aber über Geräte und Gateways verteilt |
| Modernisierung | Air und Tree reduzieren neue Verkabelung | Busverkabelung zu jedem Gerät weiterhin erforderlich |
| Gateway und Schnittstelle | Native KNX-Schnittstelle oder IP-Gateway | IP-Schnittstelle oder Router, Tunnelling oder Routing |
| Diagnose | Plattformprotokolle und Steuerungsdiagnose | Busmonitor, Gateway-Protokolle und ETS-Diagnose |
| Ausfallverhalten | Ausfall der Steuerung stoppt die zentrale Logik; lokale Geräte verhalten sich unterschiedlich | Busgeräte können lokale Funktionen beibehalten |
| Änderungsmanagement | Config-Version und Steuerungs-Backup | ETS-Projekt und Disziplin bei Gruppenadressen |
| Kompetenzen | Schulung in Loxone Config | ETS-Erfahrung und Disziplin bei Gruppenadressen |
| Typische Eignung | Integrierte Gebäudelogik und eine Bedienansicht | Gerätespezifikation über mehrere Hersteller |
Projektbilder
3 images
Häufige Fragen
01Kann Loxone KNX-Geräte steuern?
Ja, über eine KNX-Schnittstelle oder ein Gateway. Die KNX-Geräte behalten ihre eigenen Applikationsprogramme; Loxone liest und schreibt Gruppenadressen. Das Projekt sollte bestätigen, welche Datenpunkttypen und Gruppenadressen bereitgestellt werden.
02Ist KNX offener als Loxone?
KNX ist ein offener Standard mit Geräten mehrerer Hersteller. Loxone ist eine proprietäre Plattform mit offenen Schnittstellen, darunter KNX, Modbus, BACnet und IP-basierte APIs. Offenheit bemisst sich daran, was Sie später ändern können, nicht nur am Namen des Protokolls.
03Welche Lösung ist günstiger?
Es gibt keine pauschale Antwort. KNX kann wettbewerbsfähigere Gerätepreise bieten, erfordert aber ETS-Engineering. Loxone kann Verdrahtung und Integrationsaufwand reduzieren, rückt jedoch die Steuerung in den Mittelpunkt des Projekts. Vergleichen Sie den gesamten Lebenszyklus: Planung, Hardware, Programmierung, Inbetriebnahme, Ersatzteile und künftige Änderungen.
04Können wir Loxone und KNX in einem Gebäude kombinieren?
Ja. Ein häufiges Muster ist KNX für Beleuchtung und Sonnenschutz auf der Feldebene, während Loxone systemübergreifende Logik, HLK und Energie übernimmt. Die Abgrenzung sollte dokumentiert sein: welches System jeweils eine Gruppenadresse, eine Szene und ein Zeitprogramm besitzt.
05Ersetzt Loxone eine KNX-Installation?
Physisch nicht. Bestehende KNX-Geräte können in der Regel an Ort und Stelle bleiben und integriert werden. Ein Austausch ist nur sinnvoll, wenn Geräte veraltet, nicht verfügbar oder nicht in der Lage sind, die geforderte Funktion bereitzustellen.
06Was eignet sich besser für ein Hotel?
Beides kann funktionieren. KNX ist in europäischen Hotelspezifikationen verbreitet und bietet eine breite Geräteauswahl. Loxone ist stark, wo Raumsteuerung, PMS-Ereignisse, Energie und Gebäudeüberwachung eine gemeinsame Logikebene benötigen. Zimmertyp und Betriebsmodell sollten entscheiden.
07Benötigen wir ETS, um ein KNX-System zu ändern?
Ja für Änderungen auf Geräteebene: Parameter und Gruppenadressen liegen im ETS-Projekt. Eine übergeordnete Stelle kann Szenen und Zeitprogramme ohne ETS ändern, nicht aber die Geräteapplikation.
08Was passiert beim Ausfall der Steuerung?
KNX-Geräte können den lokalen Busbetrieb für Funktionen fortsetzen, die nicht von einer Steuerung abhängen. Loxone-Steuerungen sollten mit Reservekapazität, Backup und einem dokumentierten Wiederanlaufverfahren spezifiziert werden. Das Ausfallverhalten gehört in die Planung.
Nächster Schritt
Bringen Sie uns das Gebäude.
Nennen Sie uns Gebäudetyp, Systeme im Leistungsumfang und das benötigte Ergebnis. Wir zeigen den kürzesten Weg zu einem funktionierenden System.