Ein KNX-Gateway verbindet zwei Protokollwelten. Daraus entsteht schnell die Annahme, Produkte mit derselben Protokollkombination seien weitgehend austauschbar. Gerade bei DALI und Modbus ist das Gegenteil der Fall.

Die entscheidenden Unterschiede liegen häufig nicht beim physikalischen Anschluss, sondern im Applikationsmodell, bei unterstützten Gerätetypen, Datenstrukturen und der Art, wie diese auf KNX abgebildet werden.

DALI-2 erweitert die standardisierte Welt über klassische Control Gear hinaus um Control Devices. Dazu zählen Application Controller und Input Devices. Input Devices können beispielsweise Präsenz, Helligkeit oder Tastendrücke bereitstellen und kommunizieren in der Regel ereignisbasiert als Multi-Master-Teilnehmer.

Damit reicht die Angabe «DALI-2 Gateway» nicht aus. Soll das Gateway lediglich DALI-2-Betriebsgeräte steuern oder selbst als Application Controller arbeiten und zusätzlich Input Devices einbinden? Diese Unterscheidung ist für Projekte mit DALI-2-Sensorik wesentlich.

Der im Inyx-Portfolio verfügbare Multi-Master Application Controller unterstützt beispielsweise neben Vorschaltgeräten auch normkonforme DALI-2-Bewegungsmelder, Lichtsensoren und Taster-Interfaces.

Ähnlich ist es bei Colour Control und Tunable White. Die Unterstützung von DT8 stellt zunächst sicher, dass entsprechende DALI-Funktionen angesprochen werden können. Für die KNX-Integration wird jedoch relevant, wie das Gateway diese Funktionen über Kommunikationsobjekte und Parameter abbildet.

Ein zweikanaliges DALI-Gateway im Inyx-Portfolio unterstützt beispielsweise DT8-Farbtemperatur über 2-Byte-Objekte und stellt darüber hinaus Statusinformationen, Betriebsstunden, Lampen-/EVG-Fehler sowie Diagnosewerte des DALI-Busses zur Verfügung.

Damit kann ein Projekt, das lediglich Tunable White benötigt, mit anderen Anforderungen auskommen als eine Anlage, bei der detaillierte Betriebs- und Fehlerzustände in ein übergeordnetes Monitoring einfliessen sollen.

Bei Modbus liegt der Schwerpunkt nicht auf Gerätetypen, sondern auf dem Datenmodell des Fremdgeräts. Die Modbus-Spezifikation definiert Funktion Codes und Registerzugriffe, nicht jedoch, welche konkrete Bedeutung Hersteller ihren Registern geben.

Für die Integration muss deshalb bekannt sein:

• Welche Register enthalten die benötigten Werte?
• Welche Register sind lesbar beziehungsweise schreibbar?
• Welcher Datentyp wird verwendet?
• Wie viele Register belegt der Wert?
• Welche Skalierung ist vorgesehen?
• Welche Adressnotation verwendet die Herstellerdokumentation?

Gerade die Adressierung ist eine klassische Fehlerquelle. Modbus-Telegramme arbeiten mit relativen, nullbasierten Adressen, während Herstellerdokumentationen häufig absolute Registernummern wie 40001 verwenden.

Ein scheinbarer «Offset-Fehler» kann damit schlicht aus unterschiedlichen Darstellungen derselben Adresse entstehen.

Jedes Modbus-Register besteht aus 16 Bit. Grössere Datentypen müssen über mehrere Register verteilt werden. Ein 32-Bit-Float benötigt entsprechend zwei zusammenhängende Register.

Für ein KNX-Gateway wird damit relevant, welche Datentypen seine Applikation direkt unterstützt und wie diese auf KNX-Datenpunkttypen gemappt werden können. Ein Gateway mit 250 Kanälen ist nicht automatisch geeigneter als eines mit 32 Datenpunkten, wenn das kleinere Gerät genau die benötigten Datenstrukturen sauber abbildet.

Inyx führt beispielsweise sowohl ein ETS-parametrierbares RS485-Gateway mit 32 frei skalierbaren Datenpunkten als auch ein KNX/Modbus-RTU-Gateway mit 250 konfigurierbaren Kanälen, Master-/Slave-Funktion und zusätzlichen Logiken.

Die relevante Frage lautet deshalb nicht «Wie viele Datenpunkte?», sondern welche Datenpunkte, in welcher Struktur und mit welcher Funktion?

Noch wichtiger wird das bei schreibenden Funktionen. Dass beispielsweise ein Sollwert in der Modbus-Dokumentation vorhanden ist, bedeutet nicht automatisch, dass er über Modbus verändert werden darf.

Die unterstützten Function Codes und das konkrete Registermodell des Fremdgeräts bestimmen, welche Werte geschrieben werden können. Ein KNX-Gateway kann keine Stellmöglichkeit erzeugen, die das angebundene Gerät selbst nicht anbietet.

Damit muss bei einer Integration immer die komplette Kette betrachtet werden: Gewünschte KNX-Funktion → benötigter Fremdsystemwert → Zugriffsmöglichkeit → Datentyp → Gateway-Mapping.

Bei DALI wie bei Modbus zeigt sich damit derselbe Punkt: Die Angabe des Protokolls ist für die Auswahl zu grob. Relevant wird, welche Rollen, Gerätetypen, Datenstrukturen, Kommunikationsobjekte und Diagnosefunktionen das konkrete Gateway unterstützt.

Genau deshalb lohnt sich der Vergleich der Applikationen bereits vor der Spezifikation – nicht erst bei der Inbetriebnahme.