Sonderfunktionen: Szenen, Zentralbefehle, Logik und Prioritäten

Wer KNX nur als Schaltsystem versteht, nutzt einen Bruchteil seiner Möglichkeiten. Szenen, Zentralfunktionen, Logikbausteine und Zwangsführungen sind es, die aus einzelnen Schalthandlungen ein koordiniertes Gebäudeverhalten machen. Gleichzeitig sind genau diese Funktionen der häufigste Ursprung von Betriebsproblemen: unklare Prioritäten, versteckte Logik, fehlende Statusrückmeldungen und Dokumentation, die nach der Inbetriebnahme niemand mehr findet.

Dieser zehnte Teil der Serie «KNX Grundlagen: die Schulungsreihe» zeigt, wie Szenen, Zentral- und Alarmfunktionen, Zwangsführungen und Logikbausteine sauber konzipiert, in der ETS umgesetzt und so dokumentiert werden, dass auch Dritte die Anlage im Betrieb verstehen. Die Leitfrage ist dabei nicht, was technisch möglich ist, sondern wie man es so macht, dass die Anlage übersichtlich und wartbar bleibt.

Was Sonderfunktionen leisten und wo sie entstehen

Sonderfunktionen in KNX sind keine eigene Gerätekategorie. Sie entstehen durch die Kombination von Kommunikationsobjekten, Gruppenadressen und Geräteparametern. Ein Szenenaufruf ist nichts anderes als ein Telegramm auf einer bestimmten Gruppenadresse, das mehrere Aktoren gleichzeitig auf voreingestellte Werte bringt. Ein Zentralbefehl ist ein Telegramm, das an eine Gruppenadresse gesendet wird, auf die viele Aktoren gleichzeitig hören. Eine Zwangsführung ist ein Kommunikationsobjekt mit höherer Priorität, das den normalen Betrieb überlagert.

Die Stärke dieser Architektur liegt darin, dass sie keine zentrale Steuereinheit voraussetzt. Szenen können direkt in Aktoren gespeichert sein. Logikfunktionen können in spezialisierten Logikmodulen, in Raumcontrollern oder in Visualisierungsservern liegen. Genau das ist aber auch die Schwäche: Wer nicht von Anfang an festlegt, wo welche Logik liegt, findet sie später nicht mehr. Wir sehen in der Praxis regelmässig Anlagen, bei denen dieselbe Funktion an drei verschiedenen Stellen teilweise umgesetzt ist und sich die Ergebnisse gegenseitig stören.

Die Grundregel lautet deshalb: Jede Sonderfunktion hat genau einen Ort, an dem sie definiert ist. Dieser Ort ist dokumentiert. Und die Wirkung ist durch Statusrückmeldungen nachvollziehbar.

Szenen: Komfort mit Struktur

Eine Szene fasst mehrere Aktoren zu einem gemeinsamen Zustand zusammen. Beim Aufruf der Szene sendet das auslösende Gerät, zum Beispiel ein Tastsensor oder ein Raumcontroller, ein Telegramm mit der Szenennummer auf eine Gruppenadresse. Alle Aktoren, die auf diese Gruppenadresse und diesen Datenpunkttyp reagieren, stellen sich auf den für sie gespeicherten Wert ein. Gespeichert werden die Szenenwerte entweder in der ETS bei der Parametrierung oder durch einen Lernbefehl direkt am Gerät.

Der Datenpunkttyp für Szenenaufrufe ist DPT 18.001. Er enthält eine Szenennummer (0 bis 63) und ein Bit, das unterscheidet, ob die Szene abgerufen oder gespeichert werden soll. Aktoren, die Szenen unterstützen, haben dafür ein eigenes Kommunikationsobjekt, das mit der Szenen-Gruppenadresse verknüpft wird.

In der Praxis empfehlen wir, Szenen konsequent in den Aktoren zu speichern und nicht in übergeordneten Steuerungen. So funktioniert die Szene auch dann, wenn ein Server oder eine Visualisierung nicht erreichbar ist. Die Szenenwerte gehören ins ETS-Projekt dokumentiert, nicht nur im Gerät gespeichert. Wer nach einem Geräteaustausch die Szenenwerte nicht mehr kennt, steht vor einem unnötigen Problem.

