Fix stale documentation found by a doc-accuracy audit
firmware/README.md's HTTP vs HTTPS section still described the public-CA-bundle trust approach that was tried and abandoned in favor of pinning one specific certificate -- rewritten to match what's actually there. docs/architecture.md was missing the back-photo button entirely (sequence diagram and boot-flow bullets only covered next) and still said the system talks "over plain HTTP" despite HTTPS support. docker-compose.yml.example's MANAGEMENT_TOKEN comment understated its scope (said "the web UI", omitting that every /frame/* endpoint is gated too).
This commit is contained in:
+18
-10
@@ -1,8 +1,10 @@
|
||||
# Architecture
|
||||
|
||||
Two independent pieces talk over plain HTTP on the local network: the
|
||||
ESP32-C6 firmware, and a small FastAPI server that sits between it and
|
||||
Immich.
|
||||
Two independent pieces talk over HTTP or HTTPS (the server itself always
|
||||
speaks plain HTTP; HTTPS means a reverse proxy in front of it, see
|
||||
[`firmware/README.md`](../firmware/README.md#http-vs-https)) on the local
|
||||
network: the ESP32-C6 firmware, and a small FastAPI server that sits
|
||||
between it and Immich.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
@@ -16,11 +18,14 @@ sequenceDiagram
|
||||
Note over Frame: User scans WiFi QR, then config QR -> fills in<br/>home WiFi + "Tools Server" host:port
|
||||
Frame->>Frame: Save config to NVS, reboot
|
||||
|
||||
Note over Frame: Every wake (deep sleep timer, next-photo button,<br/>or any other reboot)
|
||||
Note over Frame: Every wake (deep sleep timer, next/back-photo button,<br/>or any other reboot)
|
||||
Frame->>Frame: Connect to home WiFi
|
||||
alt next-photo button pressed
|
||||
Frame->>Server: POST /frame/advance
|
||||
Server->>Server: Force-advance to next queued photo, reset interval clock
|
||||
else back-photo button pressed
|
||||
Frame->>Server: POST /frame/back
|
||||
Server->>Server: Return to previously-current photo (bounded history),<br/>reset interval clock
|
||||
else normal wake
|
||||
Frame->>Server: GET /frame/image
|
||||
Server->>Server: Advance only if refresh_interval_s has elapsed<br/>since the current photo was set -- otherwise a no-op
|
||||
@@ -52,12 +57,15 @@ sequenceDiagram
|
||||
2. **Stored config exists**: connect to the saved WiFi network (a few
|
||||
retries before falling back to provisioning if it fails), then run the
|
||||
fetch cycle in `frame_client.c`:
|
||||
- Check the next-photo button (`next_button_check()`) -- if it was
|
||||
what woke the device (checked via the latched
|
||||
`esp_sleep_get_gpio_wakeup_status()`, not a live pin read, since a
|
||||
quick tap can release before boot gets around to polling it) or is
|
||||
currently held, the fetch below hits `POST /frame/advance` instead
|
||||
of `GET /frame/image`, forcing the server to skip ahead immediately.
|
||||
- Check the next-photo and back-photo buttons (`next_button_check()`,
|
||||
`back_button_check()`) -- if either was what woke the device
|
||||
(checked via the latched `esp_sleep_get_gpio_wakeup_status()`, not
|
||||
a live pin read, since a quick tap can release before boot gets
|
||||
around to polling it) or is currently held, the fetch below hits
|
||||
`POST /frame/advance` or `POST /frame/back` instead of
|
||||
`GET /frame/image`, forcing the server to move in that direction
|
||||
immediately (next takes priority if somehow both read pressed at
|
||||
once).
|
||||
- Fetch the frame and write it into the panel's SPI buffer
|
||||
(`epd_write_frame()`), computing a CRC32 as it streams -- never
|
||||
buffering the full ~192KB frame in RAM. The panel driver refuses to
|
||||
|
||||
Reference in New Issue
Block a user