MQTT, RS485, Modbus: Welches Protokoll eignet sich für Ihre Feldsensoren?

· 13 Minuten Lesezeit
13 min read
Eziwan-Team
Eziwan-Team
IoT-Infrastruktur

Die Anbindung industrieller Sensoren an die Cloud kommt oft einer Verbindung zweier Welten gleich: der OT mit ihren robusten seriellen Bussen, SPSen und bestehenden Anlagen sowie der IT mit ihren IP-Netzwerken, Brokern, Echtzeit-Datenbanken und Cloud-Dashboards.

Der richtige Ansatz besteht nicht unbedingt darin, die Feldinstallation zu ersetzen. Bei vielen IIoT-Projekten ist es am effizientesten, RS485/Modbus auf der Feldseite beizubehalten und MQTT auf der Cloud-Seite zu nutzen, wobei ein Gateway die Daten korrekt übersetzen, filtern und veröffentlichen kann.

RS485, Modbus, MQTT: Drei Begriffe, die man nicht verwechseln sollte​

Bevor man sich für ein Protokoll entscheidet, muss man drei Ebenen unterscheiden, die oft miteinander verwechselt werden:

BegriffFunktionAnwendungsbeispiel
RS485Serielle physikalische SchichtMehrere Geräte über einen Zweidrahtbus verbinden
Modbus RTUAnwendungsprotokoll für serielle VerbindungenAuslesen von Registern eines Zählers oder Sensors
MQTTPublish/Subscribe-Protokoll über IPVeröffentlichen von Messwerten an einen Cloud-Broker

Zusammenfassung RS485 überträgt das Signal, Modbus RTU strukturiert den Datenaustausch mit den Feldgeräten, MQTT übermittelt die Daten an IT- oder Cloud-Systeme.

RS485 / Modbus: Die OT-Basis für Industrieanlagen​

RS485: eine robuste serielle Verbindung für den Feldeinsatz​

RS485 ist eine differentielle serielle Schnittstelle, die in der Industrie seit langem eingesetzt wird. Sie ist nach wie vor weit verbreitet, da sie robust und kostengünstig ist und sich für Umgebungen eignet, in denen die Geräte in einem Schaltschrank, einer Werkstatt oder an einem entfernten Standort verteilt sind.

Es wird häufig verwendet, um Folgendes anzuschließen:

  • industrielle Steuerungen;
  • Energiezähler;
  • Wechselrichter;
  • Frequenzumrichter;
  • Sensoren für Temperatur, Druck, Durchfluss oder Feuchtigkeit;
  • Analysegeräte für Luft, Wasser oder Energie.

Die theoretische maximale Übertragungsreichweite eines RS485-Busses kann unter guten Bedingungen bis zu etwa 1.200 Meter betragen, hängt jedoch stark von der Übertragungsrate, der Kabelqualität, der Topologie, dem Abschlusswiderstand und dem Ausmaß der elektromagnetischen Störungen ab.

Modbus RTU: Register lesen und schreiben​

Bei RS485 ist Modbus RTU das gängigste Protokoll. Es definiert eine standardisierte Vorgehensweise, um Slave-Geräte von einem Master aus abzufragen: Slave-Adresse, Lese- oder Schreibfunktion, Registeradresse, Wert, Fehlerprüfung.

Vorteile und Einschränkungen von Modbus RTU​

PunktMesswert
RobustheitGeeignet für industrielle Umgebungen und kontrollierte große Entfernungen
InteroperabilitätWeit verbreitet bei Sensoren, Zählern, Frequenzumrichtern und Steuerungen
EinfachheitÜbersichtliches Auslesen von Registern, mit den richtigen Tools leicht zu diagnostizieren
HauptnachteilNicht nativ IP-fähig: Zur Integration in die Cloud ist ein Gateway erforderlich
Zu beachtenEine falsche Terminierung, eine Sternverkabelung oder inkonsistente serielle Parameter können die Kommunikation erheblich beeinträchtigen

MQTT: Das geeignete Protokoll für die Veröffentlichung in der Cloud​

