RuView fleet reliability & honesty update — 2026-09-04

Eight community-contributed fixes landed today, focused on three real problems reported from live multi-node ESP32-C6/S3 deployments: sensing accuracy silently degrading under real timing conditions, the UI fabricating data when it shouldn't, and firmware giving up on the network too early. Every fix below started from a reproduced, real bug — not a hypothetical.

What actually changes for a running fleet

Motion and presence detection get materially more accurate. The smoothing and debounce logic that decides "is someone here, are they moving" was tuned for an assumed 10 frames/sec — but C6 boards actually run ~48-50 FPS. That mismatch meant the system's memory of recent history was silently 5x shorter than intended, making it twitchier and less stable than designed. Detection windows now scale to each board's measured rate instead of a guessed constant. Room-level classification (the "consensus" reading, not just any one sensor's) also gets its own stability check for the first time — previously, three sensors sitting right at a decision boundary could flip the room's status every single cycle, even while every individual sensor's own reading looked stable.

A whole class of HE20 CSI data was being silently thrown away. ESP32-C6/C5 boards produce twice as much channel data (256 subcarriers) as the older buffer size (128) was built for — the extra half was quietly dropped with no warning, no error, no counter. It's fixed for the newer chips now, at the cost of a little extra RAM.

Node position labels can now be trusted. Every node's on-screen/API position had been hardcoded to the same placeholder regardless of actual configuration. Now wired through correctly — including a fix for fleets with non-sequential node IDs (11, 12, 13 instead of 0, 1, 2), which is how real multi-node setups are actually numbered.

The dashboard stops lying when it loses connection. If the sensing server's connection dropped, the UI used to quietly fall back to a built-in simulator and display synthetic data that looked exactly like the real thing — flickering between "someone's here" and "no one's here" in a way that looked like a sensing fault, not a network fault. It now shows an explicit "NO DATA — SERVER UNREACHABLE" banner and keeps trying to reconnect, instead of making something up. This closes a real violation of RuView's own rule that sensing output must never be presented as more certain than it actually is.

Firmware retries the network forever instead of giving up. A real fleet outage lasted 7.5 hours because the firmware capped WiFi reconnection at a fixed number of attempts, then stopped trying. It now retries indefinitely with exponential backoff, plus a new watchdog that reboots a node only if it can no longer even attempt to send data locally (not if the server itself is unreachable — a dead server shouldn't reboot a healthy fleet).

New thermal awareness. Nodes now monitor their own temperature and can throttle radio power before overheating causes silent, hard-to-diagnose signal degradation (a hot node's reduced transmit power looks identical to "something moved" or "obstruction appeared" without this).

One dead radio, disabled. The C6's secondary 802.15.4 radio was running — and consuming coexistence overhead — for a wireless stack the firmware never actually uses for anything. Turned off.

Calibration can no longer finish early by accident. Empty-room calibration was gated on a frame count meant to represent "10 minutes of baseline data" — but every node in a fleet contributes to the same counter, so a 3-node fleet was completing calibration in about 1/3 the intended time, with a shorter, less representative baseline than intended. Now gated on wall-clock duration as well.

What this doesn't include

Two known, still-open issues were surfaced during review and are not fixed by this batch:

• A bound calibration session can silently produce zero presence evidence on any API endpoint (root cause not yet found).
• Firmware fixes like these don't reach real users until a separate, pre-existing release-publishing gap is closed — CI has been building and testing C6 firmware every release without actually publishing it.

Every change here was independently reviewed against the underlying code (not just the PR description) before merging, including two real merge-order conflicts caught and safely sequenced rather than merged blind.

Merged pull requests

All eight were independently reviewed against the underlying code before merge — not just the PR description. Two real merge-order conflicts were caught and sequenced correctly rather than merged blind:

• #1791 and #1793 both touched the same lines in main.rs's live-data JSON builders; #1791 was fixed and merged first, then #1793 was verified against the updated main before merging.
• #1795 is stacked on #1797 (shares main.c/Kconfig.projbuild); #1797 merged first.

Known open issues (not fixed by this batch)

• #1759 — a finalized/bound calibration session can silently emit no calibrated_presence_evidence on any endpoint.
• #1757 — C6 firmware is built and tested by CI every release, but never actually published — none of today's firmware fixes reach real devices until this is closed.
• #1764 / #1725 — two distinct, still-open UDP/CSI delivery failure modes on ESP32-S3 hardware.