Ein weiterer Punkt betrifft die Statusrückmeldung. Ein Szenenaufruf sendet Befehle, aber er weiss nicht, ob alle Aktoren reagiert haben. Wer sicherstellen will, dass eine Szene vollständig ausgeführt wurde, braucht Statusobjekte der einzelnen Aktoren und eine übergeordnete Auswertung. Für einfache Komfortszenen ist das oft nicht nötig. Für sicherheitsrelevante Szenen, etwa eine Alarmszene, ist es Pflicht.

Zentralbefehle: alle auf einmal

Ein Zentralbefehl ist konzeptionell einfach: Eine Gruppenadresse wird mit dem Kommunikationsobjekt vieler Aktoren verknüpft, und ein einziges Telegramm schaltet alle gleichzeitig. Typische Anwendungen sind das Ausschalten aller Lichter beim Verlassen des Gebäudes, das Schliessen aller Jalousien bei Windalarm oder das Sperren aller Heizkörperventile ausserhalb der Betriebszeiten.

Die Herausforderung liegt in der Reihenfolge und in der Rückmeldung. Wenn viele Aktoren gleichzeitig auf einen Zentralbefehl reagieren, entsteht kurzzeitig erhöhte Buslast. Das KNX-Bussystem mit CSMA/CA und Wiederholung bis zu dreimal verarbeitet das, aber bei sehr grossen Anlagen lohnt es sich, Zentralbefehle zeitlich zu staffeln oder auf mehrere Linien zu verteilen. Wie Buslast und Telegrammverhalten grundsätzlich funktionieren, haben wir in Teil 8 der Serie «KNX Grundlagen: die Schulungsreihe», «Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast», ausführlich beschrieben.

Zentralbefehle brauchen eine klare Namenskonvention in der Gruppenadressstruktur. Wir legen sie in einer eigenen Hauptgruppe oder Mittelgruppe an, die eindeutig als Zentralfunktion erkennbar ist. So ist beim Blick auf die Gruppenadressliste sofort klar, welche Adressen für Einzelbedienung und welche für Zentralfunktionen vorgesehen sind. Wie Gruppenadressen und Namenskonventionen grundsätzlich aufgebaut werden, beschreibt Teil 5 der Serie, «Gruppenadressen: So sprechen KNX-Geräte miteinander».

Alarmfunktionen: Wind, Regen, Brand

Alarmfunktionen sind Zentralbefehle mit erhöhter Dringlichkeit. Sie werden durch Sensoren oder externe Signale ausgelöst und müssen zuverlässig und schnell wirken. Die häufigsten Fälle in der Gebäudeautomation sind Windalarm für Jalousien und Markisen, Regenalarm für Dachfenster und Lüftungsklappen sowie Brandalarm für die Entrauchung und das Schliessen von Brandschutzklappen.

Für diese Funktionen gelten besondere Anforderungen. Erstens muss der Alarmzustand auch nach einem Busneustart erhalten bleiben oder sofort wieder hergestellt werden. Dafür nutzen wir das Flag «Lesen bei Initialisierung» (I) am Kommunikationsobjekt des Aktors, kombiniert mit einem Gerät, das den Alarmstatus auf Anfrage zurückmeldet. Zweitens darf der Alarm nicht durch normale Bedienbefehle aufgehoben werden können. Das führt direkt zum Thema Zwangsführung und Prioritäten.

Drittens muss die Rückmeldung stimmen. Ein Jalousieaktor, der einen Windalarm empfangen hat, soll seinen Status als «gesperrt durch Alarm» zurückmelden, nicht als «offen» oder «geschlossen». Nur so kann eine Visualisierung oder ein Facility Manager den tatsächlichen Zustand der Anlage beurteilen. Wir empfehlen, für Alarmfunktionen eigene Statusobjekte vorzusehen und diese in der Dokumentation explizit zu beschreiben.

Zwangsführung und Sperre: Prioritäten klar regeln

Zwangsführung und Sperre sind zwei verwandte, aber unterschiedliche Konzepte. Eine Sperre verhindert, dass ein Aktor auf normale Bedienbefehle reagiert. Eine Zwangsführung setzt den Aktor aktiv auf einen bestimmten Zustand und hält ihn dort, unabhängig von anderen Befehlen.

