KNX und Modbus: Zähler, Wärmepumpen und Lüftungsgeräte einbinden

Modbus ist seit Jahrzehnten in der Gebäudetechnik präsent. Energiezähler, Wärmepumpen, Lüftungsgeräte, Frequenzumrichter und viele weitere Geräte sprechen dieses Protokoll, weil es einfach, robust und weit verbreitet ist. Wer eine KNX-Anlage plant und gleichzeitig Messwerte aus diesen Geräten nutzen will, kommt an Modbus fast nicht vorbei. Die Kopplung ist technisch machbar, aber sie verlangt sorgfältige Vorbereitung. Denn Modbus liefert Werte, aber keine Bedeutung. Ein Register enthält eine Zahl. Was diese Zahl bedeutet, in welcher Einheit sie steht, wie sie skaliert ist und ob sie überhaupt plausibel ist, steht nicht im Protokoll, sondern in der Dokumentation des Geräteherstellers.

Dieser dritte Teil der Serie «Schnittstellen rund um KNX» zeigt, wie wir Modbus-Geräte zuverlässig in eine KNX-Anlage einbinden. Wir erklären den Unterschied zwischen Modbus RTU und Modbus TCP, beschreiben, worauf es beim Registermapping ankommt, und zeigen, wie Polling, Buslast und Gateway-Konfiguration zusammenhängen. Wer sich für die Grundlagen der KNX-Topologie interessiert, findet diese in der Serie «KNX richtig planen». Wer wissen will, wie Modbus-Daten später über BACnet oder MQTT weitergegeben werden, findet dazu die Teile 4 und 5 dieser Serie.

Modbus RTU und Modbus TCP: zwei Varianten, ein Prinzip

Modbus existiert in zwei verbreiteten Varianten, die sich in der physikalischen Übertragung unterscheiden, aber dasselbe Anwendungsprotokoll verwenden.

Modbus RTU läuft über serielle Leitungen, typischerweise RS-485. Die Geräte hängen als Teilnehmer auf einem Bus, jeder mit einer eindeutigen Adresse zwischen 1 und 247. Der Master fragt ab, die Slaves antworten. Es gibt keinen Broadcast-Mechanismus für Messwerte: Wer Daten will, muss fragen. Die Übertragungsrate ist konfigurierbar, in der Praxis sind 9600 oder 19200 Baud verbreitet, bei neueren Geräten auch 38400 oder 115200 Baud. Wichtig ist, dass alle Teilnehmer auf demselben Bus dieselbe Baudrate, dasselbe Datenformat und dieselbe Parität verwenden. Eine einzige falsch konfigurierte Schnittstelle kann den gesamten Bus stören.

Modbus TCP überträgt dieselben Funktionscodes über TCP/IP. Jedes Gerät hat eine IP-Adresse, der Port ist standardmässig 502. Der Begriff «Master/Slave» wird in neueren Dokumenten durch «Client/Server» ersetzt, die Funktion bleibt dieselbe. Modbus TCP ist einfacher zu verdrahten, weil die bestehende IP-Infrastruktur genutzt werden kann. Dafür entstehen neue Fragen: Netzwerksegmentierung, IP-Adressverwaltung und Firewall-Regeln müssen berücksichtigt werden.

In der Praxis begegnen uns beide Varianten. Ältere Energiezähler und Feldgeräte sprechen oft RTU. Neuere Wärmepumpen und Lüftungsgeräte bieten häufig TCP an, manchmal auch beides parallel. Gateways, die Modbus in KNX-Gruppenadressen übersetzen, unterstützen in der Regel beide Varianten, manchmal auf separaten Schnittstellen, manchmal konfigurierbar.

Registertabellen: die eigentliche Arbeit beginnt hier

Das Modbus-Protokoll definiert vier Objekttypen: Coils (einzelne Bits, les- und schreibbar), Discrete Inputs (einzelne Bits, nur lesbar), Holding Registers (16-Bit-Wörter, les- und schreibbar) und Input Registers (16-Bit-Wörter, nur lesbar). In der Gebäudetechnik sind Holding Registers und Input Registers am häufigsten. Energiezähler legen Messwerte in Input Registers ab, Wärmepumpen und Lüftungsgeräte nutzen Holding Registers für Sollwerte und Betriebsmodi.

