# RuView: WiFi presence sensing, and the accuracy number it withdrew

> π RuView reads Channel State Information from ESP32 sensors and turns it into presence, breathing rate and heart rate with no camera involved. The most useful line in the README is the number it withdraws: the old 100% presence figure was measured on a single-class recording, and a held-out temporal-triplet accuracy of 82.3% is what replaced it.

**ruvnet/RuView** — RuView turns commodity WiFi signals into real-time spatial sensing, detecting people and vital signs through walls without cameras, with native smart-home integration.

- Repository: https://github.com/ruvnet/RuView
- Website: https://Cognitum.One/RuView
- Stars: 95,506 · Forks: 12,615
- Language: Rust
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/ruvnet-ruview

## The 100% presence figure was withdrawn, and 82.3% took its place

One line in the README is worth more than everything else on accuracy. The v2 encoder is reported at a label-free held-out temporal-triplet accuracy of 82.3%, up from 66.4% raw, and the same sentence records that the older 100% presence figure was measured on a single-class recording and has been retracted in favour of that number. The 100% was not a rounding artefact in a table. It was a claim that did not survive being measured against data holding more than one class.

Consequence: any comparison you have read against the 100% is void, and a reader taking 82.3% at face value is still taking a number whose baseline is a held-out split the project itself chose. Roughly one detection in five will not land. That is a workable number for switching a light on when somebody walks into a room, and a bad one for deciding that a person has stopped breathing.

## Two bandpass windows decide what a node is even able to see

The sensing table pairs each measurement with its method and its range. Breathing rate comes from a bandpass of 0.1 to 0.5 Hz on wrapped phase, then circular variance and zero-crossing BPM, reported from 6 to 30 BPM in real time. Heart rate uses a bandpass of 0.8 to 2.0 Hz with zero-crossing BPM, reported from 40 to 120 BPM. Presence detection is a trained head published on Hugging Face at ruvnet/wifi-densepose-pretrained.

Consequence: those two windows are the entire contract. A respiratory rate outside 0.1 to 0.5 Hz is not reported as a low reading, it sits outside the filter, so a person breathing below 6 or above 30 BPM produces no number at all rather than a number you could alarm on. The zero-crossing method also returns a BPM figure with no uncertainty attached, which means a home automation receives a vital sign that looks exactly as solid as a light switch.

## A node publishes 21 entities, and 10 of them are conclusions

The Home Assistant path is the widest integration described: drop into any install with one --mqtt flag, or pair as a Matter Bridge into Apple Home, Google Home, Alexa and SmartThings, with Apple Home and HomePod reached through a discoverable HAP-1.1 bridge. Every node ships 21 entities, split into 11 raw signals and 10 inferred semantic states: someone-sleeping, possible-distress, room-active, elderly-inactivity-anomaly, meeting-in-progress, bathroom-occupied, fall-risk-elevated, bed-exit, no-movement and multi-room-transition. Three starter blueprints come with them, and a local automation layer called HOMECORE adds state, history, signed Wasm plugins and voice hooks on top.

Consequence: the entity count flatters the output. Only 11 of the 21 are measurements, and the rest are drawn from them, so a dashboard showing fall-risk-elevated is showing a model's reading of a filtered signal rather than a fall. Home Assistant will switch a light on that state without complaint, which is precisely how an inference gets treated as a sensor.

## The unified RF world model is synthetic until real-data validation

Among the included capabilities, the unified RF world model is described as combining WiFi CSI, radar, UWB and cellular sensing in one privacy-bounded scene model, and the same bullet says its accuracy is still synthetic until real-data validation. That qualifier carries a lot of weight in a list whose neighbouring bullets make confident claims about what the system senses.

Consequence: the four-sensor fusion layer is a schema, not a result. Anyone expecting radar or UWB input to lift the WiFi-only numbers is reading a design document, because the project states plainly that no measured accuracy exists for the combined model. Judge the WiFi path on the 82.3% figure and treat the fusion layer as scaffolding you would have to validate yourself.

## pyproject.toml and requirements.txt ask for different floors on the same packages

Two dependency manifests sit at the root and they disagree. The package metadata, which publishes wifi-densepose at version 1.2.0 and requires Python 3.9 or newer, asks for pydantic 2.5.0 or newer, fastapi 0.104.0 or newer, asyncpg 0.29.0 or newer and redis 5.0.0 or newer. requirements.txt asks for pydantic 1.10.0 or newer, fastapi 0.95.0 or newer, asyncpg 0.28.0 or newer and redis 4.5.0 or newer. One of its entries, psutil, carries a comment naming the modules that import it: health.py, metrics.py, status.py and monitoring.py.

Consequence: which file you install from decides whether your pydantic is v1 or v2, and those two carry different model APIs. A contributor following one file and an operator following the other can end up with the same repository and two different environments, and nothing in the tree says which manifest is authoritative.

