Commit Graph
2 Commits
Author SHA1 Message Date
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
Build and push server image / build-and-push (push) Successful in 35s
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