Die typische erste Integration zwischen Leserflotte und ERP ist HTTP: Das Gateway sendet jeden Lesestapel an einen Endpunkt, Odoo nimmt ihn an, alle gehen nach Hause. Drei Monate später läuft der Endpunkt unter Spitzenlast in Timeouts, das Gateway wiederholt gegen eine Wand, und die verlorenen Ereignisse sind genau die, die die Bestandsabweichung erklärt hätten.

MQTT ist die übliche Lösung, und sie ist gut — aber nur, wenn man sie als Transport mit bestimmten Garantien versteht und nicht als Warteschlange, die das Problem magisch beseitigt.

Warum HTTP-Polling bei RFID-Ereignisraten scheitert

Der Fehler ist keine Einstellungssache, sondern strukturell.

Polling heißt: Der Client fragt. Bei zehntausend Etiketten pro Stunde wird das Fragen selbst zur Last.
Eine langsame ERP-Antwort blockiert das Gateway, also puffern Leser im Speicher oder verwerfen Ereignisse an der Kante.
Netzwerk-Jitter macht aus einem synchronen Aufruf einen Timeout und aus einem Timeout eine nicht erfasste Lesung.
Es gibt keinen natürlichen Rückkanal: Odoo kann dem Gateway nicht sagen, langsamer zu werden, den Modus zu wechseln oder eine Zone neu zu lesen.
Retry-Stürme verstärken das ursprüngliche Problem, weil jede fehlgeschlagene Anfrage wiederholt wird, während neue Ereignisse eintreffen.

Was Publish/Subscribe ändert

Der Broker schiebt einen dauerhaften, adressierbaren Puffer zwischen die beiden Seiten, und das verändert die Fehlermodi.

Der Leser publiziert und vergisst; die Zustellung wird zum Problem des Brokers statt des Lesers.
Die Geschäftsseite abonniert in ihrem eigenen Tempo, also bremst ein langsames ERP die Bridge, nicht den Funk.
Topics liefern ein Routing-Vokabular: Standort, Zone, Leser und Ereignistyp sind einzeln adressierbar.
Der Broker kann puffern, während der Consumer neu startet, was einen Ausfall in eine Verzögerung verwandelt.
Kommando-Topics erlauben Odoo oder einem Bediener, Konfiguration zurück zu den Lesern zu schieben.

Der Themenbaum ist der Vertrag

Die meisten MQTT-Integrationen altern schlecht, weil die Topic-Struktur improvisiert wurde und nun jeder Consumer Zeichenketten parst.

Entwerfen Sie die Hierarchie einmal: Standort, Zone, Leser, Ereignistyp — und halten Sie die Reihenfolge für immer fest.
Publizieren Sie Rohlesungen auf einem Zweig und aufgelöste Geschäftsereignisse auf einem anderen; sie haben verschiedene Consumer und verschiedene Aufbewahrungsbedarfe.
Nutzen Sie einen separaten Zweig für Status und Heartbeat, damit ein toter Leser sichtbar wird, ohne den Ereignisstrom zu durchsuchen.
Wildcards sind praktisch für Werkzeuge und gefährlich für Produktions-Consumer, weil ein Abonnement sich stillschweigend erweitern kann.
Versionieren Sie den Baum, nicht nur das Payload; eine umbenannte Ebene bricht mehr als ein umbenanntes Feld.

Payload-Design: klein, versioniert, selbstbeschreibend

Payloads sind ebenfalls Verträge, und die Kosten eines Fehlers kommen spät.

Nehmen Sie pro Ereignis das Wesentliche mit: Ereigniszeit vom Leser, Leser-ID, Antenne, EPC, Signalstärke und eine monotone Sequenz.
Bevorzugen Sie numerische Zeitstempel in Millisekunden vom Gerät, mit der Empfangszeit des Gateways in einem separaten Feld.
Halten Sie das Schema flach, wo es geht; verschachtelte Strukturen sind schwerer zu validieren und zu indexieren.
Führen Sie eine explizite Schema- und Firmware-Version mit, weil sich Feldverhalten häufiger mit der Firmware ändert als mit dem Schema.
Komprimieren Sie nur bei echt knapper Bandbreite; ein Broker voller Binärblobs ist ein Broker, den niemand debuggen kann.

QoS, Retained Messages und was sie wirklich garantieren

Die drei QoS-Stufen werden viel beschrieben und viel missverstanden.

