Skip to content

RFID Management

Module: RFID Management  |  Audience: Admin

Table of Contents

Overview

AMS integrates with RFID infrastructure to automate asset and vehicle tracking. Physical readers publish tag reads over MQTT; AMS turns those reads into RFID Transactions, matches them against known assets or vehicles, and — for readers positioned at a gate (an entry or exit point) — uses them to automatically advance the status of an in-flight Asset Transfer or Activity without anyone having to manually check a box.

The module itself manages two things directly: Readers (the physical devices) and Vehicles (RFID-tagged transport units). Everything else described below — scan ingestion, de-duplication, EPC matching, and gate-scan-driven movement tracking — is automated processing that runs on top of that data; there is no separate configuration screen for it.

Access Requirement: Admin role required for reader and vehicle management.

RFID Readers

Path: Sidebar → RFID Management → RFID Readers  |  URL: /rfid/readers

Creating a Reader

Path: RFID Readers → + Create  |  URL: /rfid/readers/create

Field Type Required Validation Depends On
Reader Name Text Yes Unique —
Device ID Text Yes Unique; the identifier the physical reader authenticates and publishes with —
Description Text Area No — —
Location Tree Select Yes Where the reader is physically installed Locations
Reader Type Dropdown Yes One of: Entry, Exit, Warehouse, Handheld, Other — see Reader Types and What They Drive —
Scan Interval (sec) Number No Non-negative integer; Default: 5 —
Debounce Time (sec) Number No Non-negative integer; Default: 2. Also sets the scan de-duplication window for this reader —
Threshold Time (sec) Number No Non-negative integer; Default: 10. For Warehouse readers, this also controls how often the reader re-syncs asset locations — see Warehouse Readers —

Note: Earlier releases exposed additional reader fields (IP Address, Port, MAC Address, Firmware Version, Model Number, Manufacturer, per-reader auth key generation, and a standalone "Reader Types" master list with its own CRUD screen and an "Activity Logs" event history). These have been removed from the current backend and are no longer part of reader configuration — Reader Type is now a fixed dropdown, not a separate master entity.

Reader Detail

Path: RFID Readers → click a reader  |  URL: /rfid/readers/:id

Section Content
Reader Details Device ID, Reader Type, Location, Description, Last Seen, Created/Updated timestamps
Scan Settings Scan Interval, Debounce Time, Threshold Time
View Configuration Opens the reader's MQTT connection details — publish topic, subscription topic, client ID, and keep-alive — needed to provision the physical reader device against the AMS MQTT broker

Last Seen is the reader's only health indicator: every reader periodically publishes a heartbeat, and this timestamp reflects the last one received (see Reader Heartbeat). There is no separate online/offline flag — a Last Seen timestamp that stops advancing means the reader has gone quiet.

Reader Types and What They Drive

Reader Type Behavior
Entry Gate reader. A matched scan here checks an asset/vehicle in — advances a Transfer from Checked Out to Checked In, or records an Activity check-in.
Exit Gate reader. A matched scan here checks an asset/vehicle out — advances a Transfer from Approved to Checked Out, or records an Activity check-out.
Warehouse Not a gate — periodically syncs the current location of any asset it detects. See Warehouse Readers.
Handheld Used for manual/mobile scanning (e.g., during an Audit); does not drive gate matching.
Other No automated behavior attached; scans are still recorded as RFID Transactions.

Vehicle Management

Path: Sidebar → RFID Management → Vehicle Management  |  URL: /rfid/vehicles

Vehicles are RFID-tagged transport units used for asset movement tracking on Transfers and Activities.

Creating a Vehicle

Path: Vehicles → + Create  |  URL: /rfid/vehicles/create

Field Type Required Validation Depends On
Name Text Yes Max 100 characters —
Registration Number Text Yes Max 50 characters; unique —
Manufacturer Dropdown No — Manufacturers
Model Dropdown No Disabled until Manufacturer is selected; filtered by manufacturer Models → filtered by Manufacturer
Description Text Area No — —
EPC ID Text No Free text — no format is currently enforced by the system. Must match the value the vehicle's physical RFID tag actually transmits, or gate-scan matching for that vehicle won't resolve —

Field Dependency: The Model dropdown is disabled until a Manufacturer is selected (same pattern as asset creation).

Vehicle Availability

