I recently came across a striking project on GitHub: RuView.
It claims you need no camera and no wearable—just Wi-Fi in the room—to detect presence, motion, respiration, heart rate, and even attempt pose estimation.
When I looked it up, it already had more than 86k stars. That sounded like science fiction, so I decided not to stop at the README. I cloned it, deployed what I could, and tested.
How is it supposed to work?
As Wi-Fi signals move through a room, walls, furniture, and bodies keep reflecting them. Someone walking in, waving, or even just breathing changes the paths those signals take.
RuView uses an ESP32 to collect CSI—channel state information. Unlike RSSI, which is a single strength number, CSI can record amplitude and phase across dozens of Wi-Fi subcarriers over time. The stack then denoises, processes phase, runs spectral analysis, calibrates the room, and uses rules or models to infer whether someone is present, moving, and possibly how respiration and heart rate are changing.
So RuView is not literally “seeing” people through walls the way a camera would. More accurately, it watches how the wireless channel changes, then guesses what might have caused those changes.
How I set it up
I started by cloning the repo:
git clone https://github.com/ruvnet/RuView.git
cd RuViewThis is not a simple Python utility. It includes a Rust sensing server, ESP32 firmware, Python and Node clients, web and desktop UIs, Home Assistant integration, and a lot of experimental modules. Roughly:
- 2,700+ files
- 700+ Rust files
- ~38 Rust crates
- 8 Git submodules
Docker Desktop wasn’t running on my machine, and I didn’t have a Rust toolchain installed, so I took the shortest path: the official Python wheel.
The first step already failed. Running:
pip install wifi-denseposegot me 1.99.0—a tombstone release that errors on import and tells you to install stable 2.0.0, which doesn’t exist yet.
I had to pin the alpha explicitly:
py -3.11 -m venv .venv
.\.venv\Scripts\python -m pip install "wifi-densepose==2.0.0a1"That installed cleanly, and the compiled Rust/Python bindings loaded.
What did I actually test?
I don’t have an ESP32-S3, so I didn’t pretend I ran a real-room trial. I did two kinds of checks.
First, synthetic vital-sign signals. I fed the algorithm a simulated 72 BPM heart-rate signal:
- Output: 72.289 BPM
- Confidence: 0.845
- Status: Valid
Solid. Then a simulated 15 BPM respiration signal:
- Output: 18 BPM
- Confidence: 0.309
- Status: Unreliable
So the DSP interface runs and can extract results from periodic signals. It also shows that producing a number is not the same as producing a trustworthy number.
Second, the public Observatory Demo. The page rendered the 3D canvas without console errors. I switched from auto-rotate to multi-person mode and saw two people with an ACTIVE status. The front end feels polished.
But the page clearly says DEMO. These are preset or simulated scenes. They prove the showcase works—not that real Wi-Fi human sensing is accurate.
What I think it does well
It is chasing a real, valuable idea. Compared with cameras, Wi-Fi sensing doesn’t capture faces or video, and it can work in the dark, behind some occlusion, even partly through walls. For bedrooms, bathrooms, elder care, and privacy-sensitive spaces, that is genuinely attractive.
It also prefers local and edge execution. The ESP32 collects; the server can process on the LAN. You don’t have to ship raw data to the cloud.
Extensibility is strong: REST, WebSocket, MQTT, Home Assistant, Matter, Python, Rust, WASM, desktop. This isn’t just an algorithm demo—it’s trying to be a full ambient-sensing platform.
I also like that the repo is starting to separate real validation, synthetic data, and research ideas. It openly says the single-ESP32 17-keypoint pose model is still v1, and some occupancy counting is heuristic rather than a trained classifier.
The biggest problems right now
The hard part is not collecting CSI. Real users have shown ESP32s can capture and send real CSI. The hard part is stably turning channel changes into “someone is here.”
One user ran a controlled experiment with three ESP32-S3 boards. After ruling out clock drift and Wi-Fi association-mode changes, presence detection from raw amplitude features had an AUC around 0.58—close to chance. Maintainers replied clearly: reliable presence needs per-room calibration and training, not generic rules or raw CSI alone.
So it is not an out-of-the-box sensor yet. Room layout, device placement, temperature, fans, microwaves, neighboring APs, and TX power shifts can all cause false positives.
Hardware compatibility is still rough. Some report prebuilt ESP32 firmware that never outputs CSI; ESP32-C6 can fail to reconnect after a drop; multi-node setups hit time sync and fusion failures.
Security gaps are obvious too. CSI goes over UDP by default; the receiver listens on all interfaces; there is no node auth, HMAC, replay protection, or source allowlist. On an isolated home LAN that may be manageable. In enterprises, hospitals, or anything exposed to the internet, it needs a redesign.
What stage is it in?
My take: RuView is past a thin proof of concept, but not a stable product.
Data collection, protocols, APIs, and demos moved fast. Real-world accuracy, cross-room generalization, hardware consistency, and long-running stability still lag behind how complete the marketing surface looks.
The project is very active—and expanding too fast. Research tracks, hardware ports, edge modules, and product integrations all live in one repo; tags and release packages are messy.
It fits RF, IoT, edge, and ML teams who want to experiment. It should not carry medical, elder-care, or industrial-safety responsibility today.
Why I still think it has a future
Wi-Fi sensing itself is not a fake idea. CSI really can reflect motion, breathing, and environmental change. The real question is stability across rooms, APs, devices, and time.
If RuView can next:
- build larger real-room datasets
- make per-room calibration simple and reliable
- ship reproducible presence and pose models
- publish a clear hardware/firmware compatibility matrix
- harden data-plane auth and security boundaries
- replace simulated demo metrics with blind and long-term tests
then it could grow from an eye-catching research project into a genuinely useful camera-free spatial sensing platform.
Closing
RuView is one of the most imaginative open-source projects I’ve seen lately. It sketches a future where a room knows someone is there—without photographing anyone.
As things stand, I’ll watch it, study it, and maybe run a small single-room experiment. I won’t use it for medical monitoring, fall alerts, or industrial safety, and I won’t treat a simulated demo as real accuracy.
For me, the honest label isn’t “Wi-Fi that already sees through walls.” It’s an open proving ground trying to find out how far this idea can actually go.
I’ll leave you with a few questions:
If a sensor never records video but is less accurate than a camera for now, would you trade some accuracy for more privacy? What false-positive rate can you live with? And when Wi-Fi starts sensing bodies, is it really more “private” than a camera?