In KNX werden diese Funktionen über spezielle Kommunikationsobjekte in den Aktoren umgesetzt. Viele Aktoren haben ein Sperrobjekt und ein Zwangsführungsobjekt. Das Sperrobjekt blockiert die normale Bedienung, ohne den Ausgang zu verändern. Das Zwangsführungsobjekt setzt den Ausgang auf einen definierten Wert und hält ihn dort, bis die Zwangsführung aufgehoben wird.

Die Prioritätenreihenfolge muss im Projekt explizit festgelegt und dokumentiert sein. Eine typische Reihenfolge von hoch nach tief sieht so aus: Brandalarm hat die höchste Priorität und kann durch nichts anderes übersteuert werden. Windalarm hat die zweithöchste Priorität für Jalousien. Betriebszeitsperre hat eine mittlere Priorität. Die normale Bedienung durch Taster oder Raumregler hat die niedrigste Priorität.

Was in der Praxis oft fehlt, ist die Antwort auf die Frage: Was passiert, wenn eine Zwangsführung aufgehoben wird? Kehrt der Aktor in den letzten manuellen Zustand zurück? Fährt er in eine Standardposition? Wartet er auf den nächsten Befehl? Diese Frage muss für jeden Aktortyp und jede Funktion beantwortet und dokumentiert sein. Wir haben erlebt, dass nach dem Ende eines Windalarms Jalousien in einer undefinierten Position stehen blieben, weil niemand festgelegt hatte, was danach passieren soll.

Ein weiterer Aspekt ist die Rückmeldung des Sperrzustands. Wenn ein Aktor gesperrt ist, soll das für Bediener und Facility Management sichtbar sein. Wir verknüpfen Sperrstatus-Objekte mit der Visualisierung und beschriften sie so, dass der Grund der Sperre erkennbar ist.

Logikbausteine und Zeitschaltprogramme

Logikfunktionen in KNX können an verschiedenen Orten liegen: in spezialisierten Logikmodulen auf dem Bus, in Raumcontrollern mit integrierter Logik, in Visualisierungsservern oder in übergeordneten Systemen wie einem Building Management System. Jeder dieser Orte hat Vor- und Nachteile.

Logik im Busgerät ist robust und funktioniert ohne Server. Sie ist aber in der Kapazität begrenzt und schwieriger zu ändern, weil jede Anpassung eine neue ETS-Programmierung erfordert. Logik im Server ist flexibler und leistungsfähiger, aber abhängig vom Betrieb des Servers. Fällt der Server aus, fällt auch die Logik aus.

Typische Logikfunktionen in KNX-Projekten sind UND- und ODER-Verknüpfungen für Präsenz- und Helligkeitssensoren, Zeitverzögerungen für Treppenhausbeleuchtung, Grenzwertauswertungen für Temperaturen und Zählerstände sowie Zeitschaltprogramme für Betriebszeiten.

Zeitschaltprogramme sind ein Sonderfall. Sie können in dedizierten Zeitschaltuhren auf dem Bus liegen, in Raumcontrollern oder in der Visualisierung. Wir empfehlen, Zeitschaltprogramme für sicherheitsrelevante Funktionen immer in einem Busgerät zu hinterlegen, das unabhängig vom Server läuft. Komfortfunktionen können dagegen im Server liegen, wenn der Ausfall tolerierbar ist.

Für alle Logikfunktionen gilt dieselbe Grundregel wie für Szenen: Jede Logik hat genau einen Ort. Wir dokumentieren diesen Ort im ETS-Projekt und in der Anlagendokumentation. Wer Logik an mehreren Stellen verteilt, ohne das zu dokumentieren, schafft eine Anlage, die niemand mehr vollständig versteht.

Ein praktisches Hilfsmittel ist eine Logiktabelle als Teil der Projektdokumentation. Sie listet jede Logikfunktion mit Eingang, Ausgang, Bedingung, Ort der Umsetzung und zugehöriger Gruppenadresse auf. Diese Tabelle ist nicht Teil der ETS, aber sie ist das Dokument, das ein Servicetechniker braucht, wenn er drei Jahre nach der Inbetriebnahme eine Funktion anpassen soll.

