6 Commits

Include renames

Author	SHA1	Message	Date
tfaour	f74085cedf	Add third button: "scan to manage" QR overlay on the current photo ... Pressing the manage button (GPIO1) overlays a small QR code -- "SCAN TO MANAGE" -- in the top-right corner of whatever photo is currently on screen, linking to the server's config page, then reverts to the plain photo after 30 seconds. The overlay is spliced into the existing streaming fetch as chunks pass through (frame_client.c's http_read_fn), rather than buffering the full 192,000-byte frame in RAM: only the small overlay rectangle itself (~30KB) is ever held in memory, generated via new stride-parameterized drawing helpers (epd_draw_*_ex in epd_draw.c) that let the existing QR/text drawing code target an arbitrarily-sized buffer instead of a full-frame one. epd7in3e.c is untouched -- it has no idea an overlay exists.	2026-07-19 00:50:07 -04:00
tfaour	d395cf3bb9	Add two physical buttons: factory-reset and next-photo ... Factory-reset (GPIO3, hold 10s): clears stored WiFi/server config and restarts into provisioning -- the deliberate, USB-free replacement for the earlier reverted RST-based auto-reprovisioning idea. Next-photo (GPIO2, tap): wakes the device and forces the server to advance immediately via a new POST /frame/advance, instead of waiting for the refresh interval. Both buttons arm themselves as deep-sleep GPIO wakeup sources so a press is noticed promptly even while asleep. Also makes GET /frame/image side-effect-free: it now only advances once refresh_interval_s has elapsed since the current photo was set (tracked server-side), so a device reboot for any reason just redisplays the current photo instead of silently skipping ahead. The server maintains a small reorderable upcoming-photos queue, viewable and rearrangeable from the web UI.	2026-07-18 23:28:36 -04:00
tfaour	012c6dda8e	Revert "Add two ways back into provisioning: RST press and repeated server failure" ... This reverts commit d32236d832.	2026-07-18 16:24:38 -04:00
tfaour	d32236d832	Add two ways back into provisioning: RST press and repeated server failure ... RST/power-on trigger: checks esp_reset_reason() at the very top of boot. ESP32-C6 can't electrically distinguish the RST/EN button from a genuine power-on (both report ESP_RST_POWERON -- confirmed against ESP-IDF's own docs, ESP_RST_EXT is explicitly "not applicable"), so POWERON is treated as "user wants to reconfigure" and routes straight to provisioning. Safe because the device's only normal restart path is ESP_RST_DEEPSLEEP (its own scheduled wake), and crash-type resets (brownout/watchdog/panic) report their own distinct reasons, not POWERON -- so a flaky power supply or transient crash won't get bounced into provisioning, only an actual power cycle or RST press will (which plausibly means the frame is being moved/redeployed anyway). Auto-fallback: a new NVS-persisted consecutive-failure counter (frame_config_record_server_failure/reset_server_failures) tracks wakes where the tools server was unreachable. After CONFIG_FRAME_REPROVISION_AFTER_FAILURES in a row (default 12, ~1hr at the retry interval), the device clears its stored WiFi config and esp_restart()s rather than calling wifi_provisioning_start() directly -- doing that inline would mean initializing the display driver a second time in the same session (frame_client_run already did once), the same class of double-init bug hit earlier with WiFi. The next boot's frame_config_load() naturally reports "not provisioned" and routes through the existing, already-tested provisioning path with a single fresh epd_init(). Solves the "I moved the server to a new address" case without needing USB access. Both frame_config_save() (fresh provisioning) and any successful server contact reset the failure counter.	2026-07-18 16:10:03 -04:00
tfaour	de449d5973	Finish captive portal: NVS config, POST handler, STA connect, AP identity ... Splits provisioning (softAP + captive portal + NVS-backed config) into wifi_provisioning.c and home-network connection into frame_client.c. /save_config now parses the form body and persists it to NVS; on boot the device goes straight to STA mode if a config exists, retrying a few times before falling back to provisioning if the home network is unreachable. The provisioning AP is now always named ESPRESSO with a random per-device password (generated once, persisted in NVS) instead of a fixed Kconfig value, drawn from a charset that avoids visually ambiguous characters since it'll be read off the e-ink panel and possibly typed by hand.	2026-07-18 10:48:52 -04:00
tfaour	cb50c99c98	Restructure repo as monorepo: firmware/ + server/ + docs/ ... Moves the existing ESP-IDF captive_portal example into firmware/ to make room for the new FastAPI server and project docs, ahead of building out the full ESPresso Frame project (ESP32-C6 + Immich-backed e-ink photo frame).	2026-07-18 10:20:25 -04:00