Die Registertabelle des Herstellers ist das zentrale Dokument für jede Integration. Sie enthält die Registeradressen, den Objekttyp, den Datentyp, die Einheit und die Skalierung. Ohne diese Tabelle ist eine korrekte Integration nicht möglich. In der Praxis stellen wir fest, dass diese Dokumente sehr unterschiedlich gepflegt sind. Manche Hersteller liefern vollständige, versionierte Tabellen. Andere veröffentlichen nur rudimentäre Listen, die nicht alle Register abdecken oder bei denen die Skalierung unklar ist.

Ein häufiger Stolperstein ist die Registeradresse selbst. Modbus unterscheidet zwischen der Protokolladresse und der Registeradresse, wie sie in der Dokumentation angegeben wird. Manche Hersteller zählen ab 0, andere ab 1. Register 40001 in der Dokumentation entspricht im Protokoll der Adresse 0. Diese Verschiebung um 1 führt zu Fehlern, die schwer zu finden sind, weil das Gateway keine Fehlermeldung liefert, sondern einfach den falschen Wert liest.

Datentypen und Byte-Reihenfolge: wo Fehler unsichtbar bleiben

Ein Modbus-Register enthält 16 Bit. Viele Messwerte, insbesondere Energiemengen und Leistungswerte, brauchen mehr als 16 Bit. Deshalb werden häufig zwei Register zu einem 32-Bit-Wert zusammengefasst. Ob das höherwertige Register zuerst kommt (Big Endian) oder das niederwertige (Little Endian), ist nicht im Protokoll festgelegt, sondern vom Hersteller definiert. Wird die Byte-Reihenfolge falsch konfiguriert, liefert das Gateway einen Wert, der numerisch plausibel aussehen kann, aber falsch ist.

Dasselbe gilt für Gleitkommazahlen. Viele Geräte übertragen Messwerte als IEEE 754 Float über zwei Register. Auch hier gibt es vier mögliche Byte-Reihenfolgen, je nach Hersteller. Ohne die korrekte Angabe in der Registertabelle ist Raten keine Methode.

Skalierungsfaktoren sind ein weiteres Thema. Ein Energiezähler kann die Wirkenergie in Wh, kWh oder in Zehnteln von kWh übertragen. Der rohe Registerwert ist ohne den Skalierungsfaktor wertlos. Das Gateway muss diesen Faktor kennen und anwenden, bevor der Wert als KNX-Datenpunkt weitergegeben wird. Wird der Skalierungsfaktor falsch eingetragen, erscheint der Wert auf der KNX-Seite um einen Faktor 10 oder 1000 verschoben, ohne dass eine Fehlermeldung entsteht.

Wir empfehlen deshalb, für jede Modbus-Schnittstelle eine eigene Mapping-Tabelle zu führen, die Registeradresse, Objekttyp, Datentyp, Byte-Reihenfolge, Skalierungsfaktor, Einheit und den zugehörigen KNX-Datenpunkttyp enthält. Diese Tabelle ist Teil der Projektdokumentation und muss bei Geräteersatz oder Firmware-Updates geprüft werden.

Polling und Buslast: wie oft ist oft genug?

Modbus ist ein reines Abfrageprotokoll. Werte werden nicht gesendet, wenn sie sich ändern, sondern nur dann, wenn der Master fragt. Das Gateway fragt die Geräte in einem konfigurierbaren Zyklus ab. Wie kurz dieser Zyklus sein darf, hängt von mehreren Faktoren ab.

Auf einem RS-485-Bus mit mehreren Teilnehmern summiert sich die Abfragezeit. Jede Anfrage braucht Zeit für die Übertragung, die Verarbeitung im Gerät und die Antwort. Bei 9600 Baud und mehreren Geräten mit je mehreren Registern kann ein vollständiger Abfragezyklus mehrere Sekunden dauern. Wird der Zyklus kürzer konfiguriert als die tatsächliche Abfragezeit, entstehen Timeouts und Fehler.

Auf der KNX-Seite entstehen durch die Modbus-Abfragen Telegramme, die auf den Bus gelangen. Wer viele Modbus-Werte mit kurzen Zyklen abfragt und alle Werte bei jeder Abfrage auf den KNX-Bus sendet, kann die Buslast spürbar erhöhen. Sinnvoller ist es, Werte nur dann auf den KNX-Bus zu senden, wenn sie sich gegenüber dem letzten Wert um mehr als einen konfigurierbaren Schwellwert geändert haben. Die meisten Gateways unterstützen diese Funktion. Für Energiemonitoring-Werte, die in ein übergeordnetes System weitergegeben werden, kann es sinnvoll sein, zusätzlich einen zyklischen Sendeauftrag zu konfigurieren, damit der Empfänger weiss, dass der Wert noch aktuell ist.

