Skip to main content

get_operating_mode

ReferenceAudience: API consumerUse: read back the reader's current RFID operating-mode configuration

Overview​

get_operating_mode reads back the reader's current RFID operating-mode configuration — the active profile, radio start/stop conditions, Gen2 query parameters, select pre-filters, armed access operations, and tag-metadata reporting flags — under operatingMode.operatingModes. It is read-only. It is a control-plane (CTRL) command — configure the mode with set_operating_mode.

This is a CTRL-endpoint command: it is published on the control endpoint (<tenantId>/CTRL/clients/cmnd/<serial>) and answered only there (not on the MGMT/MDM channel). Returning a response requires an active CTRL endpoint (configured with config_endpoint, epType: CTRL, activate: true). See Topic Mapping.

Details​

PropertyValue
Interaction PatternRequest / Response (app publishes a command; device publishes the correlated reply)
State ChangeREAD-ONLY
Required Request Fieldscommand, requestId (no other payload)
Applies ToEndpoint: Control (CTRL). Reader: RFD40 series, RFD90 series
API VersionV1.1 (API Version Reporting)
Relatedset_operating_mode, control_operation, config_endpoint, reboot

When to Use​

Use get_operating_mode to inspect or audit the reader's RFID configuration:

  • Before an inventory — confirm the profile, query parameters, and trigger conditions are what you expect.
  • After set_operating_mode — verify the mode was applied (there is no configuration echo on the set command's response).
  • After a reboot — the operating mode reverts to default on reboot (see the volatility note); read it back to confirm the current state.
  • Check reporting — see which tagMetaDataToEnable fields the reader will include on tag reads.

Topic Mapping​

MessageDirectionTopicNote
RequestApp → Reader<tenantId>/CTRL/clients/cmnd/<serial>On the control endpoint. Requires an active CTRL endpoint.
ResponseReader → App<tenantId>/CTRL/clients/resp/<serial>Correlated reply; the in-payload requestId links the twin topics.

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.

Unlike the MGMT commands, control commands are answered only on the CTRL endpoint — publishing get_operating_mode to the MGMT/MDM command topic produces no reply.

If no CTRL endpoint is active, add or activate one with config_endpoint (epType: CTRL, activate: true) before sending control commands. The requestId you send is echoed in the response.

See Topics and Channels.

Key Fields​

  • operatingMode.operatingModes.profiles (response) — the active profile (e.g. BALANCED_PERFORMANCE); ADVANCED surfaces advancedConfigurations.
  • query (response) — the Gen2 session / inventory-state / SL-flag / tag-population parameters driving inventory.
  • radioStartConditions / radioStopConditions (response) — the trigger semantics for starting/stopping inventory.
  • tagMetaDataToEnable (response) — which metadata fields (RSSI, EPC, TID, …) the reader reports on each tag read.
  • response.code (response) — read this to determine success vs failure. The contract requires it; note the reported success-path omission. See Response Codes.

Request Payload​

The request is a minimal envelope — just command (pinned to get_operating_mode) and requestId. There are no parameters.

Request payload
{
"command": "get_operating_mode",
"requestId": "abc123"
}

Response Payload​

On success the device returns the envelope (command, requestId, apiVersion, response) with the current mode under operatingMode.operatingModes. The device returns only the configured sub-objects — advancedConfigurations, accessOperations, and select appear only when configured. The Example tab shows a default BALANCED_PERFORMANCE read-back.

Response payload
{
"command": "get_operating_mode",
"requestId": "abc123",
"apiVersion": "V1.1",
"operatingMode": {
"operatingModes": {
"profiles": "BALANCED_PERFORMANCE",
"inventoryProtocol": "GEN2",
"radioStartConditions": {
"trigger": "IMMEDIATE",
"startDelay": 0,
"repeat": false
},
"radioStopConditions": {
"trigger": "IMMEDIATE"
},
"query": {
"session": "SESSION_1",
"inventoryState": "STATE_A",
"slFlag": "ALL",
"tagPopulation": 30
},
"tagMetaDataToEnable": {
"RSSI": true,
"PHASE": false,
"SEENCOUNT": true,
"CHANNEL": false,
"PC": false,
"XPC": false,
"CRC": false,
"EPC": false,
"TID": false,
"USER": false,
"MAC": false,
"HOSTNAME": false
}
}
},
"response": {
"code": 0,
"description": "Success"
}
}

The contract requires response.code. Readers have been reported to omit it on a successful reply, returning just response: { "description": "Success" } — treat that as success too. See Success without a code.

As reported, a successful read can arrive with code omitted — the same envelope and operatingMode payload. This form does not validate against the contract; the reply with code: 0 above is the documented form. The mode object is abridged here:

Response — success reported without code (not accepted by the contract; operatingMode abridged)
{
"command": "get_operating_mode",
"requestId": "abc123",
"apiVersion": "V1.1",
"operatingMode": {
"operatingModes": {
"profiles": "BALANCED_PERFORMANCE"
}
},
"response": {
"description": "Success"
}
}

Response Semantics​

  • The read-back masks access passwords. When access operations are armed, get_operating_mode returns their structure but echoes config.password as empty ("") — the stored credential is never returned. The real password is carried only in the set_operating_mode request (mask it there). A default read-back has no accessOperations at all.
  • FAST_READ is enumerated but not supported. The profiles enum lists FAST_READ, but it is currently not supported by the firmware (per the schema's own description). Use CYCLE_COUNT, DENSE_READERS, OPTIMAL_BATTERY, BALANCED_PERFORMANCE, or ADVANCED.
  • Conditional sub-objects. advancedConfigurations appears only when profiles is ADVANCED; accessOperations and select appear only when configured. A default read-back typically returns just profiles, inventoryProtocol, radioStartConditions, radioStopConditions, query, and tagMetaDataToEnable.

Response Codes​

get_operating_mode 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
0Success — the operating mode was retrieved.
3Not able to retrieve information (IOT_ERROR_INFO_NOT_AVAILABLE) — the device could not gather the operating mode at this time. Retry after a short delay; if persistent, reboot.
101Default error — generic catch-all.

The contract requires response.code; readers have been reported to omit it on success — see Success without a code.

Examples​

Publish get_operating_mode over the CTRL endpoint (with an active CTRL endpoint); the device replies with the snapshot shown under Response Payload. There are no request variants — the command takes no parameters.

Notes and Caveats​

  • Operating mode is volatile. The operating mode resets to default (BALANCED_PERFORMANCE, armed accessOperations cleared) on reboot. Read it back after a reset to confirm the current state; re-apply with set_operating_mode if you were relying on a non-default configuration.

Read get_operating_mode to confirm the reader's RF configuration before running an inventory with control_operation, and to verify a change applied by set_operating_mode. For the concept-level view, see Operating Mode.

Related: 📕 set_operating_mode · 📕 control_operation · 📕 config_endpoint · 📕 reboot · 📕 Response Codes

Was this helpful?