Wiring an Impinj R700 into Odoo Without Making Odoo a Reader Driver

The Impinj R700 is easy to buy and surprisingly hard to integrate well, because it is not a reader in the traditional sense. It runs Linux, hosts applications, and can decide things on its own. Teams that treat it as a serial device end up with a fragile chain; teams that treat it as a small server end up with a clean one.

What the R700 actually is

Understanding the device decides the architecture.

• It is an edge computing platform with an RFID radio, not a USB peripheral with a firmware command set.
• It runs containerised applications, so logic can live on the reader rather than on a server.
• It exposes LLRP, a REST API and a management interface, each with a different role.
• It can buffer events locally, which matters when the network drops during a shift.
• It is managed as a fleet, with configuration profiles pushed centrally rather than set by hand.

Three layers, three owners

The clean pattern is boring, and boring is what survives.

• The reader owns the radio: power, session, filters, antenna scheduling and connectivity.
• Middleware owns the semantics: deduplication, zone mapping, business events and buffering.
• Odoo owns the inventory: stock moves, lots, locations and the accounting consequence.
• Never let Odoo's web workers talk to LLRP; a protocol connection does not belong in a request thread.
• Never let the reader write stock moves; a device that can book inventory is a security incident waiting to happen.

Two integration paths

There is a platform path and a direct path, and they solve different problems.

• ItemSense or an equivalent item platform aggregates many readers into one API, with zone logic already solved.
• The direct path talks to each reader's REST interface and builds the event model yourself.
• The platform path is faster for multi-reader sites and slower to customise for unusual logic.
• The direct path is lighter for a handful of readers and gives full control of the data model.
• Whichever you choose, keep the Odoo connector identical on both sides, so switching is not a rewrite.

The event contract to Odoo

Define the payload once, and version it.

• Fields: device id, site, zone, antenna, EPC, first seen, last seen, read count, RSSI and a sequence number.
• Send observations, not conclusions; let the middleware decide whether an observation is a movement.
• Batch by zone and by short time window to reduce chatter, but keep the window under a second for portals.
• Make the endpoint idempotent on device, EPC and window, so a retry cannot double-book a movement.
• Return a clear response: accepted, duplicate or rejected with a reason, so the reader can act.

Reading, gateways and network reality

The reader is only as good as its network, and warehouses are not data centres.

• Use wired Ethernet where possible; Wi-Fi at a dock door is a coin flip during peak.
• Keep the reader's local buffer sized for the longest expected outage, and test that it replays correctly.
• Monitor heartbeat and configuration drift per device, because a reader silently offline looks like no stock movement.
• Time-sync readers to a common source, or the ordering of events becomes guesswork.
• Deploy configuration through the management plane, not by logging into each device.

Security and lifecycle

An edge device that runs containers is a small computer on your network, and it must be treated as one.

• Change default credentials before commissioning, and use per-device certificates rather than a shared password.
• Restrict outbound traffic to the middleware endpoint and the management plane.
• Track firmware versions in the asset register, because a fleet with mixed firmware behaves inconsistently.
• Rotate credentials on device replacement, and delete the old device from the middleware.
• Log every configuration change with who made it and when, because "it worked yesterday" is not a diagnosis.

Testing before the first real pallet

A reader that passes a bench test has proved nothing about the aisle.

• Test with full pallets at the real distance, and with the stock that will actually be there.
• Verify the zone boundary: walk a tagged box towards the neighbour zone and see where reads appear.
• Kill the network mid-shift and confirm the buffer replays without duplicates.
• Restart the reader and confirm the application comes back with the right configuration.
• Run a full day of production traffic and compare event counts with physical counts before going live.

What good looks like after a year

Success is measured in the boring metrics, not the launch demo.

• Event loss below a fraction of a percent, and every lost event explainable.
• No manual reconciliation for normal operations, only for genuine exceptions.
• Configuration changes deployable to the whole fleet in one action.
• A new reader installable in under an hour, because the pattern is repeatable.
• Odoo stays responsive during peak reads, because the reader never touches it directly.

If the architecture respects the three layers, an R700 deployment becomes an ordinary piece of infrastructure: it runs, it reports, and nobody talks about it. That is the highest compliment an integration can earn.

Multi-site, multi-tenant readers

A fleet that grew site by site almost always carries a tenancy mistake somewhere.

• Give every reader a site-scoped identity, and never let a payload carry only a device name.
• Partition topics and database schemas by site, so a misconfigured reader cannot write into another customer's data.
• Keep one configuration template per site profile, and treat a new site as a deployment rather than a manual install.
• Centralise firmware and application versions, because mixed versions make every bug report ambiguous.
• Write the tenancy rule down; it is invisible until the day it is violated.

Common failures and their symptoms

Most integration problems announce themselves with a recognisable signature.

• Duplicate stock moves: the endpoint is not idempotent, or the deduplication window is shorter than the retry interval.
• Missing events after a network outage: the buffer is too small or the reader was configured for a clean session.
• Odoo slow during peak hours: somebody put a synchronous call to the reader inside a web request.
• Zone reads bleeding into the neighbour aisle: antenna power and orientation were set from a bench test.
• A reader that "works" but never appears in reports: the heartbeat is monitored, the event stream is not.

Each of these is cheap to fix once named, and expensive to diagnose while the plant is running. Name them in the runbook before go-live, and the first month of operation becomes a routine instead of an argument.