From 7be196112202bd38a3898af7061f55141153fb4c Mon Sep 17 00:00:00 2001 From: Claude Worker claude2 Date: Wed, 10 Jun 2026 10:24:12 +0200 Subject: [PATCH] docs: PLIP re-scoped into scenario hot-load PLIP_FIRMWARE now has its own ESP-NOW receiver (src/scenario_now.{h,cpp}); update the receiver-patch status and the PLIP section accordingly. HTTP stays the recommended push path once PLIP's REST server lands. --- docs/scenario-mesh-receiver-patch.md | 36 ++++++++++++++++++---------- 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/docs/scenario-mesh-receiver-patch.md b/docs/scenario-mesh-receiver-patch.md index 928354a..ce7ca88 100644 --- a/docs/scenario-mesh-receiver-patch.md +++ b/docs/scenario-mesh-receiver-patch.md @@ -1,8 +1,9 @@ # ESP-NOW scenario receiver — patch to report onto PLIP + puzzles Status: **box3_voice done**; **puzzle nodes done** (defensive demux in the -shared `espnow_slave.c`, see "Resolution" below); **PLIP out of scope by -design** (Wi-Fi/HTTP-only client, no ESP-NOW stack — see "PLIP" below). +shared `espnow_slave.c`, see "Resolution" below); **PLIP done** (brought back +into scope on 2026-06-10 — dedicated receiver `src/scenario_now.{h,cpp}` in +`PLIP_FIRMWARE`, see "PLIP" below). Spec: `docs/specs/2026-05-24-firmware-scenario-hotload.md`, task 6 ("Receiver side on each peer"). @@ -108,18 +109,29 @@ SRC entry already present in every puzzle `main/CMakeLists.txt`). no-op for it. Confirm per node before adding storage: `p7_coffre` (the final-code lock) is the most likely to actually consume a scenario. -## PLIP (`PLIP_FIRMWARE`) — out of scope by design +## PLIP (`PLIP_FIRMWARE`) — done (re-scoped 2026-06-10) -Resolved 2026-06-09: **PLIP needs no ESP-NOW scenario receiver.** It is its own -Arduino/PlatformIO tree (`/PLIP_FIRMWARE`, C++), connects to the master purely -over **Wi-Fi + HTTP** (`network_task.cpp` → `WiFi.begin` / mDNS, `zacus_hook_client` -REST), and registers **no** `esp_now_register_recv_cb` at all. The ESP-NOW relay -exists only as a fallback for boards that run with Wi-Fi disabled (battery / RF -noise); PLIP is mains-powered and always on Wi-Fi. +Originally resolved out of scope on 2026-06-09 (Wi-Fi/HTTP-only client, no +ESP-NOW stack). Re-scoped in on 2026-06-10 by explicit request: PLIP now has a +dedicated receiver, `PLIP_FIRMWARE/src/scenario_now.{h,cpp}` (Arduino C++, +matching the `zacus_hook_client` worker-task pattern). -If PLIP ever needs hot scenario push, the correct path is the master/box3 HTTP -one — `POST /game/scenario` over its existing Wi-Fi link — **not** ESP-NOW. No -code change made. +- Same wire format as `scenario_mesh` / the shared `espnow_slave.c`: + 4-byte header `{ seq:u16 LE, total:u16 LE }`, <=236 payload bytes, bounded + heap reassembly (<=64 KiB), 5 s sender-silence timeout. +- PLIP registers no other `esp_now_register_recv_cb`, so the module owns the + single callback — no MSG_* demux needed (unlike the puzzle nodes). +- A completed scenario is persisted to LittleFS at `/scenario.json` + (temp-then-rename); an optional `scenario_now_register_callback()` hook lets + a future Runtime 3 engine consume it. With no consumer registered the + scenario is stored and logged. +- `network_task.cpp` calls `scenario_now_init()` once the station is up + (ESP-NOW rides the AP's channel); the call is idempotent and repeated on + reconnect. + +The HTTP path (`POST /game/scenario` on PLIP's future REST server) remains the +recommended push channel once that server lands; the ESP-NOW receiver covers +the relay/fallback case in the meantime. ## Shared-protocol drift risk -- 2.52.0