Floorplans and floor maps

The Floorplan feature shows you where every AP and switch sits on a venue floor, measured in real metres, and tells you what is wrong with the layout. RUCKUS One knows where each device is on a plan and how the plan is calibrated, but never puts the two together. R1-MCP does: “AP-Lobby and AP-Cafe are 3.2 m apart and both on channel 36” is the kind of answer you get.

The findings in text are the deliverable; the picture is the attachment. Claude reads the findings — unplaced APs, APs left at (0,0), pairs closer than 6 m, APs more than 40 m from any neighbour, a plan with no scale — and the map is how you confirm them by eye.

How do I turn it on?

Floorplan is a generally available feature, so there is no password. Turn on Floorplan Mapping in the Features section of the dashboard. That adds two tools, get_floorplan and floorplan_map, and a Floor Map link in the dashboard navigation.

As with every feature, the tools appear in new Claude conversations, not in one that is already open.

What can I ask?

“Audit the AP placement on level 3 of the HQ venue.”
“Which APs on this floor share a channel, and are they actually close?”
“Show me the roaming on the ground floor over the last 24 hours.”
“What would we lose if the AP by the lifts failed?”

Placement audits and co-channel checks need nothing but the floor itself. Client, roaming and coverage questions use layers drawn over the floor.

Reading a floor: `get_floorplan`

get_floorplan reads a floor and returns it as data: the plan, its image metadata, its metric scale, and every AP and switch resolved to a position. Call it with just a venueId to list the venue’s plans (id, name, floor number, and whether a scale is set).

Parameter	Default	What it does
`venueId`	required	The venue. Alone, it lists the venue’s floorplans
`floorplanId`	—	One plan by id. With only one plan in the venue you can omit it; with several, omitting it returns the list
`name`	—	Select a plan by exact name (case-insensitive)
`floorNumber`	—	Select a plan by floor number
`includeDevices`	`true`	Resolve AP and switch positions. `false` returns just the plan, its image and its scale
`includeSwitches`	`true` (with devices)	Include placed switches
`floorWidthMeters`	—	Real width of the plan in metres, used only when R1 has no scale. Gives a low-confidence frame; never overrides a scale R1 has
`refreshImage`	—	Re-fetch the plan image from R1 instead of the stored copy
`connection`	—	Which saved connection to read, by label or id

Positions come back as percentages of the image, 0–100, origin top-left — that is how R1 stores them. The scale block converts them to metres.

Neither tool writes. Uploading a plan, setting its scale or moving an AP is done in RUCKUS One, or by Claude through the ordinary R1 API with call_r1.

Rendering a floor: `floorplan_map`

floorplan_map draws the floor and returns the findings. The map arrives as a real image Claude can look at, plus an ASCII grid traced from the same plan, so the building outline survives even in a client that drops images.

Parameter	Default	What it does
`venueId`	required	The venue
`floorplanId` / `name` / `floorNumber`	—	Which plan; with several plans and none named, you get the list
`layers`	`["aps"]`	What to draw — see Floor map layers
`format`	`["image","ascii"]`	Any of `image`, `ascii`, `svg`. SVG is vector markup returned as text
`width`	`1000`	Render width in pixels, capped by the pixel budget
`asciiCols`	`72`	Columns in the ASCII grid
`inline`	`false`	Embed the plan image inside the SVG. Costly — those bytes are read as text
`includeSwitches`	`true`	Draw placed switches. `false` skips the switch query and reports no switch count at all, rather than zero
`legend`	`true`	Draw the legend panel on the SVG. The legend entries are returned either way
`refreshClients`	`auto`	Client data freshness: `auto` re-queries R1 when the cached snapshot is over 2 minutes old, `force` always re-queries, `cache` never calls R1
`coverageBand`	5 GHz	Band for the predicted layers: `2.4g`, `5g` or `6g`
`roamWindow`	`24h`	Look-back for the roam layers: `1h`, `6h`, `24h`, `7d` or `30d`
`roamMode`	`signal`	How roam arrows are coloured: `signal` or `fastroam`. The findings are the same either way
`roamClient`	—	A client MAC, for the one-client roam trail
`lbsClient`	—	A device MAC, for the `heardBy` layer
`floorWidthMeters`, `refreshImage`, `connection`	—	As for `get_floorplan`

APs are circles and switches are squares, so the two are told apart by shape as well as colour. Markers are lettered A, B, C… in reading order, and the letters stay the same between renders, so “AP C” means the same AP next time.

What will it refuse to tell me?

Each of these is a real limit of R1’s data. A floorplan tool that ignored them would produce an answer that looks right and isn’t.

