Live sensing requires CSI hardware, not ordinary WiFi
RuView captures Channel State Information from compatible radios and turns changes in amplitude and phase into features for presence, motion, vital signs, counting, or pose models. The idea is technically different from reading normal signal strength. CSI exposes measurements across WiFi subcarriers, while a typical consumer laptop supplies only RSSI. The README therefore recommends ESP32-S3, ESP32-C6, or research network cards for advanced sensing.
A Docker image can run simulated data without hardware, which is useful for seeing the interface and message flow. It cannot prove that a room, router, sensor position, and model produce accurate live results. Our checkout at commit 0df48df contained 3,682 files, roughly 600,309 lines of source, and occupied 106.4 MB. The project spans firmware, signal processing, models, servers, home automation, documentation, and agent tooling.
The 3.0% pose model is below its stated target
RuView's README makes an unusually important distinction between model tiers. A published MM-Fi benchmark model is described separately from the committed on-device pose model. The on-device pose_v1.safetensors result is 3.0% PCK@20 and 18.5% PCK@50 on its stated holdout, below a 35% PCK@20 target. Its current runtime path is also labeled a centered-skeleton stub returning confidence=0.
Open issue 645 ties the weak result to a small, desk-framed paired dataset and defines further data collection and multi-room acceptance criteria. That honesty is welcome, but it changes the buying decision. The README headline includes camera-free 17-keypoint pose, while the shippable single-ESP32 path does not yet support that claim at useful quality. Researchers can work on the gap. A safety or consumer product cannot treat the architecture diagram as measured behavior.
What happened when we ran it
Our Python sandbox installed 210 packages in 87 seconds and occupied 5,366 MB. It used 3 CPUs, 8 GB of RAM, Python 3.12 on Debian, no secrets, and no elevated privileges. The build then failed with exit code 1 after 6 seconds. The measurement block does not include its failing log lines, so we cannot identify the command or cause behind that build failure.
The test command exited with code 1 after 8 seconds. Pytest reported 34 passed and 0 failed out of 34. The failure came after execution: coverage warned that no data was collected, reported 0.00%, and enforced a 100.00% minimum. This means the available test assertions passed while the configured coverage gate failed. It does not justify rewriting the overall result as a successful test run.
Pip-audit reported 1 known vulnerability in the installed environment. The repository had 32 CI workflow files and a tests directory, but no Dockerfile in our scan. These facts describe commit 0df48df in our harness. They do not measure sensor accuracy, inference delay, heart-rate error, through-wall range, or performance on ESP32 hardware. Any such claim needs a hardware protocol and a labeled dataset we did not run.
The published safetensors file rejects a standard loader
The README warns that model.safetensors in the published pretrained bundle has a NUL-padded header. Open issue 1522 reproduces the failure with the reference safetensors loader and explains that replacing 3 padding bytes lets the tensors load. RuView's own server reader is more permissive, while another encoder file in the same bundle is reported to load normally. This is a concrete portability defect rather than a theoretical format concern.
The model section lists native RVF, JSONL conversion, quantized binaries, and safetensors paths with different reader support. Loading weights also does not supply a matching pose decoder or establish end-to-end accuracy. A team should select one documented artifact and reproduce loading, preprocessing, inference, and output interpretation before collecting a large dataset. A file accepted by the server only proves that its parser accepted the file.
Home automation exposes claims to real households
RuView can publish entities through MQTT to Home Assistant and offers routes toward Apple Home, Google Home, Alexa, and Matter. The README describes states such as possible distress, bed exit, inactivity anomaly, fall risk, and room transitions. Those labels sound operational. Their reliability depends on the upstream sensor, calibration, inference path, thresholds, and environment, none of which a dashboard integration can repair.
For a home experiment, start with presence in one controlled room and retain the raw evidence needed to investigate errors. Do not begin with medical or emergency semantics. False negatives can hide a real event; false positives can train a household to ignore alerts. RuView's evidence and provenance machinery is useful for auditing a decision, but cryptographic attestation cannot make an inaccurate inference correct.
Rapid releases mix shipped code with staged work
GitHub showed 91,765 stars, 556 open issues and pull requests, and a push on 2026-08-27. Release v2390 appeared on 2026-08-26. Its notes explicitly say the new ultrasonic adapter was shipped as a library and was not wired into the running server. That is a good example of why repository presence, release inclusion, and user-visible capability must be checked separately.
RuView is compelling as a public laboratory for edge sensing, model formats, firmware, and home integrations. Our 5,366 MB environment and failed build make it expensive to approach casually. The strongest documentation passages admit where models are synthetic, weak, malformed, or unwired. Read those before the headline. For a production occupancy sensor, compare a focused CSI collector and your own validated classifier against the full platform before accepting its much wider scope.