Modbus RTU zu MQTT: Registerzuordnung, Byte-Reihenfolge und Skalierung

VonLIU, ZHUOHUI

Eine zuverlässige Integration von Modbus RTU in MQTT braucht eine eindeutige Vereinbarung zwischen der Registerbelegung eines Geräts und der Anwendung, die dessen Messwerte verarbeitet. Eine erfolgreiche serielle Antwort belegt, dass Bytes angekommen sind. Bei der Inbetriebnahme muss außerdem geklärt werden, was diese Bytes bedeuten und ob der daraus ermittelte Wert noch aktuell ist.

Dieser Leitfaden behandelt ausschließlich lesende Telemetrie: Adressumrechnung, Funktionscodes, vorzeichenbehaftete Werte, Skalierung, die Reihenfolge mehrerer Register und die Aktualität von MQTT-Daten. Alle folgenden Registerzuordnungen, Werte und Nutzdaten dienen der Veranschaulichung; sie sind weder Obeita-Produktspezifikationen noch Messwerte aus dem Feldeinsatz.

Beginnen Sie mit einem verifizierten RTU-Lesevorgang

Erfassen Sie Gerätemodell, Firmware-Version, Version der Registerbelegung, serielle Einstellungen, Stationsadresse und einen bekannten Referenzwert. Prüfen Sie RS-485-Verdrahtung, Terminierung und Vorspannung anhand der Installationsdokumentation. Stellen Sie sicher, dass nur der vorgesehene Master den Bus steuert. Beheben Sie Zeitüberschreitungen und CRC-Fehler, bevor Sie versuchen, Werte durch Skalierung zu korrigieren.

Der Modbus-Leitfaden für serielle Leitungen definiert RTU-Rahmenaufbau, Zeitvorgaben und Fehlerprüfung. Ein Abfrageprozess im Produktivbetrieb muss diese Anforderungen sowie die Antwortgrenzen des Geräts einhalten. Beginnen Sie mit einem dokumentierten Messpunkt; erweitern Sie den Abfrageumfang erst, wenn dessen Rohantwort und dekodierter Wert übereinstimmen.

Klären Sie Registeradresse und Funktionscode gemeinsam

Die Modbus-Anwendungsprotokollspezifikation verwendet nullbasierte PDU-Adressen. Funktionscode 03 liest Halteregister; Funktionscode 04 liest Eingangsregister. Dabei handelt es sich um getrennte logische Tabellen. Derselbe numerische Offset bedeutet nicht, dass beide Funktionen denselben Messwert zurückgeben.

In der herkömmlichen Dokumentationsnotation bezeichnet 40001 das erste Halteregister und 30001 das erste Eingangsregister. Die führende Ziffer kennzeichnet die Tabelle; sie gehört nicht zur übertragenen PDU-Adresse. Siehe dazu die Erläuterung zur Adressierung der Modbus Organization.

Beispielhafter Handbucheintrag Funktion PDU-Startadresse
Halteregister 40011 03 10 dezimal, 0x000A
Eingangsregister 30011 04 10 dezimal, 0x000A

Nach dieser Konvention gilt 40011 − 40001 = 10. Handbücher können jedoch bereits nullbasierte Offsets, einsbasierte Registernummern oder hexadezimale Adressen angeben. Gateway-Oberflächen können eigene Umrechnungen vornehmen. Dokumentieren Sie sowohl die Schreibweise im Handbuch als auch den tatsächlichen PDU-Offset; ziehen Sie niemals automatisch eins ab. Ersetzen Sie FC03 nicht durch FC04, nur um eine plausible Zahl zu erhalten, sofern die Gerätedokumentation diese Zuordnung nicht ausdrücklich vorsieht.

Für das erste Beispiel lautet die Anfrage-PDU 03 00 0A 00 01: Funktion 03, Startadresse 10, Anzahl eins. Dies ist nur eine PDU, kein vollständiger RTU-Rahmen; Stationsadresse und CRC sind nicht enthalten.

Dekodieren Sie vorzeichenbehaftete Werte vor der Skalierung

Erstellen Sie eine Messpunktdefinition mit Stationsadresse, Funktion, PDU-Offset, Registeranzahl, Datentyp, Wortreihenfolge, Skalierungsfaktor, Offset, Einheit, Regeln für ungültige Werte und Aktualitätsgrenze. Bewahren Sie die rohen Registerwörter in den Inbetriebnahmeprotokollen auf, damit andere Ingenieure die Umrechnung nachvollziehen können.

Angenommen, der Beispielmesspunkt ist eine vorzeichenbehaftete 16-Bit-Temperatur mit einem Skalierungsfaktor von 0.1 °C und einem Offset von null. Ein Antwortwort 0xFF9C ergibt bei vorzeichenloser Interpretation 65436. Vorzeichenbehaftet im Zweierkomplement interpretiert ergibt es 65436 − 65536 = −100. Wenden Sie die Skalierung nach dem Dekodieren an:

engineering_value = decoded_value × scale + offset
                  = -100 × 0.1 + 0
                  = -10.0 °C

Ein vorzeichenloser Dekoder würde stattdessen 6543.6 °C veröffentlichen. Eine Änderung des Skalierungsfaktors, um dieses Ergebnis zu kaschieren, würde den zugrunde liegenden Datentypfehler nicht beheben. Testen Sie positive und negative Werte sowie Grenzwerte. Prüfen Sie vor der Skalierung die vom Hersteller festgelegten Ungültigkeitscodes; ein Kennwert für ungültige Daten darf nicht zu einem glaubwürdig wirkenden Messwert werden.

Illustrative Modbus mapping from holding register 40011 to FC03 offset 10, signed word FF9C and an MQTT temperature value of minus 10.0 degrees Celsius.
Abbildung 1. Halten Sie Adresskonvention, vorzeichenbehaftete Dekodierung und Skalierung in technische Einheiten während der gesamten Zuordnung nachvollziehbar.

Unterscheiden Sie die Byte-Reihenfolge in 16-Bit-Registern von der Wortreihenfolge über mehrere Register

Innerhalb eines standardmäßigen 16-Bit-Modbus-Registers wird das höherwertige Byte zuerst übertragen. Daher erscheint 0x4148 als 41 48. Die RTU-CRC ist ein separates Feld, dessen niederwertiges Byte zuerst gesendet wird; diese Reihenfolge ist keine Regel für die Registerdekodierung.

Ein 32-Bit-Anwendungswert belegt zwei Register, deren Wortanordnung jedoch gerätespezifisch ist. Das Beispiel von Schneider Electric zu Gleitkommawerten mit vertauschten Wörtern zeigt, weshalb höher- und niederwertige Wörter manchmal umgeordnet werden müssen.

Für den exakt darstellbaren Beispielwert 12.5 im Format IEEE 754 float32 lautet das Bitmuster 0x41480000. Eine Registerbelegung mit höherwertigem Wort zuerst liefert 0x4148, 0x0000; bei niederwertigem Wort zuerst lautet die Ausgabe 0x0000, 0x4148. Ordnen Sie die Wörter gemäß dem Handbuch und interpretieren Sie anschließend die zusammengesetzten Bits als float32. Die numerische Umwandlung der zusammengesetzten Ganzzahl in eine Gleitkommazahl ist eine andere Operation.

Two illustrative register layouts for IEEE 754 float32 12.5, showing high-word-first and low-word-first mappings while each register retains high-byte-first transmission.
Abbildung 2. Beide Anordnungen stellen 12.5 dar, wenn der Dekoder die dokumentierte Wortreihenfolge verwendet.

Eine Gateway-Option namens „little endian“ kann mehrdeutig sein. Dokumentieren Sie die genaue Wort- und Bytevertauschung, die sie anwendet. Manche Herstellerbelegungen definieren außerdem Bytevertauschungen auf Anwendungsebene; prüfen Sie diese ausdrücklich. Lesen Sie zusammengehörige Wörter in einer Anfrage, sofern dies unterstützt wird, und prüfen Sie, ob das Gerät während Aktualisierungen eine konsistente Momentaufnahme garantiert.

Veröffentlichen Sie Aktualität und Qualität zusammen mit dem MQTT-Wert

Versehen Sie jeden Messwert mit einem stabilen Messpunktnamen, einer Einheit, einem Qualitätsstatus und einem Zeitstempel mit klar definierter Bedeutung. Liefert das Gerät keinen Erfassungszeitstempel, kennzeichnen Sie den Zeitpunkt der erfolgreichen Gateway-Abfrage entsprechend. Ein späterer Veröffentlichungszeitpunkt darf das Alter einer alten Messprobe nicht verschleiern.

Diese beispielhaften Anwendungsnutzdaten verwenden den Abschlusszeitpunkt des Gateway-Lesevorgangs und eine auf den jeweiligen Systemstart begrenzte Sequenz:

{
  "schema_version": 1,
  "device_id": "example-device-07",
  "point": "temperature",
  "value": -10.0,
  "unit": "degC",
  "quality": "good",
  "read_completed_at": "2026-10-03T12:00:00Z",
  "time_source": "gateway_read",
  "boot_id": "example-boot-01",
  "sequence": 1042
}

Legen Sie fest, was nach einer ausgebliebenen Abfrage geschieht: beispielsweise den Zeitstempel des letzten gültigen Werts beibehalten und dabei einen veralteten Qualitätsstatus melden oder einen ausdrücklich als nicht verfügbar gekennzeichneten Wert veröffentlichen. Definieren Sie eine zum Prozess passende Veraltungsgrenze, Anforderungen an die Zeitsynchronisation und Warteschlangenbegrenzungen. Behalten Sie bei der erneuten Übertragung zwischengespeicherter Messproben deren ursprüngliche Lesezeitpunkte bei.