Dokumentation der Logik: Was wohin gehört

Dokumentation ist in KNX-Projekten oft das schwächste Glied. Das ETS-Projekt enthält die Konfiguration der Geräte und die Gruppenadresszuordnungen, aber es enthält nicht die Absicht hinter der Konfiguration. Warum ist diese Gruppenadresse mit diesem Objekt verknüpft? Welche Priorität gilt bei Konflikt? Was soll passieren, wenn ein Sensor ausfällt?

Diese Fragen beantwortet das ETS-Projekt nicht von selbst. Sie müssen in einer separaten Funktionsbeschreibung oder in Kommentarfeldern innerhalb der ETS festgehalten werden. Wir nutzen beide Wege: Kommentare in der ETS für gerätespezifische Hinweise und eine separate Funktionsbeschreibung für übergeordnete Zusammenhänge.

Die Funktionsbeschreibung für Sonderfunktionen enthält mindestens folgende Punkte: eine Liste aller Szenen mit Szenennummer, beteiligten Aktoren und gespeicherten Werten; eine Liste aller Zentralfunktionen mit Auslöser, Gruppenadresse und Wirkung; eine Prioritätentabelle für alle Zwangsführungen und Sperren; eine Logiktabelle mit allen Verknüpfungen und ihrem Umsetzungsort; und eine Beschreibung des Verhaltens nach Busneustart und nach Aufhebung von Zwangsführungen.

Diese Dokumentation ist nicht optional. Sie ist die Grundlage dafür, dass die Anlage im Betrieb gewartet, angepasst und übergeben werden kann. Wir sehen das als Teil unserer Planungsleistung und liefern sie zusammen mit dem ETS-Projekt ab. Wie die Übergabe des ETS-Projekts an den Bauherrn geregelt sein sollte, beschreibt Teil 5 der Serie «KNX richtig planen», «Das ETS-Projekt gehört dem Bauherrn».

Typische Fehler und wie man sie vermeidet

Aus unserer Projekterfahrung gibt es einige Muster, die immer wieder zu Problemen führen.

Das erste Muster ist Logik ohne Ort. Jemand hat eine Funktion irgendwo eingebaut, aber niemand weiss mehr wo. Das passiert besonders häufig bei Projekten, die über mehrere Jahre gewachsen sind oder bei denen verschiedene Integratoren nacheinander gearbeitet haben. Die Lösung ist eine klare Regel zu Beginn des Projekts: Jede Logik hat einen definierten Ort, und dieser Ort ist dokumentiert.

Das zweite Muster ist fehlende Statusrückmeldung. Ein Zentralbefehl wird gesendet, aber niemand weiss, ob er angekommen ist und ob alle Aktoren reagiert haben. Für Komfortfunktionen ist das tolerierbar. Für Alarm- und Sicherheitsfunktionen ist es ein ernstes Problem. Wir planen Statusobjekte von Anfang an mit und verknüpfen sie mit der Visualisierung.

Das dritte Muster ist ungeklärtes Verhalten nach Ereignissen. Was passiert nach einem Busneustart? Was passiert nach einem Stromausfall? Was passiert, wenn ein Windalarm endet? Diese Fragen müssen vor der Inbetriebnahme beantwortet sein, nicht danach. Wir stellen sie systematisch in der Planungsphase und halten die Antworten in der Funktionsbeschreibung fest.

Das vierte Muster ist übermässige Komplexität. Manchmal wird versucht, jede denkbare Situation durch Logik abzudecken. Das Ergebnis ist eine Anlage, die niemand mehr vollständig versteht und die bei jeder Änderung unerwartete Nebenwirkungen zeigt. Wir empfehlen, Logik so einfach wie möglich zu halten und Komplexität nur dort einzuführen, wo sie einen klaren Mehrwert bringt.

Das fünfte Muster ist die fehlende Abstimmung zwischen Gewerken. Wenn eine Jalousiesteuerung einen Windalarm empfängt und gleichzeitig eine Beschattungsautomatik einen Befehl sendet, entsteht ein Konflikt. Wer hat Vorrang? Das muss im Planungsprozess zwischen Elektro, HLKS und GA abgestimmt sein, nicht auf der Baustelle gelöst werden. Wie Raumautomation mit KNX gesamtheitlich geplant wird, beschreibt Teil 9 der Serie «KNX in Betrieb und Bestand», «Raumautomation mit KNX nach EN ISO 52120».

