4 Commits

Include renames

Author	SHA1	Message	Date
tfaour	fcf3aec4c0	Move button actions to per-widget config, add hold-for-global-action ... Next/back button assignment moves from a frame-level "Button assignments" card into each widget's own gear-icon dialog, prefilled with a sane default at creation (photos/calendar -> advance/back, whiteboard/weather -> check_now, others -> none). At most one binding per (widget, button) now -- cross-widget execution order never mattered since each widget's action only touches its own state. New firmware capability: holding NEXT or BACK past a configurable duration (min 3s, server-side default) triggers a frame-wide action instead of the per-widget short-press one -- cycling saved layouts, refreshing all widgets, or freezing/unfreezing every photo widget (see app/global_actions.py). Firmware next/back checks gain the same hold-duration polling the combo button already had; the threshold comes from the previous wake's /frame/config fetch (persisted in NVS), since this wake's button decision happens before that request. Not done here: firmware/version.txt is intentionally left unbumped -- this hasn't been built or hardware-tested (no ESP-IDF toolchain in this environment), so no firmware release build should be triggered yet.	2026-07-27 22:09:33 +00:00
tfaour	3868d357ff	Add back-photo button; consolidate reset/manage onto one hold-duration button ... Back button (new GPIO0, POST /frame/back): the server now tracks a bounded history of previously-current photos (photo_queue.py), pushed to on every advance (auto or forced) and popped by back_forced() -- symmetric with advance, so pressing next afterwards returns to right where you were. frame_client.c's force_advance bool becomes a 3-way fetch_action_t (NORMAL/ADVANCE/BACK) threaded through the whole fetch path. Also folds the separate reset and manage buttons onto one pin (combo_button.c, replacing reset_button.c/manage_button.c entirely), disambiguated by hold duration: quick press shows the management menu (unchanged), ~3s hold-then-release soft-resets (esp_restart(), config kept -- new), ~15s hold factory-resets (today's old reset behavior, extended from 10s for clearer tier separation). Driven by a production board (Seeed XIAO ESP32-C6) exposing only 3 of the ESP32-C6's 8 deep-sleep-wakeup-capable GPIOs -- next/back keep their own dedicated pins where instant response matters most, everything else shares the third pin via timing instead of needing its own. Same three-pin layout now works on both the dev board and the production board. Fixed a fast-tap bug in combo_button_check() before shipping: it only did a live gpio_get_level() read to decide whether the button was pressed at all, so a press fast enough to already be released by the time boot reached that check was missed entirely (treated as "never pressed" rather than "quick press"). Added the same latched esp_sleep_get_gpio_wakeup_status() check the other buttons already use for exactly this reason.	2026-07-19 12:53:26 -04:00
tfaour	461beed04f	Fix: release GPIO hold on every button pin before reconfiguring it ... ESP-IDF locks ("holds") every pin armed as a GPIO deep-sleep wakeup source across the sleep transition, and never releases it automatically on wake -- confirmed against sleep_modes.c's esp_sleep_gpio_wakeup_prepare_on_hp_periph_powerdown(), which calls gpio_hold_en() with no corresponding gpio_hold_dis() anywhere in ESP-IDF's own wake path. Left held, live gpio_get_level() reads stay frozen at whatever level the pin had when sleep began (almost always "not pressed"), which is indistinguishable from a real "not pressed" reading and silently broke any live poll for a *new* press later in the same awake session. This never surfaced before the manage menu's escalation feature, since every other button check either used the latched wakeup-status register (unaffected by hold) or only polled once, early in boot, before any sleep/wake cycle in that session. wait_for_button_press() is the first code in this project to repeatedly poll a button live *after* having just woken via that same pin -- exactly the case hold breaks. Fixed by calling gpio_hold_dis() before gpio_config() in all three buttons' init functions, not just manage's -- reset and next-photo have the same latent issue in their own live-read fallback paths, just not yet exercised the same way.	2026-07-19 09:22:40 -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