No metric scale, no metres

If the plan has no usable calibration in R1, the scale comes back as { ok: false, reason } and no distance is reported at all — never a guessed one. The audit becomes topological: which APs are placed, not how far apart they are. The predicted coverage layers refuse outright, and co-channel pairs are listed as unconfirmable.

The one way round it is floorWidthMeters: tell Claude how wide the floor really is, and it builds a low-confidence frame from that. The better fix is to calibrate the plan in RUCKUS One.

Connected clients are not drawn as dots

R1 has no client coordinates, so there is nowhere honest to draw an associated client. Instead, connected clients appear as a count badge on each AP, a per-AP table, and a roster with one row per client (MAC, hostname, AP, SSID, band, signal and age). A dot is drawn only for a client whose position was actually measured, and that needs a location source most venues don’t have.

No distance from a signal

Every metre on a floor map comes from the plan’s own calibration. RUCKUS One exposes no measured AP-to-AP signal, so nothing here estimates a distance or a position from signal strength, and there is no automatic AP placement.

Assigned is not placed

R1 can report an AP as belonging to a floorplan without ever having been dragged onto it. Such APs are returned as unplaced, with a reason — no coordinates, unassigned, on another floorplan, or out of range. A floor whose APs are all unplaced reads as “12 APs, none placed”, never as an empty floor. The Floor Map page lists them under Assigned but not placed.

Two signal scales that never mix

Client signal arrives from two sources, measured on different scales, and they are kept in separate columns:

Source	Field	Scale
The R1 client snapshot	`rssiDbm`	dBm — negative, lower is weaker
A live webhook event	`rssiRelative`	RUCKUS relative units — positive, higher is stronger. Not dBm

Roam signal changes are also relative units, and the predicted coverage field is modelled dBm, not a reading. Never compare a number from one scale with a number from another: a +3 relative reading is not “stronger than −67 dBm”.

The Floor Map page

Floor Map (/floormap) is the same view in your browser, with room to look properly. It appears in the dashboard navigation once the feature is on.

Pickers for connection, venue and floorplan.
A checkbox per layer, each with a hover hint. Access points are always on.
Re-read clients, when the clients layer is on, to fetch a fresh snapshot.
Live (off by default): streams client joins, roams and leaves as your webhook receiver ingests them, and re-renders the floor at most once every 30 seconds.
Band, roam-window and roam-colour selectors, a client MAC box for a roam trail, and a device MAC box for heardBy.
A side panel with Findings, Assigned but not placed, and the Legend, plus per-layer data tables including the full client roster.

The links Claude gives you

Every floorplan_map result carries two links, and neither costs Claude any context:

Link	Opens
`pageUrl`	The Floor Map page, on this floor — the better link for a person
`mapUrl`	The picture alone, as an SVG — for embedding or printing

Both carry the layers and options Claude rendered with, so you open what you were just shown. They open with your dashboard sign-in. The one setting deliberately left out is refreshClients: a link gets opened repeatedly and forwarded, and baking in force would re-query R1 on every open.

The r1-mcp companion extension can also show a floor map, using a short-lived link scoped to one venue that is read-only and expires after 15 minutes.

Limits

Limit	Value
Image Claude receives	About 800,000 pixels (roughly 1,050 tokens); tried at smaller widths if it encodes over 900 KB, then refused with a pointer to the map link
Inline SVG (`inline: true`)	60 KB — refused rather than trimmed
Stored plan images	50 per user per connection; the oldest are evicted
Source plan image	20 MB
Interlaced PNG and JPEG plans	Cannot be decoded — positions are drawn on a blank frame and the reason is stated

More caps are on the limits page.

Prompts and the reference guide

Two prompts in Claude’s + menu use this feature:

Prompt	What it does
`floorplan_ap_audit`	Audits AP placement on a floor in metres — unplaced APs, APs at (0,0), pairs too close, isolated APs, and co-channel candidates confirmed or dismissed. Read-only
`floorplan_roaming`	Draws the roam matrix on a floor and reads it against the real distances, optionally with one client’s trail. Makes no R1 call

Claude can also fetch the floorplan-mapping reference guide with get_reference. It covers the refusals, the layer catalogue, the signal scales and worked workflows in depth.

Next steps

Floor map layers Every layer you can draw on a floor, and what each one can and cannot state.

Webhooks and event analytics Set up the receiver that feeds the roam layers and the live client strip.

Limits and quotas Image, cache and roster caps alongside every other limit.

Prompts The floorplan prompts and every other workflow in the + menu.