docs: v6.0 board recommendation tier + known-issues recovery steps

README: v6.0.0 shipped — describe the actual delivered features instead
of the "in progress" status. Highlight ESP32-S3 as recommended board.

HARDWARE.md additions:
- Board recommendation tier table at the top (S3 recommended, C3
  supported, classic deprecated, C6 avoid). Plain reasoning so users
  picking a board for a new install pick S3.
- "Second device not visible" recovery — erase-flash + reflash for
  stale NVS with mismatched MCU pinmap. (v6.0 has the boot guard but
  alpha-flashed devices need the manual recovery once.)
- "Slider throws ERR_CONNECTION_RESET" entry — explains the C3
  single-core httpd saturation and the 300 ms client debounce fix
  shipped in 0b63b6e.
- Reordered the supported-boards table by recommendation, not by
  validation status.

Author: Ravi Singh

README.md

@@ -3,29 +3,34 @@
   <img src="https://raw.githubusercontent.com/Techposts/AmbiSense/refs/heads/main/Assets/AmbiSense.webp" width="300" alt="AmbiSense Logo">
 </p>
 
-> ### 🔧 v6 is a ground-up rewrite — in progress
+> ### 🚀 v6.0.0 shipped — full ESP-IDF + FreeRTOS rewrite
 >
-> We're moving AmbiSense off Arduino onto **ESP-IDF + FreeRTOS** so the firmware
-> can drive radar reads, LED rendering, web serving, and ESP-NOW peer-mesh as
-> independent tasks instead of one cooperative `loop()`. v6 also adds
-> **LD2450 multi-target tracking**, a **modular radar driver layer** (LD2410 /
-> LD2412 / LD2420 / LD2450 / sim — switch via web UI without reflashing), a
-> **board picker with editable pin map** for ESP32-C3 / ESP32 / S3 / C6, a
-> **peer mesh** for U/L/asymmetric stairs (no more master/slave), **OTA
-> updates**, **captive portal**, and a **brand-new web UI** designed in
-> Claude Design.
+> v6 is a ground-up rewrite from Arduino onto **ESP-IDF + FreeRTOS**: independent
+> FreeRTOS tasks for radar read, motion smoothing, LED rendering, web serving,
+> and ESP-NOW peer-mesh — no more cooperative `loop()` starving the LED
+> render under HTTP load. v6 ships with **LD2450 multi-target tracking**, a
+> **modular radar driver layer** (LD2410 / LD2412 / LD2420 / LD2450 / sim —
+> swap via web UI without reflashing), a **board picker with editable pin map**
+> (ESP32-C3 / ESP32 / S3 / C6), a **peer mesh** for U/L/asymmetric stairs
+> (every device runs identical code; lowest-MAC wins coordinator),
+> **asymmetric pairing** (click Pair on either device → both join), a
+> **Kalman-based motion filter** (3 user knobs instead of v5's 5 cryptic
+> gains), **OTA with rollback**, **captive portal**, **PBKDF2-SHA256 auth**,
+> and a **fully responsive Preact web UI** (sidebar on desktop, bottom-tab
+> nav on mobile).
+>
+> **Recommended hardware: ESP32-S3 (DevKitC-1 or S3-Zero).** ESP32-C3 SuperMini
+> is supported for single-strip installs. See
+> [docs/HARDWARE.md](docs/HARDWARE.md) for the full board recommendation
+> table and known issues.
 >
 > | Branch | Purpose |
 > |---|---|
-> | `main` | v5.1.1 Arduino release — stable, do not break |
-> | `v6-idf-rewrite` | active rewrite (this PR series) |
-> | `legacy/v5-arduino` | frozen archive of the v5.x line |
+> | `main` | v5.1.1 Arduino release — stable |
+> | `v6-idf-rewrite` | v6 development branch (current) |
+> | `legacy/v5-arduino` | frozen archive of the v5.x Arduino line |
+> | tag `v6.0.0` | v6 release |
 > | tag `v5.1.1` | last Arduino-era release |