MQTT ist ein Publish/Subscribe-Protokoll, das für die Übertragung kleiner Nachrichten über TCP/IP entwickelt wurde. Es wird häufig in IoT- und IIoT-Architekturen eingesetzt, da es Datenproduzenten und -konsumenten voneinander trennt.

Das Prinzip ist einfach:

  • Ein MQTT-Client veröffentlicht Nachrichten;
  • Die Nachrichten werden an Topics gesendet;
  • Ein MQTT-Broker empfängt, verteilt und sichert den Datenaustausch;
  • Die abonnierten Anwendungen nutzen die Daten: Überwachung, Zeitreihendatenbank, Alarmierung, Data Lake, Fachanwendungen.

Warum MQTT eine gute Ergänzung zu Modbus ist​

Modbus eignet sich sehr gut zum Abfragen von Feldgeräten. MQTT ist besser geeignet, um Daten an entfernte Anwendungen zu senden.

AnforderungAm besten geeignetes Protokoll
Lesen der Protokolle eines RS485-SensorsModbus RTU
Abfragen einer SPS über EthernetModbus TCP
Messwerte an die Cloud sendenMQTT
Entkopplung von Datenerfassung vor Ort und IT-AuswertungMQTT
Vorhandene Industrieanlagen weiter nutzenRS485 / Modbus

MQTT ist also kein direkter Ersatz für RS485. Es fungiert vielmehr als Anwendungstransportschicht zur IT, nachdem die Felddaten erfasst, normiert und in einen Kontext eingebettet wurden.

Die Rolle des Eziwan-Gateways: Als Brücke zwischen OT und Cloud fungieren​

Das Eziwan-Gateway ermöglicht den Anschluss von Feldgeräten und die Weiterleitung ihrer Daten an entfernte Dienste. In einer typischen Architektur erfüllt es drei Funktionen:

  1. OT-Datenerfassung: Abfrage von Modbus-RTU-Geräten über RS485 oder Modbus-TCP im lokalen Netzwerk.
  2. Normalisierung: Umwandlung der Register in auswertbare Werte mit Tag, Einheit, Zeitstempel und Qualitätsangabe.
  3. IT-Veröffentlichung: Übertragung der Daten an einen MQTT-Broker, eine Cloud-Plattform oder ein Überwachungssystem.

Modbus-zu-MQTT-Konfiguration: Die wichtigsten Einstellungen​

1. Modbus-Polling definieren​

Der erste Schritt besteht darin, die abzufragenden Geräte zu beschreiben:

  • Modbus-Adresse jedes Slaves;
  • Registertyp: Holding-Register, Eingangsregister, Coil, diskreter Eingang;
  • Registeradresse;
  • Datenformat: 16-Bit-Ganzzahl, 32-Bit-Ganzzahl, 32-Bit-Gleitkomma, Boolescher Wert;
  • Wort- und Byte-Reihenfolge, falls erforderlich;
  • physikalische Einheit;
  • Leseintervall;
  • auf der MQTT-Seite veröffentlichter Tag-Name.

Zu beachten Zwei Geräte können denselben Messwert in unterschiedlichen Formaten anzeigen. Daher muss stets die Dokumentation des Herstellers überprüft werden: genaue Adresse, Indexierungsbasis, Registertyp, Skalierungsfaktor und Endianness.

2. Beispiel für eine JSON-Konfiguration​

{
  "modbus": {
    "baud_rate": 9600,
    "parity": "none",
    "stop_bits": 1,
    "slaves": [
      {
        "slave_id": 1,
        "registers": [
          {
            "address": "0x0001",
            "type": "holding",
            "format": "float32",
            "tag": "temperature",
            "unit": "°C"
          },
          {
            "address": "0x0003",
            "type": "holding",
            "format": "float32",
            "tag": "humidity",
            "unit": "%"
          }
        ]
      },
      {
        "slave_id": 2,
        "registers": [
          {
            "address": "0x0010",
            "type": "input",
            "format": "int16",
            "tag": "pressure",
            "unit": "mbar"
          }
        ]
      }
    ]
  },
  "mqtt": {
    "broker": "mqtt.example.com",
    "port": 8883,
    "tls": true,
    "base_topic": "site/{site_id}/gateway/{device_id}/sensors"
  }
}

