RuView: Turning WiFi into a Contactless Sensor with ESP32 and Rust

What RuView Actually Solves

RuView addresses a specific gap: extracting human presence, breathing rate, and heart rate from ordinary WiFi signals without any camera, wearable, or microphone. The target user is a privacy-conscious homeowner or integrator who already runs Home Assistant or Apple Home and wants room-level occupancy and vitals without installing dedicated radar hardware. The README claims detection through walls and in the dark, which is plausible given the physics of radio frequency sensing, but the actual performance depends on the environment. RuView is not a general-purpose motion detector; it is a sensing platform that turns CSI data from ESP32 sensors into semantic states like someone-sleeping, possible-distress, and fall-risk-elevated. That places it in the niche of ambient assisted living and smart home automation, not security or high-accuracy medical monitoring.

The CSI Mechanism and Edge Architecture

The core mechanism is Channel State Information (CSI). Every WiFi router emits radio waves that scatter off moving bodies, and RuView captures these disturbances using low-cost ESP32 sensors. The README describes a pipeline where the ESP32 reads radio reflections, and a pretrained model, published on Hugging Face as ruvnet/wifi-densepose-pretrained, interprets the CSI patterns. The model is small, fitting in 8 KB with 4-bit quantization, and runs in microseconds on a Raspberry Pi. The system uses spiking neural networks that adapt to each environment in under 30 seconds, and it scans across 6 WiFi channels, using neighboring routers as additional illuminators. Every measurement is cryptographically attested via an Ed25519 witness chain, which is an unusual and notable feature for a sensing platform. The architecture is edge-only: no cloud, no internet required, and the ESP32 mesh can be as low as $9 per node. This is a fundamentally different approach from camera-based pose estimation or wearable heart rate monitors, because it relies on radio wave perturbations rather than optical or contact signals.

Getting It Running: Commands and Integration Paths

The README gives concrete integration steps. For Home Assistant, you drop into any install with a single --mqtt flag, which publishes via the HA-DISCO MQTT publisher. The system ships 21 entities per node: 11 raw signals and 10 inferred semantic states. There are also 3 starter HA Blueprints. For Apple Home and HomePod, RuView acts as a discoverable HAP-1.1 bridge, and for Google Home, Alexa, and SmartThings, it exposes a Matter endpoint via an ADR-122 design. The MetaHarness, a separate npm package @ruvnet/ruview, provides a doctor command to check local setup, a guidance command for source-cited help, and an agent run command for Codex. For example, npx @ruvnet/ruview@0.4.0 doctor checks the setup, and npx @ruvnet/ruview@0.4.0 guidance --topic sensing --query "model loading" gives guidance. Agent runs are read-only by default; workspace writes require both --allow-write and --confirm. The actual ESP32 firmware and Rust crates are not fully detailed in the README, but the repository is Rust-based and built on RuVector, so you will likely need to compile the firmware from source and flash it to the ESP32 boards.

Honest Accuracy Numbers and a Retraction

A notable strength of this project is its willingness to retract an overclaim. The README states that an older "100% presence" figure was measured on a single-class recording and has been retracted. In its place, the v2 encoder reports a label-free held-out temporal-triplet accuracy of 82.3%, up from 66.4% raw. This is a concrete, honest number, though it is not a direct measure of presence detection accuracy in all rooms. The 82.3% is specifically for temporal-triplet accuracy on a held-out set, which may not translate to real-world multi-room scenarios. This transparency is rare in sensing products and should be weighed positively. However, the README also notes that the unified RF world model, which combines WiFi, radar, UWB, and cellular sensing, has accuracy that is "still synthetic until real-data validation." That is a clear warning: the ambitious multi-modal model is not yet proven. For vital signs, the README gives bandpass ranges: breathing at 0.1-0.5 Hz and heart rate at 0.8-2.0 Hz, with zero-crossing BPM calculations. These are plausible but unvalidated against medical-grade references.

Limitations and Failure Modes

RuView has several genuine limitations. First, the accuracy claims are tied to a specific model and recording setup; the retracted 100% figure shows that single-class recordings can mislead. In a real home with multiple people, furniture, and moving pets, the temporal-triplet accuracy may drop. Second, the system requires a mesh of ESP32 sensors, and the README does not specify how many sensors are needed for a given room size or layout. Third, the RF world model is explicitly synthetic until real-data validation, so any claims about combining WiFi, radar, UWB, and cellular sensing are aspirational. Fourth, the system depends on stable WiFi channels; if your neighbors' routers are not present or are on different channels, the multi-frequency mesh scanning may not work as described. Finally, the semantic states like fall-risk-elevated and possible-distress are inferred, not diagnosed. Using RuView for safety-critical monitoring without independent validation would be a mistake. The README does not mention false positive rates or latency for fall detection, so those remain unknown.

Alternatives and How They Differ

The most direct alternative is a dedicated radar sensor like the Aqara FP2 or the Everywhere Smart Hub, which uses mmWave radar for presence and fall detection. Radar sensors do not rely on WiFi interference and typically have higher accuracy for presence, but they cost more per room and cannot see through walls as effectively as WiFi. Another alternative is a camera-based system like OpenCV with pose estimation, but that defeats the privacy purpose and requires line of sight. RuView's approach differs by using existing WiFi infrastructure, which can penetrate walls and operate in the dark, and by running entirely on edge hardware with no cloud dependency. However, radar sensors are purpose-built for sensing, whereas RuView is a software platform that depends on the quality of your WiFi environment. The README mentions Matter and HomeKit support, which radar sensors also offer, so the integration surface is similar. The key difference is cost and privacy: RuView can be cheaper per room but may require more tuning and validation.

Maintenance, Licensing, and Upgrade Path

RuView is MIT-licensed, which is permissive and allows commercial use, modification, and redistribution with attribution. The repository is not archived and has recent releases, with v2403 pushed on 2026-08-27. The release cadence suggests active development, but the maintenance cost for a user is non-trivial: you need to keep the ESP32 firmware updated, retrain models when your environment changes (the README mentions a built-in model workflow to record CSI and train models), and manage the RVF file format and LoRA profiles. The MetaHarness includes a brain verify command to check claims, which could help with reproducibility. The documentation mentions ADRs (Architecture Decision Records), which is a good sign for long-term maintainability, but you will need to read those to understand upgrade implications. The model is hosted on Hugging Face, so you can track new versions, but you must verify that new models are compatible with your existing sensor firmware. The project's reliance on RuVector and Cognitum Seed means you are also dependent on those upstream projects' stability.

Editorial conclusion

Adopt RuView if you need contactless presence and vital sign monitoring in private spaces where cameras are unacceptable, and you can run an ESP32 mesh plus a local hub like a Raspberry Pi. Do not adopt it if you require validated radar-grade accuracy or if your environment lacks stable WiFi coverage across multiple channels. Before deployment, verify the temporal-triplet accuracy of 82.3% against your own recordings, confirm the RVF model format supports your ESP32 hardware revision, and test the MQTT or Matter bridge with your specific Home Assistant version. The project is MIT-licensed and under active development, but the synthetic RF world model and retracted presence claims mean you must validate sensing claims in your own space before relying on them for safety.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes