Floor plans¶

Maps → Floor plans lays out a location - a room, a hall, a floor - as a grid of tiles: racks, aisles, walls, cooling units, cameras, doors… Each tile can link to a real object (a rack, a DIN-rail cabinet, a device, a power panel or feed, or another floor plan), so the drawing stays a live view of your DCIM data rather than a static diagram.

Everything is self-contained: an SVG canvas, uploaded background images served from your own deployment, no external tile servers - floor plans work fully air-gapped.

The palette is yours (zero pre-filled data)¶

There are no built-in tile kinds. Before placing tiles, define your palette under Customize → Floor tiles: each tile type has a name, a color, an optional icon (searchable Lucide picker - type "cam" and pick a camera), and a default size in cells (a rack is 1×1, an aisle might be 1×4).

Two sources feed the palette automatically:

• Floor tile types - the kinds you create.
• Device roles - every role doubles as a tile type, reusing its color, so a shop that already defined "Firewall / Access / Server" roles gets matching tiles for free. The palette lists a role as its colored role badge, a tile type as its tile.

Two ticks on a tile type change how its tiles behave:

• Background zone - the tile paints the grid background instead of occupying it: red for a hot aisle, blue for cold, an amber security zone… Zones render under normal tiles, and normal tiles may sit on top of them (they're the one exception to the no-stacking rule). Their name labels (Cold aisle, Hot aisle…) can be hidden with the Zone labels toggle under Display when they clutter a busy plan.
• Camera field of view - tiles of this type get a FOV cone (direction / angle / reach in cells) drawn on the canvas. The same tick exists on device roles (e.g. a CCTV role), so camera devices get cones whichever way you type the tile. Toggle all cones under Display. Per tile: a dice-style anchor picker sets where the cone emits from (center or any corner), and a PTZ toggle swaps the cone for a full 360° coverage ring (radius = reach) for pan-tilt-zoom cameras.

A tile's behaviour never depends on what its type is called - it comes from what the tile links to. A tile linked to a rack acts like a rack tile whether you named its type "Rack", "Cabinet", or "Skab".

Open a tile type¶

Clicking a name under Customize → Floor tiles opens that type's detail page - the answer to "what breaks if I change this?" before you recolor, rename, or delete a palette entry.

• Overview - its color, icon, slug and default size; the three rendering ticks (Background zone, Camera field of view, Perforated); and a short Site markers list, because a type is also the vocabulary for free markers on the geographic site map. Markers are a handful at most, so they sit here rather than in a tab of their own.
• Placed - every tile of this type on any floor plan, with the plan, the grid cell, the size, and what the tile is linked to. Both placed tiles and site markers block a delete, and both are listed here.
• Journal - your notes on this tile type.
• Change log - the automatic record of changes to the type itself.

Creating a plan¶

Maps → Floor plans → Add (or the Floor plan button on a Location page). A plan belongs to a location, has a grid (default 24×16 cells, up to 512×512), and can carry an uploaded background image - a blueprint or photo scaled under the grid with adjustable opacity.

The grid also carries a real-world scale: a cell size in millimetres (default 600 - one standard raised-floor tile) and a ceiling height (default 3000). Existing plans keep working untouched; the scale powers the 3D view, route-length estimation, and the scale bar on printed drawings.

The 3D room view¶

The 2D / 3D toggle in the plan header (or ?viz=3d in the URL) turns the plan into a navigable room: rack tiles become cabinets at their grid positions - sized from the rack's rail width, outer dimensions and U height - with their racked devices drawn at true U positions when you move close. Trays render at their recorded level/elevation (overhead runs hang below the ceiling, underfloor runs sit beneath the slab), zones tint the floor, and the uploaded blueprint textures it.

• Navigate: drag to orbit, scroll to zoom, right-drag to pan. Keyboard: the arrow keys or WASD glide the camera level with the floor in the direction it faces - the way to walk the aisles - while Space rises, C descends (PageUp/PageDown work too) and holding Shift sprints at 4× speed. Speed tracks how far you are zoomed out, so close-up moves are fine-grained and hall-scale hops are quick. The first key press also pulls the orbit pivot to a few metres ahead of the camera, so dragging looks around first-person-style while you walk; double-click a rack to re-anchor the pivot on it and orbit for inspection, flying the camera to its front.
• Zoom has no wall: the wheel zooms right down to a few centimetres from a faceplate, and scrolling past that point walks the camera forward - through the rack front and out into the aisle behind it - so orbit turns into fly exactly when orbiting stops being useful. Zoom-out reaches far enough to frame a campus-sized plan, and wheel speed scales with room size, so a closet and a 400-rack hall take about the same number of ticks end to end.
• Cabinet shell (View menu, 3D): a three-position mode, not a checkbox. Solid closes every cabinet - side panels plus smoked-glass doors front and rear, so the gear reads as silhouettes - the room as a visitor sees it. Cutaway (the default) strips doors and side panels down to the corner-post frame so whole rows read through. X-ray keeps the open frame up close and draws distant cabinets as bare outlines, ghosts the walls and floor, and lifts every raised floor - the tin goes, the equipment stays: faceplate photos and ports render (and click) exactly as in the other modes. The shell mode is independent of draw distance: how much detail a far cabinet gets is still the renderer's business.
• Focus (F, or the button on a selected rack/device card): the selection stays lit and everything else drops to a faint ghost. Click another cabinet to move the spotlight; Esc (or clicking empty floor) lifts it.
• Isolate: on a selected rack's card, Isolate row keeps just that row (the row axis is detected from how the hall actually lines up) and Isolate zone - offered when the rack stands in a zone - keeps everything inside that zone. A pill at the bottom shows what's isolated; Esc or Show all restores the room. Isolation hides tiles outright - ghosts are for focus, absence is for isolation.
• View rear on a rack's card flips the camera to the cabinet's other face - the same framing as a double-click fly-to, mirrored through the rack - and flips back with View front.
• A rack's card gives its devices, Space, Power, Ports and Panel ports as bars on the racks' scale, and its role and status as their pills.
• Color by (Display) colours the room's racks as it colours their 2D tiles: a cabinet takes its tile's fill - the whole frame from afar, the posts, caps and side panels up close - with the same legend in the corner, and a row of the rack table lights its cabinet up.
• Light that grounds the room: one shadow-casting key light plus a procedural studio environment (no downloaded assets - it works airgapped), so cabinets stand on the floor instead of floating in front of it, and painted steel and galvanised tray read as material rather than flat grey. On High quality, screen-space ambient occlusion adds the interior depth that makes an open cabinet look hollow.
• Port labels (View menu, 3D, shown when the deployment prints them): turns the labels on the port quads off for this browser only - the same switch as the device page's Panel header.
• Device names (View menu, 3D): name plates per device. Underneath, All racks / Highlighted rack limits them to the rack you have selected or are focused on, and Names off the gear starts each plate at the rail edge so it runs over the frame and past the cabinet instead of covering the faceplate.
• Cable thickness (View menu, 3D): a slider from a quarter to double life size. Real jacket diameters are right up close and vanish across a hall; pick what reads at the distance you work at. Under it, Auto / Tubes / Lines picks the renderer: real tubes shaded like the rest of the room, or flat lines of constant on-screen width in the cable's solid color. Auto draws tubes up to two hundred cables and lines past that. Both saved per device in the browser, like Quality.
• Quality (View menu, 3D): Auto / Low / Medium / High - how much the effects may cost. Low drops shadows and caps resolution (software rendering survives), Medium adds shadows, High adds ambient occlusion. Saved per device in the browser, not on the plan: your workstation's High never follows the plan onto a weak laptop. Auto probes the GPU once and picks a tier.
• Click a rack for a summary card (space used, monitoring rollup) and a jump to the rack page; click a device inside an open cabinet for its own card (U position, size, face) and a jump to the device page. Up close, devices wear their device-type front/rear images. Monitoring state lights a beacon on top of each cabinet - the same worst-status rollup the 2D overlays use.
• DIN-rail cabinets (a tile linked to a cabinet) stand on the floor as closed light-grey boxes of the cabinet's outer size, with a door handle and the name over the front - nothing is recorded about how high one hangs. The outline carries the monitoring rollup in the beacon colours; focus, isolation, the hide eyes and X-ray (outline only, still clickable) apply as to racks. Hover for the device and rail counts, click for Focus, Open door, Isolate row/zone and Open cabinet, double-click to fly to the front. Open door swings the door out on its left-hand hinge (it snaps open when the system asks for reduced motion) and shows the inside as the cabinet page's 3D view does: the mounting plate, its rails, and each device on its rail at its type's true size, wearing its front photo with the ports marked on it, coloured as a racked device's (a port held for a cable amber) and in the room's key. Hover a device or a port for its card; click a device for the card with Open device, a port for the same card a racked port gets - its cable and far end, Connect cable, Trace run. Close door on the cabinet's card shuts it again. A cabinet's contents are fetched the first time its door opens, never for a shut one, and its ports in one request. Cable runs end on the box's lid, each in its own lane; a cable between two devices in one cabinet stays inside it and is not drawn.
• Side-mounted 0U strips (vertical PDUs with a rail mount) hang on their cabinet's flank as slim vertical strips in both detail tiers - click one for its device card. Up close, the strip's end face carries one small quad per outlet (spread down the strip at a real C13 pitch, by the trailing number in the outlet's name) plus its inlet at the foot. Each quad is clickable like a photo port - card, connect flow - and power cords land exactly on them.
• Build in advance: a typed tile needs no linked object - paint the future rack row now (bulk Set type makes this one sweep) and link real racks as they land. In 3D, non-rack tiles render as translucent ghost boxes so the planned room reads as a room rather than empty floor. Each carries a camera-facing name tag - the tile's label, else its linked device's name, else the type name. Scroll-zoom dollies toward the pointer, so getting close to a far corner of a big hall is one scroll, not a slow W-key flight.

• Airflow (View menu, 3D): draws each device's cooling direction as small cones - blue where air is drawn in, red where it is exhausted - from the device's effective airflow (its own setting, else its type's). Front-to-rear gear shows intake cones on the face and exhaust cones on the rear, side-breathing gear shows them on its flanks, mixed shows one of each on the exposed face, and passive draws nothing. The legend gains an Airflow row only while cones are on screen.

• Up close, a device whose type has photo-anchored ports wears its port markers on the image, colored exactly as on the device page - speed tier for cabled ports, the part's status for hardware bays. Click one for a card with its cable, far end and, when SNMP disagrees with the record, the difference (see drift in the room). A hardware bay's card carries the part's status as pills to pick from, and a right-click on the bay - pressed and let go without dragging, since a right-drag pans - opens the same choices at the pointer (see part status). The same goes for a rack's 3D view and a cabinet's. Marker names match their components case-insensitively, so a photo marked Psu 1 still resolves a port named PSU 1.

• Power ports the photo doesn't mark still exist: any power port or outlet without a photo marker gets a small synthetic quad along the bottom edge of the device's rear panel, ordered by name. It clicks, cards and cables exactly like a photo port, and power cords anchor on it instead of the middle of the face.
• Arriving with a cable trace (?trace=<cable> - e.g. "Show on floor plan" from a cable) draws the run as an animated line riding its assigned trays and dropping into both end racks.
• Cables are real geometry: each run renders as a lit tube whose jacket thickness follows its kind (power fatter than copper, copper fatter than fibre), leaves its port with a rounded bend into a corner channel just outside the rail - never straight down across the faceplates - and rides its trays in a lane of its own, so ten runs in one duct read as ten parallel runs. Hover glows; click opens the cable card. Past a couple hundred runs the layer falls back to simple lines for performance.
• Same-rack runs dress at the rail. A lead between two devices in one cabinet takes the corner channel nearest the two ports (2 cm outside the rail opening, 3 cm in front of the face) and gets a small lane of its own, so ten patch leads down one rail read as ten. Two ports a U apart on the same face still patch directly. An end whose device type has no marker for that port is drawn at the panel's centre, and the cable card says so.
• Trays are open baskets - two side rails and a floor of rungs - and runs ride inside them, resting on the rungs. Click a tray to open it: the near rail drops away, the basket tints, and a card lists every cable routed through it (click one to select that run). Click it again, or Close tray, to shut it. Where runs corner, tee or cross, the rails stop short and a junction plate bridges the joint, so a crossing reads as fabricated tray instead of two baskets shot through each other.
• A run with no tray flies over the cabinets rather than through them - it clears the tallest rack in the room and stays under the ceiling.
• The cable card names what the run follows - the trays in order, or point-to-point when it follows none. A cable that ignores an obvious duct is almost always set to point-to-point; change it on the cable's own page (see routing a cable).
• Double-click a cabinet to fly to its face; double-click a device to fly to that device, framed for its height, from whichever aisle its face is on.
• The key in the top-right corner appears only once something photo-anchored is in view, and lists the hardware statuses actually on screen, as their pills. The speed ramp itself is always the full <100M→400G+ scale, so it reads the same here as under a 2D panel - see The panel's key. It is the maps' legend box: Hide legend folds it to a Legend chip, and the room remembers that per browser.
• The view is read-only in v1 - layout editing stays in 2D.
• Everything is drawn from the same millimetre constants as the 2D elevation and faceplates, so proportions match reality (EIA-310 rack opening, 44.45 mm U pitch). Browsers without WebGL fall back to a notice; 2D is unaffected.

Face images and text labels are filtered at the GPU's best anisotropy and the canvas renders at the display's pixel ratio, so a cabinet read at an angle stays sharp. What that can't fix is a low-resolution source photo - a 600 px device image stretched across a 19″ face is soft at close range in any view. Upload the largest faceplate photo you have.

Drift in the room¶

A port or hardware bay whose observed SNMP state disagrees with the record wears an amber outline - the 3D reading of the same ring the 2D faceplate uses. The marker keeps showing your source of truth; the outline is a separate signal saying "look here". Click it and the card names the difference ("SNMP says failed", "speed: SNMP says 1 Gbps"). Nothing changes until you accept it on the device's Monitoring tab - see SNMP discovery.

Drift rides along in the same batched request the port markers already use (GET /api/devices/face-ports/?ids=…&drift=1), so a rack of cabinets costs no extra round trips. Resolving the markers costs that request the same number of queries for two devices or two hundred; drift is the part that grows with the devices, so the request asks for it by name, and without drift=1 every marker's drift is null. A single rack's port state leaves drift out.

Floors¶

A location can hold several plans - its floors. Name them "Basement", "Floor 1", "Floor 2"… and the plan header shows a floor switcher (the same segmented tabs used everywhere) plus a + to add another floor to the same location. Switching floors with unsaved edits asks first - the same guard that covers every other way out of the editor, described under the editor. For click-through navigation between plans (e.g. a stairwell tile), link a tile to another floor plan.

The editor¶

Anyone with floorplan · change gets the edit tools; everyone else sees the read-only viewer.

The page has two bars, split the way the topology map's are. The header names the plan, with the floor switcher and the Edited badge, and holds the 2D / 3D and Layout / Structure / Cables tabs. The bar under it has Find on plan…, Fit to view and Grid on the left, and Racks (while the plan is coloured by its racks), Objects, Display, Background, PNG, plan settings and Save on the right. When that bar is too narrow for all of them (a small window), Grid, Background, PNG and plan settings move into More, so nothing is ever cut off.

Tiles never stack. Placing, dragging, resizing, or rotating a tile onto occupied cells is blocked - the tile stays where it was. Background zones are the exception: they may cover anything, and anything may sit on them.

Edits are local until you press Save - one transactional bulk call writes all creates, moves, and deletes together, and the change log records each tile individually.

While there are unsaved edits an Edited badge sits in the header, and leaving the plan asks first - Discard unsaved changes?, with Keep editing or Discard and leave. One guard covers every in-app exit: a sidebar link, a breadcrumb, browser back/forward, a tile that links out to a rack or another floor, and the floor switcher. Closing the tab or reloading raises the browser's own leave-site prompt instead, since that never reaches the app.

Switching the same plan between 2D and 3D, or clearing a cable trace, is a view change rather than an exit, so neither is guarded.

Under Display: Color by heads the menu - see below; Fit labels to tiles auto-sizes each tile's text to its footprint (so single-cell tiles keep readable names) - the preference is saved on the plan; and Camera FOV cones shows/hides the camera wedges.

Changing a tile's type. Select a placed tile and pick another Type in the inspector - any tile type, or a device role standing in as one. The tile keeps its position, size, label, color and object link; only the look (and the popover rows configured for that type) follow the new type. Zones stay zones.

Live state on tiles¶

The canvas refreshes GET /api/floor-plans/<id>/state/ every 30 seconds - a poll that costs the same number of queries however many devices the plan holds. A rack tile's figures are the rack page's, its power included (see Racks); a plan's racks with their port figures are GET /api/racks/?floor_plan=<id>&include=ports, asked for once rather than on every poll.

• Rack tiles carry a space-utilization bar (green ≤80% · amber 80–95% · red >95%) and a percentage. The racks list's Used and Power bars and the tile popover's bar use the same scale. Coloured by a rack measure (Color by), the bar and the figure show that measure instead.
• Monitoring rollup - a rack tile's border turns red the moment any device inside it goes down (worst status across the rack's devices' IPs); device tiles do the same for their own IPs.
• Cabinet tiles report the cabinet's device and rail counts - the device count sits in the tile's corner - and roll up its devices' monitoring the same way. A cable to a device in a placed cabinet ends on the cabinet's tile, as one to a racked device ends on its rack's, and in the 3D room the cabinet stands as a closed box of its outer size.

Color by¶

Display → Color by colours the plan's racks by how full they are, or by what they are - in 2D and in the 3D room alike:

• The four measures fill a rack's tile with its level on the racks' one scale - green up to 80 %, amber above 80 %, red above 95 % - and grey where there is nothing to measure: no supply, no ports counted. The figure is always written on the tile, 86% or No data, on a one-cell rack too, so the reading never rests on colour alone; the bar along the tile's foot shows the same measure.
• Rack role and Status take the role's or the status's own colour, grey for a rack without one, and keep the space bar.
• Monitoring keeps the outline in every mode: a rack with a device down is outlined red whatever its fill says.
• Tiles that are not racks - walls, aisles, a rack tile with no rack linked yet - turn neutral and faint while the racks are coloured; zones keep their tint.
• A legend in the plan's corner keys the colours: the levels with how many racks sit in each, or the roles and statuses as their pills, and what the outline means while a rack is alarming. It is part of the picture, with no Hide button, so the PNG carries it.
• The choice is saved with the plan, like its other view settings: an editor's choice is the plan's, a viewer's lasts the visit.
• Units and power refresh with the 30-second live state; ports, roles and statuses come from the plan's racks, asked for once when a rack choice is picked (GET /api/racks/?floor_plan=<id>&include=ports), never on the poll.

The rack table¶

While the plan is coloured by its racks, a table of them opens under it, the width of the page: the racks list's own columns - Name, Role, Status, Devices, Used, Power, Ports, Panel ports and Tags - sortable, with the rest and the custom fields in Columns. Find rack… matches a name or facility ID; the rail filters by role, status and tag, and its advanced filter reaches custom fields.

• Pointing at a row rings its rack on the plan; a click on the row - not on its links - selects the rack and zooms to it, and in the 3D room flies to its front.
• While anything is filtered, the racks the table leaves out fade on the 2D plan.
• The Ports figures open Port utilization on the rack.
• Drag the table's top edge to resize it (remembered per browser). Racks on the bar, or the table's ×, closes it, and the plan fits itself to the room it gets back.
• The table lists the racks the Objects sidebar otherwise would: while it is open, the sidebar keeps the plan's other tiles.

Rack & device deep view¶

Click a rack tile (or its Contents & trace button) to open a side panel with the rack's capacity, its real elevation (front/rear, role-colored), and the device list - each device has an End-to-end button that shows its cable paths through patch panels to the far end, the same trace view as the device page. Device tiles open the end-to-end view directly.

A cabinet tile opens the same panel for the cabinet: its status, monitoring, devices, rails and size, the plate drawn with its devices' photos, and the devices rail by rail, each with a link and a trace. Editors open it with a double-click, viewers with a click, and either from Contents & trace or right-click → Open.

Viewer¶

Click a tile to see what it is and jump to the linked object (Open rack, Open device…, the same link every map panel uses). Rack, cabinet and device tiles open the deep view; a tile linked to another floor plan navigates into it on click - use this to nest a cage or suite plan inside a hall plan.

Working many tiles at once¶

Ctrl/⌘-click tiles to build a selection, or Shift-drag on empty grid to sweep one (plain drag still pans). A bulk bar appears with the count, Facing buttons that set the orientation of every selected tile in one click - placing a hundred racks no longer means a hundred rotate clicks - and Delete. The changes join the normal draft: nothing persists until Save, and Esc or a plain click clears the selection.

Raised floors (Structure mode)¶

The Structure tab models the room itself. Draw raised-floor areas - rectangles of tiles standing on pedestals with a cable plenum underneath - and give each one its plenum depth (default 300 mm). Rooms are rarely uniformly raised, so the raised floor is per-area: the DC pad is, the corridor isn't, and an L-shaped pad is simply two abutting rectangles (areas may share edges but never overlap, so the depth under any point is unambiguous).

In 3D the finished floor draws its 600 mm tile grid (the grid every operator actually addresses), and each area can be lifted on its own: click an area's edge skirt and its floor fades out over a beat so the plenum contents read; click again to close it. The global Lift raised floor toggle (View menu) still lifts everything at once. Zone tile types marked Perforated floor (3D) (Customize → Floor tiles) render their zones as grate/supply tiles instead of a flat tint - the cold-aisle read, one repeat per 600 mm tile. An optional Ceiling (View menu, 3D, default off) closes the room from the inside without ever blocking the bird's-eye view.

The plenum is data, not decoration:

• Underfloor trays with no explicit elevation dive to the plenum of the area beneath them (still 300 mm outside any area, as before).
• Route-length estimates use the same depth for their vertical-drop term, so a 600 mm plenum genuinely lengthens the cables that dive into it.
• The 3D room draws the finished floor and the void below; the Lift raised floor toggle (View menu, 3D) turns the floor translucent so the underfloor runs read through it.

Areas are drawn with the same drag-a-rectangle gesture as tiles; select one in the left rail to edit its label, plenum depth and color, or delete it.

Walls & doors (Structure mode)¶

The Structure tab also draws the room shell: walls as polylines on the same half-cell lattice trays snap to, so a wall can run along tile boundaries or straight down a tile's centerline. Click Draw wall, click corners (drawing magnetically snaps to existing walls, so rooms chain cleanly), and double-click or press Enter to finish - the wall is saved immediately and its inspector opens.

A selected wall edits like the rest of the structure kit:

• Label, color - cosmetic; the default wall follows the theme.
• Height (mm) - blank means full height, i.e. the plan's ceiling. A half wall is just a wall with a height.
• Doors - arm Add door, then click the wall where the opening goes. Each door is a 900 mm gap by default (2100 mm tall); width and height are editable per door in the inspector, and a blank door height renders the standard 2100 mm. Doors live on the wall (spans of a segment), so a wall and its openings always move - and save - together.
• Move - drag a wall to translate the whole run (0.5-cell snap); delete and redraw to reshape it.

The 2D canvas draws walls in every mode - solid spans with a dashed threshold and jamb ticks across each door gap - because the shell is context whether you're placing tiles or pulling cable. The 3D room raises the same geometry: solid runs, true door gaps, and a lintel over each opening (none when a door reaches the wall top). The Walls toggle (View menu, 3D) hides the shell when it blocks the view - it defaults on.

Walls are documentation geometry in this release: walls do not affect routing in v1. A cable's route and length ignore them, exactly as they did before walls existed.

Cable trays (Cables mode)¶

The Cables tab (top-right toggle, next to Layout) turns the plan into a buildable wiring drawing. Draw trays - cable/conduit runs - as polylines a contractor can follow, and assign the real DCIM cables that run through each one. Hand the PNG to whoever's pulling cable.

• Draw a tray: Cables mode → Draw in the left rail → click grid points to route the run → double-click (or Enter) to finish, then name it. Esc cancels. Trays snap to a half-cell lattice (twice as fine as the tile grid), so you can lay two runs a half-cell apart and they read as distinct parallel trays.
• Trays may overlap and cross - unlike tiles, there's no no-stacking rule; one run can pass over another (route them on the fine lattice to keep both visible).
• Assign cables: select a tray → its inspector lists the cables in it, with Add cable (searches all cables) and a × to remove. The tray shows its cable count on the canvas and in the rail.
• Auto-route: on a cable's page, the Auto-route button computes the best path through this plan's tray network (Dijkstra over segments, junctions and crossings), assigns those trays to the cable, and estimates its physical length - horizontal run × cell size, plus the vertical drops between each end rack and its tray, plus 10 % slack. A recorded length is never overwritten (the API accepts overwrite: true). Ends farther than ~6 cells from any tray come back unreachable rather than pretending a 20 m unsupported hop is a route. POST /api/floor-plans/{id}/route/ previews the same computation without saving.

Routing a cable¶

Auto-route picks a path for you. The Routing card on a cable's own page is the manual twin - and the answer to "what is this run actually set to follow?", which nothing used to show:

• Point-to-point - the cable follows no tray and draws as a direct A↔B run. This is the default, and the usual reason a cable in the 3D room ignores a tray it visibly passes.
• Through trays - pick the ducts yourself, as many as the run needs, and order them with the arrows so the path reads the way the cable travels. Removing every tray puts it back to point-to-point.

Changes take effect immediately in the 2D canvas and the 3D room. Routing is recorded per floor plan, so a cable that crosses plans keeps each plan's assignment separately. GET/PUT /api/cables/{id}/routing/?floor_plan=<id> is the same operation over the API; editing requires change on the cable. - Level & elevation: each tray records where it physically lives - Overhead (the default), Underfloor, or Floor level - plus an optional exact elevation in mm. Leave elevation blank and it derives from the level (overhead → ceiling − 300, underfloor → −300, floor → 0). This drives the tray's height in the 3D view and the vertical-drop term in route-length estimation. - Trays render above tiles so the run is legible on the print, and they export with the PNG. - Cables mode is edit-gated; viewers still see the trays.

Connecting trays (junctions, T-splits, crossings)¶

Trays form a network - a cable assigned to several connected trays routes through their junctions. There are three ways trays connect, and while drawing the cursor magnetically snaps to nearby trays so the joins land exactly:

1. End on another tray. While drawing, move near an existing tray - the next point snaps onto its line or a vertex (within half a cell). Click there (or double-click to finish there) and the two trays share that point, so they're joined. This is the usual "branch off the main run" move.
2. T-split. Draw a branch that starts (or ends) on the middle of another tray - it snaps to that tray's line, creating a T-junction the cable can turn through.
3. Crossing. Two trays that simply cross each other are joined at the crossing automatically - no click needed.

Editing a tray. Select a tray (Cables mode) and drag its body to move the run or a vertex dot to reshape - both snap to the grid and magnetically to other trays (drag a vertex onto another tray to connect them).

For heavier reshaping - e.g. rerouting runs around something added in a remodel - flip on Edit trays (the toggle at the top of the Cables rail). It hides all cables so nothing blocks the trays, and every tray becomes reshapeable. Click a tray to select it, then:

• Drag any point to move it.
• Click a ＋ on a segment to add a bend, then drag it into place.
• Right-click a point → Remove bend to delete it.
• Drag the body to shift the whole run.

Done editing trays (or Esc) turns cables back on. Name / kind / color / cables and delete stay in the inspector.

Tips:

• If a join doesn't take, zoom in and re-draw (or drag a vertex) onto the other tray until it snaps (the point sits exactly on the line).
• Draw parallel runs a half-cell apart so they stay visually distinct.
• Assign a cable to every tray it passes through (main run + each branch); the trace stitches them at the junctions and takes the branch toward the destination. If there's no tray between two points, the trace draws a straight line for that stretch.

Assignment is manual for now - a cable belongs to the trays you put it in. Auto-picking a cable's trays from its endpoints is the next phase.

Seeing cables A↔B (routed through the trays)¶

Turn on Display → Cable links (A↔B) and every cable routed through a tray draws its physical run - not a straight line, but the actual path through the trays it's assigned to. Danbyte resolves each cable's terminations to its devices, then to the tile holding that device (or the device's rack tile), and routes A→B along the tray network: it enters at the nearest tray point, follows the trays - including T-junctions and across several connected trays - and only straight-lines the short hops from a device to the tray. A cable with no trays just draws straight A→B. Click a cable in a tray's inspector to highlight its run (animated).

Assigning a cable to several trays is how branching works: add the cable to each tray it passes through (a main run plus a branch, say). The trace stitches them at their junctions - including where two trays cross mid-run - and takes the branch toward the destination.

Tracing a single cable - no Cables mode needed. With Display → Cable links on, just click any cable line (in Layout or Cables mode) to trace it: the clicked run jumps to the front, brightens with a moving dash, and every other cable dims so the route reads clearly even where several share a tray. Click empty floor to clear.

Trace on map from a cable - the cable detail page has a Trace on map button that jumps to the plan showing that cable, with its route already highlighted and the view fitted to it. The rack/device deep-view (click a rack or device tile) shows each device's end-to-end paths: a ⟿ next to the origin traces the whole run (all its cables, through patch panels), and the ⟿ on a single cable segment traces just that cable. Both close the panel, highlight on the plan, and fit the view.

Right-click anywhere on the plan for a quick menu - Trace cables here (highlight every run touching a tile), Open, Fit to view, Clear trace.

What shows a route: any cable that's either routed through a tray, or has both ends placed on the plan (a device tile, or the device's rack tile). Untrayed cables between two placed devices draw as a straight A↔B line; trayed ones follow the trays.

Where things live: patch panels are rack-mounted, so they stay inside their rack (their runs trace from the rack tile) - only floor-level things like drops (wall plates) and the equipment they serve (a printer, an AP) are placed as their own tiles.

Trays render as a subtle gray channel (recolor per tray) with no solid centerline, so a highlighted cable reads as running inside the tray.

Display → Cable trays hides/shows the tray layer itself - look at just the cable runs, just the trays, or both.

Finding things¶

• Find on plan… (Layout mode, the bar under the header): type a tile's label, linked object, or type name and jump straight to it - the canvas pans and zooms to the hit.
• Fit to view (the ⤢ button) recentres the whole plan after you've zoomed around.
• Hover any tile for a popover: name, type, status, a link straight to the linked object, and (racks) utilization / power / weight / device count / live monitoring state - for a cabinet, its devices and rails. Click to pin it - a pinned popover stays put so you can read it, follow its link, or hit Contents & trace; Esc or a click outside dismisses it. Which rows appear is configurable - see Popover fields. Power reads as the rack page reads it: demand over supply (1.2 kW / 3.6 kW), marked nameplate when no draw is recorded and No feed when no feed is.
• Objects (header toggle) opens a side list of everything placed on the plan - the same Objects sidebar the site map and the topology map open. Tiles fold into groups by device role and by tile type, each headed by the role's or type's color badge with a count, and the down/degraded counts on the header even while it is folded. A tile with live monitoring carries its status pill. The Search… box covers each tile's label, linked object and type (Enter jumps to the first hit), the All · Down · Degraded · Up tabs narrow the list to one monitoring state, and a labelled tile shows its linked object's real name as a muted second line. Click a row to select and zoom to that tile. Editors' toggle state is saved with the plan. While the plan is coloured by its racks, the rack table under it lists the racks and the sidebar keeps the rest.
• Hiding things - the same eyes the site map and the topology map have. Every group header in the Objects list (a device role, a tile type) and every tile row carries an eye: click it and that role, that type or that one tile leaves the plan - the 2D canvas, the 3D room and a cable whose end it was all follow, and the PNG export draws the plan as you see it. Hidden rows stay in the list, dimmed, so they can be brought back; a count and Show all sit at the top of the list, and a chip in the canvas corner says how many are hidden while the list is closed. A hidden tile cannot be selected, nudged or deleted until it is shown again. What is hidden is part of the plan (saved with its other view settings by anyone who can edit it), because "the plan without the old rack row" is part of how a plan is shaped for its readers; hiding never changes the plan's contents. Keyboard: H hides the selected tile(s); Shift+H shows all.
• Show on floor plan - the Rack, Cabinet and Device detail pages carry a button that opens the plan zoomed onto the tile; placed on several plans (its own tile and its rack's, or a cloned what-if plan), the button becomes a menu listing them. The Rack and Device detail pages carry a button that jumps to where they're placed (a device falls back to its rack's or its cabinet's plan, marked "via rack" or "via cabinet").

Cloning a plan¶

The Clone action on the floor plans list copies a plan with everything drawn on it - tiles (with their rack / device / panel links), cable trays (geometry only; the cables routed through the originals stay where they are), raised-floor areas and walls - into the same location as <name> copy, and opens it. Handy for a second identical floor, or a what-if layout you can throw away. Needs the floor-plan add permission.

Export¶

PNG exports the current view, theme-aware, at 2× resolution - same as the topology map and rack elevation exports. Trays and their labels are included, so the export doubles as the builder's pull sheet. The Color by legend is part of the picture too, so a coloured plan explains itself on paper.

Tenancy, permissions, audit¶

Plans, tiles, and tile types are tenant-scoped like everything else; links are validated against the active tenant. RBAC object types: Floor plans (floorplan, the plan and its tiles) and Floor tile types (floortiletype, the palette). All three models are audited - every tile create/move/delete lands in the change log.

Popover fields¶

Settings → Floor plans → Tile popover picks which rows the tile popover shows, and in what order. A field with nothing to say for a given tile is skipped automatically - no rack utilization on a wall tile - so turning one on is safe everywhere. A cabinet has no units to fill, so on its tile Utilization reads as its devices and rails; Rails shows the rail count on its own, and the cabinet's custom fields can be picked like a rack's.

Ports (off by default) gives a rack tile's ports in use over its counted ports, and its panel ports under them when it has any - the split the racks list and the rack page show - each opening Port utilization on the rack. It reads the plan's racks, asked for once for the whole plan while the field is on (or the plan is coloured by its racks), never per tile and never on the 30-second poll.

Showing the device's panel¶

Tick Faceplate (on by default) to draw a device-linked tile's front panel in its popover - what the box actually looks like, without opening its page. It uses the type's photo with its mapped ports when there are any, the plain uploaded photo when the type has a picture but no ports mapped on that side, and the drawn panel otherwise, and offers a rear toggle when the type has a rear image.

It applies to tiles linked to a device; a rack tile has an elevation rather than a faceplate, so the row is skipped there. Unlike the other rows, this one fetches the device's ports when the popover opens - which is why it is off by default: the standard popover answers entirely from data the plan has already loaded.

The card is scoped. Deployment default is the list every tenant starts from; This tenant carries its own once you switch the card off inheriting, seeded from what it was inheriting so you edit the current look rather than a blank slate. Per-tile-type lists are supported too - pick a tile type or device role on the left and Override; a type without its own list inherits the global one, so the two can't drift apart as you change the default.

Roadmap¶

Planned next: multi-select and undo/redo, cable traces drawn on the plan with "show on map", wall-plate ("drop") tiles with port assignments, in-plan search, and PDF export.