Integrating RFID into your software
This page is for teams who already build ERP, WMS, or retail software and are working with an RFID reader for the first time. The approach here: tie each RFID concept back to something you already use every day, and draw the boundary clearly between what the SDK handles and what your software handles.
The reader is an event source, not an API
The model most familiar to a software developer is request and response: call an API, get a result, done. An RFID reader does not work that way. You send one start-inventory command, and the reader then pushes data to you continuously until you tell it to stop.
If you want a familiar picture:
- A barcode scanner is like a keyboard: the user acts, your software receives exactly one event.
- An RFID reader is like a message queue whose producer is hardware: messages arrive continuously, the same identifier repeats hundreds of times, and the consumer, your software, has to fold them into meaningful events.
If you have ever written a Kafka or RabbitMQ consumer, every technique you know transfers directly: handling duplicate messages, idempotency keys, windowed aggregation.
Where the SDK sits
The SDK plays the same role as a database driver: you never deal with the wire protocol, you call methods and receive parsed data.
Division of responsibility:
| Job | Owner |
|---|---|
| Open the serial port, talk to the reader, parse tag data | SDK |
| Configure power, antennas, frequency region | SDK, you choose the values |
| Fold many reads into one event (deduplication) | Your software |
| Give the event business meaning based on the read point | Your software |
| Write to the ERP idempotently | Your software |
The common architecture: a small service next to the reader
The most common shape is an edge service: a small program running on a computer at the warehouse or store, connected to the reader over USB.
- The service (usually Python with
nrn-sdk) receives tags through the SDK callback. - It deduplicates locally, so hundreds of repeat reads never cross the network.
- It pushes clean events to your backend over HTTP or a message queue, with the read point and timestamp attached.
- The backend maps EPC to SKU and creates ERP documents the same way it does for any other transaction.
For a sales screen or kiosk running in the browser there is a shorter path: the Web Serial package (@nextwaves/nrn-sdk) lets the web page talk to the reader directly, with nothing to install.
One note for distributed-systems people: the reader is a serial device, so exactly one process may hold the connection. Never let two services open the same reader; if several consumers need the data, have the edge service republish it through a queue.
The data you add to your system
Usually three tables, and all three resemble things you have built before:
| Table | Role | Resembles |
|---|---|---|
| EPC mapping | Which EPC belongs to which SKU and batch, since when | A serial-number or IMEI table |
| Read points | Which reader and antenna stand at which business location | A register/dock/warehouse catalog |
| Read events | Deduplicated events with an idempotency key | A transaction log table |
An EPC identifies an individual item, so the EPC mapping table is simply a serial-number table at larger scale. The rules for generating EPCs are in EPC encoding.
Preventing duplicate writes: the double-submit playbook
Every web developer has stopped a user from clicking Save twice. RFID needs exactly that technique, because the same tag is guaranteed to be reported many times, and your service may restart mid-stream:
- Give each event a natural key:
(EPC, read point, business window). - Write to the ERP with a conditional operation on that key, in the spirit of
INSERT ... ON CONFLICT DO NOTHING. - A second write of the same event becomes a no-op instead of a second stock movement.
The full three-layer deduplication approach, from the reader down to the database, is in reading tags and deduplication.
A one-week trial plan
- Day one: plug a desktop reader into a laptop,
pip install nrn-sdk, run the quickstart. The goal is EPCs printing to the console. - During the week: wire the callback into your existing event pipeline in a test environment, build the EPC mapping table, and exercise the idempotency key by passing one tag through repeatedly.
- Before going on site: survey the real read zone with the RFID deployment guide, because read performance depends on the physical environment, not on your code.
Read next
- What to know before deploying RFID if you have not read it: how RFID differs from barcodes
- Quickstart for your first connection code
- Reading tags and deduplication for the complete read pipeline