WiFi Weave Documentation

Getting Started

1. Upload a floor plan image and confirm dimensions.
2. Set scale and ceiling height to calibrate distance calculations.
3. Draw wall materials to model attenuation.
4. Place APs manually or run Auto Planner.
5. Review heatmap, optimize channels, then export deliverables.

Core Concepts

• Scale: converts pixels to real-world distance.
• Walls: material-specific attenuation affects predicted RSSI.
• Coverage Areas: scope analysis to target zones only.
• Visualization Modes: signal, SNR, data rate, overlap, and capacity.

API discovery

Start from GET /api/v1 for a JSON index of version, auth headers, product webhook env hints, and endpoint paths (floor plans, coverage, exports, auto-planner, trial). Use OpenAPI JSON for codegen and integration tests.

API and Exports

Use API v1 for automation, coverage calculations, and export workflows.

Product webhooks (optional)

Automate downstream systems when exports or planning events occur. Set environment variables on the server:

• PRODUCT_EVENTS_WEBHOOK_URL
• PRODUCT_EVENTS_WEBHOOK_SECRET (optional HMAC)

Payloads include typed events (for example export.channel_plan) plus a generic export.ready event with a kind field (channel_plan, coverage_summary, walls_csv, pdf_audit, pptx) for integrations that want one subscription.

Keyboard Shortcuts

In the planner, press ? for the live shortcut overlay. Common bindings:

Use Ctrl on Windows/Linux or Cmd on Mac for undo/redo. Changelog lists recent feature updates.

Advanced topics & roadmap

How today's product maps to common enterprise questions: history, collaboration, RF assumptions, and scale.

• Undo / redo: Canvas changes to walls, access points, and coverage areas support Ctrl+Z / Ctrl+Y (Cmd on Mac) with a rolling in-memory history. Reloading the floor plan resets the stack.
• Named versions: Use Version history in the planner to save a named snapshot and restore layout later (walls, APs, coverage areas, scale).
• Pin comments: Plan comments are stored per floor plan for install notes and review threads (API-backed).
• Team workspaces: Open the planner’s “Team workspaces” panel to create a workspace, add teammates by email as viewer / editor / admin, and share the current plan. Editors can modify shared plans; viewers get read-only access. Read-only share links remain available for clients without an account.
• Buildings & floors: The planner’s “Buildings & floors” panel groups plans into a multi-floor building (create floors, reorder them, assign plans) and powers inter-floor signal bleed in the RF propagation panel. The same data is scriptable via authenticated JSON routes GET/POST /api/buildings, GET/PATCH/DELETE /api/buildings/:id, GET/POST /api/buildings/:id/floors, and PATCH/DELETE …/floors/:floorId for the signed-in user (same JWT as the planner). GET /api/v1 lists this cluster under buildings-session; OpenAPI describes the v1 prefix only.
• Analytics JSON APIs: GET /api/analytics/trends, /api/analytics/reports, and /api/analytics/performance require auth and a floorPlanId query param; they load persisted APs and walls from the database (no placeholder layouts). Enterprise routes under /api/enterprise/* use API-key style auth as documented for integrators.
• Noise & spectrum: SNR views use a configurable ambient noise floor; we do not model third-party interference sources—document assumptions in client deliverables.
• Catalog freshness: Admin sync updates the global AP catalog; the planner footer shows active count, totals, custom models, and last DB update time.
• Performance: Coverage uses caching and preview mode; large images can use WebP negotiation. DB indexes support list queries by user and recency.
• Observability: GET /api/health and GET /api/health/ready return app version and optional commitSha when the host sets VERCEL_GIT_COMMIT_SHA (or GIT_COMMIT_SHA). Liveness also includes uptime. Many JSON APIs echo X-Request-Id (and emit structured JSON logs server-side) so you can tie client errors to coverage, v1 floor plans, PayPal webhooks, and admin dashboards.
• Admin JSON (granular): Authenticated routes such as PATCH/DELETE /api/admin/features/:id, …/admin/users/:id (and …/subscription), …/admin/ap-models/:id, invoice PDF GET …/invoices/:id, POST …/invoices/:id/resend, verification-code lookup, and catalog sync follow the same X-Request-Id + structured-log pattern as list endpoints (Bearer or session JWT depending on route).
• Accessibility (heatmap): In Visualization, toggle Color-blind friendly for legend swatches that do not rely on red–green alone; the main coverage heatmap uses the same accessible palette when this option is on.
• Localization: Capacity metrics support imperial/metric; full UI i18n is planned—APIs and exports remain English-first for integration stability.
• Mobile & tablet: The planner targets desktop; shared links are suitable for tablet review. Heavy editing on small screens is not supported.

FAQ