RuView reads WiFi CSI from ESP32 nodes for presence and vitals, but its accuracy claims are still unvalidated

Sensing runs on ESP32 CSI nodes, not on the router you already own

RuView starts from the idea that a WiFi router already fills a room with radio waves, and that people moving, breathing or sitting still disturb those waves in measurable ways. The capture side is a separate piece of hardware: RuView reads Channel State Information (CSI) from low-cost ESP32 sensors, and the firmware for those nodes lives in firmware/esp32-csi-node/. Firmware ships on its own release track; the most recent is v0.8.17-esp32, published 2026-10-29 with experimental C5 support. The harness live view covers ESP32 and Realtek RAC1 nodes.

The consequence is practical. Installing the software on a laptop does not turn a home router into a sensor. Plan to buy and flash nodes before any presence or vitals feature produces data, and treat C5 boards as experimental until the firmware notes say otherwise.

install.sh splits the project into seven profiles

The Makefile wraps one script, install.sh. Run bare, it starts a guided interactive installer; the profile targets run it non-interactively with --yes. There are seven profiles: verify, python, rust, browser, docker, field and full. A check-only mode inspects hardware and the environment without installing anything, which is the sensible first run on an unfamiliar machine.

./install.sh --check-only
./install.sh --profile verify --yes
./install.sh --profile rust --yes
./install.sh --profile full --yes

Each profile also has a make target (install-verify, install-rust, install-full and so on), and make check maps to the check-only run. Picking the smallest profile that matches the job matters, because the Python and Rust halves of the project pull in very different toolchains.

A Python package and a Rust workspace carry different dependency weight

Two stacks sit side by side. The Python package in pyproject.toml is named wifi-densepose, version 1.2.0, classified as Development Status 4 Beta, and requires Python 3.9 or newer, with classifiers up to 3.12. Its dependency set includes torch, torchvision, opencv-python and scikit-learn, FastAPI with uvicorn, SQLAlchemy with alembic, asyncpg and psycopg2-binary for PostgreSQL, and Redis clients marked optional. requirements.txt adds websockets, paramiko, asyncio-mqtt and prometheus-client.

The Rust code lives under v2/ and builds with cargo, with a separate WebAssembly target for the browser:

cd v2 && cargo build --release
cd v2 && wasm-pack build crates/wifi-densepose-wasm --target web --release
cd v2 && cargo test --workspace --no-default-features

The cost lands on small machines. The Python dependency list alone brings PyTorch and OpenCV, so anyone who only needs the Rust path should not reach for the full profile by default.

./verify replays a proof and audits the code for mock data

A verify script sits at the repository root next to PROOF.md, and the Makefile calls it the Trust Kill Switch: a one-command proof replay. Verbose mode prints detailed feature statistics and the Doppler spectrum. Audit mode goes further and scans the codebase for mock and random patterns.

./verify
./verify --verbose
./verify --verbose --audit

This is the right first command for anyone asking whether the signal pipeline is real rather than simulated. Its limit is scope. A replay re-runs an existing proof; it does not measure your room, your walls or your node placement. Treat a passing run as evidence that the code path is not faked, not as a promise about how well presence or breathing detection will work in your house.

Pose, vitals and the RF world model are not validated accuracy claims

Several headline features carry caveats from the project itself. Camera-free pose estimates 17 body keypoints from WiFi CSI, but its capability card is titled Pose research and limitations and links to docs/benchmarks/pose-estimation-cog.md. The unified RF world model, which combines WiFi CSI, radar, UWB and cellular sensing, has accuracy the README calls still synthetic until real-data validation. Device-reported vitals are labelled as unvalidated, and the MetaHarness includes an honesty check for accuracy claims.

The feature list also names sleep stage classification, apnea screening and fall detection. Given the labels above, do not treat breathing rate, heart rate, fall-risk or apnea output as diagnostic data, and do not build a care setup that depends on them without your own validation. Read the pose benchmark document before quoting any accuracy figure.

The @ruvnet/ruview harness is read-only until you grant more

The MetaHarness is published as @ruvnet/ruview and runs through npx, pinned in the README to version 0.9.1. It offers source-cited guidance, device access for CSI nodes, radar and LiDAR, firmware flashing with boot evidence, one MCP server over stdio or HTTP for ChatGPT, a Claude Code mod and guarded Claude Code and Codex agents.

npx @ruvnet/[email protected] doctor
npx @ruvnet/[email protected] guidance --topic sensing --query "model loading"
npx @ruvnet/[email protected] devices
npx @ruvnet/[email protected] mmwave --source esphome --host <kit-ip>

The defaults restrict agents. Runs are read-only; workspace writes need both --allow-write and --confirm. Hardware reads need the device-access grant. Flashing and calibration never run over the HTTP transport, so a ChatGPT session connected over HTTP cannot flash or calibrate a node. Retrieved brain content is treated as evidence, not authority. Companion packages are homecore and @ruvnet/ruview-kernel, the vitals pipeline as WASM.

Home Assistant gets 21 entities per node through one --mqtt flag

Smart-home output runs through Home Assistant first. The HA-DISCO MQTT publisher is enabled with a --mqtt flag and exposes 21 entities per node: 11 raw signals and 10 inferred semantic states such as someone-sleeping, possible-distress, bathroom-occupied, fall-risk-elevated, bed-exit and multi-room-transition. Three starter HA Blueprints ship with it, and the repository carries examples/ha-blueprints/ and examples/lovelace/.

Apple Home and HomePod pair with RuView as a discoverable HAP-1.1 bridge. Google Home and Amazon Alexa connect through the same Home Assistant bridge or through a Matter endpoint, covered in ADR-122. The inferred states inherit the validation caveats above: an automation that fires on possible-distress or elderly-inactivity-anomaly is acting on an unvalidated inference, so keep a person in the loop for anything safety related.

Releases are numbered CI snapshots alongside separate firmware tags

The main release stream is CI snapshots with build numbers rather than semantic versions: v3422 on 2026-10-26 and v3446 on 2026-10-29. Firmware is tagged separately, as with v0.8.17-esp32. The Python package reports 1.2.0 and the npm harness 0.9.1, so four different numbering schemes describe one repository. The last push landed on 2026-11-02, and the repository is not archived.

For a deployment, that means recording which snapshot, firmware tag and harness version you installed together. The harness commands already pin @0.9.1; keep that pin rather than pulling the newest package when nodes are running older firmware.

Editorial conclusion

RuView suits people willing to buy and flash ESP32 nodes who want camera-free presence data in Home Assistant or Apple Home. It does not suit anyone who needs validated vitals, pose or fall detection, because the project labels those outputs unvalidated or synthetic. Before deploying, run ./install.sh --check-only and ./verify, and read docs/benchmarks/pose-estimation-cog.md.

Frequently asked questions

Official sources

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