LLRP in Practice: Configuring RFID Readers Without Creating New Silos

LLRP — the Low Level Reader Protocol — exists because every fixed UHF reader used to speak a different language. Before it, integrating three reader vendors meant three SDKs, three sets of connection semantics and three ways of expressing "read these four antennas with this filter". LLRP replaces that with one binary protocol over TCP.

What LLRP actually standardises

LLRP defines the messages a client sends to a reader and the reports the reader sends back: capability discovery, reader configuration, inventory and access specifications, tag access commands and event notifications. Version 1.0.1, ratified in 2007, is still the most widely deployed; version 2.0 adds the Gen2 v2 commands.

It does not standardise your business logic, your data model or your antenna naming. Those remain yours, and confusing the protocol with the integration is where most projects drift.

• Capability discovery: antenna count, power range, supported air protocols.
• Configuration: RF mode, transmit power, antenna weights, GPI and GPO behaviour.
• Inventory: ROSpec and AISpec defining which antennas fire and what is reported.
• Access: read, write, lock and kill operations against a selected tag set.

Which settings belong in middleware, not firmware

Anything that differs between two sites must live in middleware, versioned in the same repository as the rest of the integration. Reader-side defaults are invisible, unversioned and impossible to audit after the engineer who set them has left.

• Inventory session, target and tag-population estimate.
• Transmit power per antenna, and the antenna-to-zone mapping.
• Filters (EPC prefix, TID mask) that decide what the reader is allowed to report.
• Reader mode: maximum throughput, dense reader or hybrid.
• GPI triggers and debounce windows for conveyor or door sensors.

How should ROSpec, AISpec and AccessSpec be modelled?

A ROSpec is the container: it groups antennas, an inventory specification, an optional access specification and a report specification, and it moves through disabled, inactive and active states. AISpec says which antennas run which inventory parameters; AccessSpec says what to read or write on the tags that match a filter.

Keep one ROSpec per physical zone, not one per antenna. A dock door then becomes a single object you can start, stop and monitor, and the antenna mapping stays a configuration detail rather than a code change.

• One ROSpec per zone: dock door, production line, stockroom.
• Report interval of 200–1,000 ms for portals; immediate reporting only for low-volume reads.
• AccessSpec only for writes; keep read-only zones free of access commands.

Where LLRP deployments usually fail

The protocol is rarely the problem. The failures are operational.

• Connection handling: readers reboot, drop TCP and reconnect in storms; a client without backoff will hammer both the reader and the network.
• Duplicate reads: the same tag seen twelve times in two seconds is one event, not twelve stock movements.
• Buffer overflows: a burst of 800 tags at a portal overruns a client that processes synchronously.
• Firmware variance: optional fields and capabilities differ between models and versions, so discovery results must be treated as data, not assumptions.
• No separation of concerns: business rules buried in reader configuration cannot be tested.

How should events reach Odoo?

The clean path is: reader event, normalisation, deduplication, business event, ERP call. Each step has one responsibility and can be logged independently.

• Reader event: EPC, antenna, timestamp, read count, RSSI.
• Normalisation: EPC to product, antenna to location, reader to operation type.
• Deduplication: a debounce window of 3–10 seconds per EPC and zone.
• Business event: receipt, transfer, count or adjustment — one per physical movement.
• Odoo call: stock.quant update, stock.move creation or inventory adjustment, with an idempotency key built from EPC, zone and window.

What does monitoring and failover look like?

Treat readers as network equipment. Poll heartbeat and GPI state every 30 seconds, alert on a collapse in read rate rather than on individual errors, and buffer events locally when the ERP or the network is unavailable.

Store-and-forward is not optional in a warehouse where a missed dock-door read becomes a stock discrepancy three weeks later. Size the buffer for at least four hours at peak read rate, and replay with the original timestamps so the ERP sees the correct sequence.

Bottom line

LLRP gives you one protocol for multi-vendor readers, and that is all it gives you. Put configuration, filtering and buffering in middleware, model one ROSpec per zone, deduplicate before you touch the ERP, and monitor readers like the network devices they are.