->
-> Current status: **PR #1 of 5 — IDF skeleton merged.** Wi-Fi + web (#2),
-> radar + LED engine (#3), peer mesh + topology (#4), and the new UI (#5)
-> follow. Each PR is independently flashable; releases will be tagged
-> `v6.0.0-alpha.N` until P5 ships.
 
 ## v6 quickstart (ESP-IDF, requires `v5.3` LTS)
 

docs/HARDWARE.md

@@ -4,6 +4,17 @@ For locked architectural decisions about which boards/sensors are
 supported, see [`V6-ARCHITECTURE.md`](V6-ARCHITECTURE.md). This file
 covers the practical "I have hardware in front of me" stuff.
 
+## Board recommendation (read this first)
+
+| Tier | Board | Why |
+| ---- | ----- | --- |
+| **Recommended** | **ESP32-S3 DevKitC-1** *or* **ESP32-S3-Zero** | Dual-core LX7 @ 240 MHz, native USB-OTG (no CH340 driver fights), 512 KB SRAM. Wi-Fi/HTTP can be pinned to core 0 and radar+LED+motion to core 1 — slider floods can't starve the render loop. Headroom for v6.1 features (auto-topology, encrypted ESP-NOW, larger strips). Best choice for a stairwell with mesh peers. |
+| **Supported** | **ESP32-C3 SuperMini** | Single-core RISC-V @ 160 MHz. The validated v6.0 reference build. Fine for **single-strip, single-device** installs. The 300 ms client-side debounced-save shipped with v6.0 prevents HTTP saturation under slider drag. Stops being the right choice the moment you want >2 mesh peers or >300 LEDs. |
+| **Deprecated** | ESP32 classic (WROOM-32) | Older silicon, no native USB, no advantage over S3. Profile still builds; not recommended for new installs. |
+| **Avoid** | ESP32-C6 | Single-core, *less* SRAM than C3, and Wi-Fi 6 / Thread don't help AmbiSense. |
+
+If you're starting from scratch and asked us "which board do I buy" → **S3-Zero**. If you already have a C3 SuperMini on the bench → it works.
+
 ## Reference wiring (ESP32-C3 SuperMini)
 
 This is the validated reference build for v6.0.
@@ -52,12 +63,17 @@ for v6, the firmware reads everything via UART.
 
 ## Supported boards (v6.0)
 
-| Profile               | Status   | LED pin | Radar RX | Radar TX | Button | Status LED    |
-| --------------------- | -------- | ------- | -------- | -------- | ------ | ------------- |
-| `esp32c3-supermini`   | ✅ valid | 10      | 20       | 21       | 4      | 8 (active-low)|
-| `esp32-devkit`        | builds   | 5       | 16       | 17       | 4      | 2             |
-| `esp32s3-zero`        | builds   | 21      | 4        | 5        | 9      | 21            |
-| `esp32c6-devkit`      | builds   | 8       | 4        | 5        | 9      | 15            |
+| Profile               | Status        | LED pin | Radar RX | Radar TX | Button | Status LED    |
+| --------------------- | ------------- | ------- | -------- | -------- | ------ | ------------- |
+| `esp32s3-zero`        | recommended   | 21      | 4        | 5        | 9      | 21            |
+| `esp32c3-supermini`   | ✅ validated  | 10      | 20       | 21       | 4      | 8 (active-low)|
+| `esp32-devkit`        | deprecated    | 5       | 16       | 17       | 4      | 2             |
+| `esp32c6-devkit`      | builds only   | 8       | 4        | 5        | 9      | 15            |
+
+The `esp32s3-zero` profile is structurally validated (the firmware
+builds and the pinmap is correct for the AliExpress S3-Zero / S3-Mini
+clones) but Ravi's bench currently only has C3s — full hardware
+validation pending arrival of S3 units.
 
 Profiles defined in
 [`firmware/components/board/board.c`](../firmware/components/board/board.c).
@@ -147,6 +163,46 @@ or any serial terminal at 115200 baud. Logs are also mirrored to a
 16 KB in-RAM ring buffer accessible at `GET /api/logs` once PR #2's
 web server is up.
 
+### Device boots but second one isn't visible (no AP, no STA)
+
+**Symptom**: After flashing, the device serial output shows boot logs
+but no AP `AmbiSense-XXXX` shows up on a phone scan and the device
+never joins Wi-Fi. First device works fine.
+
+**Most common cause**: stale NVS holding a board profile for a
+different MCU (e.g., `esp32-devkit` saved on a C3 from a prior test
+flash). v6.0 ships an MCU-mismatch boot guard that catches this on
+new boots, but if you're upgrading from an alpha build the safest
+recovery is:
+
+```sh
+idf.py -p /dev/cu.usbmodemXXXXXXX erase-flash
+idf.py -p /dev/cu.usbmodemXXXXXXX flash
+```
+
+The erase-flash wipes the NVS partition so the device boots with
+factory defaults. Confirm with `idf.py monitor` — you should see
+`Board profile (default): esp32c3-supermini (ESP32-C3 SuperMini)`
+followed by netmgr starting AP.
+
+### Slider in web UI throws ERR_CONNECTION_RESET
+
+**Symptom**: Dragging a slider in the LED or Motion screen flood-fires
+`POST /api/settings` and the browser console fills with
+`ERR_CONNECTION_RESET` / `ERR_EMPTY_RESPONSE`.
+
+**Cause**: The C3 is single-core. The HTTP server, ESP-NOW broadcast,
+radar UART, motion smoother, and LED render task all run on one
+RISC-V core. Sliders fire `onChange` ~30 times/second; each one was
+posting + reloading at full rate, saturating the httpd's
+`max_open_sockets = 7`.
+
+**Fix**: v6.0 adds a 300 ms debounced-save on the client side
+(`useDebouncedSave` in `frontend/src/screens.tsx`). The slider only
+POSTs once you stop dragging, and multiple slider changes within
+300 ms get coalesced into a single batched request body. If you
+build the UI yourself, make sure you're on commit `0b63b6e` or later.
+
 ### Brownout reset loop
 
 The C3's brownout detector is configured at threshold level 7 (~2.7 V).