Multiple people moving: The system detects "motion presence" rather than counting individuals. With multiple people, CSI variance increases, so detection works well. Distinguishing how many people would require ML (on the roadmap).
Detection latency: The algorithm processes each packet in real-time (~10ms @ 100 pkt/s), so detection is essentially instant.
The default Home Assistant publish rate is 1 second to avoid flooding the event bus, but it's fully configurable via publish_interval.
Accuracy vs traditional sensors: See PERFORMANCE.md in the repo for detailed benchmarks.
Main advantages over PIR: no line-of-sight needed (Wi-Fi passes through walls) and no dead zones.
On the critical topic of Mesh Routers and Roaming, a possible solution is to force the ESP32 to hook onto the MAC address of a single Access Point, as discussed here:
Thanks for the insights Quinnjh! Would love to hear more about your invisible strings tuning system!
The ESP32-S3 extracts a moving variance signal from spatial turbulence (updates at 20-50 Hz), and I want to map this directly to audio frequency using a passive buzzer + PWM (square wave, 200-2000 Hz range).
Two quick questions:
1. Do you see any pitfalls with updating PWM frequency at 20-50 Hz for responsive theremin-like behavior?
2. Any recommendations on mapping strategies - linear, logarithmic (musical scale), or quantized to specific notes?
My first step is to 'listen' to the raw channels and features to quickly find which mapping produces the most musically coherent (i.e., clean and physically predictable) output.
If it sounds like white noise, the mapping is bad or the signal is artifact.
If it sounds like a sine wave moving predictably, the physics are sound.
That's a great thought. The challenge is that Wi-Fi sensing (CSI) is measuring multipath changes across a few meters, not direct motion in a small volume like Leap Motion. I think its accuracy is measured in centimeters, not sub-millimeters.
Currently, ESPectre performs only binary motion detection (IDLE/MOTION) based on simple statistical thresholding.
It cannot ignore cats or prioritize size over speed directly on the device, but ESPectre's architecture is designed to enable this kind of advanced classification externally.
It collects a rich set of pre-processed features (spatial turbulence, entropy, etc.) and transmits them via MQTT.
Any external server (like a Home Assistant add-on or a dedicated Python script) can use these features as the input for a trained ML model to perform classification (e.g., Cat vs. Human vs. Fall detection vs. Gesture detection).
Regardin Ruckus Router / Beamforming: for CSI sensing, stability is generally more important than raw power. I recommend starting by disabling beamforming or reducing the power output if you experience poor motion sensitivity, as the stability of the ESP32 receiver is often the bottleneck.
The project’s open-source nature acts as an ethical safeguard, and I am explicitly not pursuing any identity recognition features, just movement detection.
But you are absolutely right that, in theory, misuse of this technology could reveal certain behavioral patterns that might lead to identification.
However, it can also be extremely useful for safety purposes, for example, detecting people during a house fire or an earthquake.
You hit the nail on the head! That's precisely the motivation.
Having two kids myself, I've thought of turning it into a game: blindfolded hide-and-seek where the pitch of the Wi-Fi Theremin tells the seeker how close they are to the 'signal disruption' of the other person. It's essentially a real-time sonar game!
The final statistic I threshold is the Moving Variance of Spatial Turbulence.
The decision is a binary comparison: When moving_variance > threshold then MOTION state (movement detected) else IDLE state.
The features are extracted only during MOTION segments (to save CPU cycles) and published via MQTT.
They serve as rich foundation data for potential external ML models (e.g., to capture nuances like gestures, running, or falling), but they are absolutely not used for the core segmentation decision itself.
The price difference can vary wildly by region, but €10 is still super cheap compared to a dedicated presence sensor!
Regarding the chip recommendation, it’s a classic trade-off:
ESP32-S3: This is what I mainly recommend today. It gives you more raw processing power (dual-core), which is great for managing the OS, MQTT, and the CSI analysis without hiccups.
ESP32-C6: I just ordered a C6 myself to run extensive tests! The C6 might have a superior quality Wi-Fi module and better internal CSI extraction capabilities due to hardware improvements.
Fun fact: I’m working on turning ESPectre into a Wi‑Fi Theremin (the musical instrument you play by moving your hands near an antenna).
The idea of “playing” by simply moving around a room sounds a bit ridiculous… but also kind of fun.
The key is the Moving Variance of the spatial turbulence: this value is continuous and stable, making it perfect for mapping directly to pitch/frequency, just like the original Theremin. Other features can be mapped to volume and timbre.
It’s pure signal processing, running entirely on the ESP32. Has anyone here experimented with audio synthesis or sonification using real-time signal processing?
Interesting note, I actually disabled promiscuous mode after some testing because it made the CSI signal noisier and consumed more resources.
I found that normal station mode with pings to gateway gave me cleaner, more predictable CSI data. But your MAC filtering approach might mitigate those issues!
You're spot on about the MVS approach. It's essentially a sliding window variance of the spatial turbulence (std dev across subcarriers), with adaptive thresholding based on the moving variance of that signal.
If you're interested in the MVS details, I wrote a free Medium article that walks through the segmentation algorithm step-by-step with visualizations. Links are in the README.
Your approach is actually quite similar to what I'm doing, just in a different order:
- My flow: Raw CSI → Segmentation (MVS) → Filters (Butterworth/Wavelet/Hampel/SG) → Feature extraction
- Your flow: Raw CSI → EWMA de-meaning → Dimensionality reduction → Feature extraction
The main difference is that I segment first to separate IDLE from MOTION states (keeping segmentation on raw, unfiltered CSI to preserve motion sensitivity), then only extract features during MOTION (to save CPU cycles).
Thanks for the thoughtful feedback! Always great to exchange notes with someone who's been in the trenches with CSI signal processing
It really depends on the environment: wall materials, interference, signal strength, and even temperature and humidity all play a role. Honestly, 100 m² is probably too large for a single sensor to cover reliably.
That said, ESP32 boards are very inexpensive, you can find them online for around €1 or even less.
Sure, the ESP32 will connect to whichever mesh node provides the best 2.4 GHz signal
- It monitors CSI from that specific node (the one it's associated with)
- If the ESP32 roams to a different mesh node, it will start monitoring CSI from the new node
The system doesn't care about the router's internal mesh topology, it just needs a stable connection to receive CSI data from the associated access point.
Hi kristianpaul, this is Francesco Pace, the author of the project (ESPectre).
Thank you so much for sharing my repository truly appreciate you giving it an early signal boost!
I just posted an official Show HN for the project (titled 'Show HN: ESPectre – Motion detection based on Wi-Fi spectre analysis') and am actively answering all technical questions there.
Multiple people moving: The system detects "motion presence" rather than counting individuals. With multiple people, CSI variance increases, so detection works well. Distinguishing how many people would require ML (on the roadmap).
Detection latency: The algorithm processes each packet in real-time (~10ms @ 100 pkt/s), so detection is essentially instant. The default Home Assistant publish rate is 1 second to avoid flooding the event bus, but it's fully configurable via publish_interval.
Accuracy vs traditional sensors: See PERFORMANCE.md in the repo for detailed benchmarks.
Main advantages over PIR: no line-of-sight needed (Wi-Fi passes through walls) and no dead zones.
Happy to answer more questions!