RuView: WiFi spatial sensing and a dispute over its maturity

Everything you need to know about ruvnet/RuView: a WiFi CSI sensing repository that claims to detect presence, movement, and vital signs without video, backed by extensive documentation and a sharply divided community reception.

What RuView is

RuView presents itself as an edge spatial-intelligence platform. Its approach is to read WiFi Channel State Information (CSI) with ESP32 nodes and turn signal changes into presence, movement, breathing, pulse, occupancy and, in some cases, pose estimation. The repository claims processing can happen entirely locally, with no cameras and no internet connection, and that the typical deployment combines an ESP32-S3 mesh with, optionally, Cognitum Seed.

Close-up of an ESP32-S3 node emitting neon-cyan WiFi signals that form a mesh network with other nodes, visualizing Channel State Information (CSI) as pulsing geometric wavefronts.

The stated scope is very broad: ESP32 firmware, a sensing server, models, a Docker image, Python packages, a Rust library, and connectors for MQTT, Home Assistant, Matter, and home assistants. The README flags an important limitation: Docker uses simulated data; the advanced capabilities require hardware that exposes CSI, such as ESP32-S3, ESP32-C6 (still in research), or certain network cards. A conventional WiFi laptop is limited to RSSI-based presence and movement.

The project includes warnings worth keeping in mind: it defines itself as beta software; its own README says the built-in 17-point pose model for ESP32 is a first cut, falls short of its target, and its inference path returns zero confidence. It also documents that the Hugging Face model file is not yet accepted by the server’s --model option. Those caveats come from the project itself, not from an independent audit.

The origin: from wifi-densepose to RuView

The GitHub API dates the repository’s creation to June 7, 2025. The author account is ruvnet, whose profile identifies as rUv, links to Cognitum.One, and describes their company as “Not a Bot”. No independent launch post was found that would allow reconstructing the personal motivation or an initial announcement with precision.

The verifiable public history does show a rename: installation tutorial issue #34, created on February 28, 2026, explicitly states that the repository moved from wifi-densepose to RuView. A Hacker News thread from December 26, 2025 still linked to ruvnet/wifi-densepose; another from March 3, 2026 already linked to ruvnet/RuView.

The tension surrounding the project is not purely technical. The pitch proposes privacy by avoiding video, while commenters objected that sensing through walls without consent can amount to surveillance. In parallel, the current README tries to separate measured results from aspirations: it retracts an earlier claim of 100 percent presence accuracy, reports 82.3 percent for a temporary test of its encoder, and labels several capabilities as experimental or pending. That self-correction is an editorial feature of the README; it does not substitute for external replication.

Split illustration: on the left a neon shield symbolizing camera-free privacy; on the right a warning sign with an eye made of WiFi waves symbolizing concern over passive surveillance.

Philosophy and principles

The proposal is built around four ideas that are verifiable in the documentation:

No pixels, no cameras: capture radio signals instead of images or video.
Edge processing: use ESP32 nodes and local processing to reduce cloud dependency.
Local calibration: learn a fingerprint of each environment from CSI and adapt models per room.
Claim traceability: the repository publishes a deterministic proof, attestation logs, and a policy that separates measured, experimental, and pending capabilities.

This last principle has a concrete application: the portable harness npx @ruvnet/ruview advertises a claims-checking feature that flags unlabeled figures or the old, retracted claim. It is a project tool; its effectiveness has not been independently validated here.

A digital scale comparing a bright green neon checkmark, representing measured capabilities and local calibration, against a glowing orange neon question mark, representing experimental and pending features.

How it works

The technical flow described by the README is as follows:

A compatible ESP32 node captures CSI from WiFi transmissions; a mesh can collect several links and channels.
The server combines channels and nodes, cleans the signal, and computes features for presence, movement, vital signs, or room fingerprints.
Outputs can reach a web interface, MQTT, or home integrations. Home Assistant is configured with --mqtt; the documentation also describes a Matter bridge for Apple Home, Google Home, Alexa, and SmartThings.
For experimentation without hardware, the documented startup is docker pull ruvnet/wifi-densepose:latest and docker run -p 3000:3000 ruvnet/wifi-densepose:latest. For a real node, the README provides build, flashing, and provisioning commands for ESP32.

Futuristic dark-mode server dashboard showing RuView processing WiFi CSI data, with neon green and orange data streams and a 3D room map showing a moving figure, with no cloud icons, emphasizing edge computing.

There is also a learning flow: cargo run -p wifi-densepose-sensing-server -- --pretrain to pretrain on CSI, --train for labeled training, and --embed or --build-index to extract and query fingerprints. This is a documented interface, not evidence that every mode produces useful results on any hardware or in any room.