3. Strukturierte Daten veröffentlichen​

Sobald der Wert ausgelesen wurde, kann das Gateway eine strukturierte MQTT-Nachricht senden:

Thema: site/paris/gateway/eziwan-01/sensors/temperature
Payload: {"value":23.4,"unit":"°C","timestamp":"2025-02-20T14:32:01Z","quality":"good"}

Ein klarer Payload erleichtert anschließend die Integration mit:

  • eine Zeitreihen-Datenbank;
  • ein Grafana-Dashboard;
  • ein Node-RED-Workflow;
  • ein Cloud-basiertes SCADA-System;
  • eine Fachanwendung;
  • eine zentralisierte Überwachungsplattform.

Modbus RTU vs. Modbus TCP: Was ist der Unterschied?​

Modbus kommt in Industrieprojekten hauptsächlich in zwei Formen vor: Modbus RTU und Modbus TCP.

KriteriumModbus RTUModbus TCP
UnterstützungRS485 / RS232Ethernet oder IP-Netzwerk
AdressierungsmodusSlave-AdresseIP-Adresse + Port
DatenrahmenKompakt, mit CRCIn TCP gekapselt
Typische AnwendungSensoren, Zähler, FeldgeräteSPS, Frequenzumrichter, Ethernet-Geräte
DiagnoseSerieller Analysator, Modbus-RTU-TesterPing, Netzwerkscan, Modbus-TCP-Client
Zu beachtende PunkteVerkabelung, Abschlusswiderstand, Geschwindigkeit, ParitätRouting, Firewall, VLAN, Netzwerklatenz

In einer Eziwan-Architektur können beide Ansätze nebeneinander bestehen: der RS485-Bus für die vorhandenen Feldgeräte und das lokale IP-Netzwerk für die Ethernet-Geräte.

Beispiel für eine Anlagenkonfiguration: Werk mit gemischter Ausrüstung​

An einem Industriestandort können Anlagen verschiedener Generationen nebeneinander zum Einsatz kommen:

  • ein Energiezähler mit Modbus-RTU-Schnittstelle;
  • eine SPS mit serieller Schnittstelle;
  • ein über Modbus-TCP zugänglicher Frequenzumrichter;
  • eine Cloud-Überwachungslösung, die die Daten über MQTT abruft.

Durch diese Architektur muss keine bereits funktionierende Hardware ausgetauscht werden. Das Gateway übernimmt die Funktionen der Datenerfassung, -umsetzung und -veröffentlichung.

So wählen Sie das richtige Protokoll für Ihren Kontext aus​

Situation vor OrtEmpfohlene WahlWarum
Vorhandene Geräte mit RS485-AnschlussModbus RTUKompatibel mit zahlreichen Sensoren, Zählern und Steuerungen
Industrielle Geräte mit Ethernet-AnschlussModbus TCPEinfachere Integration in ein lokales IP-Netzwerk
Neue vernetzte SensorenNatives MQTT, sofern verfügbarDirekte Veröffentlichung an einen Broker oder eine Cloud-Plattform
Bestehendes SCADA-System, das gewartet werden mussSicherer Fernzugriff oder VPNKontinuität mit der bereits vorhandenen Architektur
Daten an Grafana, InfluxDB oder Node-REDMQTTSaubere Entkopplung zwischen Datenerfassung und -auswertung
Abgelegener oder mobiler StandortGateway mit MobilfunkverbindungDatenerfassung vor Ort ohne Abhängigkeit von einem lokalen kabelgebundenen Netzwerk

Sicherheit: Wesentliche Punkte für ein Feldgateway​

Die Anbindung der OT an die Cloud erfordert einen umsichtigen Ansatz. Das Ziel besteht nicht nur darin, Daten zu übertragen, sondern dies mit einem Maß an Kontrolle zu tun, das dem industriellen Kontext angemessen ist.

