5 Commits

Include renames

Author	SHA1	Message	Date
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	878909b302	Fix status screen logic: first-connection screen, false-negative skip ... Two bugs found testing against a real (partially-configured) server: - The reachability check hit HEAD / with -- our server only registers GET on that route, so it always got a 405. Harmless for the check itself (any completed HTTP response counts as "reachable"), but noisy and semantically wrong. Points at GET /health instead, which exists for exactly this. - fetch_and_display() failing before any pixel data was sent (e.g. a 400/404 on /frame/image) was treated the same as a mid-stream failure, which skips drawing a status screen to avoid compounding flashing on top of an already-refreshed panel. But a pre-stream failure never touches the panel at all, so skipping the status screen there just left the old provisioning QR code on screen with no indication anything had gone wrong. fetch_and_display() now reports whether streaming ever started so the caller can tell the two cases apart. - The status screen now always shows on the very first successful connection after (re)provisioning, regardless of outcome, via a new "connected_once" NVS flag that frame_config_save() resets on every fresh provisioning event. Later wakes skip it on success (straight to the photo) but still show it on any failure, matching the intent from the original status-screen feature.	2026-07-18 15:06:50 -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