Futuristic command-line terminal showing Rust code and commands like cargo run -- --pretrain and npx @ruvnet/ruview, with holographic 17-point human pose models labeled experimental and showing zero confidence.

For coding agents, the repository ships a Claude Code plugin with nine skills, seven /ruview-* commands, and three agents. The README states the commands are mirrored as Codex prompts by copying files to ~/.codex/prompts/; the npx @ruvnet/ruview harness exposes MCP tools for operation and verification.

Official and semi-official status

No evidence was found that RuView has been accepted into an official marketplace run by Anthropic, OpenAI, Home Assistant, Matter, Apple, Google, or Amazon. The repository does publish its own marketplace manifest for its Claude Code plugin and uses badges claiming compatibility with Home Assistant, Matter, Apple Home, Google Home, and Alexa. Those badges and the documentation are claims made by the project, not certifications from those vendors.

In practice, there is documented technical integration for MQTT, Home Assistant, and a Matter bridge; that can ease adoption within those ecosystems. It does not establish vendor endorsement or that RuView is a de facto standard.

Cyberpunk-styled smart living room where neon data streams represent the MQTT and Matter protocols connecting a central ESP32 node to icons of Apple Home, Google Home, and Alexa, with no cameras visible.

The ecosystem

Author repositories

RuView’s own documentation links to or declares dependence on several ruvnet projects:

ruvnet/RuVector: a vector, memory, and graph store that the README names as part of the architecture; 4,398 stars and 581 forks.
ruvnet/rvcsi: a runtime for normalizing CSI from Nexmon, ESP32, Intel, Atheros, files, and replay; the README says it is included as a submodule. It had 18 stars and 2 forks.
ruvnet/rufield: a specification for camera-free field sensing; 24 stars and 3 forks.
ruvnet/ruflo: an agent harness with memory and multi-agent flows; 66,769 stars and 7,962 forks.
ruvnet/metaharness: a harness generator with a CLI, MCP, and memory; RuView’s README says its portable harness was built with this project. It had 534 stars and 64 forks.

The figures above come from the GitHub API on August 1, 2026. They indicate an authorship or documentation relationship; they do not guarantee a versioned dependency or joint support.

Ports, forks, and community extensions

The GitHub search turned up a mix of forks, adaptations, and projects that present themselves as related. Not all of them are maintained by ruvnet:

deletexiumu/wifi-densepose, 105 stars, is a fork presenting itself as a critical audit and using the label “SCAM ALERT”. It is the recurring reference point for Hacker News criticism; its description is that fork’s own stance, not an independent verdict from this piece.
Gast779/RuView-fixed, 4 stars, advertises itself as a variant with fixes and a working API.
MAXXTANG/ruview-xiao, 6 stars, adapts the sensing to Seeed XIAO ESP32-S3, C6, and C5 boards.
DevvGwardo/openclaw-ruview-presence, 34 stars, is an OpenClaw plugin for presence-aware agent behavior.
x1958075990h-pixel/RuView_Radar_Lite, 115 stars, presents itself as a lightweight Python DSP engine for ESP32 CSI, and its description includes Chinese text; it is a community port or related project, not an official translation.
kyleyct/wifi-densepose-elderly, 57 stars, presents itself as a CSI-based fall-detection system for the elderly, and its description includes Traditional Chinese text.

Copies with descriptions in Chinese, Korean, Bengali, and Vietnamese also turned up, but the queries do not establish which ones are complete translations or their quality. For that reason they are not treated as official ports here. The mapping above prioritizes repositories with a readable statement of function and an explicit relationship in the search results.

Central neon core labeled RuView connected to satellite nodes representing community forks and ports; one side shows blue and green integration connections, the other flickering red nodes with warning signs symbolizing the "SCAM ALERT" criticism.

Repo numbers

Measured: August 1, 2026, GitHub API.

Metric	Value
Stars	88,051
Forks	11,698
Real subscribers	761
Commits	1,207
Open issues reported by the API	421
Primary language	Rust
License	MIT
Created	June 7, 2025
Last metadata update	August 1, 2026
Latest release	`v2129`, July 31, 2026

The top contributors returned by the API, by number of contributions, were ruvnet (993), claude (76), proffesor-for-testing (36), and dependabot[bot] (31). The total of 1,207 commits was obtained from the last-page link of GitHub’s commit pagination. The open_issues_count field can include open pull requests; it does not necessarily equal issues exclusively. The API repeats the star count in watchers_count, so subscribers_count is reported here as real subscribers.

How to contribute

