LLRP – das Low Level Reader Protocol – existiert, weil jeder feste UHF-Leser früher seine eigene Sprache sprach. Vorher bedeutete die Integration von drei Herstellern drei SDKs, drei Verbindungssemantiken und drei Arten, "diese vier Antennen mit diesem Filter lesen" auszudrücken. LLRP ersetzt das durch ein binäres Protokoll über TCP.

Was LLRP tatsächlich standardisiert

LLRP definiert die Nachrichten, die ein Client an einen Leser sendet, und die Berichte, die der Leser zurückschickt: Fähigkeitsermittlung, Leserkonfiguration, Inventar- und Zugriffsspezifikationen, Tag-Zugriffsbefehle und Ereignisbenachrichtigungen. Version 1.0.1 von 2007 ist noch immer am weitesten verbreitet; Version 2.0 ergänzt die Gen2-v2-Kommandos.

Es standardisiert weder Ihre Geschäftslogik noch Ihr Datenmodell oder Ihre Antennenbenennung. Das bleibt Ihre Aufgabe, und die Verwechslung von Protokoll und Integration ist der Punkt, an dem die meisten Projekte abdriften.

Fähigkeitsermittlung: Antennenzahl, Leistungsbereich, unterstützte Luftprotokolle.
Konfiguration: RF-Modus, Sendeleistung, Antennengewichte, GPI- und GPO-Verhalten.
Inventar: ROSpec und AISpec legen fest, welche Antennen senden und was berichtet wird.
Zugriff: Lesen, Schreiben, Sperren und Kill gegen eine ausgewählte Tag-Menge.

Welche Einstellungen in die Middleware gehören, nicht in die Firmware

Alles, was sich zwischen zwei Standorten unterscheidet, muss in der Middleware liegen und im selben Repository wie die übrige Integration versioniert werden. Leserseitige Voreinstellungen sind unsichtbar, nicht versioniert und nach dem Ausscheiden des einrichtenden Technikers nicht mehr prüfbar.

Inventar-Session, Target und Schätzung der Tag-Population.
Sendeleistung pro Antenne und die Zuordnung Antenne zu Zone.
Filter (EPC-Präfix, TID-Maske), die festlegen, was der Leser melden darf.
Lesermodus: maximale Leistung, Dense-Reader oder hybrid.
GPI-Trigger und Entprellfenster für Förderband- oder Türsensoren.

Wie modelliert man ROSpec, AISpec und AccessSpec?

Ein ROSpec ist der Container: Er bündelt Antennen, eine Inventarspezifikation, eine optionale Zugriffsspezifikation und eine Berichtsspezifikation und durchläuft die Zustände deaktiviert, inaktiv und aktiv. Die AISpec sagt, welche Antennen mit welchen Inventarparametern laufen; die AccessSpec sagt, was auf den Tags gelesen oder geschrieben wird, die einem Filter entsprechen.

Halten Sie einen ROSpec pro physischer Zone, nicht pro Antenne. Damit ist ein Tordurchgang ein einzelnes Objekt, das Sie starten, stoppen und überwachen können, und die Antennenzuordnung bleibt ein Konfigurationsdetail statt einer Codeänderung.

Ein ROSpec pro Zone: Tordurchgang, Produktionslinie, Lagerraum.
Berichtsintervall von 200–1.000 ms für Portale; Sofortmeldung nur bei geringem Volumen.
AccessSpec nur für Schreibvorgänge; schreibfreie Zonen ohne Zugriffsbefehle halten.

Wo LLRP-Projekte üblicherweise scheitern

Das Protokoll ist selten das Problem. Die Fehler liegen im Betrieb.

Verbindungsbehandlung: Leser starten neu, verlieren TCP und verbinden sich in Wellen; ein Client ohne Backoff belastet Leser und Netzwerk gleichzeitig.
Doppellesungen: Derselbe Tag zwölfmal in zwei Sekunden ist ein Ereignis, nicht zwölf Lagerbewegungen.
Pufferüberläufe: Ein Schub von 800 Tags an einem Portal überrollt einen synchron arbeitenden Client.
Firmware-Unterschiede: Optionale Felder und Fähigkeiten differieren zwischen Modellen und Versionen; Ermittlungsergebnisse sind Daten, keine Annahmen.
Fehlende Trennung: Geschäftsregeln, die in der Leserkonfiguration stecken, lassen sich nicht testen.

Wie sollten Ereignisse Odoo erreichen?

Der saubere Pfad lautet: Leserereignis, Normalisierung, Entdopplung, Geschäftsereignis, ERP-Aufruf. Jeder Schritt hat genau eine Verantwortung und lässt sich unabhängig protokollieren.

Leserereignis: EPC, Antenne, Zeitstempel, Leseanzahl, RSSI.
Normalisierung: EPC zu Produkt, Antenne zu Lagerort, Leser zu Vorgangsart.
Entdopplung: Entprellfenster von 3–10 Sekunden pro EPC und Zone.
Geschäftsereignis: Wareneingang, Umlagerung, Zählung oder Anpassung – eines pro physischer Bewegung.
Odoo-Aufruf: stock.quant-Aktualisierung, stock.move-Erzeugung oder Inventuranpassung, mit einem Idempotenzschlüssel aus EPC, Zone und Zeitfenster.

Wie sehen Monitoring und Failover aus?

Behandeln Sie Leser wie Netzwerkgeräte. Fragen Sie alle 30 Sekunden Heartbeat und GPI-Status ab, alarmieren Sie bei einem Einbruch der Leserate statt bei Einzelfehlern und puffern Sie Ereignisse lokal, wenn ERP oder Netz nicht erreichbar sind.

Store-and-Forward ist in einem Lager keine Option, in dem eine verpasste Torlesung drei Wochen später zur Bestandsdifferenz wird. Dimensionieren Sie den Puffer für mindestens vier Stunden bei Spitzenlast und spielen Sie mit den Originalzeitstempeln ab, damit das ERP die richtige Reihenfolge sieht.

Fazit

LLRP gibt Ihnen ein Protokoll für Leser mehrerer Hersteller – mehr nicht. Legen Sie Konfiguration, Filterung und Pufferung in die Middleware, modellieren Sie einen ROSpec pro Zone, entdoppeln Sie, bevor Sie das ERP berühren, und überwachen Sie Leser wie die Netzwerkgeräte, die sie sind.