Deploying Reader Configuration
Part of: Devices — deploying configuration changes to locally-managed readers and tracking whether a reader is actually running what Tagnet has stored.
For a locally-managed reader (Impinj R700 or Zebra FX/ATR), saving changes under a reader's Reader configuration section only updates what Tagnet has stored. It does not, by itself, change anything on the hardware. Deploying is the separate step that pushes that stored configuration to the reader: antennas, power, filters, triggers, and everything else in that section.
This guide covers what happens when you deploy, how to tell whether a reader is running the configuration Tagnet has on file, and what to do when a deploy doesn't finish cleanly.
Note: None of this applies to cloud-managed readers. Because Tagnet can't reach a cloud-managed reader directly, there's nothing for Tagnet to deploy: you re-apply configuration changes yourself through the reader's own web UI. See Cloud Reader Setup.
The Deploy Prompt
Edit a locally-managed reader's configuration and click Update, and Tagnet offers to deploy the change, explaining that the reader is running its previous configuration until the change is deployed, that deploying runs in the background, and that a currently-scanning reader will be stopped and restarted automatically as part of it.
- Deploy now starts the deploy right away.
- Later saves the change in Tagnet and leaves the reader running its previous configuration until you deploy it yourself, from the reader's Reader control tab.
Either way, you're returned to wherever you came from, not held on a progress screen. The prompt applies to both Impinj R700 and Zebra FX/ATR readers. On a Zebra reader it also names which deploy it will run and why, for example Deploy operating mode: operating mode settings changed. See Choosing a Deploy on Zebra Readers.
The first deploy offered right after creating a local reader, at the end of the setup wizard, uses this same background mechanism. See Impinj R700 Local Management.
Choosing a Deploy on Zebra Readers
A Zebra reader (FX7500, FX9600, FXR90, ATR7000) holds its configuration in three places, and each is written by a different part of a deploy:
| Scope | What it covers | Written by |
|---|---|---|
| Operating mode | Mode type, antennas, transmit power, environment, tag metadata, report filter, radio and antenna stop conditions, Gen2 query and selects, the tag filter, and on the ATR7000 the directionality settings and zone names | The operating-mode step |
| Reader | Heartbeat interval, management event flags and thresholds, GPIO LED, cable loss per port | The reader configuration step |
| Endpoint | The address the reader posts to, the ingest credential, tag data batching and retention | The endpoint steps: the reader is disconnected from its cloud session, the endpoint rewritten, and the reader reconnected |
The endpoint steps are the slow part. An FX leaves the cloud in a few seconds, but an ATR7000 can take minutes to disconnect, and most edits never touch the endpoint at all. So Tagnet tracks which scopes each saved change needs and runs the smallest deploy that covers them.
The Reader control tab has one Deploy button. Its main action is the deploy Tagnet recommends for what is pending, labelled with what it will run, and the caption under it says why. The arrow beside it offers all three:
| Option | What it does | Usual time (FX / ATR7000) | When Tagnet recommends it |
|---|---|---|---|
| Operating mode only | Stops the radio, rewrites the operating mode, starts the radio again. The reader configuration and endpoint are not touched. | about 15 s / about 30 s | Only operating mode settings are pending |
| Configuration (skip endpoint) | Rewrites the operating mode and reader configuration. The endpoint is not touched, so the reader stays on its cloud session. | about 30 s / under a minute | Reader settings are pending (with or without operating mode settings), nothing endpoint-side is, and the endpoint has been deployed before |
| Full configuration (rewrite endpoint) | Disconnects the reader, rewrites the endpoint and reconnects, then rewrites the operating mode and reader configuration. | about a minute / about 3 minutes | Endpoint settings are pending, the endpoint has never been deployed, or nothing is pending and you want the reader in a known state |
Each menu entry shows the usual time for the reader's model. These are typical lab figures; the Duration column on the Deploy logs tab has the real number for each run.
Each menu entry says what it does and, when something is pending, whether it covers it or what it would leave behind. You can always pick a different option than the recommended one: choosing Operating mode only while an endpoint change is pending is allowed, and the endpoint change simply stays pending.
A full deploy also decides for itself whether the endpoint steps are needed. When nothing endpoint-side has changed since the endpoint was last written to the current ingest address, Cloud Disconnect, Telemetry Endpoint Configuration and Cloud Reconnection show as skipped in the step list, with the reason. Connection Verification is skipped with them when the reader was connected throughout: that step proves a reconnection worked by waiting for a fresh heartbeat, and with no reconnection it would only wait out its minute while the reader keeps its existing heartbeat cadence. Anything that touches the endpoint still verifies. They always run for a reader whose endpoint has never been deployed, one the readiness check finds not enrolled, or one whose Tagnet ingest address has moved since the endpoint was written. Full configuration (rewrite endpoint) forces them to run.
The ingest credential travels in the endpoint, so regenerating a reader's inbound password is an endpoint change and needs the full deploy. The ingest address itself comes from Tagnet's hosting configuration rather than a save, so a reader's Refresh status compares the address the reader was last sent with the current one and records an endpoint change when they differ.
Deploying to an FXR90
An FXR90 deploys the same way from your side: the same three options, the same recommendations, and the same configuration. The difference is in the deploy log. The Cloud Readiness Check, Cloud Enrollment, Cloud Disconnect and Cloud Reconnection steps do not appear, because the FXR90 takes its ingest endpoint over its REST API and has no cloud session to drop and restore.
- Telemetry Endpoint Configuration writes the data endpoint and routes heartbeats to Tagnet, then waits briefly for the reader's connector to restart.
- The endpoint write replaces any data or management connection configured on the reader by hand. The deploy log names what it replaced, so check it if the reader was previously sending data somewhere else.
- Connection Verification checks the reader's own interface status rather than a cloud session.
Note: The FXR90 serves HTTPS only on port 443, and port 80 is closed. Discovery detects this and fills in the address for you. If you add the reader by manual address, enter
https://<address>. See The Address Field.
Impinj R700 readers have a single deploy and are not affected by any of this.
Deploys Run in the Background
Accepting the prompt (or clicking Deploy from the Reader control tab) hands the deploy to a background process and does not tie it to your session. An Impinj R700 deploy typically takes a few seconds; a full Zebra FX deploy takes about a minute. A full ATR7000 deploy takes about three minutes, most of it spent waiting for the reader to leave the cloud and restart its directionality application. If the reader is already scanning, the radio is stopped for the deploy and restarted automatically, but only once the deploy finishes successfully. A deploy that fails partway through does not restart it: see Failed below.
Because the deploy runs independently of your browser session, navigating away, or even closing the tab, no longer abandons it. To watch a deploy's progress, open the reader's Reader control tab. It picks up whatever is currently running for that reader and shows live, step-by-step progress, whether that deploy is:
- one you just started from the edit page,
- one someone else on your team started,
- or the first deploy started from the reader creation wizard.
Deployment Status
Because a deploy no longer requires anyone to sit and watch it, Tagnet tracks each reader's deployment status persistently and surfaces it in two places:
- The Devices list has a Last deployed column. If you don't see it, check it hasn't been hidden: see Column Selection.
- A reader's own detail page shows an alert when the last deploy failed or there are undeployed changes.
Both are visible to every user with access to the reader, not just the one who made the change, and both survive a page refresh.
| What you see | Meaning | What to do |
|---|---|---|
| A timestamp (e.g. "2 hours ago") | The last deploy succeeded, and no configuration has changed since | Nothing |
| Deploying | A deployment is running right now | Wait, or open Reader control to watch it |
| Failed | The last deployment did not finish | Deploy again |
| Changes pending | Configuration was saved in Tagnet but has not been deployed | Deploy from Reader control |
| Interrupted | A deployment started but never reported back | Deploy again |
| Never | No configuration has ever been deployed to this reader | Deploy from Reader control, or the setup wizard |
Deploying
The reader's Status column also reads Deploying during this time, and outranks every other status, including Unresponsive: a deploy stops and restarts the radio, so the reader briefly looks unreachable, and reporting "Unresponsive" right when Tagnet knows exactly why would be misleading.
Failed
A deploy pushes its settings to the reader in a sequence of steps (authentication, region, webhook, preset, and so on). If it fails partway through, some of those settings have already been written. Neither "the reader kept its old configuration" nor "the reader took the new one" is a safe assumption: the reader may be running a partially applied configuration. Deploying again is the way to put it back in a known state, since the next deploy pushes the complete configuration from scratch regardless of where the previous attempt stopped.
If the reader was scanning when the deploy started, a failure can also leave its radio stopped. Stopping the radio happens partway through the sequence, and starting it again is one of the last steps, so a failure anywhere in between means nothing runs to bring it back up. Tagnet does not restart it for you: check the reader's Status after a failed deploy, and start it again from Reader control if it's sitting Idle.
Admins can see exactly which step failed on the reader's Deploy logs tab; each row links to a detail page with the failed step and unsanitized request/response data. The steps after the failure are still listed, but greyed out and empty, with nothing to expand: they never ran, rather than running against a reader whose configuration is already known to be incomplete.
A failed deploy almost always leaves undeployed changes too, since the configuration Tagnet has on file was never fully applied. Tagnet reports both facts together rather than showing a generic "changes pending" chip that undersells what actually happened.
Changes pending
This means the reader is still running its previous configuration: something was saved in Tagnet but never deployed. It appears whether you declined the deploy prompt, closed the tab before deciding, or someone else has changed the configuration and not yet deployed it. It doesn't go away on its own: it clears only when a deployment that covers the change succeeds.
On a Zebra reader, "covers" is per scope. An operating-mode deploy clears the signal when operating mode settings were all that changed; if an endpoint change was also pending, the signal stays and the reader's detail page says what is still to deploy, for example Still to deploy: endpoint settings. A full deploy that skipped the endpoint steps clears the operating mode and reader scopes and leaves an endpoint change pending. See Choosing a Deploy on Zebra Readers.
Because it's visible to every user on the Devices grid and the reader's own page, not just the one who made the change, it functions as a shared signal that a reader's hardware configuration is stale, useful when more than one person can edit the same reader.
Interrupted
A deployment started but never reported a result, most often because Tagnet itself restarted while the deploy was running. Tagnet ages an in-progress deploy out of the Deploying state after several minutes rather than leaving it stuck there forever; past that point it shows as Interrupted. As with a failed deploy, run it again to be sure of the reader's actual configuration.
One Deploy at a Time
Tagnet allows only one configuration deploy per reader at a time. Starting a second deploy for a reader that already has one running is refused, with a message naming what's already running and, if known, who started it.
Saving configuration changes for that reader is refused the same way while a deploy is in flight: "A deployment is running for this reader. Wait for it to finish before changing the configuration."
This exists because a successful deploy writes the configuration it just pushed back into Tagnet's own record. A configuration edit saved while that write-back is in progress would be overwritten and silently lost the moment the deploy finished. Other edits to the device, such as its name, device type, or group, are not affected and can still be saved while a deploy is running.
Start, stop, reboot, and refresh operations are not subject to this lock: only configuration deploys (a full deploy or, on Zebra readers, an operating-mode-only deploy) are exclusive per reader.
Deploy Logs and the Operation Column
The Deploy logs tab (admins only, on a reader's detail page) records every reader operation, not just deploys. Its Operation column distinguishes:
| Operation | What ran |
|---|---|
| Deploy configuration | A full configuration deploy, including the endpoint rewrite |
| Deploy configuration (endpoint skipped) | Zebra-only: the full pipeline with the endpoint steps skipped, because nothing endpoint-side had changed or you chose Configuration (skip endpoint) |
| Deploy operating mode | Zebra-only: a shorter deploy that rewrites just the operating mode |
| Start | Started the reader's radio |
| Stop | Stopped the reader's radio |
| Reboot | Restarted the reader |
| Refresh status | Re-synced Tagnet's view of the reader without changing anything on it |
| Factory reset | Zebra-only: restored factory defaults |
| Event delivery | Turned the reader's event webhook on or off |
Only the three deploy operations move the reader's Last deployed timestamp and deployment status. Starting, stopping, rebooting, or refreshing a reader's status leaves those alone: a status refresh isn't a deployment, and showing it as one would make "Last deployed" meaningless as a signal that the reader is actually running current settings.