Loxone-System
Loxone-Systemleitfaden: Architektur und Anwendungen
Wie ein Loxone-Gebäudeautomationssystem aufgebaut ist: Miniserver, Erweiterungen, Tree, Air und 1-Wire, Programmierung in Config, Integration mit KNX, BACnet und Modbus sowie Projektabwicklung.
Kurze Antwort
Loxone ist eine Local-First-Gebäudeautomationsplattform rund um den Miniserver, einen Controller, der Logik, Zeitprogramme und Szenen ohne zwingende Cloud-Verbindung ausführt. Erweiterungen ergänzen Ein- und Ausgänge, Tree, Air und 1-Wire binden Feldgeräte an, und Config definiert das Verhalten, das die App und Schnittstellen bereitstellen.
Eine Local-First-Architektur
Loxone ist um ein einfaches Prinzip herum konzipiert: Das Gebäude soll weiter funktionieren, wenn das Internet es nicht tut. Der Miniserver speichert das Steuerungsprogramm, führt Zeitprogramme und Szenen aus und kommuniziert mit Feldgeräten über lokale Busse. Fernzugriff und die mobile App sind Komfortfunktionen, die darüber liegen, keine Voraussetzung für den täglichen Betrieb. Dieses Design eignet sich für Gebäude mit unzuverlässiger Konnektivität, strengen Anforderungen an die Datenhaltung oder dem Bedarf, bei einer Netzstörung weiter zu arbeiten. Es verändert auch das Supportmodell: Der Integrator kann die Logik lokal diagnostizieren, und der Eigentümer ist nicht dem Auslaufen eines Abonnements ausgesetzt. Local-First bedeutet nicht isoliert. Gateways und Schnittstellen verbinden KNX-, Modbus-, DALI- und BACnet-Geräte, und ein übergeordnetes System kann die Daten lesen, ohne die Steuerung zu übernehmen. Für ein gewerbliches Gebäude gilt dasselbe Prinzip für das Controller-Netz: zuerst lokale Autonomie, dann zentrale Koordination. Die praktische Frage ist, welche Funktionen einen WAN-Ausfall überstehen müssen und ob die Planung dieses Szenario getestet hat. Eine Local-First-Behauptung, die nie offline getestet wurde, ist nur ein Marketingsatz. Der Test sollte nach einem Firmware-Update wiederholt werden, denn eine Änderung im Verhalten des Controllers kann stillschweigend eine Abhängigkeit wieder einführen, die die Planung beseitigt hatte. Lokale Autonomie hat auch einen Preis: Jeder Controller benötigt seine eigene Sicherung und seinen eigenen Ersatzplan.
- Logik und Zeitprogramme vor Ort gespeichert
- App und Fernzugriff als optionale Ebenen
- Lokale Busse für Feldgeräte
- Gateways für Fremdsysteme
Miniserver und Erweiterungen
Der Miniserver ist der Kerncontroller: Er enthält das Programm, die Zeitprogramme, die Benutzerberechtigungen und die Schnittstellen. Integrierte Ein- und Ausgänge decken eine kleine Installation direkt ab; Erweiterungen ergänzen Kapazität über einen lokalen Bus, wenn das Projekt wächst. Die Kapazitätsplanung sollte vor dem Schaltschrankbau erfolgen, denn Eingangsart, Ausgangsart und Reservekapazität wirken sich auf Gehäuse, Stromversorgung und Verdrahtung aus. Die Planung sollte außerdem festhalten, welche Funktionen auf welchem Controller laufen, damit ein Ausfall begrenzte Wirkung hat. Sicherungen, Lizenzunterlagen und ein getestetes Wiederherstellungsverfahren sind Teil des Systems und kein Nachgedanke. Die Modellwahl ist eine Projektentscheidung anhand von Punktzahl, Schnittstellenanforderungen und künftiger Erweiterung und keine Standardwahl, die vom letzten Projekt übernommen wird. Das gewählte Modell sollte mit der Punktzahl und der Schnittstellenliste dokumentiert werden, die es begründet haben. Eine Reservekapazität ist in der Planungsphase günstiger als ein zweiter Schaltschrank nach der Übergabe, und sie sollte als Prozentsatz der genutzten Kapazität angegeben und nicht als vage Absicht belassen werden. Das Austauschverfahren sollte für jemanden geschrieben sein, der den Schaltschrank nie gesehen hat, und einmal getestet werden, solange der ursprüngliche Ingenieur noch verfügbar ist. Ein zweiter Controller für Ausfallsicherheit ist eine Planungsentscheidung und kein Standard; er benötigt definiertes Failover-Verhalten.
- Programm, Zeitprogramme und Berechtigungen
- Integrierte E/A plus Erweiterungsbus
- Kapazitäts- und Reserveplanung
- Sicherungen und ein getestetes Wiederherstellen
Tree, Air und 1-Wire
Loxone nutzt drei Peripherietechnologien für unterschiedliche Aufgaben. Tree ist ein verdrahteter Bus für Schalter, Sensoren, Dimmer und Aktoren; er führt Strom und Daten und eignet sich für Neubauprojekte mit geplanten Kabelwegen. Air ist ein Funkprotokoll für Geräte, bei denen eine Verkabelung unpraktisch ist, einschließlich Sanierung und bestimmter Sensorpositionen; es erfordert eine Signaluntersuchung und eine Stromstrategie für Batteriegeräte. 1-Wire ist ein einfacher Bus, der vor allem zur Temperaturerfassung in Böden, Rohren und Räumen dient, mit einer Adressierung, die jeden Sensor identifizierbar macht. Die drei können in einer Installation koexistieren. Planungsregeln betreffen Topologie, Kabellänge, Abschluss, Strombudget und Trennung von Netzstörungen. Die Wahl dreht sich nicht darum, welche Technologie neuer ist, sondern um das Gebäude, die Wege und das Wartungsmodell. Funk sollte als Planungsentscheidung mit Wartungsplan behandelt werden und nicht als Abkürzung um die Planung herum. Die Dokumentation von Geräteadressen und Bustopologie spart bei der Inbetriebnahme und späteren Fehlersuche Stunden und geht zuerst verloren, wenn ein Projekt zwischen Installateuren übergeben wird. Ein Funkgerät, das nur mit einer Leiter erreichbar ist, verursacht Wartungskosten, auch wenn es kein Steuerungsproblem darstellt. Jeden Busabschnitt an beiden Enden zu kennzeichnen, ist eine kleine Gewohnheit, die einen langen Nachmittag erspart.
- Tree: verdrahteter Bus mit Strom und Daten
- Air: Funk für Sanierung und Sensoren
- 1-Wire: Temperaturerfassung
- Topologie, Strom und Adressierung dokumentiert
Config: das Gebäude programmieren
Config ist die Engineering-Umgebung, in der das Verhalten des Gebäudes definiert wird. Funktionsbausteine behandeln Ein- und Ausgänge, Logik, Zeitprogramme, Szenen, Alarme und Benutzerrechte. Ein gut strukturiertes Projekt nutzt Namenskonventionen, wiederverwendbare Bausteine und Kommentare, denen ein anderer Ingenieur folgen kann. Simulation und Online-Tests helfen, die Logik vor der Inbetriebnahme zu prüfen, ersetzen aber keine Punkt-für-Punkt-Prüfungen vor Ort. Versionskontrolle ist wichtig: Ein geändertes Zeitprogramm oder eine neue Verriegelung sollte mit Datum und Begründung aufgezeichnet werden. Auch die Zugriffskontrolle auf die Projektdatei ist wichtig, denn eine undokumentierte Änderung kann eine getestete Sequenz untergraben. Das Ergebnis von Config ist nicht nur ein funktionierendes Programm, sondern eine wartbare Beschreibung, wie sich das Gebäude verhalten soll – genau das benötigt der Eigentümer bei der Übergabe. Eine zu Beginn vereinbarte Namenskonvention ist günstiger als das Umbenennen von Bausteinen nach der Inbetriebnahme. Ist die einzige Person, die das Programm lesen kann, aus dem Projekt ausgeschieden, hat das Gebäude einen Teil seiner Dokumentation verloren. Das Programm sollte als kontrolliertes Dokument behandelt werden, nicht als persönliches Notizbuch. Ein Programm, das von undokumentierten globalen Variablen abhängt, ist nicht wartbar, so elegant die Logik auf dem Bildschirm auch wirkt. Zwei Ingenieure sollten es öffnen können und für dieselbe Funktion denselben Baustein finden.
- Funktionsbausteine für Logik und Sequenzen
- Namenskonventionen und wiederverwendbare Bausteine
- Simulation plus Punktprüfung vor Ort
- Versionskontrolle und kontrollierter Zugriff
Integration mit anderen Systemen
Nur sehr wenige Gebäude stammen von einem einzigen Anbieter. Loxone integriert über native Schnittstellen und Gateways: KNX für Beleuchtung und Raumgeräte, Modbus RTU oder TCP für Zähler, Wechselrichter und Geräte, DALI für Leuchten, BACnet über ein Gateway für Anlagen und Leitsysteme sowie HTTP oder REST für Softwaredienste. Potentialfreie Kontakte bleiben ein verlässlicher Rückfallweg für Brandmeldung, Altgeräte und einfache Statussignale. Jede Schnittstelle benötigt eine Punktzuordnung: Quelladresse, Zielname, Datentyp, Einheit, Skalierung, Lese- oder Schreibrichtung und Störzustand. Gateways fügen ein Gerät hinzu, das versorgt, konfiguriert und dokumentiert werden muss. Die Integrationsplanung sollte festlegen, was geschieht, wenn ein Gateway offline geht, und ob der lokale Controller ohne es weiterarbeiten kann. Native Unterstützung und Gateway-Unterstützung sind unterschiedliche Zusagen; die Spezifikation sollte für jedes System angeben, welche erforderlich ist. Für jede Schnittstelle ist festzuhalten, wer die Gateway-Konfiguration verantwortet und wer bei einem Ausfall angerufen wird. Eine Schnittstelle, die heute funktioniert, aber keinen Verantwortlichen hat, fällt nächstes Jahr stillschweigend aus. Der Störzustand sollte für jeden Punkt definiert werden, nicht für das Gateway als Ganzes. Das Schnittstellenregister ist bei Fehlverhalten eines Fremdgeräts nützlicher als ein Verdrahtungsplan.
- KNX und DALI für Beleuchtung und Raumsteuerung
- Modbus für Zähler und Geräte
- BACnet über Gateway für die Anlagentechnik
- Punktplan mit Skalierung und Störzuständen
Planung und Kapazität
Die Planung eines Loxone-Projekts ist überwiegend eine Übung im Zählen und in der Grenzziehung. Beginnen Sie mit der Punktliste, gruppieren Sie Punkte nach Standort und entscheiden Sie, welcher Controller welche Gruppe bedient. Halten Sie den Umfang jedes Controllers so klein, dass ein Ausfall eine Zone oder ein Anlagenteil betrifft und nicht das ganze Gebäude. Lassen Sie Reserve-E/A für künftige Änderungen; eine typische Planungsreserve sind 10 bis 20 Prozent der genutzten Kapazität, doch die eigene Wachstumserwartung des Projekts sollte entscheiden. Prüfen Sie Strombudget des Busses, Kabellängen und Geräteanzahl pro Linie anhand der Herstellerdokumentation für das genaue Modell und die Firmware. Reservieren Sie Platz im Schaltschrank für eine zusätzliche Erweiterung und kennzeichnen Sie die Reserveklemmen. Dokumentieren Sie die Schnittstellenliste mit Protokoll, Gateway-Modell und Punktzahl je Verbindung. Ein Kapazitätsplan, der nicht schriftlich vorliegt, ist eine Schätzung, und eine Schätzung vor dem Schaltschrankbau wird zur Einschränkung für die nächsten zehn Jahre. Der Plan sollte auch angeben, was beim Austausch eines Controllers geschieht, denn dieser Tag wird kommen. Programmdatei, Lizenz und Sicherung sollten dort gespeichert werden, wo der Eigentümer sie kontrolliert, nicht nur auf dem Server des Integrators. Der Kapazitätsplan sollte bei jeder Planungsänderung überprüft werden, nicht nur zu Beginn.
- Punkte nach Standort und Ausfallgrenze gruppieren
- Typische Reserve von 10 bis 20 Prozent
- Busleistung, Kabellänge und Geräteanzahl prüfen
- Kapazitätsplan und Ersatzpfad dokumentieren
Lieferung und Lebenszyklus
Ein Loxone-Projekt wird in Stufen geliefert: Anforderungen, Punktliste, Schaltschrankplanung, Konfiguration, Werkstest, Inbetriebnahme vor Ort, Übergabe und Support. Der Werkstest findet Verdrahtungs- und Konfigurationsfehler, bevor die Baustelle ausgelastet ist. Die Inbetriebnahme vor Ort weist jeden Punkt, jede Sequenz und jeden Alarm nach, einschließlich des Verhaltens bei getrenntem Gerät. Die Übergabe sollte Sicherungen, Netzpläne, Zugangsdaten, ein Benutzerhandbuch und eine Schulung für die Personen umfassen, die das Gebäude bedienen werden. Das Supportmodell sollte ausdrücklich festgelegt sein: wer reagiert, in welchem Umfang und wie Änderungen freigegeben werden. Ein Local-First-System ist einfacher zu warten, wenn der Eigentümer die Projektdatei und die Dokumentation besitzt, statt von einem einzigen Ingenieurslaptop abhängig zu sein. Die Lebenszyklusplanung sollte auch Ersatzgeräte, Firmware-Updates und das Verfahren zum Hinzufügen eines neuen Geschosses oder Mieters abdecken. Der Eigentümer sollte ein Gerät hinzufügen oder ein Zeitprogramm ändern können, ohne das gesamte Programm neu aufzubauen. Das ist die praktische Bedeutung eines offenen, lokalen Systems. Das Inbetriebnahmeskript sollte einen Controller-Neustart, das Trennen eines Busgeräts und einen Gateway-Ausfall umfassen, denn diese Bedingungen wird das Gebäude irgendwann erleben. Die Schulung sollte auch das Lesen eines Alarms umfassen, nicht nur das Drücken einer Szenentaste. Das erste Betriebsjahr sollte eine Durchsicht der tatsächlich vorgenommenen Änderungen enthalten, denn diese Liste zeigt, ob das System wie geplant genutzt wird.
- Anforderungen und Punktliste zuerst
- Werkstest vor den Arbeiten vor Ort
- Inbetriebnahme Punkt für Punkt
- Sicherungen, Schulung und Supportbedingungen
Wo eine andere Plattform besser passt
Eine Local-First-Plattform ist nicht für jedes Gebäude die richtige Antwort. Sehr große Anlagen mit Hunderten von Regelschleifen, strenge Cybersicherheitsanforderungen auf Versorgerniveau oder eine Spezifikation, die ein bestimmtes Leitsystem vorschreibt, können mit einer anderen Architektur besser bedient sein. Loxone ist am stärksten, wo Raumsteuerung, lokale Autonomie, Integration von Fremdgeräten und ein klar eigentümerbetriebenes System zählen. Es ist schwächer, wo ein Projekt eine sehr große einheitliche Datenbank, tiefgehende native BACnet-Engineering oder eine Supportorganisation benötigt, die nur mit einer Enterprise-Plattform arbeitet. Das ehrliche Planungsgespräch dreht sich um Eignung, nicht um Markentreue. Ein Projekt kann Loxone für Raum- und Anlagensteuerung und ein separates Leitsystem für die Portfolioberichterstattung nutzen, sofern die Grenze und die Punktverantwortung dokumentiert sind. Das schlechteste Ergebnis ist eine aus Ideologie gewählte Plattform, die dann über ihre vorgesehene Rolle hinaus gedehnt wird, denn das resultierende System ist weder Local-First noch Enterprise-tauglich. Eine gute Spezifikation sagt, was jede Plattform tut und was sie bewusst nicht tut. Die Grenze sollte überprüft werden, wenn ein neues System hinzugefügt wird, denn alte Annahmen überstehen eine neue Schnittstelle selten. Eine Plattform, die in jedem Meeting verteidigt werden muss, ist für das Projekt meist die falsche. Die häufigen Ausfallmuster sind ein Controller, der über seine Kapazität hinaus gedehnt wird, ein Gateway ohne Verantwortlichen, ein Programm mit nur einem Leser und eine Sicherung, die nie wiederhergestellt wurde. Jedes ist eine Planungsunterlassung und kein Produktfehler.
- Gut geeignet für Raum, Anlage und Fremdintegration
- Weniger geeignet für sehr große Liegenschaften mit einer einzigen Datenbank
- Geteilte Architekturen funktionieren, wenn die Grenzen dokumentiert sind
- Die Plattform nach der Rolle wählen, nicht nach dem Etikett
Loxone-Systemelemente und ihre Planungshinweise
16 rows| Element | Funktion | Typische Anwendung | Planungshinweis |
|---|---|---|---|
| Miniserver | Kerncontroller und Logik-Engine | Technikzentrale oder Geschossschrank | Kapazität, Sicherung und Austausch planen |
| Extension | Zusätzliche Ein- und Ausgänge | Zusätzliche Zonen und Anlagensignale | Reservekapazität und Busleistung berücksichtigen |
| Tree | Verdrahteter Peripheriebus | Schalter, Sensoren und Dimmer | Topologie, Abschluss und Strombudget |
| Air | Funkperipherie | Sanierung und entfernte Sensoren | Signaluntersuchung und Batterieplan |
| 1-Wire | Temperaturerfassung | Boden-, Rohr- und Raumsensoren | Kabellänge und Adressierung |
| Config | Programmierumgebung | Logik, Zeitprogramme und Szenen | Versionieren und dokumentieren |
| Loxone App | Benutzeroberfläche | Bedienung durch Nutzer und Bediener | Rollenbasierte Ansichten und Berechtigungen |
| KNX-Schnittstelle | KNX-Geräteintegration | Licht und Sonnenschutz | Gruppenadresszuordnung |
| Modbus | Zähler- und Geräteintegration | Zähler, Wechselrichter und Antriebe | Registerplan und Skalierung |
| BACnet-Gateway | BACnet-Geräteintegration | Anlagen und RLT-Geräte | Objektzuordnung und Abfragelast |
| DALI-Gateway | Lichtsteuerung | Leuchten und Treiber | Adressierung und Gruppen |
| Stromversorgung und Notstrom | Versorgung und Ausfallsicherheit | Schaltschränke und Controller | USV, Überspannungsschutz und Wiederherstellungstest |
| Netzwerk | Controller- und Gateway-Konnektivität | Lokale Netze und Standortnetze | Segmentierung, Adressierung und Zeitquelle |
| Fernzugriff | Fernsupport und App-Zugriff | Nutzung durch Bediener und Integrator | Rollenbasierter Zugriff, Protokollierung und Entzug |
| Reservekapazität | Künftige Punkte und Geräte | Erweiterung und Mieterausbau | Reserve als Prozentsatz angeben |
| Dokumentation und Sicherungen | Übergabe und Wiederherstellung | Eigentümer und Wartungsteam | Versioniert und außerhalb des Engineering-Laptops gespeichert |
Projektbilder
3 images
Häufige Fragen
01Was ist ein Loxone Miniserver?
Er ist der Kerncontroller eines Loxone-Systems. Er speichert das Programm, führt Logik und Zeitprogramme aus, stellt Schnittstellen bereit und koordiniert Erweiterungen und Peripheriegeräte. Die Steuerung bleibt lokal, sodass das Gebäude ohne Cloud-Verbindung betrieben werden kann. Kapazität, Schnittstellenanzahl und Sicherungsregelungen sollten vor dem Schaltschrankbau geplant werden.
02Benötigt Loxone eine Internetverbindung?
Für die lokale Steuerung nein. Der Miniserver betreibt das Gebäude vor Ort. Internetzugang wird für Fernzugriff per App, Benachrichtigungen, Updates und Fernsupport genutzt. Die Planung sollte festlegen, welche Funktionen bei ausgefallener WAN-Verbindung weiterlaufen müssen, und die Inbetriebnahme sollte diese Liste nachweisen statt sie anzunehmen.
03Worin unterscheiden sich Tree, Air und 1-Wire?
Tree ist ein kabelgebundener Bus für Schalter, Sensoren und Aktoren. Air ist funkbasierend für Geräte, bei denen eine Verkabelung nicht praktikabel ist. 1-Wire ist ein einfacher Bus, der überwiegend für Temperatursensoren verwendet wird. Die Systeme können parallel betrieben werden; die Wahl hängt vom Gebäude, den Leitungswegen und dem Wartungsplan ab. Funkgeräte erfordern eine Signaluntersuchung und einen Plan für den Batteriewechsel.
04Kann Loxone in BACnet integriert werden?
Ja, über ein BACnet-Gateway. Das Gateway bildet BACnet-Objekte auf Loxone-Punkte ab. Prüfen Sie vor der Festlegung der Planung, welche Objekte unterstützt werden, wie hoch die Punktkapazität ist, wie sich das Polling verhält und was beim Ausfall des Gateways geschieht. Ein nicht dokumentiertes Gateway ist ein Single Point of Failure ohne Verantwortlichen.
05Eignet sich Loxone für Gewerbegebäude?
Ja, sofern lokale Steuerung, offene Schnittstellen und ein klar geregeltes Supportmodell zum Projekt passen. Gewerbeprojekte benötigen üblicherweise mehr Dokumentation, rollenbasierte Zugriffe, Integrationstests und Lebenszyklusplanung als ein Wohngebäude. Leistungsumfang und Support sollten ausdrücklich vereinbart werden. Ein Gewerbegebäude benötigt außerdem einen namentlich benannten Verantwortlichen für das Programm und die Sicherungen.
06Wie wird ein Loxone-System programmiert?
Das Verhalten wird in Config aus Funktionsbausteinen für Ein- und Ausgänge, Logik, Zeitprogramme, Szenen und Alarme erstellt. Gute Projekte arbeiten mit Namenskonventionen, wiederverwendbaren Bausteinen, Versionsverwaltung und Punktprüfungen vor Ort vor der Übergabe. Das Programm sollte als gelenktes Dokument behandelt werden, das ein anderer Ingenieur lesen und pflegen kann.
07Was geschieht, wenn der Miniserver ausfällt?
Die Funktionen dieses Controllers entfallen, bis er wiederhergestellt oder ersetzt ist. Die Planung sollte den Umfang jedes Controllers begrenzen, Sicherungen vorhalten, Ersatzhardware bereithalten und das Wiederherstellungsverfahren dokumentieren. Kritische Funktionen sollten nicht von einem einzelnen undokumentierten Gerät abhängen. Ein Austausch sollte möglich sein, ohne das Programm aus dem Gedächtnis neu aufzubauen.
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.