RuView ESP32 firmware 0.8.13 pre-release: stalled sensors recover themselves

What this is about

Pre-release and research status: built from pull request #2050, which was still open and unmerged on October 5. Tested on one ESP32-C6 board with deliberately triggered faults. The original field fault's cause is unknown, and ESP32-S3 builds were not tested on hardware.

RuView sensing nodes are small ESP32 boards that capture WiFi channel state information. One failure mode is quiet: a board stays connected, answers pings and prints logs, but stops sensing. One board stayed like that for almost eight minutes without anything noticing.

What changed

• A capture watchdog checks every second that sensing data is flowing. After 15 seconds without data while WiFi is up, it restarts just the sensing part of the radio, then reconnects WiFi, then reboots, stopping as soon as data returns. The timeout is configurable.
• A timing mismatch between two internal rate limits was dropping snapshots the board had already collected. The release reports loss falling from 21 to 28 percent to 0.08 to 0.15 percent on one board.
• Reported recovery time with a test fault: about 15 seconds when the first step works, about 53 seconds in the worst case that needs a reboot, and zero false alarms in 14 minutes of normal use.

These numbers come from one ESP32-C6 on one home network. They are not a benchmark and should not be read as typical for other boards or networks.

Get started

Prerequisites: a supported ESP32-C6 or ESP32-S3 node, esptool, and willingness to run pre-release firmware. The release provides per-board bundles and a SHA256SUMS.txt file. It says flashing the app, bootloader and partition table keeps saved WiFi settings and node ID, and no new settings are required.

sha256sum -c SHA256SUMS.txt

Expected result: every listed file reports OK. Then follow the flashing guide inside the bundle for your exact chip and flash size. No MCP server, npm package or skills are involved in this firmware release.

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: a node in a test room keeps going silent overnight. Input is that board on 0.8.13. Workflow: leave it running and watch its logs or the RuView pane for recovery events. Output: gaps of seconds instead of minutes, if the watchdog behaves as reported.

Acceptance test: block CSI on the board while WiFi stays up. Data should resume within about 15 seconds without a manual reset; on a healthy board, no recovery should fire over an hour.

Push it further

Experimental commentary. A health check that measures the useful output rather than connectivity is the right shape for edge sensors, where looking healthy and working are different things.

Limitation: induced faults on one board do not prove the watchdog fixes the real fault, whose cause is unknown. Falsifiable test: run several C6 and S3 boards on 0.8.12 and 0.8.13 side by side for a week; 0.8.13 should show shorter data gaps and lower loss on every board, or the result does not generalise.