Der rote Faden zu unseren Fachbeiträgen

Die Grundlagen für diesen Artikel liegen in mehreren früheren Teilen der Serie «KNX Grundlagen: die Schulungsreihe». Kommunikationsobjekte und Flags, die das Fundament jeder Sonderfunktion bilden, erklärt Teil 6, «Kommunikationsobjekte und Flags: Wer sendet, wer hört zu?». Datenpunkttypen wie DPT 18.001 für Szenenaufrufe behandelt Teil 7, «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht». Wie Buslast und Telegrammverhalten bei Zentralbefehlen zu berücksichtigen sind, zeigt Teil 8, «Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast». Die ETS-Projektierung als Werkzeug für die Umsetzung aller hier beschriebenen Funktionen ist Thema von Teil 9, «ETS-Projektierung Schritt für Schritt».

Für die Planung im Gesamtprojekt sind die Serien «KNX richtig planen» und «KNX in Betrieb und Bestand» relevant. Besonders der Beitrag «Topologie, Linien und IP-Backbone sauber aufbauen» (Teil 2 der Serie «KNX richtig planen») und «Gruppenadressen und Namenskonvention als Fundament» (Teil 3 der Serie «KNX richtig planen») legen die strukturelle Basis, auf der Sonderfunktionen sauber aufgebaut werden können.

Wer KNX in grössere Systemumgebungen einbettet, findet in der Serie «Schnittstellen rund um KNX» weitere Hinweise: «KNX und BACnet: Raumautomation an die Gebäudeleittechnik» (Teil 4 der Serie «Schnittstellen rund um KNX») zeigt, wie Szenen- und Alarmzustände an übergeordnete Systeme weitergegeben werden können.

Den Abschluss der Grundlagenserie bildet Teil 11, «KNX lernen in der Schweiz: Kurse, Partnerprüfung und Weiterbildung», mit einem Überblick über Ausbildungswege für alle, die ihr KNX-Wissen vertiefen möchten.

Fazit

Szenen, Zentralbefehle, Logikbausteine und Zwangsführungen machen KNX zu einem leistungsfähigen Werkzeug für komfortables und sicheres Gebäudeverhalten. Aber diese Leistungsfähigkeit hat ihren Preis: Sie erfordert klare Regeln, wo die Logik liegt, welche Priorität gilt, wie Status zurückgemeldet wird und was nach Ereignissen wie Busneustart oder Alarmende passiert.

Die technischen Mittel sind in KNX vorhanden und gut durchdacht. Was in der Praxis fehlt, ist meistens nicht die Technik, sondern die Planung und die Dokumentation. Wer Sonderfunktionen von Anfang an mit einem klaren Konzept angeht, schafft eine Anlage, die im Betrieb funktioniert, gewartet werden kann und auch nach Jahren noch verständlich ist. Wer diese Arbeit auf die Inbetriebnahme verschiebt, schafft eine Anlage, die niemand mehr vollständig versteht.

Sie haben Fragen dazu?

Sie planen eine KNX-Anlage mit Szenen, Alarmfunktionen oder komplexerer Logik und möchten sicherstellen, dass Konzept, Umsetzung und Dokumentation stimmen? Wir unterstützen Sie von der Funktionsbeschreibung bis zur Abnahme. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association: KNX System Specifications, insbesondere Abschnitte zu Szenen (DPT 18.001), Kommunikationsobjekten, Flags und Geräteverhalten (sinngemäss verwendet; KNX und ETS sind eingetragene Marken der KNX Association, Brüssel)
• KNX Association: ETS6 Dokumentation und Anwendungshinweise (sinngemäss verwendet)
• EN 50090 / ISO/IEC 14543-3: KNX-Norm (Systemspezifikation)
• EN ISO 22510: KNXnet/IP
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden, Beitrag der Gebäudeautomation und des Gebäudemanagements
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Inbetriebnahme und Betriebsbegleitung