Path: Vehicle Detail → Availability

Shows whether a vehicle is currently tied to an active Transfer, so schedulers can avoid double-booking the same vehicle across two movements at once.

How RFID Scan Processing Works

This section explains what happens, end to end, once a reader reads a tag — useful when troubleshooting why a Transfer or Activity didn't move to the status you expected.

Ingestion Pipeline

RFID Reader → MQTT → rfid-middleware → RabbitMQ (per-tenant queue) → AMS backend → RFID Transaction

Each reader publishes tag reads to a per-tenant, per-device MQTT topic (shown in its View Configuration dialog). The middleware forwards them to a per-tenant RabbitMQ queue, and the AMS backend consumes that queue and writes each read as an RFID Transaction (EPC ID, reader, scanned-at timestamp).

Reader Heartbeat

Readers also periodically publish a lightweight heartbeat message on the same channel. Receiving one simply updates that reader's Last Seen timestamp — it does not create an RFID Transaction or count as a tag scan.

Scan De-Duplication

A physical tag held near a reader is typically read many times per second. To avoid creating a flood of duplicate transactions, repeat reads of the same tag on the same reader within that reader's configured Debounce Time are collapsed into a single RFID Transaction. Increase Debounce Time on a reader if it's producing noticeably more duplicate-looking transactions than expected; decrease it if legitimate back-to-back scans of different tags feel like they're being dropped.

EPC Matching

Once written, an RFID Transaction's tag ID is matched:

  1. First against Asset.rfid_epc_id (exact, case-sensitive match) — see Asset Management for where this is set on an asset.
  2. If no asset matches, against Vehicle.epc_id.

If neither matches, the transaction is still stored (for traceability) but doesn't drive any automated movement tracking.

Gate Scan Matching and Movement Sessions

For Entry and Exit readers only, a matched scan is checked against any Transfer or Activity currently expecting a movement for that asset or vehicle:

  • A matched Exit scan checks the asset/vehicle out — the Transfer/Activity's checkout step is recorded.
  • A matched Entry scan checks it in, but only once an open checkout for it already exists.
  • Every checked matching scan is recorded as a Movement Session — the audit trail entry showing which reader, which timestamp, and (for a real scan) which RFID Transaction produced it.
  • A scan that doesn't correspond to any open Transfer/Activity claim is still recorded (as an unauthorized Movement Session) and triggers a notification to the asset's assigned user — see RFID-Driven Notifications.
  • Asset-tracked Transfers require every asset in the transfer to be scanned in a given direction before the transfer's status advances; vehicle-tracked Transfers advance as soon as the vehicle itself is scanned.

This processing is safe to run across multiple backend workers at once — each scan is claimed and processed exactly once, so you won't see a single physical scan double-advance a status.

See Asset Transfer — RFID-Based Movement Tracking and Schedule & Activity Management — Movement Tracking in Activities for how this plays out from the Transfer/Activity side, including what happens when a scan never arrives.

Warehouse Readers and Location Tracking

A Warehouse-type reader doesn't participate in gate matching. Instead, on an interval controlled by its Threshold Time, it re-syncs the recorded location of every asset it currently detects — updating that asset's Last Scanned Location and Last Scanned At.

If an asset's Last Scanned Location ever disagrees with its assigned Location, the asset is flagged as mislocated — this is what feeds the Asset Location Mismatch Report.

RFID-Driven Notifications

Gate-scan activity generates in-app notifications through the standard Notification Center — there is no separate RFID notifications screen. Relevant types:

Notification Type Trigger
Unauthorized Asset Movement An asset was scanned at an Entry/Exit reader with no open Transfer/Activity expecting that movement; sent to the asset's assigned user
Vehicle Movement Checkout A vehicle was matched and checked out at an Exit reader
Vehicle Movement Checkin A vehicle was matched and checked in at an Entry reader

Master Data Used by This Module

Master Entity Where Used Purpose
Locations Reader location Where the reader is installed
Floor Plans Reader detection zones (configured via the Floor Plan Interactive Editor) Visual positioning
Manufacturers Vehicle manufacturer Vehicle identification
Models Vehicle model (filtered by manufacturer) Vehicle identification

Related: Asset Transfer · Audit Management · Floor Plan Management · Schedule & Activity Management · Reports · Notifications