Die meisten RFID-Projekte beginnen damit, dass ein Leser in eine Datenbank schreibt, und enden damit, dass vierzig Leser schneller in dieselbe Datenbank schreiben. Interessant ist die Strecke dazwischen, und dort geht es fast nie um die Wahl des Brokers.

Warum MQTT zu RFID-Ereignisströmen passt

Ein RFID-Bestand erzeugt einen spitzen, unidirektionalen Strom kleiner Nachrichten mit hohem Volumen, und diese Form hat Folgen.

Ereignisse sind winzig und häufig; ein REST-Aufruf pro Etikett verschwendet drei Größenordnungen.
Leser hängen an unzuverlässigen Industrienetzen, also muss der Transport Wiederverbindungen ohne Zustandsverlust überstehen.
Der Publisher weiß nichts vom Consumer und sollte das bleiben; Leser tragen keine ERP-Logik.
Topics ergeben eine natürliche Partitionierung nach Standort, Zone und Gerät, und genau so skaliert man Consumer.
MQTT hält eine persistente Sitzung, sodass ein wieder verbundener Subscriber verpasste Nachrichten nachholen kann.

Der letzte Punkt ist der, auf den sich fast alle verlassen und den fast alle falsch konfigurieren.

Der Vertrag ist die Integration, nicht der Broker

Broker sind Massenware. Das Ereignisschema ist das Kapital und verdient dieselbe Disziplin wie eine Datenbanktabelle.

Versionieren Sie die Nutzlast vom ersten Tag an im Nachrichtenkörper, nicht im Topic-Namen.
Fixieren Sie die Identitätsfelder: Geräte-ID, Standortcode, Antenne, Lesezeit in UTC, EPC, RSSI und eine monotone Sequenz.
Definieren Sie, was ein Lesevorgang bedeutet: ein einzelnes Antennenereignis oder ein entdupliziertes Beobachtungsfenster.
Entscheiden Sie, wo Geschäftsbedeutung entsteht: Der Leser meldet Fakten, der Subscriber interpretiert sie.
Schreiben Sie das Schema auf und generieren Sie Publisher- und Subscriber-Typen daraus.

Wenn zwei Standorte für denselben Sachverhalt unterschiedliche Feldnamen erzeugen können, haben Sie keine Integration, sondern zwei, die zufällig einen Broker teilen.

Der Subscriber gehört nicht in die Request-Worker

Der häufigste Produktionsfehler ist architektonisch, nicht technisch: Der Subscriber steckt im selben Prozess, der Webanfragen bedient.

Odoo-Web-Worker leben kurz und werden recycelt; eine langlebige Subscription gehört dort nicht hin.
Betreiben Sie einen separaten Dienst mit eigener Prozessaufsicht, eigenem Speicherbudget und eigener Neustartpolitik.
Geben Sie ihm eine Datenbankverbindung getrennt vom Benutzerpool, mit eigenen Statement-Timeouts.
Lassen Sie niemals zu, dass ein Handler die Transaktion offen hält, während er auf die nächste Nachricht wartet.
Deployen Sie ihn mit derselben Pipeline wie die Anwendung, aber bei Bedarf mit eigenem Freigaberhythmus.

Ein Subscriber, der stirbt, wenn ein Benutzer eine große Datei hochlädt, ist kein Subscriber, sondern eine Geisel.

QoS, Duplikate und die Falle der zurückgehaltenen Nachricht

Service-Level werden oft aus Gewohnheit gewählt, und das erzeugt gleichzeitig verlorene Ereignisse und doppelte Bestandsbuchungen.

QoS 0 verliert Nachrichten bei Wiederverbindung; für Telemetrie akzeptabel, für Bestandsbewegungen nicht.
QoS 1 garantiert Zustellung und erlaubt ausdrücklich Duplikate; Ihr Handler muss daher idempotent sein.
QoS 2 beseitigt Duplikate auf Protokollebene, kostet aber Roundtrips und lohnt hier selten.
Zurückgehaltene Nachrichten sind für den letzten bekannten Zustand, nicht für Historie; halten Sie niemals eine Bestandsbewegung zurück.
Saubere Sitzungen verwerfen die Queue bei Wiederverbindung; brauchen Sie Wiederherstellung, nutzen Sie eine persistente Sitzung mit unveränderlicher Client-ID.