QoS null ist Feuer und Vergessen: passend für hochfrequente Rohlesungen, bei denen die nächste Lesung in einer Sekunde sie ersetzt.
QoS eins garantiert mindestens eine Zustellung, also Duplikate, und Duplikate bedeuten, dass die Bridge idempotent sein muss.
QoS zwei garantiert genau eine Zustellung auf Protokollebene, zum Preis eines vierteiligen Handshakes pro Nachricht.
Retained Messages sind für Zustand, nicht für Ereignisse: Der letzte bekannte Leserstatus gehört dorthin, eine Etikettenlesung nicht.
Ein Last Will ist das, was einen toten Leser in Sekunden sichtbar macht statt erst bei der nächsten Inventur.

Die Bridge: wo das Protokoll zum Geschäftsereignis wird

Die Bridge ist eine echte Anwendung mit Zustand, und dort entsteht oder zerstört sich der Wert.

Abonnieren Sie Rohlesungen, deduplizieren Sie nach EPC in einem Zeitfenster und aggregieren Sie zu vorzeichenbehafteten Deltas.
Lösen Sie EPC zu Produkt und Los über eine zwischengespeicherte Abbildung auf und routen Sie unbekannte Etiketten in ein Quarantäne-Topic.
Wenden Sie über einen einzigen Schreiber mit Idempotenzschlüssel auf Odoo an, niemals aus mehreren Bridge-Instanzen gleichzeitig.
Bestätigen Sie die MQTT-Nachricht erst, nachdem der Geschäftsschreibvorgang committet ist, sonst verlieren Sie Ereignisse im schlechtesten Moment.
Publizieren Sie das aufgelöste Ereignis zurück auf den Geschäftszweig, damit andere Consumer diese Arbeit nicht wiederholen.

Backpressure, Replay und die Poison Message

Jede Ereignispipeline trifft irgendwann eine Nachricht, die sie nicht verarbeiten kann, und die Designfrage ist, was dann geschieht.

Begrenzen Sie Nachrichten in Bearbeitung; ein unbegrenzter Consumer ist nur ein langsamerer Weg, den Speicher zu erschöpfen.
Wächst der Puffer über eine Grenze, verwerfen Sie mit Zähler statt den Leser zu blockieren, und alarmieren Sie laut.
Schicken Sie unverarbeitbare Nachrichten mit Begründung in ein Dead-Letter-Topic und lassen Sie nie eine Nachricht die Warteschlange blockieren.
Speichern Sie die monotone Sequenz, damit ein Replay an einem bekannten Punkt beginnt statt zu raten.
Testen Sie den Replay-Pfad bewusst; ein ungetesteter Replay ist ein Glaube, keine Fähigkeit.

Sicherheit: TLS, Zugangsdaten und Topic-ACLs

Ein MQTT-Broker im Lager ohne Zugriffskontrolle ist eine Schnittstelle zur Bestandsmanipulation.

Nutzen Sie TLS auf dem sicheren Standardport und deaktivieren Sie den Klartext-Listener vollständig.
Geben Sie jedem Leser eigene Zugangsdaten oder ein Client-Zertifikat, damit ein kompromittiertes Gerät einzeln widerrufen werden kann.
Beschränken Sie Publish- und Subscribe-Rechte pro Topic-Zweig, damit ein Leser nicht auf dem Zweig eines anderen Standorts publiziert.
Deaktivieren Sie anonymen Zugang und das Standard-Admin-Konto; beides sind weiterhin die häufigsten Prüfungsbefunde.
Protokollieren Sie Verbindungs- und Autorisierungsfehler, denn sie sind das früheste Signal für ein fehlkonfiguriertes oder feindliches Gerät.

Betrieb: Sie besitzen jetzt einen Broker

Ein Broker hinzuzufügen heißt, ein System hinzuzufügen, das wie jedes andere überwacht werden muss.

Verfolgen Sie verbundene Clients, Nachrichtenrate, verworfene Nachrichten und die Tiefe persistenter Sitzungen.
Alarmieren Sie bei Bridge-Verzögerung, beim Alter der ältesten unverarbeiteten Nachricht und bei Wachstum der Dead-Letter-Queue.
Kapazitätsplanung für die Spitzenstunde, nicht für den Tagesdurchschnitt, und testen Sie einen Broker-Neustart in einer vollen Schicht.
Sichern Sie den Retained-Zustand und die Abbildungstabellen der Bridge; sie sind Konfiguration, kein Cache.
Dokumentieren Sie Themenbaum und Payload-Schema im Repository, denn die nächste Integration schreibt jemand anderes.