Empfohlene bewährte Praktiken​

  • IT- und OT-Netzwerke segmentieren, um zu weitreichende Zugriffe aus der Cloud auf die Feldgeräte zu vermeiden.
  • Ausgehende Datenflüsse beschränken auf die notwendigen Dienste: MQTT-Broker, Überwachung, Updates oder Administration.
  • Das Prinzip der geringsten Berechtigung anwenden: Ein Gerät oder ein Benutzer darf nur auf die tatsächlich benötigten Ressourcen zugreifen.
  • Verbindungen und Ereignisse protokollieren, um Audits und Diagnosen zu erleichtern.
  • Die Widerrufung von Zugriffsrechten vorsehen, falls der Dienstleister wechselt, Geräte verloren gehen oder ein Vorfall eintritt.
  • Verschlüsseln Sie die MQTT-Kommunikation, sobald Daten das lokale Netzwerk verlassen.
  • Überwachen Sie den Verbindungsstatus: Latenz, Wiederverbindungen, Signalverluste, lokale Warteschlangen.

Nicht zu vernachlässigen Eine 4G- oder LTE-Verbindung kann je nach Netzabdeckung, Antenne, Funkumgebung und Netzauslastung zeitweise unterbrochen sein. Daher sollte eine Strategie für die Wiederherstellung der Verbindung, einen lokalen Puffer und die Zeitstempelung der Daten vorgesehen werden, wenn die Kontinuität der Messung wichtig ist.

Häufige Fehler bei einem Modbus-zu-MQTT-Projekt​

Verwechslung von Registeradresse und Dokumentenadresse​

Manche Hersteller dokumentieren die Register in Basis 1, andere in Basis 0. Eine erwartete Messung an 40001 kann daher je nach verwendetem Tool einer unterschiedlichen tatsächlichen Adresse entsprechen.

Die Wortfolge ignorieren​

32-Bit-Werte, insbesondere Gleitkommazahlen, können mit unterschiedlichen Wortreihenfolgen kodiert werden. Eine falsche Konfiguration kann zu inkonsistenten Werten führen, ohne dass dabei ein Fehler in der Modbus-Kommunikation auftritt.

Zu häufiges Anfahren von Pollern​

Ein gemeinsam genutzter RS485-Bus darf nicht wie eine HTTP-Schnittstelle abgefragt werden. Zu aggressives Polling kann den Bus überlasten, die Anzahl der CRC-Fehler erhöhen oder die langsameren Geräte überlagern.

Zu vage MQTT-Themen veröffentlichen​

Ein Thema wie „data/value1“ wird schnell unübersichtlich. Es ist besser, die Themen nach Standort, Gateway, Gerät und Tag zu strukturieren.

site/{site_id}/gateway/{gateway_id}/equipment/{asset_id}/metric/{tag}

Die Datenqualität außer Acht lassen​

Ein Wert ohne Qualitätsindikator kann falsch interpretiert werden. Das Hinzufügen eines Feldes quality, eines Zeitstempels und gegebenenfalls eines Fehlercodes erleichtert die Auswertung auf der Überwachungsseite.

Empfohlene Standardarchitektur​

EbeneRolleBeispiel
FeldMessung und AutomatisierungSensoren, Zähler, SPS, Frequenzumrichter
Edge-ErfassungModbus-Auslesung, Filterung, ZeitstempelungEziwan-Gateway
ÜbertragungSichere MQTT-VeröffentlichungMQTT-Broker
VerarbeitungProtokollierung, Warnmeldungen, TransformationInfluxDB, Node-RED, Cloud-Plattform
VisualisierungÜberwachung und EntscheidungsfindungGrafana, Cloud-SCADA, Fachanwendung

Diese Trennung macht die Architektur übersichtlicher: Die Infrastruktur bleibt stabil, das Gateway übersetzt die Daten, die Cloud verarbeitet sie.

FAQ – MQTT, RS485 und Modbus​

Können Modbus RTU und MQTT auf demselben Gateway gleichzeitig betrieben werden?​

Ja. Das ist sogar eines der klassischen Szenarien für ein IIoT-Gateway: Die Felddaten werden über RS485 im Modbus-RTU-Format erfasst und anschließend per MQTT an einen Broker oder eine Cloud-Plattform übertragen. Die beiden Protokolle haben unterschiedliche Aufgaben: Modbus dient zur Abfrage der Geräte, MQTT dient zur Übertragung der Daten an die Anwendungen.

