Jede KNX-Anlage jenseits von reinem Schalten braucht Logik: Verknüpfungen, Bedingungen, Zeitsteuerungen, Prioritäten. Die Frage ist nicht ob, sondern wo diese Logik liegt – und diese Entscheidung wirkt sich über die gesamte Lebensdauer der Anlage aus.
Es gibt drei Orte, und jeder hat seinen Bereich.
Ort 1: Logik in den Geräten
Viele Aktoren und Sensoren bringen eigene Logikfunktionen mit: UND-Verknüpfungen, Sperrobjekte, Verzögerungen, Szenen, Schwellwerte.
Wofür geeignet: Alles, was lokal bleibt. Ein Präsenzmelder, der Licht schaltet und nach zehn Minuten abschaltet. Ein Aktor, der bei Sperrobjekt nicht reagiert. Eine Szene, die drei Kanäle desselben Geräts betrifft.
Vorteile: Kein zusätzliches Gerät, kein Ausfallpunkt. Die Funktion läuft, solange das Gerät läuft.
Nachteile: Verteilte Logik ist schwer nachvollziehbar. Wer wissen will, warum das Licht ausgeht, muss jedes beteiligte Gerät einzeln prüfen. Bei zwanzig Geräten wird das zur Suche.
Grenze: Sobald eine Funktion mehr als zwei Geräte betrifft, wird Gerätelogik unübersichtlich.
Ort 2: Dediziertes Logikmodul
Ein Reiheneinbaugerät, das ausschließlich Logik ausführt – mit grafischer oder textueller Programmierung, meist in der ETS parametriert oder über ein Herstellertool.
Wofür geeignet: Verknüpfungen über mehrere Gewerke. Prioritätenregelungen. Alles, was mehr als zwei Eingänge braucht.
Vorteile: Die Logik liegt an einer Stelle und ist dokumentierbar. Änderungen betreffen ein Gerät. Für einen Nachfolger nachvollziehbar.
Nachteile: Ein zusätzlicher Ausfallpunkt und ein zusätzliches Gerät, dessen Parametrierwerkzeug man beherrschen muss. Bei Herstellerwechsel ist die Logik nicht übertragbar.
Typischer Einsatz: Ab etwa fünf bis zehn gewerkübergreifenden Funktionen lohnt sich ein Modul gegenüber verteilter Gerätelogik.
Ort 3: Server oder Visualisierung
Gira X1, HomeServer, MDT VisuControl, aber auch Home Assistant oder ioBroker. Logik läuft dort als Programm, oft mit komfortabler Oberfläche.
Wofür geeignet: Komplexe Automatik mit vielen Bedingungen. Anbindung an Wetterdienste, Kalender, Anwesenheitserkennung. Alles, was Daten von außerhalb des Busses braucht.
Vorteile: Mächtig, komfortabel programmierbar, gut visualisierbar.
Nachteile: Ein einzelner Ausfallpunkt für die gesamte Automatik. Wenn der Server steht, funktionieren Grundfunktionen zwar weiter – aber alles, was über Logik läuft, nicht. Und: Bei Systemen wie Home Assistant hängt die Wartbarkeit an Software, die sich schneller ändert als eine KNX-Anlage.
Die praktische Aufteilung
Eine Aufteilung, die in der Praxis trägt:
| Funktionstyp | Wo |
|---|---|
| Schalten, Dimmen, Fahren | Gerät |
| Präsenzabhängiges Licht in einem Raum | Gerät (Präsenzmelder) |
| Sperrfunktionen, Zwangsführung | Gerät (Aktor) |
| Wind- und Frostschutz | Logikmodul oder Wetterstation, nie Server |
| Beschattungsautomatik nach Sonnenstand | Logikmodul |
| Zentralfunktionen (alles aus, Anwesenheit) | Logikmodul |
| Szenen über mehrere Gewerke | Logikmodul |
| Zeitprogramme mit Kalenderbezug | Server |
| Anbindung Wetterdienst, Verbrauchsdaten | Server |
| Visualisierung, Fernzugriff | Server |
Die Trennlinie verläuft dort, wo eine Funktion sicherheitsrelevant oder alltagsnotwendig wird. Windschutz ist sicherheitsrelevant – der gehört nicht in ein System, das man aktualisieren muss.
Was die Wartbarkeit am meisten beschädigt
Nicht die Wahl des Ortes, sondern die Mischung ohne Regel. Wenn dieselbe Funktionsart mal im Gerät, mal im Modul und mal im Server liegt, ist keine Fehlersuche mehr planbar.
Drei Empfehlungen:
- Eine Regel festlegen und aufschreiben – welche Funktionsart liegt wo. Fünf Zeilen im Projektkommentar reichen.
- Nicht wandern. Wenn eine Funktion erweitert wird, bleibt sie an ihrem Ort, statt aus Bequemlichkeit in den Server zu wandern.
- In der Dokumentation vermerken, wo welche Logik liegt. Sonst sucht der Nächste im falschen System.
