Site Spaces

Site Spaces organize your physical environment into a navigable hierarchy of buildings, floors, wings, and rooms. Spaces can be assigned zones, modes, and floor plan blueprints for spatial visualization and AI-assisted room extraction.

Overview

The Spaces page provides:

• Hierarchical Organization: Nest spaces (building > floor > wing > room) to mirror your physical layout
• Zone Assignment: Associate control zones with specific spaces
• Mode Assignment: Set operational modes per space with inheritance from parent spaces
• Blueprint Upload: Upload floor plans and annotate them with space overlays
• AI-Powered Extraction: Analyze blueprints with AI to automatically identify and create child spaces
• UI Generation: Create user interfaces directly from spaces

Layout

The Spaces page is a single-screen tree + detail editor — no tabs, no drill-in navigation.

• Tree Rail (left) - The full space hierarchy, expandable in place. Filter box at the top.
• Center Pane - The selected space's editor, organized as scrollable sections (Overview, Mode, Blueprint, Zones, UIs, Child Spaces). When nothing is selected, a welcome panel shows summary stats (total spaces, with blueprint, linked UIs).
• Right Rail - Mode History for the selected space. Collapsible via the chevron in its header.

Single root

The site has exactly one root site_space, auto-managed from the Site record with This Server enabled. The server refuses any attempt to create a second root or to promote an existing space to root — every other space must live under the root. Pick the root in the tree and use Add Child to grow the hierarchy.

Tree Rail

Each tree row shows, left to right:

• Chevron - Click to expand/collapse children (only present when the space has children)
• Color swatch - The space's configured color
• Label - Display name (system name shown on hover); disabled spaces are dimmed and struck through
• Mode pill - Active mode (gray = inherited from a parent, blue = set directly on this space). Tooltip names the source parent for inherited modes.
• Counts/badges - Nz zone count, a map icon when a floor plan is uploaded, an eye icon when a UI is linked

Click any row to load that space into the center pane. The tree auto-expands to reveal the selected node.

