RuView: The Open-Source Project That Sees Through Walls With WiFi

RuView turns commodity WiFi signals into real-time spatial intelligence, vital sign monitoring and presence detection, in the project's own words, without a single pixel of video. Your router already floods every room with radio waves. When a person moves, or even breathes, those waves scatter differently. RuView reads that scattering pattern, called Channel State Information or CSI, and reconstructs what happened: someone is in the room, how many people there are, whether they are moving, how fast they are breathing, and what their heart rate is doing.

The numbers explain the attention. The repository, from the ruvnet organization, was created in June 2025 and had 101,423 stars and 13,182 forks when we checked on October 29, 2026. It is written mostly in Rust, licensed under MIT, and built to run on edge hardware rather than in the cloud. A small pretrained model published on Hugging Face does the sensing, and the whole stack is designed so your rooms can be aware of you without a camera ever watching you.

The pipeline starts with the WiFi you already have. A mesh of 4 to 6 ESP32 nodes captures CSI on channels 1, 6 and 11, and multi-band fusion combines 3 channels with 56 subcarriers each into 168 virtual subcarriers per link. Fusing the viewpoints of every node pair gives an attention-weighted picture of the room, a coherence gate throws out unstable measurements, and classic signal processing (Hampel filtering, SpotFi, Fresnel-zone geometry, breathing and heart-rate extraction, spectrograms) cleans up what is left. Then the AI backbone, called RuVector, turns those features into output: real-time pose, breathing, heart rate, a fingerprint of the room, and drift alerts when the room changes.

Two details make it more than a demo. First, the system learns each room on its own. Its self-learning pipeline builds compact fingerprints from raw CSI and adapts to a new environment, with spiking neural networks that the README says adapt in under 30 seconds. Second, the sensing model is tiny. The pretrained encoder fits in 8 KB when quantized to 4 bits and runs in microseconds on a Raspberry Pi, with a held-out temporal-triplet accuracy of 82.3 percent that the project re-benchmarked honestly after retracting an earlier, weaker 100 percent presence claim measured on a single recording. That kind of self-correction is rare in a README, and it is a good sign.

The most relatable use is the smart home. Room-level presence that works through walls means lights, heating and music that follow real occupancy instead of motion-sensor timeouts, with no dead zones. Elderly care is the most human one: fall detection in under 2 seconds and nighttime breathing monitoring with no wearable the person has to remember to charge or wear. Hospitals get continuous breathing and heart rate for non-critical beds without wired sensors, retail gets foot traffic and dwell time by zone, offices get true desk and meeting-room utilization, and hotels get occupancy-driven energy savings the project puts at 15 to 30 percent on HVAC.

Then it gets more extreme, because WiFi goes where cameras cannot. The disaster module, called WiFi-Mat, is built to detect survivors through rubble by their breathing signature, through 30 cm of concrete. Firefighters can locate occupants through smoke and walls before entry. Warehouses get forklift proximity alerts through shelving, and the project ships a catalog of 105 edge modules, small programs that run directly on the ESP32 sensor with no internet, covering health, security, building, retail, industrial and research jobs. Each access point distinguishes roughly 3 to 5 people, and a 4-AP mesh covers about 15 to 20 occupants, so the practical ceiling is signal physics, not software limits.

RuView works natively with the four major smart-home ecosystems, which is unusual for a project this deep in signal processing. Home Assistant connects through an MQTT publisher, Apple Home sees it as a discoverable HAP-1.1 bridge, and Google Home and Amazon Alexa come along through the same Home Assistant bridge or a Matter endpoint. Siri, Google Assistant and Alexa can then voice presence and vitals by room with no custom skills to build.

The practical effect is that a room can report itself. A bedroom that knows someone is asleep and breathing steadily, a living room that knows it is empty and can let the heating drop, a hallway that knows someone fell and has not moved. All of that arrives over the WiFi and sensor mesh you already run, with the heavier features, persistent memory and a cryptographic witness chain, available through the optional Cognitum Seed device the project sells for around 140 dollars total hardware.

The privacy argument is the project's strongest card, and it is real as far as it goes. There is no video, so deployments sidestep the consent, signage and retention rules that come with cameras, and the README notes that avoiding video keeps GDPR video and HIPAA imaging rules out of the picture by design. Everything runs on edge hardware, an ESP32 mesh paired with local processing, with no cloud and no internet required, and every measurement can be cryptographically attested through an Ed25519 witness chain.

But honest framing cuts both ways. A sensor that counts people through walls and reads breathing is still a sensor that watches people, and presence plus vitals is sensitive data even when no face is attached. The right question is not whether RuView is private in the abstract, it is who controls the sensor, who sees its output, and whether the people being sensed know it is there. In your own home, with your own hardware and your own data, the answer is good. Pointed at someone else's room, the same technology is surveillance. The tool does not decide that. You do.

The fastest trial needs no hardware at all. Pull the Docker image ruvnet/wifi-densepose, run it on port 3000 and open localhost:3000, but know that Docker runs on simulated data, so it shows you the system, not your rooms. For live sensing you need CSI-capable hardware. The recommended path is an ESP32-S3 mesh, about 9 dollars per node: flash the CSI node firmware, provision your WiFi credentials, and watch live data with the project's npm toolkit, which also ships an MCP server and a Claude Code sensing pane.

A cheaper research option is the ESP32-C6 board at 6 to 10 dollars, and a Python package is on PyPI under both ruview and wifi-densepose, the same compiled wheel under two names. One warning from the README matters here: a normal laptop WiFi card only gives RSSI, coarse signal strength, which is enough for rough presence and motion but not for breathing, heart rate or pose. Those need real CSI from an ESP32-S3 or a research network card.

RuView is beta software, and the README says so plainly. APIs and firmware may change. The ESP32-C3 and the original ESP32 are not supported, because a single core cannot handle the CSI signal processing, and a single ESP32 node gives limited spatial resolution, so plan on two or more nodes.

The bigger caveats are about what the models can actually do today. The on-device pose model is a first cut: its PCK@20 score is around 3 percent, far below the 35 percent target, and its runtime path is still a stub. The widely quoted 82.69 percent figure is a separate benchmark result on the MM-Fi dataset, not the live on-device model, and the project is explicit about that distinction. Vital-sign outputs are labelled unvalidated, and the README draws a safety boundary in bold: these are research and prototype applications, not medical devices, emergency systems or safety-certified controls, and any vital-sign or pose output needs independent validation on your exact hardware, room, subjects and failure conditions before operational use. Cross-room pose without retraining is still a proposed research direction, not a solved problem. None of that makes RuView uninteresting. It makes it a project to adopt with eyes open, which is exactly how its own documentation treats it.