Client journey
wifi.client_journey tells one wireless client’s story in time order, oldest
first: when it joined, was authorised, roamed, got an IP address, failed to
authenticate or connect, and disconnected, then where it is connected now. It is
read-only and open to every role. Ask Claude something like “why does the
laptop aa:bb:cc:dd:ee:ff keep dropping off the Wi-Fi?”, or pick A client’s
journey from Claude’s + menu.
How much can it show without streaming?
Section titled “How much can it show without streaming?”Without Northbound streaming, the journey holds only IP updates, recently
ended sessions and the current connection. Northbound streaming is not
available on the hosted service yet, so on the hosted service this is what you
get, and the result says so in notes.
The journey merges two kinds of source:
| Source | Holds | Needs streaming |
|---|---|---|
The controller’s current client list (POST /query/client) | Where the client is connected now: AP, SSID, RSSI, SNR, VLAN, IP | No |
The controller’s REST event log (POST /alert/event/list) | For clients, only IP-learned events (code 236) | No |
The controller’s historical clients (POST /query/historicalclient) | Ended sessions, which SmartZone keeps for only a few hours | No |
| Streamed events | Joins (202), disconnects with their reason (204), roams (209, including a band steer on the same AP) and IP learned (236) | Yes |
| Streamed association steps | New, associated, authorised and ended, with byte counts | Yes |
| Streamed connection diagnostics | Failed attempts with their reason, such as a wrong passphrase. Also needs apHccdEnabled on the AP’s zone | Yes |
So without streaming there are no joins, roams, disconnects or authentication failures, and an empty journey for yesterday is not proof the client was never there.
Arguments
Section titled “Arguments”Give either mac or text.
| Argument | Default | Notes |
|---|---|---|
mac | — | The client’s MAC, in any case or format |
text | — | A hostname, IP or user name. It must match exactly one client connected now; an earlier client needs its MAC. At least 2 characters |
sinceHours | 24 | How far back to look: 0.25 to 336 (14 days) |
limit | 200 | Steps returned, 1–1,000. When there are more, the newest are kept and truncated: true is set |
What comes back
Section titled “What comes back”| Field | Contents |
|---|---|
mac, window | The client and the from/to of the look-back |
summary | joins, roams, bandSteers, disconnects, authFailures, ipUpdates, the aps, ssids and ips it used, and connectedNow |
steps | [{ time, kind, source, what, ap, apName, ssid, band, rssi, ip, code }], oldest first. source is stream or api |
sources | How many rows each source gave, or stream: "off" |
notes | Present when something limited the answer: streaming off, no connection diagnostics, a capped source |
errors | Present when one of the controller reads failed; the rest of the journey is still returned |
A step’s kind is one of join, authorised, roam, ip, auth_failure,
connect_failure, disconnect, session, session_ended, event or
connected_now. Identical steps in a row are folded into one, with repeated
and lastTime: the REST log repeats code 236 on every DHCP renewal.
The REST event log is read up to 1,000 rows for the client; past that, the oldest are left out and a note says so.
Errors
Section titled “Errors”error | Meaning |
|---|---|
bad_mac | mac is not a MAC address. Use text for a name or IP |
bad_request | Neither mac nor text was given |
not_found | No client connected now matches text. An earlier client needs its MAC |
ambiguous | More than one client matches text. candidates lists up to 20 (MAC, hostname, IP, SSID, AP); call again with one MAC |
client_query_failed | The controller refused the lookup of text; status and detail say why |