Devices
This guide covers how to add, configure, and monitor the RFID readers that power your tracking system. Devices are the hardware endpoints (fixed RFID readers) that detect tags and feed data into Tagnet.
Overview
The Devices page displays all registered readers in a searchable grid. Each row shows the device's name, type, group, operational status, health, and when it was last seen. From here you can add new readers, view device details, edit configurations, and manage device lifecycles.
From the Devices page you can:
- Register new RFID readers (cloud-managed or local network)
- Monitor real-time health and operational status
- Configure scan processing, location mapping, and automation settings
- Group the list by device group or scope to organize devices, and manage groups from there
- View detailed device pages, including analytics and ingest data
- Open the Ingest History to see raw tag reads and telemetry across every device before scan processing
- Start, stop, and deploy configuration to locally-managed readers, and track whether each one is running the configuration Tagnet has on file
Permissions
| Permission | What It Allows |
|---|---|
| View Devices | See the device list, status, and health information |
| Manage Devices | Add, edit, configure, and delete devices |
Access scopes further restrict which devices a user can see and manage. Devices are operational records, so the scope picker on a device only lists site scopes (never the shared system scope) once your deployment has created one.
The Device Grid
Columns
| Column | Description |
|---|---|
| Icon | Visual indicator of the device |
| Name | Device name with model info |
| Type | User-defined device type category (colored chip) |
| Group | Device group membership |
| Status | Operational status: Scanning, Idle, Deploying, Unresponsive, or Unknown |
| Health | Aggregate health score with warning/critical counts |
| Last deployed | For locally-managed readers, when configuration was last deployed, or a chip showing why it hasn't been. See Deploying Reader Configuration |
| Last seen | When the device last communicated with Tagnet |
| Scope | Access scope assignment (shown when multiple scopes are active) |
| Actions | Details, Edit, Reader control (local readers), Go to group (grouped devices), Deactivate/Activate, and Delete options |
Search
Use the search bar to filter devices by name, device type, or group name. Results update as you type.
Column Selection
Click the menu icon in the grid's header row to choose which columns are visible. Type, Group, and Scope are hidden by default, since showing every column at once tends to wrap the grid on an ordinary desktop screen; the rest are shown. Your choice is remembered per user, so it applies the next time you visit the page too.
Auto-Refresh
The device grid refreshes automatically every 30 seconds to keep status and health information current.
Filtering Devices
Click the filter icon (funnel) next to the search bar to open the filter drawer. When any filter is active, the icon appears filled, and each active filter appears as a chip below the search bar; click a chip's X to remove it, or Clear All to reset every filter at once. Filters apply whether the list is flat or grouped: in a grouped view, filtering hides groups with no matching devices and automatically expands the ones that do. Your search, filters, grouping, and the column you sorted by are remembered for the rest of your session, so switching to another tab and back does not lose them; Clear All forgets the filters but leaves the sort in place.
| Filter | Description |
|---|---|
| Access Scope | Show only devices in a specific access scope |
| Group | Show only devices in a specific device group, or select Ungrouped for devices with no group |
| Device Type | Show only devices of a specific user-defined device type |
| Reader Model | Show only readers of a specific hardware model |
| Status | Scanning, Idle, Deploying, Unresponsive, Unknown, or Inactive |
| Health | Healthy, Warning, Offline, or Unknown |
The Devices Tabs
Under the page header, a tab strip switches between four views of your fleet: Devices, Types, Live Reads, and Ingest History. Devices is the grid described above; a group-by selector in its search bar (List, By group, By type, or By scope) arranges the same devices flat, as a tree by device group with an Ungrouped bucket for devices that don't belong to one, as a tree by device type, or as a tree by access scope (offered only in multi-site deployments). Types lists the device types that classify them. Live Reads is described in Live Reads, and Ingest History is the raw feed described in Ingest History.
Each group row in the tree shows its member count, a health chip, and a scope badge if your deployment has more than one site. The health chip is a ratio, such as "12/14 healthy", rather than a single status word: a group with one offline reader out of twenty reads very differently from one with nineteen offline, and a worst-status verdict alone can't tell the two apart. Hover the chip for a breakdown (for example "2 offline · 1 degraded · 3 inactive"). Deactivated members count separately and are excluded from the ratio entirely, since a deactivated device is expected to be silent and shouldn't drag the group's health down. Expand a group with its arrow to see its member devices, each shown with the same status, health, and last-seen information as the grid.
The tree works like the Locations tree:
- Clicking a row opens it. A device row opens the device, a group row opens the group's detail page, a type row opens the device type (if you can view types), and a scope row opens the access scope (admins only). Rows with nothing to open, such as Ungrouped, No type, or a type or scope you can't open, expand or collapse instead.
- The arrow expands. Click the arrow at the start of a row to show or hide its devices. Expand all and Collapse all buttons beside the group-by selector open or close every row at once.
- The ⋮ menu holds the row's actions. A group's menu offers Edit, Manage devices, and Delete to users who can edit the group; a type's offers Edit to users who can manage types; a scope's offers Edit to admins.
- Tagnet remembers what you left open, separately for each arrangement, so the tree looks the same the next time you sign in. While a search or filter is active, rows with matching devices open automatically, and that doesn't change what's remembered. Rows you open or close while the scope filter narrows the list apply for that visit only.
To link directly to a grouped view, add ?view=group, ?view=type or ?view=scope to the URL: /devices?view=group.
The header's Add menu creates either a Device or a Device Group, so you don't need to switch tabs just to create one. For creating and configuring groups, adding and removing members, and the group detail page, see Device Groups.
Adding a Reader
From the header Add menu, choose Device to register a new RFID reader. First pick how it connects, then Tagnet shows a setup flow tailored to that choice:
- Local network readers connect directly over your network. This is a multi-step wizard: discover the reader (or enter its address manually; see Reader Discovery if discovery doesn't find it) and sign in, review what Tagnet read straight from the hardware, adjust its reader configuration, and create it. Tagnet then offers to deploy the configuration immediately, and after a successful deploy offers to create a workflow for the reader or watch its live reads. See Impinj R700 Local Management.
- Cloud managed readers are deployed and managed through Tagnet's cloud infrastructure. This is a single form page: fill in the reader's identifying details (MAC address, and hostname for an Impinj R700), its reader configuration, its grouping, scan event processing, and read point location, then save. Tagnet generates ingest credentials, shown once on the page after you create the reader; you then point the reader's own web UI at Tagnet manually. See Cloud Reader Setup.
Both flows put access scope first: if your organization has more than one site scope, an Availability step or section appears before anything else, and choosing it decides which device types and groups the rest of the form offers. Single-site deployments skip this step entirely and route the reader to that one scope automatically.
Both flows can also start from a reader you have already set up. In the local wizard this is the Starting point step, right after Discovery; the cloud form has a Copy settings from select under Basics. See Copying Settings from Another Reader.
Note: Leaving the local reader wizard partway through asks for confirmation once you've started connecting to a reader; nothing is saved until the reader is actually created, so leaving discards the form and leaves the reader itself untouched. The one case Tagnet is stricter about is a factory-fresh reader whose forced password change it has already handled for you (see Impinj R700 Local Management): that password exists only in your browser session until the reader is created, and losing it means a factory reset to recover. Tagnet confirms before any action that would discard it, whether that's the Cancel button, going back to change how you're connecting, switching vendor, picking a different discovered reader, or navigating away from the wizard entirely (breadcrumb, nav menu, or closing the tab).
For a local reader over TLS with a self-signed certificate (the factory default on most readers), Tagnet accepts it without complaint. If your organization enables Security / Reader certificate validation under Policies and a reader's certificate doesn't validate, the connection attempt fails with an explanation and a pointer back to that policy.
License cap
Your Tagnet license limits the number of active RFID readers. Before opening either setup flow, Tagnet checks whether capacity is available. If all licensed reader slots are in use, a "License limit reached" dialog appears and the flow does not open. The same check runs again when you submit the form, so the cap is enforced even if the pre-flight check is bypassed.
The denial message tells you exactly how many readers are in use and what your cap is. To resolve it, either deactivate a reader you no longer need active (see Activating and Deactivating Devices below), or contact your Stratum Global account representative to expand your license. Every blocked attempt is recorded as a LicenseCapExceeded security event. See License and Security Events for details.
Note: If the system enters a locked state (expired trial or no license installed), readers receive
403responses to their scan posts. Most enterprise-grade RFID readers buffer tag reads locally and replay them automatically once the system resumes accepting connections. See License for details on the locked state and recovery.
Device Configuration
General Settings
| Field | Description |
|---|---|
| Name | Display name (required, must be unique) |
| Description | Optional notes |
| Device Type | User-defined category for organization (e.g., Dock Portal, Conveyor Reader) |
| Device Group | Optional group for shared configuration |
| Access Scope | Controls user visibility (locked if a group is assigned) |
Editing a Reader
Click a reader's row and choose Edit (or select Edit from the row actions menu) to open its edit page. Settings are organized into sections, with a status rail on the left flagging anything still missing:
| Section | Description |
|---|---|
| Basics | Name, description, device type, device group, reader model, antenna count |
| Connection | How Tagnet identifies and reaches the reader: MAC address, hostname (Impinj R700), and, for local readers, a single Address field |
| Reader configuration | Antenna, power, and read settings deployed to the reader. See Zebra FX Configuration, Zebra ATR7000 Directionality and Impinj R700 Local Management for what each vendor supports |
| Scan event processing | Processing mode, quiet period, max event duration, and cooldown, with inheritance from the device group |
| Read point location | Where this reader is, for Move Inventory actions and the within-read-point filter |
| Access scope | Which users can see and manage this device |
The page header's Copy settings from... button fills these sections from another reader of the same model; see Copying Settings from Another Reader.
For a locally-managed reader, changes under Reader configuration are not applied automatically. Click Update and Tagnet offers to deploy the change right away, or you can deploy later from the reader's Reader control tab; see Deploying Reader Configuration. Cloud-managed readers show the same settings for reference, but you must manually re-apply them through the reader's own web UI; see Cloud Reader Setup.
The Address Field
A local reader's Address field accepts a bare host (10.0.0.24), a host and port (10.0.0.24:443), or a full URL copied straight from the reader's own web page (https://reader.corp:8443). Tagnet infers HTTP or HTTPS and the port from whatever you type and echoes back the resolved target ("Will connect to https://10.0.0.24:443") so the assumption is visible before you save, not after a failed connection.
This exists because reader defaults are genuinely inconsistent in the field: most readers ship listening on plain HTTP port 80, some switch themselves to HTTPS on port 443 the first time someone logs into their web UI, some ship on 443 from the factory, and some sites front a reader through a firewall or NAT rule on a completely different port. A single field that accepts whatever you have to hand, rather than separate address, port, and TLS controls that have to be kept in sync by hand, avoids a row that quietly contradicts itself (port 443 with TLS switched off, for example).
The default port and protocol a bare host resolves to depends on the reader model: Impinj R700 defaults to HTTPS on port 443, Zebra FX and ATR readers default to plain HTTP on port 80, except the FXR90, which serves HTTPS only and defaults to port 443 (port 80 is closed on it). A well-known port (80 or 443) in what you type always states the scheme on its own, whatever the model default is.
Copying Settings from Another Reader
Portals and shelf systems are usually several identical readers that share every setting except their name and address. Instead of re-entering everything, start from a reader you have already configured. Only readers of the same model that you can see are offered, and what is copied is always the same bundle:
| Copied | Never copied |
|---|---|
| Reader configuration (operating mode, antennas and power, filters, session control, cable loss compensation, antenna port names; on an Impinj R700, the stored read configuration and the webhook TLS setting) | Name and description |
| Scan event processing (processing mode, quiet period, max duration, cooldown) | Address, port, TLS and credentials |
| Organization (device type and device group) | Serial number, MAC address, hostname and firmware |
| Read point location and site | The reader's reported regulatory region |
Three places offer it:
- Starting point step (local wizard). After Tagnet connects to the new reader, the wizard asks whether to Start fresh (the default, so the common case is one extra Next) or Copy an existing reader. Choosing a reader shows a short receipt of what will be set, and the Reader Info and Configuration steps arrive filled in. Everything stays editable; the copy happens once when you pick the reader and again only if you pick a different one, so later edits are never overwritten. Picking Start fresh again, or clearing the picker, returns the fields to their defaults.
- Copy settings from... (edit page). The reader edit page has a Copy settings from... button in the header. Pick the source reader and which sections to take: Reader configuration, Scan event processing, Organization, and Read point location. The first two are checked by default, since the reader is already placed. The values land in the unsaved form; click Update to save them, and Tagnet offers to deploy as for any other edit. Change History records which reader the settings came from.
- Copy settings from (cloud form). The cloud reader form has a Copy settings from select under Basics, filtered to the chosen model. Choosing a different model clears it.
From a reader's detail page, Create similar reader in the Actions menu opens the matching create flow (local wizard or cloud form) with that reader already chosen as the source. In the local wizard you still discover and connect to the new reader first; the copy applies on the Starting point step once Tagnet knows the new reader is the same model.
Two things to check after a copy:
- Antenna power, cable loss compensation and antenna port names describe the source reader's installation. Identical portals usually share them, but confirm them against the new reader's own cable runs. The Configuration step and the receipt call these out.
- Transmit power above the new reader's ceiling. A source running at a power its regulatory region permits may exceed what Tagnet allows for a reader whose region has not been read yet. The configuration validator flags it on save; lower the power or deploy once so Tagnet learns the new reader's region.
An Impinj R700 source created before Tagnet stored read configurations, or never deployed, has no stored configuration to copy. The wizard then reads the new reader's own configuration as usual and says why; the source's other settings are still copied. The edit dialog shows the same note and leaves Reader configuration unchecked.
Once you have one reader tuned for an installation, this is also how a Reader Setup Recipe spreads to the rest of the portal: tune one, copy to the others.
Read Point Location
A reader's Location says where the reader is. It does not move anything by itself; a workflow decides what a read means:
- A Move Inventory action with the target read point's location moves the items it sees to this location. That is the shape for a workstation, a cabinet, or any reader that stands in one place: seen here means it is here.
- The Within read point action filter tests whether an item is already inside this location, descendants included. That is the shape for a threshold such as a site portal or a doorway: place the reader's location at the site root or the building, and "within" means leaving while everything else means arriving.
When a device belongs to a group, the location is inherited from the group unless the device sets its own. A giant portal made of several readers sets the location on the group; a bank of workstations sets one per reader. A Zebra ATR7000 goes one level further: each of its zones can link to a location, and a tag resolves to the zone it was last seen in before the reader's own location. See Zebra ATR7000 Directionality.
Status and Health
Operational Status
| Status | Color | Meaning |
|---|---|---|
| Scanning | Green | Reader is actively scanning and sending tag data |
| Idle | Default | Reader is connected but not actively scanning |
| Deploying | Blue | A configuration deployment is running against this reader. Outranks every other status, including Unresponsive, since a deploy stops and restarts the radio |
| Unresponsive | Amber | Reader has not communicated recently |
| Unknown | Gray | Status cannot be determined |
Health Monitoring
Health is calculated from multiple metrics including CPU usage, temperature, memory, error rates, and antenna connectivity. The health indicator shows:
| Health | Icon | Meaning |
|---|---|---|
| Healthy | Green check | All metrics within normal ranges |
| Warning | Amber warning | One or more metrics show elevated values |
| Offline | Red error | Reader is not communicating or has critical issues |
| Unknown | Gray help | Insufficient data for health assessment |
Hover over the health icon to see the overall score, warning count, critical count, and which specific metrics are affected.
Ingest History
Every device sends raw tag reads and telemetry to Tagnet before scan events, movement rules, or workflows process any of it. To see that raw feed across your entire fleet, open the Ingest History tab. See Ingest History for the full guide, including search, filters, batch correlation, and how to read tag read and telemetry details.
For a single device's own raw data, open its detail page and select the Ingest data tab (below).
Device Detail Page
Click a reader's row, or select Details from the row actions menu, to open its detail page. Details is a read action and is always visible in the menu, even to users who can't edit the device. The page has its own tabs:
| Tab | Contents |
|---|---|
| Overview | Alerts (including a failed or undeployed configuration, for locally-managed readers); status cards for operation status, last check in, device health, and antenna ports (with GPI/GPO state when the reader reports it), each linking to the tab that explains it; then the Basics, Connection, and Reader configuration (read-only) sections, the effective scan event processing and read point location settings, and the workflows that run on this device. The Connection section also shows each credential's state and when it was last used: the Reader login Tagnet uses to reach a locally-managed reader, and the Ingest credential the reader presents when it posts. Admins change them from the page's Actions menu (Update reader login, Regenerate ingest password, Clear lockout, Manage credentials). On a locally-managed reader, Regenerate ingest password offers Generate & deploy, which pushes the new password to the reader straight away; a cloud reader shows the password once for you to enter in the vendor's console. A Read signature card shows the reader's state (Not set up, Capturing, Capture finished, Matching off, Matching on, or Settings changed) with one next action, or says its read point is the group when the reader is in one (see Read Signatures) |
| Analytics | Connectivity, read activity, antenna history, and health trend charts. One range selector (1h to 30d) in the first chart's header sets the period for all of them |
| Reader control (local readers) | Reader operations in three groups: Scanning (start, stop), Configuration (deploy), and Reader (refresh status, reboot) |
| Connection info (cloud readers) | Ingest endpoint URL, credentials, and operating mode config to copy into the reader's own web UI |
| Scan events | The latest ten scan events from this device, with View all opening the Scan Events list filtered to it |
| Ingest data | Server-paged tag reads and telemetry for this device, deep-linkable with ?tab=ingest. Includes a search box and the same Tag ID and Inventory columns as the Ingest History, but with no time filter, since it shows everything the retention policy has kept. Refreshed by the page header's Refresh button |
| Deploy logs (admins, local readers) | History of every operation run against the reader (deploys, start, stop, reboot, refresh, and more), labeled by an Operation column. Each row opens a detail page with the operation's steps and unsanitized request/response data for troubleshooting; the page has its own URL, so a specific one can be linked directly. Logs are retained for 30 days |
| Change history (View Audit Logs) | This device's entries in Change History, newest first |
GPS Position
An FXR90 has a built-in GPS receiver. When a reader reports positions, its detail page shows a GPS position section on the Overview tab with:
- Last known position: The coordinates. Select them to see the spot on a map, with a link to open it in OpenStreetMap. It reads "No position reported yet" until the reader reports one.
- Reported: When that position was reported.
The section appears for every FXR90, and for any other device that has reported a position. The Ingest data tab also gains a GPS column on the reader's tag reads (you can hide it with the grid's column picker), and each read's detail dialog has a GPS Position section.
To make an FXR90 report positions, turn on Include GPS position in its reader configuration and deploy. The reader needs its DC power supply (PoE and PoE+ switch its GPS off) and a GPS antenna with a view of the sky. See GPS Position in the Zebra FX guide for the requirements.
Check position
For an FXR90 that Tagnet reaches directly (not a cloud-managed reader), the section has a Check position button. It asks the reader for its current fix and shows the result as Current fix: the number of satellites in use, or No fix. Use it to confirm an installation: after fitting the antenna, wait a few minutes for the first fix and check again. When the reader has no fix, the section says why it is usually missing (a reader on PoE power, or an antenna without a view of the sky). If the check returns a fix newer than the stored one, it also updates the last known position.
A cloud-managed reader has no Check position button. Its last known position still updates from the GPS-stamped reads it sends, and a position is never replaced by an older one.
Reader Control
For locally-managed readers, the Reader control tab (also reachable directly from the row actions menu) lets you start scanning, stop scanning, deploy configuration, reboot, and refresh status. Deploy pushes whatever is currently saved under the reader's Reader configuration to the hardware: operating mode and antenna settings for Zebra FX readers, or the antenna, read-setting, filter, and trigger configuration for Impinj R700 readers. See Zebra FX Configuration and Impinj R700 Local Management for the settings each vendor supports.
A deploy runs in the background rather than holding the tab open: it keeps running if you navigate away, and reopening Reader control picks up live progress on whatever is currently running for that reader, whether you started it, a teammate did, or it's the first deploy from the setup wizard. Only one deploy can run per reader at a time; starting a second one, or saving a configuration change while one is running, is refused rather than queued.
If a deploy fails, whether during initial setup or a later redeploy, Tagnet's own record of the intended configuration is safe, since it was saved before the deploy ran. The reader itself is a different story: a deploy that stops partway through has already written some of its settings, so the reader may be running a partially applied configuration rather than either its old one or its new one. Deploy again to put it back in a known state. During first-time setup specifically, the failure dialog says so explicitly ("Reader saved, not yet deployed") so a failed first deploy doesn't read as "nothing was created." Retry from the same dialog, or deploy again later from Reader control once the underlying problem (network reachability, a rejected certificate, insufficient power, and so on) is resolved.
See Deploying Reader Configuration for the full deploy workflow: the prompt shown after saving configuration changes, what each deployment status chip means, and how deployment history is recorded.
When a reader misbehaves and you need help from support, an administrator can run Collect debug bundle from the Reader group on this tab. It runs like a deploy, gathers the reader's own log archives, recent deployment logs with credentials removed, and a snapshot of the reader's state into one zip, and changes nothing on the reader. See Collecting a Reader Debug Bundle.
Cloud-managed readers don't have a Reader control tab. Their detail page shows a Connection info tab instead, with the values you copy into the reader's own web UI. See Cloud Reader Setup.
Converting a Cloud Reader to Local Management
If a cloud-managed Zebra FX or Impinj R700 reader becomes reachable on your network, an admin can convert it to local management from its Connection info tab. Tagnet connects to the reader, verifies it's the same physical device (matching hostname for Impinj, MAC address for Zebra), and stores its admin login as the reader's credential for outbound control. The device keeps its history, ingest credentials, and existing configuration; nothing on the reader changes until you deploy afterward. Once converted, the reader's tab set switches from Connection info to Reader control. See Impinj R700 Local Management for the R700-specific walkthrough.
Activating and Deactivating Devices
Use Deactivate to take a reader out of service without deleting it. Inactive devices retain all of their history, credentials, and configuration, but:
- Incoming scan and telemetry data is discarded rather than stored, with a log entry on the device timeline recording that the device is still sending. Readers are answered normally and told the delivery succeeded, because a reader that is refused retries the same batch indefinitely and stops sending anything else. API clients posting on a user or API key still receive an explicit error.
- For a locally managed Impinj R700, Tagnet also stops the reader scanning and pauses its event delivery, so the reader goes quiet instead of reading into nothing. Reactivating resumes delivery and restarts scanning if the reader was running when you deactivated it. See Pausing Event Delivery
- The device is hidden from dashboard widgets by default
- The device does not count toward the licensed reader cap
- Configuration is read-only: Edit and Reader control are hidden from the row menu
If the reader is offline when you deactivate it, Tagnet saves the settings and applies them on the next deploy; until then its data is discarded on arrival.
An Inactive chip appears next to the device name on the grid and a yellow banner is shown on the device's detail page so the state is obvious at a glance.
To return a device to service, select Activate from the row menu, or from the Actions menu on the device's own detail page. That page's Actions menu always offers Activate/Deactivate (whichever applies) and Delete, even when the device is inactive, so you're never stuck needing to reactivate a device from anywhere but its own page. Only Edit requires an active device; the Reader control tab stays visible on an inactive device, but its start/stop/deploy/reboot buttons are hidden, since there's nothing to control on a reader Tagnet has stopped accepting data from.
Both actions write a security event so SOC 2 audit trails capture who activated or deactivated each device and when.
When to deactivate instead of delete: if you ever plan to bring the reader back, or if you need to keep the historical scan/telemetry record, deactivate. Delete is permanent and removes history.
Deleting a Device
Select Delete from the actions menu. A confirmation dialog shows the device name and how many scan events it recorded before permanent deletion. The device's scan events, tag reads, telemetry, and dashboard history are deleted with it. Devices that are read-only (based on scope restrictions) show a lock icon instead of action buttons.
A device cannot be deleted while a workflow uses it in its event conditions or a movement rule is triggered by it. The dialog names them; change or delete them first.
Best Practices
- Start from a recipe: Reader Setup Recipes gives starting-point reader and processing settings for portals, dock doors, conveyors, workstations, and cabinets or shelves.
- Use device groups: Group related readers (e.g., all readers at a loading dock) to share configuration. Choose By group in the search bar to manage them together.
- Set meaningful device types: Categorize devices by function (Dock Portal, Conveyor Reader) for quick identification.
- Monitor health regularly: The auto-refreshing grid makes it easy to spot degrading readers before they cause data gaps.
- Set the read point location: Give each reader (or its group) a location so a Move Inventory workflow action can land items where they were seen.
- Use cloud management when possible: Cloud-managed readers simplify deployment and connectivity management.
- Deactivate before retiring: When replacing or decommissioning hardware, deactivate the reader first. Wait until you're sure you no longer need its history before deleting.