4 Commits

Include renames

Author	SHA1	Message	Date
tfaour	fd9516f5d1	Server: quiet hours (no wake overnight), zero firmware changes needed ... Purely a server-side decision: GET /frame/config hands back a longer refresh_interval_s while quiet hours are in effect (exactly the seconds until they end), and clamps the normal interval so the device's next wake lands at the boundary instead of wandering into the window, when outside it but approaching. A device already mid-sleep when quiet hours begin can still land one wake inside the window -- unavoidable without touching the firmware, since it has no wall-clock awareness -- but from that wake on it sleeps straight through to the end. Window is "HH:MM"-"HH:MM", wrap-past-midnight aware (e.g. 22:00-07:00), in the server's local timezone -- added tzdata to the Dockerfile since python:3.12-slim doesn't include it and TZ would otherwise silently resolve to nothing and fall back to UTC. Also fixed the "overdue" device-status check to account for quiet hours: without this it would falsely flag a device sleeping through a long quiet window as unreachable.	2026-07-20 23:25:43 -04:00
tfaour	d5de882b1e	Fix stale documentation found by a doc-accuracy audit ... firmware/README.md's HTTP vs HTTPS section still described the public-CA-bundle trust approach that was tried and abandoned in favor of pinning one specific certificate -- rewritten to match what's actually there. docs/architecture.md was missing the back-photo button entirely (sequence diagram and boot-flow bullets only covered next) and still said the system talks "over plain HTTP" despite HTTPS support. docker-compose.yml.example's MANAGEMENT_TOKEN comment understated its scope (said "the web UI", omitting that every /frame/* endpoint is gated too).	2026-07-19 15:20:12 -04:00
tfaour	6c7468a36e	Add HTTPS support and a management-token gate for the web UI ... ESP32 side can now reach the tools server over HTTPS: the Tools Server field accepts an https:// address for a TLS-terminating reverse proxy in front of the server (which still only ever speaks plain HTTP itself), trusting Cloudflare's Origin CA root (embedded at build time) since that's the common way to get a real cert on a private origin. Every URL the device builds -- image fetch, config check, manage-menu data, the QR codes' own links -- goes through one build_url() helper that picks the scheme from what's configured. Also adds an optional MANAGEMENT_TOKEN (docker-compose.yml) that gates the web UI (/, /api/*) behind a shared secret -- unset by default, so existing trusted-LAN deployments are unaffected. The same token is entered once during the ESP32's captive-portal setup and gets baked into the manage-menu's QR code (?token=...), so scanning it just works; visiting the page without a valid token shows a plain entry prompt instead of the config UI, and a valid query-param hit sets a cookie so the page's own fetch()/<img> calls stay authorized for the rest of the visit. Device-facing /frame/* endpoints are unaffected -- a separate, already-documented trust boundary.	2026-07-19 09:42:38 -04:00
tfaour	e7f096ac23	Support Immich URL/API key via docker-compose env vars ... docker-compose.yml is tracked in a repo meant for publishing, so it can't hold a real API key. Renamed it to docker-compose.yml.example (placeholder values, safe to commit) and gitignored the real docker-compose.yml -- deploying is now "cp the example, fill in real values, docker compose up", no .env file needed. config.load() now reads IMMICH_URL/IMMICH_API_KEY from the environment and applies them on top of whatever's in config.json, so setting them in the compose file's environment: block takes effect without ever touching the web UI. Env vars always win over the UI-saved values when both are present -- verified they survive a save() with different UI-entered values still in place.	2026-07-18 16:05:06 -04:00