4 Commits

Include renames

Author	SHA1	Message	Date
tfaour	015993af00	Add battery level reporting (Kconfig-gated) and display orientation ... Battery (firmware + server, disabled by default): new battery.c reads a 2x200k voltage divider via ADC oneshot with curve-fitting calibration (the ESP32-C6's scheme), maps through a piecewise LiPo discharge curve, and restores the pin to button duty after each read -- the settled XIAO ESP32-C6 design shares the back button's GPIO0/A0, time-shared per wake. Skipped entirely when on mains (a 2x100k VBUS divider into a spare digital pin -- the 5V pin is dead on battery power, so presence = mains, where the charging voltage would read misleadingly full) or when the reading is implausible. The manage overlay gains a battery region (static outline glyph + "NN%", below the manage QR, all menu levels), and the device POSTs to the new /frame/battery endpoint after a successful fetch; the server stores percent + as-of timestamp, exposed via /api/queue and shown in the web UI. FRAME_BATTERY_ADC_GPIO / FRAME_VBUS_SENSE_GPIO default to -1 (fully inert on the dev board); compile-verified both disabled and enabled, hardware bring-up deferred until the ordered XIAO + batteries arrive. Orientation (server-side only): new config setting + web UI dropdown (landscape / portrait / landscape_flipped / portrait_flipped). Photos are composed/cropped at the logical hanging shape (portrait crops at 480x800, so face-aware crops match how the frame actually hangs), then rotated losslessly into the panel's native 800x480 byte layout after dithering -- the device never knows. Face-label anchors are transformed through the same rotation (logical_to_native()) so they stay attached to faces on rotated frames. Known documented limitation: the on-device manage overlay still renders in native orientation, so it appears sideways on a portrait-hung frame (QRs scan at any rotation; text reads sideways).	2026-07-19 22:11:14 -04:00
tfaour	e870898490	Refine manage overlay: US/CAN state abbreviations, share-QR caption, and an escalating second menu with named-face labels ... Two rounds of follow-up work on the manage-button overlay: 1. Location formatting: US/Canada now show abbreviated state/province ("CA", "ON") instead of the full name, other countries show the full country name, and each is its own line (was one line, now wraps to two) so longer international place names have more room without threatening to overlap the top-right QR box. The bottom-left share QR also gets a "SCAN TO DOWNLOAD" caption. 2. Escalating menu: pressing the manage button again while its overlay is already up adds a second level -- each Immich-identified person's name labeled next to their face in the photo (using Immich's own face recognition/People data, no detection/recognition added to this project). A third press exits immediately instead of waiting out the 30s auto-revert timer. No new Immich API needed -- GET /api/faces already embeds a nullable person.name per face; new server/app/face_labels.py maps a named face's box into the final 800x480 frame's pixel space (reusing crop-box math extracted from image_pipeline.py's face-aware cropping). Capped at 4 named faces, sized to a real firmware RAM budget: each label is its own malloc'd overlay region on the device, alongside the 4 fixed corner regions already in use. New GET /frame/face-labels returns a flattened fixed-slot JSON shape (not a real array) so firmware's existing flat-scalar parser can read it without needing an actual array parser. No persistent state needed for the escalation itself -- it's all local control flow within one continuous awake session (frame_client.c's run_management_menu()).	2026-07-19 09:09:06 -04:00
tfaour	a358045cea	Fix "Show next" staleness bug; add location/date/share-QR to manage overlay ... Two changes, bundled since they landed in the same session and touch overlapping files: 1. Fix: "Show next" sent the browser's full queue snapshot to POST /api/queue/reorder, which hard-rejected if the server's queue had shifted since the last fetch (e.g. right after a queue-length trim). New POST /api/queue/promote moves one photo to the front authoritatively, with no dependency on client staleness. /reorder itself is now tolerant too -- unrecognized IDs are dropped and missing ones appended, instead of rejecting the whole request. 2. Feature: the manage button's overlay now also shows the photo's location (top-left, only if Immich reverse-geocoded it from GPS EXIF), the date it was taken (bottom-right), and a QR code (bottom- left) linking to a 30-minute public Immich share link -- created lazily when someone actually scans it, not when the button's pressed. New server endpoints GET /frame/photo-info and GET /frame/share/{asset_id} (scoped to the frame's current/queued photos, not any arbitrary Immich asset). Firmware-side, the overlay mechanism generalizes from one spliced region to up to four (manage_qr_overlay.c), each its own small buffer, still never holding the full frame in RAM.	2026-07-19 01:28:25 -04:00
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