Retained-Nachrichten in MQTT können einem neuen Abonnenten helfen, den zuletzt veröffentlichten Zustand zu erhalten; die Speicherung als Retained-Nachricht belegt jedoch keine Aktualität. Die Message-Expiry-Funktion von MQTT 5 kann die Lebensdauer von Nachrichten in Warteschlangen begrenzen; verarbeitende Anwendungen benötigen weiterhin Altersprüfungen auf Anwendungsebene. Siehe MQTT 5.0, Abschnitte 3.3 und 4.3.

Wählen Sie QoS, ohne eine durchgängig genau einmalige Verarbeitung zu versprechen

MQTT QoS 0 bietet eine höchstens einmalige Zustellung, QoS 1 eine mindestens einmalige Zustellung und QoS 2 eine genau einmalige Zustellung innerhalb seines Protokollaustauschs. Die Spezifikation begrenzt die Zustellung auf einen einzelnen Sender und Empfänger; die Zustellung vom Broker an einen Abonnenten ist ein separater Austausch. QoS 2 allein kann nicht garantieren, dass im Gesamtsystem genau eine Sensorerfassung oder Datenbankaktualisierung erfolgt.

Gestalten Sie Schreibvorgänge der verarbeitenden Anwendung idempotent, wenn Duplikate relevant sind. Ein Anwendungsschlüssel aus Gerät, Boot-ID und Sequenz kann die Deduplizierung unterstützen, sofern seine Eindeutigkeits- und Persistenzregeln festgelegt sind. Testen Sie Wiederverbindungen und nachgelagerte Wiederholungsversuche mit der tatsächlichen Broker-, Client- und Speicherkonfiguration.

Checkliste für die Inbetriebnahme

  • Vergleichen Sie die Anfrage-PDU mit der freigegebenen Adressbelegung, einschließlich der Unterscheidung zwischen FC03 und FC04.
  • Prüfen Sie die Rohwörter anhand einer bekannten Geräteanzeige, bevor Sie Cloud-Berechnungen aktivieren.
  • Testen Sie negative Werte, Ungültigkeitscodes, Änderungen der Wortreihenfolge und teilweise fehlgeschlagene Abfragen.
  • Trennen Sie serielles Gerät und Broker jeweils separat; prüfen Sie, dass veraltete Daten weiterhin erkennbar bleiben.
  • Starten Sie Gateway und verarbeitende Anwendung neu; prüfen Sie das Alter erneut übertragener Daten, den Umgang mit Duplikaten und das Sequenzverhalten.
  • Dokumentieren Sie getestete Firmware, Version der Registerbelegung, Nutzdatenschema und Abnahmeergebnisse.

Bereiten Sie eine Anforderungsprüfung für Modbus RTU zu MQTT vor

Bereiten Sie für ein Integrationsgespräch mit Obeita die relevanten Handbuchseiten des Geräts, einen beispielhaften Anfrage-/Antwortrahmen, erwartete Werte in technischen Einheiten, Messpunktanzahl, Abfrageintervall, Broker-Anforderungen und das Verhalten bei Ausfällen vor. Schwärzen Sie Passwörter, Schlüssel, Kundenkennungen, private Netzwerkdetails und proprietäre Daten, zu deren Weitergabe Sie nicht berechtigt sind. Mit diesen Angaben lässt sich die Zuordnung definieren und testen, bevor eine Gateway-Konfiguration verbindlich festgelegt wird.

Informieren Sie sich über Obeitas Service zur Anbindung von Bestandsgeräten und das realisierte Projekt zur STM32-Datenerfassung und MQTT-Integration (auf Englisch), um verwandte Engineering-Leistungen kennenzulernen. Um Ihre eigenen Anforderungen an die Registerzuordnung zu besprechen, kontaktieren Sie Obeita.

Primärquellen

  1. Modbus-Anwendungsprotokollspezifikation V1.1b3. Relevante Abschnitte: 4.2, 4.3, 4.4, 6.3, 6.4.
  2. Einführung in Modbus – Modbus Organization. Relevante Abschnitte: Modbus-Datenadressierung und Funktion 03.
  3. Modbus über serielle Leitungen: Spezifikation und Implementierungsleitfaden V1.02. Relevante Abschnitte: 2.2, 2.5.1, 3.
  4. Schneider Electric – Gleitkommawerte mit vertauschten Wörtern in Modbus lesen. Relevanter Abschnitt: Lösung.
  5. MQTT Version 5.0 – OASIS-Standard. Relevante Abschnitte: 3.3.1.3, 3.3.2.3.3, 4.3.

Ähnliche Beiträge