tfaour 5e86a20e8b
Build and push server image / build-and-push (push) Successful in 35s
Fix config read-modify-write race and two firmware buffer edge cases
Found by a thorough code review:

- server/app/config.py's load()/save() each locked only their own file
  I/O, not the full read-modify-write cycle each route does around
  them. Since uvicorn dispatches sync routes to a thread pool, two
  concurrent requests (e.g. the device's own poll landing alongside a
  web UI edit) could each load() the same on-disk state and the
  second's save() silently clobber the first's changes. Added
  config.locked() (backed by an RLock, since load()/save() also take
  the lock internally) and wrapped every mutating route's
  load/mutate/save span in it -- kept outside the lock wherever a route
  also does slow Immich network I/O, re-loading fresh state right
  before the actual mutation instead. Verified with a new concurrency
  stress test (many concurrent /api/queue/promote and /api/config
  calls) alongside the existing scratch suite.
- firmware/main/root.html's SSID/password/toolsserver/access-token
  inputs had no maxlength, so pasting something longer than the
  matching NVS buffer (wifi_provisioning.h's FRAME_CFG_*_MAX_LEN) was
  silently truncated with no indication why the device later can't
  connect or gets 401s.
- frame_client.c's share_url buffer (256 bytes) could be too small in
  the worst case -- toolsserver (128) + "/frame/share/" + asset_id (47)
  + "?token=" + access_token (64) can reach ~266 bytes, silently
  dropping the token off a request that would then just 401 with no
  obvious cause. Widened to 320.
2026-07-19 15:20:26 -04:00

ESPresso Frame

A DIY e-ink photo frame: an ESP32-C6 pulls photos from your Immich library and displays them on a 7.3" full-color e-paper panel, waking on a timer to refresh and spending the rest of its time in deep sleep.

  • No cables to a computer, no SD card shuffling. Provisioning is a captive portal with a QR code drawn on the panel itself -- scan, join, fill in your WiFi and server address, done.
  • The frame never decodes an image. A small self-hosted server does all the work (pulling from Immich, cropping, dithering, packing into the panel's exact pixel format) and hands the device a stream it can write straight to SPI. The ESP32-C6 has no PSRAM and not much SRAM to spare -- keeping it a dumb display client is what makes that workable.
  • Crops toward faces, not just the center, using face bounding boxes Immich already computed for its own People feature -- no bundled face detector.
  • Refresh interval and album are configurable from a web UI, no reflashing needed to change them.

Hardware

See docs/hardware.md for wiring and docs/architecture.md for how the two halves talk to each other.

Getting started

  1. server/ -- run the FastAPI server first (Docker Compose, points at your Immich instance). See server/README.md.
  2. firmware/ -- build and flash the ESP32-C6, then scan the QR codes it draws on first boot to provision it. See firmware/README.md.

Repo layout

firmware/   ESP-IDF project for the ESP32-C6
server/     FastAPI server: Immich -> crop/dither/pack -> the frame
docs/       Wiring and architecture notes

License

MIT -- see LICENSE. A few small pieces of vendored third-party code (a QR code generator, a bitmap font table) keep their own permissive licenses; see LICENSE for details.


Built with substantial assistance from Claude Code.

S
Description
No description provided
Readme MIT
17 MiB
v1.5.0
Latest
2026-08-04 19:27:00 -04:00
Languages
Python 62.9%
C 19.2%
JavaScript 7.4%
HTML 5.6%
CSS 1.7%
Other 3.2%