Für Energiezähler, deren Werte sich langsam ändern, reicht ein Abfragezyklus von 30 bis 60 Sekunden in den meisten Fällen aus. Für Betriebszustände einer Wärmepumpe, auf die eine Regelung reagieren soll, kann ein kürzerer Zyklus nötig sein. Für Alarme und Fehlerzustände empfehlen wir, den Zyklus kurz zu halten und den Wert immer zu senden, unabhängig von einer Änderungsschwelle.

Gateways: Auswahl, Konfiguration und Dokumentation

Das Gateway ist das Herzstück der Modbus-KNX-Integration. Es liest die Modbus-Register, wandelt die Werte in KNX-Datenpunkte um und sendet sie auf den KNX-Bus. In der Gegenrichtung kann es KNX-Telegramme empfangen und als Modbus-Schreibbefehle weitergeben, zum Beispiel um den Sollwert einer Wärmepumpe zu setzen.

Bei der Auswahl eines Gateways sind mehrere Punkte zu prüfen. Erstens die unterstützten Modbus-Varianten: RTU, TCP oder beides. Zweitens die Anzahl der konfigurierbaren Datenpunkte, die je nach Gerät stark variiert. Drittens die unterstützten Datentypen: nicht alle Gateways können 32-Bit-Float-Werte oder alle Byte-Reihenfolgen verarbeiten. Viertens die Konfigurationsmöglichkeiten für Polling-Zyklen, Änderungsschwellen und zyklisches Senden. Fünftens die Diagnosemöglichkeiten: Kann das Gateway Kommunikationsfehler anzeigen und auf den KNX-Bus melden?

Die Konfiguration des Gateways muss vollständig dokumentiert werden. Das bedeutet: alle konfigurierten Modbus-Adressen mit den zugehörigen KNX-Gruppenadressen, Datenpunkttypen, Skalierungsfaktoren und Zykluszeiten. Diese Dokumentation ist nicht nur für die Inbetriebnahme wichtig, sondern auch für den Betrieb. Wenn ein Energiezähler nach Jahren ersetzt wird und der Nachfolger eine andere Registertabelle hat, muss die Gateway-Konfiguration angepasst werden. Ohne Dokumentation ist das eine aufwendige Fehlersuche.

Wir empfehlen, die Gateway-Konfiguration als exportierbare Datei zu sichern und zusammen mit der Registertabelle und der Projektdokumentation abzulegen. Viele Gateways bieten diese Exportfunktion an. Wer das nicht tut, riskiert, dass bei einem Geräteausfall die gesamte Konfiguration neu erstellt werden muss.

Typische Geräte und ihre Besonderheiten

Energiezähler

Energiezähler sind die häufigste Modbus-Anwendung im Energiemonitoring. Sie liefern Wirkenergie, Wirkleistung, Spannung, Strom und Leistungsfaktor. Die Registertabellen sind bei etablierten Herstellern meist gut dokumentiert. Typische Fallstricke sind die Byte-Reihenfolge bei 32-Bit-Werten, unterschiedliche Skalierungen je nach Gerätegeneration und die Frage, ob der Zähler die Energie als absoluten Zählerstand oder als Differenzwert liefert.

Für das Energiemonitoring ist der absolute Zählerstand in der Regel sinnvoller, weil er auch nach einem Gateway-Neustart korrekt ist. Differenzwerte können bei Kommunikationsunterbrüchen zu Datenlücken führen. Wer Energiedaten für Abrechnungen oder Nachweise verwendet, sollte ausserdem prüfen, ob der Zähler geeicht ist und ob die Modbus-Schnittstelle den geeichten Wert liefert oder einen internen Hilfswert.

Mehr zum Aufbau eines sinnvollen Energiemonitorings und zur Bedeutung korrekter Messwerte findet sich in unserem Beitrag «Datenqualität im Monitoring: warum falsche Zähler falsche Entscheide erzeugen».

Wärmepumpen

Wärmepumpen bieten über Modbus typischerweise Betriebszustände, Temperaturen, Leistungsaufnahme und Sollwerte an. Die Registertabellen sind herstellerspezifisch und variieren stark. Manche Hersteller unterscheiden zwischen Lese- und Schreibregistern für denselben Parameter, andere verwenden dasselbe Register für beides.