Was ist der Unterschied zwischen RS485 und Modbus RTU?​

RS485 ist die physikalische Schicht: Verkabelung, elektrische Signale, Bus-Topologie. Modbus RTU ist das Anwendungsprotokoll: Rahmenstruktur, Adressierung der Slaves, Lese- und Schreibfunktionen, Fehlerprüfung. RS485 kann zwar auch mit anderen Protokollen verwendet werden, doch die Kombination aus RS485 und Modbus RTU ist im industriellen Umfeld nach wie vor sehr verbreitet.

Wie viele Geräte können an einen RS485-Bus angeschlossen werden?​

Die Antwort hängt von den Transceivern, der elektrischen Last des Busses, der Kabellänge, der Übertragungsrate und der Qualität der Installation ab. Die häufig genannte Grenze für ein klassisches RS485-Segment liegt bei 32 Einzel lasten, doch moderne Geräte mit geringer Last und Repeater können umfangreichere Architekturen ermöglichen. In der Praxis muss die Topologie anhand der Gerätespezifikationen und der örtlichen Gegebenheiten überprüft werden.

Ist MQTT geeignet, wenn die 4G-Verbindung unregelmäßig ist?​

MQTT lässt sich bei richtiger Architektur an zeitweise unterbrochene Verbindungen anpassen: angemessene Dienstgüte, ordnungsgemäße Wiederverbindung, lokale Zeitstempelung, Warteschlange auf der Gateway-Seite und Überwachung des Netzwerkstatus. Man darf jedoch die Robustheit des Protokolls nicht mit der Funkverfügbarkeit verwechseln: Die Qualität der Mobilfunkabdeckung bleibt ein entscheidender Faktor.

Sollte man sich für MQTT oder OPC UA entscheiden?​

Die beiden Protokolle erfüllen nicht genau denselben Zweck. MQTT ist schlank und sehr effizient, wenn es darum geht, Nachrichten an einen Broker zu senden. OPC UA bietet umfangreichere Möglichkeiten zur Modellierung von Geräten, zur Bereitstellung industrieller Semantik und zur Integration bestimmter Automatisierungssysteme. In vielen Projekten wird MQTT für die Veröffentlichung in der Cloud gewählt, während OPC UA im Bereich der industriellen Überwachung oder der Maschinenintegration weiterhin relevant bleibt.

Wie lässt sich eine industrielle MQTT-Veröffentlichung absichern?​

Zumindest müssen die Verbindungen verschlüsselt werden, wenn Daten das lokale Netzwerk verlassen, die Clients müssen authentifiziert werden, die Zugriffsrechte müssen je nach Thema eingeschränkt werden, die Verbindungen müssen protokolliert werden und es muss die Möglichkeit geben, Zugriffsrechte zu widerrufen. Die Sicherheit muss auch das Gateway selbst umfassen: geschützte Verwaltung, kontrollierte Updates, Netzwerksegmentierung und Ereignisüberwachung.

Mit Eziwan noch einen Schritt weiter gehen​

Verfügen Sie über RS485-, Modbus-RTU-, Modbus-TCP- oder MQTT-Geräte, die Sie in eine Cloud-Architektur integrieren möchten? Der richtige Ansatz besteht darin, die bestehenden Protokolle zu erfassen, die Einschränkungen vor Ort zu ermitteln und anschließend ein geeignetes Gateway zwischen OT und IT zu definieren.

Weitere Ressourcen​

  • Modbus RTU zu MQTT – Die Brücke zwischen RS485-Modbus-RTU-Geräten und MQTT-Broker verstehen
  • RS485 Modbus 4G – einen RS485-Modbus-Bus über ein Mobilfunknetz verbinden
  • OPC UA zu MQTT – OPC-UA-Daten an einen MQTT-Broker veröffentlichen
  • Industrieprotokolle – Vergleich von Modbus, MQTT, OPC UA und anderen Industrieprotokollen
  • IIoT-Gateway – Auswahl eines für Ihre Feldinstallation geeigneten Gateways