The README invites issues and contributions, but no CONTRIBUTING.md file, branching guide, or pull request template was found. The verifiable material for contributing is, therefore, opening an issue or pull request and running the checks the project mentions, such as python archive/v1/data/proof/verify.py and bash plugins/ruview/scripts/smoke.sh for the plugin.

This is insufficient documentation to infer an acceptance process, mandatory tests, or a review policy. Contributors should confirm those rules in an issue before assuming them.

How the community received it

The reception found is mostly critical and contains concrete anchors, not a consensus on quality:

On HN 46388904, posted by nateb2022 on December 26, 2025, the link to the old wifi-densepose received 32 points and 17 comments. heavyset_go objected that the documentation did not explain what was needed on the router side. Zambyte quoted a review from the repository itself describing it as a prototype with core components unimplemented. These are user criticisms, not an audit reproduced in this investigation.
In the same thread, archermarks questioned the project describing itself as privacy-focused given the potential to observe without cameras; the point overlaps with the passive-surveillance debate, though it does not by itself prove a violation or a specific technical capability.
On HN 48157639, posted by unixhero on May 16, 2026, RuView got 22 points. Rpu-Micro found it interesting to reduce the compute of an always-on sensor when the environment does not change. 6r17 praised the idea, the packaging, and the potential product, but asked whether the data could identify a person. There were also severe objections: prakashqwerty called it low-quality generated content, and Gys named tommysense.com and ESPectre as alternative working solutions.
GitHub issues reflect real installation difficulties: in #249, munozluis1015 reported that an ESP32-S3 mesh showed the same result regardless of position or people present; in #1125, Sycrosity asked for testimonials from someone who had obtained real data. These entries show user-reported problems; they do not demonstrate that every installation fails.

The combination of high visibility, ambitious technical claims, and verifiable user doubts suggests treating RuView as a beta program that needs to be tested with your own hardware and a validation protocol, not as a health, safety, or surveillance product ready for deployment.

RuView versus other proposals

Proposal	Verifiable overlap	Verifiable difference or limit
`superstar1225/DensePose_from_WiFi`	A human pose estimation repository using WiFi and deep learning; 477 stars.	Its description links it to DensePose from WiFi; the search results do not allow confirming ESP32 compatibility or functional equivalence with RuView.
`davidakpele/wifi-densepose`	A WiFi-based dense pose project; 470 stars.	Presents itself as an implementation of InvisPose for mesh routers. The source found does not allow verifying its results or comparing its performance against RuView.
`x1958075990h-pixel/RuView_Radar_Lite`	Shares ESP32 CSI and spatial sensing; 115 stars.	Describes itself as a lightweight Python DSP engine, versus RuView’s much broader declared scope of firmware, server, models, and integrations.
`kyleyct/wifi-densepose-elderly`	Uses WiFi CSI for non-invasive fall detection; 57 stars.	Focuses on the elderly and falls, while RuView claims presence, vital signs, pose, and home integrations.

The star counts were retrieved from the GitHub API on August 1, 2026. No independent comparative benchmarks were found that would allow ranking these options by accuracy, latency, or maturity.

Use cases and who this repository can help

People experimenting with edge presence sensing can use RuView to set up a test with CSI-compatible ESP32 nodes, process signals locally, and send results to a web interface, MQTT, or a home integration. The documented path allows starting with Docker and simulated data, then moving on to build, flash, and provision the hardware, and to try calibration, training, or room-fingerprint lookup with the --pretrain, --train, --embed, and --build-index modes.

Home automation integrators and WiFi CSI researchers can evaluate the Matter bridge, Home Assistant configuration via --mqtt, and the node mesh as components of a prototype. They can also use the npx @ruvnet/ruview harness and the Claude Code plugin to explore configuration and verification. These flows are best treated as experimental: Docker does not replace CSI-capable hardware, and the project’s own report notes limits of the pose model, of --model, and of its performance claims.

Resources

Repository: https://github.com/ruvnet/RuView
Documentation and installation: https://github.com/ruvnet/RuView#documentation
User guide: https://github.com/ruvnet/RuView/blob/main/docs/user-guide.md
Official plugin and prompts: https://github.com/ruvnet/RuView/tree/main/plugins/ruview
Published model: https://huggingface.co/ruvnet/wifi-densepose-pretrained
Home Assistant and Matter integration: https://github.com/ruvnet/RuView/blob/main/docs/integrations/home-assistant.md
Community: https://github.com/ruvnet/RuView/discussions
Reviews and discussions: https://news.ycombinator.com/item?id=46388904, https://news.ycombinator.com/item?id=48157639, https://github.com/deletexiumu/wifi-densepose

Note: this article combines RuView’s README and issues, the GitHub API, repository searches, and the Hacker News threads consulted on August 1, 2026. Figures and software status change over time.