ESPectre

Roadmap

Follow ESPectre from one node sensing platform to multi-node orchestration.

Roadmap · A privacy-first sensing layer

Make spaces responsive without making them watch.

ESPectre is building a local-first sensing layer that turns changes already present in Wi-Fi into useful motion events. Processing stays on the device. ESPectre does not collect images or audio, and the default service boundary does not export raw CSI.

Local by default Motion, not media Built to embed
Planned · after v3.0.0-rc2 v3.0.0
A shared foundation for product integration

Make the sensing layer dependable and easy to carry into products.

Version 3.0.0 is planned as the shared baseline for ESPectre as a reusable platform. One shared sensing core supports several firmware paths, so product teams can add local motion sensing without maintaining a separate implementation for each integration.

Shared architecture
The sensing core and shared runtime intended for the stable v3 baseline.
Runtime contracts
Runtime behavior, Direct WebSocket, and protocol services frozen as one platform contract.
Supported frontends
ESPHome, Native, Matter, and Streamer included in the candidate scope.
Release surfaces
Release artifacts and the embeddable SDK included in whole-platform validation.
PRODUCT DIRECTION

From one node to a shared sensing system.

Each horizon expands what ESPectre can do while keeping the same local-first boundary.

Latest release · unavailable

Put private sensing inside real products.

The v3 line brings ESPectre closer to real products with broader integrations, SDK support, and new sensing capabilities.

  1. v3.1.0Expand Matter support and validate it across more controllers.
  2. v3.2.0Bring ESPectre to Arduino projects through a supported SDK runtime.
  3. v3.3.0Bring ESPectre into Apple Home with a dedicated HomeKit frontend.
  4. v3.4.0Recognize stationary presence, even when no movement is visible.
  5. v3.5.0Explore gesture control and breathing-related micro-motion.
Next major · v4.0.0

Let nearby nodes cooperate as one sensing system.

The planned v4 platform combines local node coordination with an optional web layer. Nodes keep sensing without a managed service and exchange only the minimum derived state required by the supported coordination contract.

  • Discover peers, coordinate traffic, and degrade cleanly when a node disappears.
  • Claim and manage rooms and devices, view live and historical state, and configure alerts.
  • Choose local, self-hosted, or managed deployment without exporting raw CSI.
Future hardware · v5.0.0

Build on Wi-Fi hardware designed for sensing.

v5 starts when practical embedded hardware exposes IEEE 802.11bf or equivalent measurements. Deliberate sensing procedures could make radio data more repeatable, improve coordination between nodes, and open a path to richer presence and motion capabilities.

  • Qualify the first supported radio, driver, and measurement API on real embedded hardware.
  • Add a standards-backed sensing backend and validate every detector against new datasets.
  • Measure calibration, false positives, stationary presence, and multi-node fusion from scratch.
  • Let existing products adopt the new backend through the same SDK and protocol, with a documented migration path from ESP32 CSI.
RESEARCH TRACKS

Research areas under evaluation.

Research does not reserve release scope. A track may become a product, remain a host-side experiment, or end with a measured rejection.

01

5 GHz and new PHYs

Validate HT20 on 5 GHz first, then evaluate VHT20, HE20, and wider layouts with representative detector evidence.

02

Stationary presence

Test whether scale-invariant micro-motion can distinguish an occupied quiet room from an empty one.

03

Brief gestures

Build a gesture-specific corpus only after the high-rate sensing path preserves the necessary short-timescale information.

04

Breathing-related motion

Explore breathing-related micro-motion only after stationary presence is measurable and suitable paired recordings exist.