Wählen Sie QoS 1 mit idempotentem Handler und stecken Sie den Aufwand in den Handler.

Idempotenz, Reihenfolge und Uhrdisziplin

Zwei Ereignisse zur selben Palette können out-of-order ankommen, doppelt, oder beides.

Bilden Sie den Idempotenzschlüssel aus Gerät, EPC, Antenne und Lesezeit und sichern Sie ihn mit einem Unique Index.
Vertrauen Sie Geräteuhren nicht; speichern Sie Empfangszeit und gemeldete Zeit.
Lösen Sie ungeordnete Ankunft durch Vergleich der Ereigniszeitstempel, nicht der Ankunftsreihenfolge.
Schreiben Sie bei Korrekturen ein append-only Ereignisprotokoll und leiten Sie den Saldo ab, statt eine Menge in place zu ändern.
Machen Sie Wiederholungen by design sicher, damit ein Operator den Lauf von gestern Nacht furchtlos erneut starten kann.

Bestand, der nur manuell korrigiert werden kann, ist Bestand, der jede Woche manuell korrigiert wird.

Rückstau, Batching und Dead-Letter-Queue

Ein Subscriber, der an einem ruhigen Dienstag mitkommt, bleibt bei einer Vollinventur zurück.

Bündeln Sie Schreibvorgänge in kleinen Gruppen mit begrenztem Flush-Intervall, damit Durchsatz steigt, ohne Latenz zu verlängern.
Erzeugen Sie Rückstau bewusst: Bremsen Sie die Consumer-Gruppe, verwerfen Sie niemals still.
Leiten Sie Giftnachrichten mit Originalnutzlast und Fehlergrund in ein Dead-Letter-Topic.
Alarmieren Sie bei Wachstum der Dead-Letter-Queue, denn dort versteckt sich Datenverlust.
Begrenzen Sie Wiederholungen mit exponentiellem Backoff und parken Sie die Nachricht danach zur menschlichen Prüfung.

Die Dead-Letter-Queue ist kein Eingeständnis von Versagen; sie ist der Unterschied zwischen einem schlechten Nachmittag und einem korrupten Hauptbuch.

Sicherheit und Mandantentrennung über Standorte

Ein offener Broker im Fabriknetz ist ein Werkzeug zur Bestandsmanipulation für jeden, der ihn findet.

Terminieren Sie TLS am Broker und authentifizieren Sie jedes Gerät mit eigenen Zugangsdaten statt eines gemeinsamen Passworts.
Autorisieren Sie Topics, damit ein Leser in Halle A nicht in den Namensraum von Halle B publiziert.
Halten Sie Nutzlasten möglichst frei von Personendaten; wenn ein Etikett auf eine Person zeigt, verschlüsseln oder tokenisieren Sie diese Zuordnung.
Rotieren Sie Zugangsdaten nach Plan und bei Geräterente, und protokollieren Sie jede Rotation.
Trennen Sie auf Datenbankebene die Leserechte des Subscribers von seinen Schreibrechten.

Beobachtbarkeit: beweisen, dass die Kette lebt

Die Frage um drei Uhr nachts lautet nie, ob der Broker läuft, sondern ob die letzte Stunde Lesungen in Odoo angekommen ist.

Verfolgen Sie das Nachrichtenalter Ende zu Ende: Publikationszeit minus Commit-Zeit, mit Alarmschwelle.
Senden Sie pro Gerät einen Heartbeat und alarmieren Sie, wenn ein Gerät zu Betriebszeiten verstummt.
Zählen Sie empfangen, verarbeitet, entdupliziert und abgelehnt und zeigen Sie die vier Zahlen gemeinsam.
Halten Sie einen Abgleichjob vor, der Ereigniszahlen mit resultierenden Bestandsbuchungen der letzten Stunde vergleicht.
Protokollieren Sie eine Korrelations-ID vom Leser bis zum Odoo-Datensatz, damit eine strittige Lesung in Minuten nachvollziehbar ist.

Nichts davon ist exotisch. Es ist die gewöhnliche Disziplin, eine Ereigniskette wie ein Finanzsystem zu behandeln, weil sie genau das wird, sobald Bestand von ihr abhängt.