ruvnet/RuView

RuView is an ambitious WiFi-sensing stack: ESP32 nodes capture Channel State Information, and a Rust/Python pipeline turns it into presence, keypoints and breathing/heart-rate estimates. The project is unusually candid about which checkpoints are validated and which are not, and that honesty is the main reason to read it before wiring anything up.

The problem

You want to know whether someone is in a room, roughly what they are doing, and whether they are breathing — without mounting cameras, asking people to wear bands, or paying for a commercial radar installation. Traditionally this means either a camera with all its privacy baggage, or PIR/motion sensors that go blind the moment a person sits still. RuView proposes replacing that hardware layer with WiFi radios that are already present: the ESP32 nodes collect CSI, and the software reports occupancy, pose keypoints and vital-sign estimates to a downstream consumer such as Home Assistant. The workflow change is that sensing becomes a software problem on cheap radio hardware rather than a camera-and-cloud problem.

What's different

The mechanism is multistatic CSI fusion: several ESP32 nodes listen on channels 1/6/11, the pipeline combines subcarriers across links, applies signal cleaning (Hampel, SpotFi, Fresnel, BVP), and runs a neural backbone to produce 17 body keypoints plus vital signs. A coherence gate is supposed to accept or reject noisy measurements so the model does not drift with every furniture move, and per-node LoRA adapters allow environment-specific fine-tuning. Some edge modules run on the ESP32 itself, so simple detections work without internet or cloud fees.

The trade-off is that the headline claims and the actual maturity are separated by several tiers. The README's own labeling ADR distinguishes validated, experimental and architecture-only checkpoints; the pretrained release reports 82.3% held-out temporal-triplet accuracy for its encoder, and the older "100% presence" figure was explicitly retracted because it came from a single-class recording. Torso-PCK numbers around 82–84% for the MM-Fi pose model are reported by the project, not independently reproduced here. None of this means the technique is not real — WiFi CSI sensing is an established research area — but it does mean the demo GIF should not be read as a finished product.

Who should try it

Good fit: an experimenter with a handful of ESP32 boards, a Home Assistant setup and willingness to tune radio placement, who wants to explore CSI-based occupancy or vitals and can read the model-maturity table carefully. Also a reasonable fit for someone studying the signal-processing chain, since the pipeline is documented at an unusually granular level.

Poor fit: anyone who needs a drop-in room-monitoring product today, a renter who cannot place several nodes around a room, or a user whose primary interest is accurate pose rather than a research platform. The smart-home integrations (Home Assistant MQTT, Apple Home bridge, Google Home) exist, but treating them as turnkey would misread the project's stage. A commenter on the March thread asked whether anyone had run it on real hardware and found no public verification outside the author at that time; later Show HN replies are enthusiasm rather than independent reports.

Requirements and limitations

Hardware is the first filter: four to six ESP32 CSI-capable nodes plus a router are needed for the multistatic setup described, and node placement affects results, so this is not a one-board evening project. The Rust toolchain requires 1.85+, and the Python package is published separately. Beyond setup, the ongoing work is calibration: environment changes, moved furniture and per-room adapters mean the coherence gate and LoRA tuning are part of normal upkeep rather than a one-time configuration.

The second constraint is evidentiary. The project's own labeling document says some checkpoints are architecture-only, and the pretrained encoder's accuracy is a held-out triplet metric, not a guarantee of pose quality in your room. Cross-room pose is described as a separate, data-gated effort. Treat reported benchmarks as the author's measurements and plan a small pilot before committing a whole home to it.

HotRepo's take

HotRepo recorded 14 board days between 2026-07-05 and 2026-10-26, from 76,576 to 99,663 stars, with the last three recorded days averaging +312/day versus +454/day in the three before. That is a snapshot of a very popular repository whose recorded growth is slowing, not a verified adoption curve. The more useful signal is the March HN thread, titled around the claim that nobody could run it, and the project's own honest-labeling ADR, which suggests the maintainers have since tried to separate demonstrated from aspirational capabilities. Before investing, check the model-maturity table and confirm which checkpoint covers the sensing task you actually need.