Skip to main content

reboot

ReferenceAudience: API consumerUse: perform a warm reset of the reader

Overview​

reboot performs a warm reset of the reader. It requires only command and requestId. The device accepts the request (response.code 1), reboots, and then auto-reconnects to the previously-connected server — no manual reconnect needed. It is a state-changing command on the device-management (MGMT) endpoint.

reboot is session-severing — the reply is code 1 ("Command payload is accepted"), returned before the reset, and the control session drops for ~30 s–2 min. See the warning in Notes and Caveats.

Details​

PropertyValue
Interaction PatternAsynchronous Request → Accept → Warm reset → Auto-reconnect
State ChangeSTATE-CHANGING (warm reset; clears volatile state)
Required Request Fieldscommand, requestId (no other payload)
Applies ToEndpoint: Management (MGMT). Reader: RFD40 series, RFD90 series
API VersionV1.1 (API Version Reporting)
Relatedset_os, get_version, get_status, control_operation

When to Use​

Use reboot to warm-reset the reader:

  • Recover from a bad state — clear a transient fault when a targeted command will not.
  • Apply/settle changes that take effect on restart.
  • Clear the operating mode — a reboot resets the operating mode to default (see the volatility note below).

Do not reboot during an active RFID inventory — the device refuses with code 5. Stop the inventory first with control_operation.

Topic Mapping​

MessageDirectionTopicNote
RequestApp → Reader<tenantId>/MGMT/clients/cmnd/<serial>On the management endpoint.
ResponseReader → App<tenantId>/MGMT/clients/resp/<serial>The code 1 accept, returned before the reset. Correlated by the in-payload requestId.

Topics follow the pattern <tenantId>/<topic>/<serial> — the tenant id assigned to you at provisioning (a slot you fill in, never a literal), the base topic you configure on the endpoint, and the reader's serial number, which the reader appends itself in its model-prefixed form (for example RFD40-212735201D0053). App → Reader means your app publishes and the reader subscribes; Reader → App means the reader publishes and your app subscribes.

reboot carries no credential field — there is nothing to mask. The requestId you send is echoed in the accept so you can pair reply to request.

See Topics and Channels.

Key Fields​

  • command / requestId (request) — the entire request; there is no reboot payload.
  • response.code (response) — 1 means accepted (the reset then proceeds); 5 means the device refused the reboot because an inventory is running. See Response Codes.

Request Payload​

The request is a minimal envelope — just command and requestId.

Request payload
{
"command": "reboot",
"requestId": "123abcd"
}

Response Payload​

The reply is an accept — command, requestId, apiVersion, and response with code 1, returned before the reset begins.

Response payload
Example: accept
{
"command": "reboot",
"requestId": "123abcd",
"apiVersion": "V1.1",
"response": {
"code": 1,
"description": "Command payload is accepted"
}
}

Lifecycle​

A single reboot drives the device through a clean warm-reset cycle.

Acknowledgment​

The device replies response.code 1 ("Command payload is accepted"), before it resets. This is the success-ack — there is no later "reboot complete" message on success. If the reboot fails, the device sends a failure notification.

Session Impact​

  • Down — the reader drops its MQTT connections and warm-resets. It is unreachable for the duration.
  • Auto-reconnect — the device auto-reconnects to the previously-connected server on its own, with no manual intervention. Recovery time varies (observed ~44 s and ~110 s across two runs — roughly ~30 s to ~2 min); do not hard-code a fixed wait.

Persistence​

State after reset:

  • Endpoint configuration persists — saved and active endpoints are restored/re-activated across the reset.
  • Operating Mode is volatile — the reboot resets the operating mode to default (e.g. BALANCED_PERFORMANCE, any armed accessOperations cleared). See set_operating_mode; this is the documented "on reboot the set configuration is lost" behavior.

Response Codes​

reboot returns response.code. The codes applicable to this command are below; for the full table see the Response Codes and Correlation and Request/Response Pairing.

CodeDescription
1Command payload is accepted (IOT_STATUS_CMD_PAYLOAD_ACCEPTED) — the reboot success-ack, returned before the reset. The device then reboots and auto-reconnects.
0Success — the generic success code; in practice reboot acks with 1, not 0.
5Can't reboot device, inventory in progress (IOT_ERROR_IN_REBOOT_INVENTORY_IN_PROGRESS) — unique to reboot; the device refuses the reset while an RFID inventory is running. Stop the inventory with control_operation, then retry.
101Default error — generic catch-all.

Code 1 is the acceptance ack, not a reboot-only code. The contract scopes code 1 ("Command payload is accepted") to reboot, set_os and install_certificate alike, and scopes code 5 to reboot alone. Accept 0 and 1 as success-equivalents here.

Examples​

Publish reboot; the device replies with the code 1 accept under Response Payload, then runs the reboot cycle. If an inventory is active, the device refuses the reset with code 5:

Response — refused during inventory (code 5)
{
"command": "reboot",
"requestId": "123abcd",
"apiVersion": "V1.1",
"response": {
"code": 5,
"description": "Can't reboot device, inventory in progress"
}
}

Notes and Caveats​

Session-severing — send once, never auto-retry

The warm reset drops the control session; the device auto-reconnects to the previously-connected server, but recovery time varies (~30 s–2 min observed). Because a reboot cannot be un-done and interrupts service, issue it deliberately (ideally after operator confirmation) and never auto-retry it — the reboot may already have taken effect even if the accept was lost.

  • Endpoint config persists; operating mode does not. Across the reset, saved and active MQTT endpoints are restored and re-activated, but the operating mode reverts to default (any tuned profile or armed accessOperations is cleared). Re-apply the operating mode after a reboot if you were relying on a non-default configuration — see set_operating_mode.

Sequence a reboot as: (optionally) stop any inventory with control_operation → send reboot once → wait out the reconnect (poll, do not hard-code the delay) → confirm with get_version / get_status. For the concept-level view, see Device Lifecycle and Broker Connection.

Related: 📕 Device Lifecycle · 📕 set_os · 📕 get_version · 📕 control_operation · 📕 Response Codes

Was this helpful?