Filter box - Type to filter the tree by label, name, or space type. Matching nodes and their ancestors stay visible (ancestors are dimmed if they don't match), and the tree is force-expanded so all matches are reachable. Clear the filter to restore manual expansion state.

Multi-select / bulk re-parent - Hold Shift and click to range-select rows, or Ctrl/Cmd-click to toggle individual rows. Selection is constrained to siblings — rows under the same parent. Multi-selected rows are highlighted amber. When more than one row is selected, a yellow action bar appears above the tree showing the count and current parent, with a Move to… button and a clear (×) button. Move to… opens a modal listing every valid destination parent (the current parent, the selected rows, and any of their descendants are excluded to prevent cycles); picking a destination and confirming re-parents every selected space in a single batch — children, zones, and attributes are preserved. A plain click anywhere collapses the multi-selection back to a single focused row.

Center Pane Header

Above the sections, a breadcrumb chain shows the selected space's ancestor path; click any ancestor to jump to it. A dirty dot (orange) appears when there are unsaved changes. Action buttons:

• Add Child - Start a new child space under the selected one
• Delete - Opens a dependent-aware confirmation modal (see Deleting a Space)
• Discard / Close - Discard unsaved changes (label switches to Close when clean)
• Save - Persist changes (disabled while clean)

If you click a different tree row while there are unsaved changes, you're prompted to discard them first.

Welcome Panel

When no space is selected, the center pane shows four summary tiles (Total Spaces, With Blueprint, Linked UIs, Zones Assigned) and instructions to pick a space from the tree.

Space Types

Spaces are categorized by type, which affects hierarchy behavior:

Container Types

These types can contain child spaces and support floor plan visualization:

• Building - Top-level structure
• Floor - Level within a building
• Wing - Section of a floor

Room Types

• Room - Generic room
• Bathroom, Kitchen, Living Room, Bedroom, Office - Specific room types
• Hallway, Closet, Garage, Utility, Outdoor, Other - Additional types

Creating a Space

The root space is auto-managed — you cannot create another root. To add anywhere else in the tree, select the parent and click Add Child in the center header. A fresh editor opens in the center pane with the parent pre-filled.

Overview Section

Name

• Internal identifier (lowercase_with_underscores)
• Auto-formatted on blur
• Required

Label

• Human-readable display name
• Required

Description

• Optional text describing the space

Space Type

• Select from the list of space types (Building, Floor, Room, etc.)

Parent

• The parent space in the hierarchy
• Pre-filled based on current navigation level
• Can be changed via dropdown
• Required — cannot be cleared (only the auto-managed site root is allowed to be parentless)

Color

• Color code for UI and floor plan visualization
• New overlays drawn on a floor plan cycle through a built-in palette (blue, green, orange, purple, teal, pink, amber, red, cyan, slate), skipping colors already used by siblings under the same parent, so adjacent rooms get visually distinct colors out of the box

Tags

• Comma-separated tags for categorization and filtering

Sort Index

• Numeric value controlling display order

Enabled

• Toggle to enable/disable the space

Auto-create a UI bound to this space (include child spaces) — a checkbox shown only while creating a new space

• When checked, an accompanying UI is created and linked to the new space, with Include child spaces turned on so the UI also surfaces zones from spaces nested beneath it. The new UI's launcher group defaults to the parent space's label (or "Spaces" at the root), and the prodigy theme is applied.

Deleting a Space

Clicking Delete opens a confirmation modal that first inspects every row referencing the space:

• Child spaces — listed as a blocker; reparent or delete them first.
• Zones — listed as a blocker; reassign each zone to a different space first.
• UIs — listed as an unlink warning, not a blocker. Deleting clears each UI's site_space_id; those UIs surface at the top of the launcher as orphans until re-linked or deleted.

The Delete button stays disabled while any blocker rows exist. When the modal is unblocked and you confirm, the success toast reports how many UIs were unlinked (if any).

Mode Section

Visible once the space is saved. Shows the active mode as a large pill (gray = inherited, blue = direct), the inheritance chain back to the ancestor that supplied the mode (annotated with source), and inline controls to:

• Set a mode — pick from the dropdown; the change applies immediately (no need to click Save).
• Clear & inherit — only shown when this space has a direct mode; reverts to parent inheritance.
• Hold / Release Hold — pins this space's current mode assignment (including "no direct mode" = keep inheriting). While held, an amber held badge appears next to the mode pill, and mode changes and clears on this space are rejected — from this page, macros, or voice — until the hold is released. Broader (site- or ancestor-level) mode changes already skip spaces with a direct mode, so a held direct assignment is untouched by them too. See Site Modes for the hold semantics and the bypass pattern.

Mode changes captured here are recorded in the Mode History right rail. The effective-mode display for the tree auto-refreshes every 30 seconds.

See Site Modes for defining the modes available here.

Blueprint Section

Container spaces (Building, Floor, Wing) can have a floor plan image uploaded for spatial visualization.

• Upload Floor Plan / Replace Floor Plan - PNG, JPG, or WebP
• Extract Spaces with AI - Visible once a blueprint exists AND an Anthropic API key is configured (System Attributes > anthropic_api_key)
• Edit Layout (header) - Toggles the floor plan between view and edit modes. The button is present whenever a floor plan is available — the space's own uploaded plan or one inherited from an ancestor. While editing, the button reads Done Editing.
• Crop Image (Edit Layout modal, own plans only) - Trim the blueprint to a tighter rectangle. The drag handles let you frame the area to keep; a shaded inner rectangle marks the bounding box of all existing immediate child overlays — the crop can't shrink past it so cropping never slices into a placed room. Applying the crop re-renders the blueprint, re-uploads it, and rewrites each immediate child's bounds against the new image. Deeper descendants are stored relative to their immediate parent and don't need to move.

Once uploaded, the floor plan renders every bounded descendant as an overlay — not just direct children. Nested bounds are composed automatically (a room inside a wing inside a floor lands in the right pixel position on the floor's blueprint). Each overlay shows the space label, its active mode pill (if any), and a subsystem rollup chip row summarizing the zones that live in the space (e.g. 4 lights, 2 shades). When a zone in the space is currently active (e.g. lights on, door unlocked), the overlay pulses softly in the leading subsystem's color — alert subsystems (security/doors/locks/gates/garages/power/fire) win the color pick over comfort subsystems when both are active. In edit mode (toggle via Edit Layout in the section header) the overlays become drag/resizable for placement; drags are decomposed back into the immediate parent's coordinate system on save, so you can rearrange a deeply nested room from any ancestor's plan. You can also drag out a new rectangle on empty floor-plan space to place a room there — see Placing spaces on the plan below. In view mode, clicking an overlay opens that space's zones — if there's only one zone, the live control modal opens directly (same control component the zone uses in UIs); otherwise a chip picker lists the zones so you can pick one.

If a space does not have its own blueprint but lives inside an ancestor that does, the section displays an inherited view: a zoomed crop of the nearest ancestor's blueprint, framed to this space's bounds. It renders the same label / mode pill / subsystem chips / activity pulse as the overlay does on the parent plan, and clicking it opens the same zone chooser. Edit Layout is available on inherited views too — drag to draw or move child overlays directly on the cropped image without uploading a separate blueprint for the leaf.

Placing spaces on the plan

In edit mode, drag out a rectangle on empty floor-plan space to place a room. A dialog opens with two ways to fill that rectangle:

• Assign to existing (N) — shown first when the current space already has child spaces that haven't been placed on the plan yet. Pick one of those unplaced children and the rectangle you drew becomes its position. (Only children of the current space without a placement are listed; the count N is how many are waiting.)
• Create new — make a brand-new child space at those bounds. Enter a Label; a Name (system identifier) is optional and is derived from the label if you leave it blank. Pick a Color for the overlay — it's pre-filled from the palette, skipping colors already used by sibling rooms.

If the current space has no unplaced children, the dialog skips straight to Create new with no tabs. Click Assign / Create to confirm. To reposition or resize a room that's already placed, click its overlay and drag its edges instead.

AI Blueprint Extraction

1. Click Extract Spaces with AI - the model examines the floor plan and identifies rooms/spaces
2. Review the Extracted Spaces list - each entry shows a checkbox, color swatch, name, and type
3. Optionally toggle Also create UIs to generate a UI per extracted space (each linked to its space, with Include child spaces on and the prodigy theme applied)
4. Click Create N Spaces - the selected spaces are inserted as children of the current space

End-user floor plan maps

Everything the Blueprint and Zones sections capture is also what end-user zone maps are built from. A UI linked to this space (or an ancestor of it) renders an interactive floor plan of any subsystem — all the lights on a floor, all the shades, the cameras, the door locks, the fan zones — with no per-zone placement work at all. Lighting, Shades, Cameras, Garage and AV have their own map affordance; every other subsystem gets one through the generic zone grid, where tapping a pin opens that zone's control.

AV rooms are ordinary zones in the av subsystem, so they place themselves from the same room assignments — see AV Zones for what the plan does on the Audio and Video pages.

A zone's pin position is derived:

• Which plan — the space's own floor plan, or the nearest ancestor's. When the plan comes from an ancestor, the whole plan is used and the map opens zoomed into this space's rectangle, so a UI scoped to the Kitchen shows the Kitchen exactly as the First Floor UI shows it once you drill in — the room filling the panel, its lights spread out as individual pins, and the rest of the floor a zoom-out away for context.
• Where on it — inside the rectangle of the room the zone is assigned to, composed through every intermediate ancestor. When a room holds several zones of the same subsystem they are fanned out on a grid inside the room, in the zones' sort order, so the same site lays out identically on every panel.
• Which page — one pager page per floor that has a plan and holds zones, labelled with the space label ("Second Floor"), not a filename.

So the setup is just the two things this page already asks for: give the floor a plan and draw its rooms, and assign each zone to its room. Nothing is placed by hand and nothing is stored per theme.

How the plan is drawn

The plan opens with its name in a header above the image and an X at the right to close it; when more than one plan is in scope, the pager arrows below the image page between them. On the control pages the header also carries the subsystem — First Floor Doors — since the same plan draws the doors on one page and the lights on another, and the floor name alone says where you are but not what you are looking at. It stays as you drill in, so a room reads Kitchen Doors once the floor name has been zoomed away.

Every control page that raises a plan names it this way — Lighting, Shades, Audio, Video and the generic zone grid. The wording is the subsystem's own label, so a subsystem renamed Landscape Lighting reads First Floor Landscape Lighting; where the site has no such subsystem row the page's own name is used instead. The Audio and Video pages name the page rather than the subsystem — First Floor Audio — because both draw from the one av subsystem and the useful distinction is which of the two you are on.

The header and the pager both earn their space: the pager only appears when there is something in it, and the X is dropped on a map that is the page rather than an overlay over one (the Garage page), where there is nothing to close back to.

The header is the width of the plan itself, not of the screen, so the title centres over the image and the actions sit on its right edge instead of drifting out to a screen corner on a wide panel.

An active zone's pin carries a halo that blooms with its level — a lamp at 10% shows a tight ring, one at full a wide glow, and the same for shade position or fan speed. A zone that is on but publishes no level (a switch, a lock) gets the full halo rather than none. A room's cluster marker blooms on the average level of the zones in it that are on, so a floor of dim rooms reads differently from a floor of bright ones without drilling in.

A pin that isn't blooming still carries a faint neutral halo, and so does a room's count marker. At rest the disc is a mid grey sitting on a plan that is mostly mid greys, and without it the eye finds the lit zones and loses every other one. The at-rest halo is deliberately colourless: the coloured, level-sized bloom is the whole active language, and repeating it quietly at rest would blur the one distinction the map exists to make.

The plan is raised over a live page — zone tiles, source cards — so it sits on a dark scrim that dims whatever it is drawn over. That is fixed, not a theme setting: a theme that left it out would leave the plan competing with the page underneath it, which is a readability question rather than a skinning one. The overlay covers the whole screen, the app's top header bar included, on every page that raises a plan over one — the plan gets the full height of the panel to draw into and nothing above it competes for attention while it is open.

Floor plans are inverted by default — 0.85, which turns the usual dark-on-white architectural drawing into light-on-dark-grey. An un-inverted plan is a sheet of white glaring out of a themed UI, and the room outlines are drawn light for the same reason. Override per plan with the plan_invert attribute on the space that owns the floor plan: a value from 0 (exactly as uploaded) to 1 (fully inverted). Set 0 for a colour render or a plan that is already dark.

Rooms that set a Color use it for their outline on the plan. Rooms with no colour fall back to a light neutral, which reads correctly on an inverted plan — so if you turn inverting off, give the rooms colours or their outlines will wash out against the white background.

Pins carry live state

A pin is a single state-coloured disc centred on the zone's position, with a small subsystem glyph on it. A zone that is active takes the active colour and a soft halo, so an on light or an open shade reads at a glance across a whole floor; everything else sits at rest.

On the pages that run the generic zone grid (doors, gates, covers, lifts, power, water, fire, irrigation, fans, climate and any custom subsystem) the disc instead takes the same colour as that zone's tile badge, because on/off is not the only thing those zones can say:

colour	meaning	states
green	secured, running as it should be	closed, locked, on, running, dry, clear, ok
amber	worth noticing, nothing is wrong	open, unlocked, ajar, motion, trouble, pending
blue	in transit	opening, closing, moving, charging
grey	at rest, nothing to say	off, idle, standby, disarmed
red	wrong	alarm, fault, leak, error, offline, and locked on the doors page

This is what a water-leak sensor needed: leak used to fall through to the plain "active" green, so a flooding sensor painted the same colour as a light that was on. A state the vocabulary doesn't know still falls back to the active/inactive language, so a custom subsystem with its own words keeps working untouched.

The state arrives with the plan, so a pin is correct on the first paint rather than from the next time its zone changes — every map shows live status, not just the pages that already track their zones. "Active" is judged by the same central at-rest state registry the space rollups, the tile headlines and the View Active filters use, so a pin can never disagree with the tile for the same zone.

Camera pins take one identity colour

Cameras have no on/off — a camera zone is simply there — so the active / inactive / selected language has nothing to say about one, and every camera pin would otherwise land on the same at-rest grey. On a map of the camera subsystem the pins, their halos and any count markers instead take a single identity colour, standing in for every state: nothing a camera reports changes what its pin says, including selecting it. This is a default only — a page that paints its own pin colours still wins per zone, and every other subsystem keeps the state colours above untouched.

Climate pins read as thermostats

On the Climate map a pin shows the room's current temperature in place of the subsystem glyph, and colours its halo by the zone's system mode — blue for cool, red for heat, green for auto, cyan for fan, amber for dry. On a floor of thermostats the glyph says nothing the number doesn't, and which rooms are calling for heat and which for cooling reads across the whole plan without opening a zone.

A zone in off shows no halo at all, since off is what "at rest" means for climate — the same rule the Climate page's View Active filter and tile badges use. A room whose thermostats have collapsed into a cluster marker takes the mode colour only when they agree on one; a room running one head in heat and another in cool falls back to the map's own colour rather than picking a winner. A zone that hasn't reported a temperature yet keeps the ordinary glyph.

Not every climate zone is a thermostat. A heated floor loop switched on and off — no setpoint, no mode, no temperature of its own — is read as the switched load it is: its pin takes the ordinary state colours (green on, grey off), its halo glows in that same palette while it is on, and it keeps the subsystem glyph rather than an empty readout. The system mode is what decides which treatment a zone gets, so a thermostat that reports one is unaffected.

Knowing which zone a pin is

A pin carries its zone's name under the disc wherever the plan has room to print it without running into a neighbour. The decision is made in pixels, like clustering: names appear on a large wall panel, thin out on a phone, and the ones that were too tight at floor level appear as you drill into a room and the pins spread apart.

Where a name doesn't fit, touch and hold a pin and it names itself in a callout above the disc — which is also the safe way to check before acting on a map that responds to the first tap, such as cameras. Sliding your finger off the pin before lifting cancels the tap, exactly like a physical button, so you can read the name and back out. On a mouse the same name is in the hover tooltip.

On maps with a control row underneath (lights, shades), the current selection is echoed over the foot of the plan — Kitchen Island +2 — so you can confirm what Off is about to reach, including zones hidden inside a cluster or sitting on another floor.

Reaching a room's keypad from the plan

On the Lighting, Shades and generic control-page maps, a room whose space owns a UI carrying Lutron control-station attributes shows a keypad glyph in the room's top-right corner, clear of the room name and of the pins that fan out from the middle. Tapping it opens that room's real keypad in a modal — every station in the area, on a wallplate, with live LED state — so the floor plan becomes a way of reaching the wall control you'd otherwise walk to. A room with several stations stacks them in one column and the modal scrolls, so each faceplate is shown whole rather than squeezed. Each keypad carries its Lutron area name as a title above the faceplate (title-cased from the processor's ALL-CAPS convention), so stacked stations read apart at a glance.

Nothing is configured for this. The lutron_qsx driver's sync_areas command already stamps each UI with its area's stations (see Lutron), and a UI is already linked to a space, so the plan just follows the two links that exist: room → UI → stations. A room with no UI, a UI with no stations, or a disabled UI shows no glyph.

The glyph appears only where the room is drawn wide enough to carry it alongside a readable room name — the same pixel test clustering and the pin labels use — so a small room hands its keypad back when you drill into it.

Room clusters and drilling in

A whole floor rarely has room for a pin per zone — a small room is only tens of pixels wide on a fitted floor plan, well under a tappable target. So a room whose pins would collide collapses into a single count marker: the number of zones in that room, tinted when any of them is active.

Where the pins carry state colours, the marker shows the room's most noteworthy state rather than an average — a leak or an open door still reads red or amber from across the plan instead of hiding behind three zones that are fine. Plain at-rest ranks last, so a room with one fan running still reads as running.

The decision is made in pixels against the room as currently rendered, not on a zone count, so the same site shows individual pins on a large wall panel and markers on a phone.

Tapping a marker zooms into that room — the plan scales and re-centres, and the room's pins spread out and become individually controllable. The header shows the room name, and a zoom-out button appears next to the close X that returns straight to the whole floor from however deep you have drilled; markers inside the zoomed room can be drilled into again. Zooming is a view change only: no data is re-fetched, and closing the map returns to the view it opened in.

A UI scoped to a room inside a larger plan starts at that room's zoom rather than at the whole floor, so the panel in the kitchen opens on the kitchen. It is the same view, reached without the tap: the room's pins are already spread out, and the zoom-out button is there from the start for a look at the rest of the floor.

Pins keep their on-screen size as the plan scales, so they never grow into the walls, and the transition respects the operating system's reduced-motion setting. Once a zoom lands, pins and room names are drawn at their real size rather than stretched from the unzoomed plan, so they stay sharp on an iPad or iPhone at any zoom depth.

Nudging a pin

Set the space_position attribute on a zone to override its derived position: {"x": 25, "y": 80}, as a percentage of its space's rectangle. Because it is stored relative to the space rather than to the plan, the override survives the room being moved or resized and the blueprint being replaced or re-cropped.

Overriding one zone does not disturb its neighbours — the remaining zones in the room are fanned out among themselves.

Zones that can't be placed

A zone is left off the plan, and logged with a reason, when it has no site space, its space has no bounds, there is a gap in the bounds chain between its room and the plan, or its room's rectangle lands off the image. Nothing is silently dropped, so a missing pin always has a findable cause — see UI Themes → Zone Map Not Loading.

Zone maps were previously authored per theme, by uploading a plan as a theme asset and dragging one pin per zone onto it. That editor is gone and the map_coordinate zone attribute it wrote is no longer read; existing values are inert and need no cleanup.

Zones Section

Visible once the space is saved.

• Assigned zones render as clickable chips (label + subsystem badge). Clicking a chip opens the zone's control inline in a modal — the same control component the zone uses in user UIs (dimmer, climate, gate, lock, etc.), based on the zone's control setting. If control matches a user-defined Svelte widget instead of a built-in control, that widget is rendered. The active UI theme is applied so themed components render with their normal appearance.
• Each chip also carries a small settings icon that opens that zone's editor in a reference modal over this page, so a zone bound to the wrong device or subsystem can be fixed without leaving the space and discarding its unsaved edits.
• Assign / Unassign Zones uses a multi-select picker listing all enabled zones. Optionally filter by subsystem first. Adding a zone assigns it to this space immediately; removing one unassigns it.

UIs Section

If a UI is linked to this space it's displayed with Open UI — launches in a new tab. Sub-info shows whether the UI has Include child spaces turned on and any launcher group value.

If no UI is linked, Create UI generates one:

• UI name matches the space name; label matches the space label
• Include child spaces is enabled automatically for container types (Building, Floor, Wing)
• The UI is linked to the space and gets the prodigy theme

Child Spaces Section

Compact table of direct children (label, type, zones, mode, badges). Click any row to navigate to that child. Add Child in the section header creates a new child under the current space.

Mode History (right rail)

The right rail records every mode change for the selected space — direct or inherited-from-parent — with timestamp, action (activated / cleared / held / released), and the resolved mode. Up to 20 most recent rows are shown. Collapse the rail with the chevron in its header; reopen with the small toggle that takes its place. Hidden on narrower viewports (< 1100px).

Database Schema

Column	Type	Description
id	INTEGER	Primary key
name	STRING	Internal name (required)
label	STRING	Display name
description	STRING	Optional description
tags	JSON	Array of string tags
sort_index	INTEGER	Display order
enabled	BOOLEAN	Active state (default: true)
site_mode_id	INTEGER	FK to site_mode (direct mode assignment)
mode_hold	BOOLEAN	Pins the mode assignment — changes/clears rejected until released (default: false)
parent_site_space_id	INTEGER	FK to parent site_space (hierarchy)
space_type	STRING	Type classification
blueprint	TEXT	Floor plan image data
bounds	JSON	Position/size on parent's floor plan
color	STRING	Color code for visualization

Common Use Cases

Residential Home

Home (Building)
  First Floor (Floor)
    Living Room (Living Room) - zones: living_lights, living_shades
    Kitchen (Kitchen) - zones: kitchen_lights, kitchen_fan
    Master Bedroom (Bedroom) - zones: master_lights, master_shades
  Second Floor (Floor)
    Kids Room (Bedroom)
    Office (Office)
  Garage (Garage)

Commercial Building

Office Tower (Building)
  Floor 1 (Floor) - mode: business_hours
    Lobby (Hallway)
    Conference Room A (Room)
    Conference Room B (Room)
  Floor 2 (Floor) - mode: business_hours
    East Wing (Wing)
      Office 201 (Office)
      Office 202 (Office)
    West Wing (Wing)
      Open Plan (Room)

Best Practices

1. Start with Structure: Create the building/floor/wing hierarchy first, then add rooms
2. Use Labels: Always set labels for user-friendly display in UIs
3. Assign Zones: Link zones to the most specific space possible
4. Use Modes Sparingly: Set modes at the highest level that makes sense; let child spaces inherit
5. Upload Blueprints: Floor plans on container spaces enable visual navigation for users
6. Use AI Analysis: For complex floor plans, AI extraction saves significant manual effort
7. Create UIs: Generate UIs directly from spaces to maintain a consistent mapping

Related Documentation

• Site Modes - Defining operational modes for spaces
• Sites - Multi-site management
• Zones - Zone configuration
• UIs - User interface management
• UI Themes - Styling; zone maps used to be authored there