Besondere Aufmerksamkeit verdienen Schreibzugriffe. Wenn das Gateway einen Sollwert schreibt, muss sichergestellt sein, dass der Wert im richtigen Format und im richtigen Wertebereich liegt. Ein falsch skalierter Sollwert kann dazu führen, dass die Wärmepumpe einen unplausiblen Wert erhält. Manche Geräte ignorieren solche Werte, andere übernehmen sie. Im schlimmsten Fall führt ein falscher Schreibzugriff zu einem Gerätealarm oder einer Schutzabschaltung.

Wir empfehlen, Schreibzugriffe auf Wärmepumpen immer mit Grenzwertprüfung im Gateway zu konfigurieren und die Funktion im Rahmen der Inbetriebnahme zu testen. Dazu gehört auch ein Test des Verhaltens bei Kommunikationsunterbruch: Was macht die Wärmepumpe, wenn das Gateway ausfällt und keine neuen Sollwerte mehr kommen?

Lüftungsgeräte

Lüftungsgeräte bieten über Modbus Betriebsmodi, Volumenstromsollwerte, Temperaturen, Filterzustände und Alarme an. Die Integration ist oft komplexer als bei Zählern, weil mehr Parameter relevant sind und weil Schreibzugriffe für die Regelung nötig sein können.

Ein häufiges Thema ist die Koordination zwischen der internen Regelung des Lüftungsgeräts und dem externen Eingriff über Modbus. Viele Geräte haben eine eigene Regellogik, die durch externe Sollwerte übersteuert werden kann. Ob und wie das funktioniert, ist im Handbuch des Herstellers beschrieben. Wir empfehlen, diese Koordination vor der Inbetriebnahme mit dem Gerätehersteller zu klären und die Verantwortung für die Regelung klar zu definieren.

Fehlerbehandlung und Diagnose

Modbus ist ein einfaches Protokoll mit begrenzten Fehlermeldungen. Ein Slave kann auf eine Anfrage mit einem Exception-Code antworten, zum Beispiel wenn die angefragte Registeradresse nicht existiert oder der Wert ausserhalb des zulässigen Bereichs liegt. Das Gateway muss diese Exception-Codes auswerten und dem Betreiber anzeigen.

Häufiger als Exception-Codes sind Timeouts: Das Gerät antwortet nicht innerhalb der konfigurierten Zeit. Ursachen können eine unterbrochene Leitung, ein falsch konfigurierter Slave, ein überlasteter Bus oder ein Gerätefehler sein. Das Gateway sollte Timeouts zählen und als Diagnoseinformation bereitstellen. Auf dem KNX-Bus kann ein Kommunikationsfehler als Statusdatenpunkt abgebildet werden, damit die Gebäudeleittechnik oder ein Monitoring-System den Zustand erkennt.

Wir empfehlen, bei der Inbetriebnahme gezielt Fehlersituationen zu testen: Gerät ausschalten, Leitung unterbrechen, falsche Adresse konfigurieren. Das Gateway sollte in allen Fällen klar erkennbare Fehlerzustände anzeigen und keine falschen Werte auf den KNX-Bus senden. Manche Gateways senden bei Kommunikationsfehler den letzten gültigen Wert weiter, was irreführend sein kann. Besser ist es, einen definierten Fehlerwert oder ein Statusbit zu senden.

Bezug zum Energiemonitoring

Modbus-Zähler sind in vielen Liegenschaften die primäre Datenquelle für das Energiemonitoring. Die Qualität der Daten hängt direkt von der Qualität der Integration ab. Ein falsch skalierter Wert, eine falsche Byte-Reihenfolge oder ein unerkannter Kommunikationsfehler führen zu falschen Messwerten, die in Dashboards und Berichten weiterverwendet werden.

Wir haben in unseren Projekten erlebt, dass Energiedaten über Monate falsch waren, weil ein Skalierungsfaktor bei der Inbetriebnahme nicht geprüft wurde. Der Fehler fiel erst auf, als die Jahresauswertung mit den Abrechnungswerten des Energieversorgers verglichen wurde. Eine einfache Plausibilitätsprüfung bei der Inbetriebnahme, zum Beispiel der Vergleich des Modbus-Werts mit dem Display des Zählers, hätte den Fehler sofort aufgedeckt.