## Seven install targets all hand off to one shell script

No target in the Makefile installs anything itself. The install target runs the interactive installer, and seven profile targets pass a profile name and a yes flag into the same script:

```bash
./install.sh --profile full --yes
./install.sh --profile field --yes
./install.sh --check-only
```

The profiles are verify, python, rust, browser, docker, field and full, and the check target passes --check-only for a hardware and environment check with no install at all. Verification is a separate family: verify runs ./verify, verify-verbose adds --verbose for feature statistics and a Doppler spectrum, and verify-audit adds --audit, described in the file as scanning the codebase for mock and random patterns.

Consequence: a first-time user cannot see what a profile does before it runs, and the default is the interactive one, so an unattended install has to choose a profile target instead. The audit target is the more interesting one. A repository scanning itself for mock and random patterns is unusual, and it runs as its own command rather than as part of the proof replay.

## The Rust half lives in v2/, and the test target disables the default features

Every Rust target changes directory into v2 before doing anything. build-rust runs cargo build --release there, test-rust runs cargo test --workspace --no-default-features, bench runs cargo bench --package wifi-densepose-signal, and the two WebAssembly targets run wasm-pack build on crates/wifi-densepose-wasm for the web target, one of them adding the mat feature. The top level meanwhile holds v2/, wifi_densepose/, wifi-veil/ and python/ next to each other.

Consequence: the test suite is not exercising the configuration you would ship. --no-default-features means whatever the defaults enable goes untested, so a build that works under cargo build --release can behave differently under cargo test. Four parallel-looking directories at the root, only one of which the Makefile names, also means which tree you are meant to edit is settled by convention rather than by the build.

## Three releases in two days, and only one carries a version number

The three most recent tags are v2934 on 2026-09-30, bfi-research-v0.1.0-rc.1 the same day, and v0.8.13-esp32 on 2026-09-29 marked as a pre-release whose note says sensors that go quiet now fix themselves. The Python package in the repository metadata is separately at 1.2.0. The last push to main is dated 2026-09-29, the licence is MIT, and the project is not archived.

Consequence: there is no single version to pin, because the platform, the research tools and the ESP32 firmware move on three independent lines and one of them is a bare build number. A deployment that records a commit hash has recorded the trunk, not the firmware sitting on a sensor nobody reflashed. The pre-release note also names a class of failure, a sensor that stops reporting, which platform and firmware versions may not fix between them.

## Conclusion

Treat RuView as a research platform that publishes its own error bars, not as something to install on a weekend and trust in a bedroom. Read the two sentences the README already gives you before pointing it at a person: the unified RF world model is synthetic until real-data validation, and the 100% presence figure was withdrawn in favour of 82.3%. Ten of the twenty-one entities a node publishes are inferred states, so an automation reacting to possible-distress is acting on a model's reading of a bandpass filter. If you want a dependency you can reason about, note that every install path is a profile flag handed to one shell script, and that the two Python manifests ask for different floors on pydantic, so pick one and verify it before you build on it.

## FAQ

### Is RuView free to use?

The code is published under the MIT licence, and the sensing hardware is described as an ESP32 mesh at as low as $9 per node, paired with a Cognitum Seed for persistent memory, cryptographic attestation and AI integration. The README states no licence fee for the software itself.

### What is RuView WiFi?

It is a WiFi sensing platform that captures Channel State Information from low-cost ESP32 sensors and turns the resulting disturbances into presence, breathing rate, heart rate and activity data. The project states it runs entirely on edge hardware with no cloud, no cameras and no internet required.

### How do I install RuView?

The Makefile routes every install through install.sh. make install runs it interactively, and profile targets pass a name and a yes flag, for example ./install.sh --profile full --yes or ./install.sh --profile field --yes, with verify, python, rust, browser, docker and field as the other profiles. ./install.sh --check-only does a hardware and environment check without installing.

### Can my WiFi router track movement in my home?

Not through this project alone. RuView reads Channel State Information from ESP32 sensor nodes rather than from the router, and it describes multi-frequency mesh scanning across 6 WiFi channels that uses your neighbours' routers as free radar illuminators. The router supplies the signal; the nodes do the sensing.

### Can you use RuView on an iPhone?

No iPhone client is described. The interfaces named are Home Assistant over MQTT with a one --mqtt flag, Apple Home and HomePod through a discoverable HAP-1.1 bridge, and a Matter Bridge into Apple Home, Google Home, Alexa and SmartThings. Reading the output from a phone would mean going through one of those.

## Sources

- [Official documentation](https://Cognitum.One/RuView)
- [Official README](https://github.com/ruvnet/RuView#readme)
- [Project repository](https://github.com/ruvnet/RuView)
- [Release notes](https://github.com/ruvnet/RuView/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ruvnet-ruview