RuView sensing fixes: no vital-sign numbers from an empty room or stale nodes

What this is about

RuView's sensing server turns WiFi signals into room occupancy and, when it can, breathing and heart-rate estimates. A sensing system earns trust by staying quiet when it does not know. These three fixes are about exactly that: fewer confident numbers that the evidence does not support.

Nothing here is a medical device or a clinical claim, and the fixes do not say the estimates are accurate. They narrow when estimates are shown.

What changed

• PR #2060, September 30 (commit e1fbbede): a stale node count of three could raise a fresh count of one back to three. One strict ten-second freshness rule now applies to node counts, room contributors and the fallback path, and the count is computed after room classification. The PR reports 15 focused count tests and 929 sensing-server tests passing, on synthetic fixtures, with no field accuracy claim; the original report stays open for field confirmation.
• PR #2061, September 30 (commit b90b592d): breathing-only synthetic input could come out as a confident 120 BPM heart rate, and a 72 BPM pulse drifted to about 79 BPM. The detector now needs a genuine local peak, a second filter reduces breathing leakage, and confidence is capped by the original filter's evidence. The PR states three new regressions failed before the fix and pass after, again on synthetic signals, with no real-signal or clinical accuracy claim.
• PR #2147, October 4 (commit 7c8aeace): in a physical run, an empty calibrated room showed 12 of 12 absent while eight server samples still contained vital-sign outputs. Rates are now published only with strict, calibrated, fresh evidence of a single occupant, on both the streaming and REST paths. The PR reports 932 server tests passing and a physical retest on a signed Mac build with full 600-second captures: 12 of 12 absent and zero vital outputs.

The PRs are explicit about limits: occupied-room sensitivity and vital-sign accuracy remain unqualified, longer empty-room runs still show transient calibrated false presence, and no release acceptance is claimed. v2938, v2940 and v3037 are the automated server builds that carried each merge.

Get started

Prerequisites: a RuView checkout with the Rust toolchain. These are server-side changes; there is no new command, package, MCP tool or skill. The PRs name the test commands used to check them, which you can run from the repository root:

cargo test -p wifi-densepose-sensing-server --no-default-features --locked

cargo test -p wifi-densepose-vitals --no-default-features --locked

Expected result: the suites pass with no failures; the PRs report 929 and 107 unit tests respectively at their merge points, and counts will change as the code moves.

Commands here were read from the release notes and repository documentation at the pinned reference; they were not executed as part of writing this article.

Use it today

Practical case: you calibrate a room, leave it empty, and check whether the dashboard invents a heartbeat. Input is a calibrated room and a ten-minute empty capture. Workflow: run the capture on a build with #2147. Output: absent status and no heart or breathing numbers.

Acceptance test: repeat the PR's check. Over a full empty-room capture, the server should report zero vital-sign outputs. Any numeric rate with nobody present is a regression.

Push it further

Experimental commentary. Gating outputs on fresh, calibrated evidence is the right default for any sensing system that might be read by someone who cares about the answer. Abstaining is a feature, and these PRs treat it that way by testing the negative cases as carefully as the positive ones.

Limitation: the evidence for occupied rooms is synthetic, so these fixes can make the system quieter without making it more accurate. Falsifiable test: with one person seated, a build with #2147 should still publish rates when calibration is fresh; if it abstains, the gate is too strict.