Für Energieverantwortliche, die Modbus-Daten für Nachweise oder Berichte verwenden, empfehlen wir, die Datenqualität regelmässig zu prüfen. Dazu gehört der Vergleich mit Referenzwerten, die Prüfung auf Datenlücken und die Kontrolle der Kommunikationsfehler-Statistik des Gateways. Mehr dazu in unserem Beitrag «Datenqualität im Monitoring: warum falsche Zähler falsche Entscheide erzeugen» sowie in «Energiemonitoring aufbauen: was brauche ich wirklich?».

Der rote Faden zu unseren Fachbeiträgen

Wer die Grundlagen von KNX kennenlernen möchte, findet diese in der Serie «KNX Grundlagen: die Schulungsreihe», insbesondere in «Datenpunkttypen (DPT): Warum ein Wert auch eine Bedeutung braucht» (Teil 7), das zeigt, warum die korrekte Zuordnung von Datenpunkttypen auf der KNX-Seite genauso wichtig ist wie das Registermapping auf der Modbus-Seite.

Wie KNX-Daten, einschliesslich der über Modbus gewonnenen Messwerte, an eine Gebäudeleittechnik über BACnet weitergegeben werden, beschreibt Teil 4 dieser Serie: «KNX und BACnet: Raumautomation an die Gebäudeleittechnik». Wer Modbus-Daten für Dashboards oder Cloud-Systeme nutzen möchte, findet in Teil 5 «KNX und MQTT: Gebäudedaten für Dashboards und Cloud» die passende Ergänzung.

Die Frage, wer in einem Projekt für welche Schnittstelle verantwortlich ist und wie das in der Planung geregelt wird, behandelt Teil 6 dieser Serie: «Wer mappt was? Schnittstellenliste und Verantwortung». Gerade bei Modbus-Integrationen ist die Verantwortungsabgrenzung zwischen Gerätelieferant, Integrator und Planer ein häufiger Streitpunkt.

Für den Kontext Energiemonitoring empfehlen wir ausserdem «Energiemonitoring: mehr als Zählerablesung, was man wirklich ablesen sollte» und «Vom Messkonzept zum Messstellenplan», die zeigen, wie ein sinnvolles Messkonzept aufgebaut wird, bevor die technische Integration beginnt.

Fazit

Modbus ist ein robustes und weit verbreitetes Protokoll, das sich gut für die Integration von Energiezählern, Wärmepumpen und Lüftungsgeräten in eine KNX-Anlage eignet. Die technische Kopplung über ein Gateway ist in der Regel machbar. Die eigentliche Arbeit liegt im Registermapping: Jeder Wert braucht eine dokumentierte Adresse, einen Datentyp, eine Byte-Reihenfolge, einen Skalierungsfaktor, eine Einheit und einen zugehörigen KNX-Datenpunkttyp. Ohne diese Dokumentation sind die Daten unzuverlässig, und Fehler bleiben oft lange unentdeckt.

Polling-Zyklen und Buslast müssen aufeinander abgestimmt sein. Fehlerbehandlung und Diagnose müssen von Anfang an mitgeplant werden. Und die Konfiguration des Gateways muss vollständig dokumentiert und gesichert sein, damit sie im Betrieb nachvollziehbar bleibt.

Modbus liefert Werte, aber keine Bedeutung. Die Bedeutung entsteht durch sorgfältige Planung, korrekte Konfiguration und konsequente Dokumentation.

Sie haben Fragen dazu?

Sie planen die Integration von Modbus-Geräten in eine KNX-Anlage oder möchten bestehende Integrationen auf Korrektheit prüfen? Wir unterstützen Sie bei der Erstellung von Registermapping-Tabellen, der Gateway-Konfiguration und der Inbetriebnahme. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• Modbus Application Protocol Specification V1.1b3, Modbus Organization, 2012 (Funktionscodes, Objekttypen, Exception-Codes)
• Modbus over Serial Line Specification and Implementation Guide V1.02, Modbus Organization, 2006 (RS-485, Adressierung, Timing)
• EN 50090 / ISO/IEC 14543-3: KNX-Standard (Datenpunkttypen, Kommunikationsobjekte, Topologie); KNX und ETS sind eingetragene Marken der KNX Association, Brüssel (www.knx.org)
• SN EN ISO 52120-1 (SIA 386.111): Energieeffizienz von Gebäuden, Beitrag der Gebäudeautomation
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Modbus-Integrationen, Energiemonitoring und GA-Inbetriebnahmen