Skip to main content

get_wifi

ReferenceAudience: API consumerUse: read the reader's saved Wi-Fi profiles and connection status

Overview​

get_wifi retrieves the Wi-Fi profiles saved on the reader together with their current connection status and configuration. The response is a list (wifiProfiles.wifiConfig[]) of profiles; each describes the wireless interface, the associated access point (ESSID, security type, connection status), the IPv4/IPv6 addressing, and a securityDetails block keyed by the security type (WPA2Personal, WPA3Personal, WPA2Enterprise, WPA3Enterprise). It is a read-only query on the device-management (MGMT) endpoint.

The device masks stored credentials — passwords, passphrases, and identities are returned as a mask, never the real secret. Use get_wifi to verify which SSID a reader is connected to and confirm its addressing before relying on the wireless uplink.

Details​

PropertyValue
Interaction PatternRequest / Response (app publishes a command; device publishes the correlated reply)
State ChangeREAD-ONLY
Required Request Fieldscommand, requestId
Applies ToEndpoint: Management (MGMT). Reader: RFD40 series, RFD90 series
API VersionV1.1 (API Version Reporting)
Relatedset_wifi, delete_wifi_profile, get_eth

When to Use​

Use get_wifi when you need to verify the reader's wireless configuration — during commissioning, a connectivity check before inventory, or a fleet audit of which SSID each device is on.

  • Confirm the connection: check accessPoint.status (CONNECTED?), accessPoint.essid (correct network?), and accessPoint.isPreferred.
  • Validate security: check accessPoint.securityType matches the AP; the matching securityDetails block shows the (masked) credential/protocol configuration.
  • Validate addressing: check ipv4Configuration.ipAddress, gateway, and enableDhcp to confirm the reader has a working route to the broker / back-end.

Topic Mapping​

MessageDirectionTopicNote
RequestApp → Reader<tenantId>/MGMT/clients/cmnd/<serial>On the management endpoint.
ResponseReader → App<tenantId>/MGMT/clients/resp/<serial>Correlated reply to the request above; 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.

Credentials are presented once at CONNECT. The requestId you send is echoed in the response so you can pair reply to request. The endpoint's mqttParams govern QoS and retain, not this command.

See Topics and Channels.

Key Fields​

  • requestId (request) — your correlation token; make it unique per request. The device echoes it in the response so you can pair reply to request.
  • wifiProfiles.wifiConfig[] (response) — the array of saved profiles; iterate it to find the connected one.
  • …accessPoint.status / essid (response) — the association state and network name of each profile.
  • …accessPoint.securityType (response) — selects which securityDetails key is populated.
  • …ipv4Configuration.ipAddress (response) — the DHCP-assigned address the reader uses to reach the broker.
  • response.code (response) — read this to determine success vs failure (see Response Codes).

Request Payload​

The request envelope is just command and requestId — there is no payload wrapper. Use the Schema tab for the field reference and the Example tab for a ready-to-send, copy-pasteable request.

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

Response Payload​

The response envelope is command, requestId, apiVersion, response, and a wifiProfiles object whose wifiConfig is the array of profiles. On the Schema tab, expand wifiProfiles → wifiConfig → interfaceDetails (and its accessPoint, ipv4Configuration, ipv6Configuration, securityDetails sub-objects) to see every field. Within each profile's interfaceDetails, only interfaceName, hostname, and macAddress are required; the interface-level status is optional. securityDetails carries only the key matching accessPoint.securityType, with secrets masked. The Example tab shows a WPA2-Personal profile; enterprise variants are in Examples.

Response payload
Example: WPA2-Personal
{
"command": "get_wifi",
"requestId": "abc123",
"apiVersion": "V1.1",
"wifiProfiles": {
"wifiConfig": [
{
"interfaceDetails": {
"interfaceName": "wlan0",
"status": "",
"hostname": "RFD40-211545201D0034",
"macAddress": "AC:3F:A4:00:2B:15",
"accessPoint": {
"essid": "IOT_TESTAP",
"status": "CONNECTED",
"securityType": "WPA2Personal",
"isPreferred": false,
"autoConn": false
},
"ipv4Configuration": {
"ipAddress": "192.168.0.110",
"subnetMask": "255.255.255.0",
"gateway": "192.168.0.1",
"enableDhcp": true,
"dnsServer": "192.168.0.1",
"domainName": "zebra.com"
},
"securityDetails": {
"WPA2Personal": {
"password": "XXXXXXXX"
}
}
}
}
]
},
"response": {
"code": 0,
"description": "Success"
}
}

Response Semantics​

  • Credentials are masked. The device returns stored passwords, passphrases, and identities as a mask (never the real secret). Treat every credential field in the response as opaque — you cannot read back the actual value with get_wifi.
  • Security type selects the credential block. securityDetails contains only the one key that matches accessPoint.securityType — WPA2Personal / WPA3Personal (a single password) or WPA2Enterprise / WPA3Enterprise (EAP authentication, optional innerAuthentication / identity / anonymousIdentity, a certificate array, and a protocol).
  • ipv6Configuration is schema-defined but not returned by the current firmware.
  • Wi-Fi-disabled response shape. When Wi-Fi is disabled, the contract's own example returns the profile under a top-level wifiConfig object (rather than wifiProfiles.wifiConfig[]), carrying only interfaceName, status (Disabled), hostname and macAddress. The response schema does not declare a top-level wifiConfig, so parse both shapes; the connected shape documented here is wifiProfiles.wifiConfig[].

Response Codes​

get_wifi 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 — Wi-Fi profiles retrieved and returned.
3Not able to retrieve information (IOT_ERROR_INFO_NOT_AVAILABLE) — the device could not gather the Wi-Fi configuration at this time. Retry after a short delay; if it persists, reboot the device.
101Default error — generic catch-all.

For the full code list see the Response Codes. (Code 20, Wifi is not supported, applies to the Wi-Fi setter set_wifi, not to get_wifi.)

Examples​

get_wifi is a single request/response exchange. Publish the standard {command, requestId} request shown under Request Payload; the device replies on the response topic with the correlated reply — the requestId you send (abc123) is echoed back so you can pair reply to request. The Connection scenario dropdown under Response Payload shows each contract example:

  • WPA2 Personal connection — a single masked password.
  • WPA2 Enterprise connection — an EAP authentication method, a certificate array of {key, value} references and a protocol, with credentials masked.
  • WPA3 Enterprise connection — additionally innerAuthentication, identity and anonymousIdentity, and a WPA3 protocol suite.
  • WiFi interface disabled — the minimal reply for a disabled interface.

Notes and Caveats​

get_wifi is a read-only getter — safe to poll during commissioning or troubleshooting. Configure profiles with set_wifi / delete_wifi_profile; for the concept-level view, see Network Configuration. Enterprise profiles depend on installed certificates — see TLS and Authentication.

Related: 📕 Network Configuration · 📕 get_eth · 📕 Network and Connectivity · 📕 Response Codes

Was this helpful?