25 Commits

Include renames

Author	SHA1	Message	Date
tfaour	474b92a282	Add server-side support for a second panel (13.3in Spectra 6 / EE02) and scaffold its firmware target ... Server: Frame.panel_type (new column + migration) is auto-derived from the device's reported board (X-Frame-Board), never user-set -- the panel is a property of the hardware, not a picker in the UI. image_pipeline's packing/render pipeline is parameterized by panel geometry instead of hardcoded 800x480 globals, with the real confirmed 13.3in geometry (1600x1200) registered alongside the original 7.3in panel. Existing 7.3in frames are unaffected (column default + board mapping both resolve to the original panel). Board identifiers are also renamed (devkit/xiao -> devkit_esp32c6/ xiao_esp32c6, plus new "ee02") since the EE02 board also carries a XIAO module -- "xiao" alone stopped disambiguating hardware. The server keeps accepting the legacy bare names indefinitely for already-flashed devices. Firmware: scaffolds a third build target (ee02, ESP32-S3 -- a real chip-target change, not just a same-chip Kconfig variant like xiao) and a new epd13in3e driver component skeleton. The actual panel init/LUT/ refresh register sequence isn't ported from vendor demo code yet (none was available), so that component deliberately fails to compile (#error) rather than risk sending unverified register values to real hardware -- devkit/xiao are unaffected and build identically to before. CI's ee02 build step is continue-on-error for the same reason.	2026-08-04 20:08:22 +00:00
tfaour	3fdda096a9	Smooth battery percent readings before computing drop-rate steps ... A 1M-ohm divider (way over the ~10k source impedance the ESP32 ADC's sample-and-hold expects) doesn't always misfire in isolation -- short bursts of a few consecutive bad readings, and multi-reading drifts, both slip past the existing step-level MAD outlier rejection since the steps between two bad readings in the same burst look ordinary. Add a Hampel-filter smoothing pass (local-neighborhood MAD, same statistical approach as the existing outlier rejection) ahead of it.	2026-07-28 02:09:12 +00:00
tfaour	52ebafab78	Add standalone weather widget (current/hourly/daily/multi-city, pluggable providers) ... New widget type with four display modes -- current conditions, an hourly forecast strip, a multi-day forecast, and several cities' current day side by side -- backed by a pluggable provider registry (app/weather/, mirroring the app/widgets/ dispatch pattern): Open-Meteo (worldwide) and NWS (US-only) both wired up now, Environment Canada documented as the next one to add given its more involved station/grid-lookup API. The calendar widget's existing embedded weather strip is untouched and still Open-Meteo-only; this lifts the same underlying icon-drawing primitives (now shared via app/weather_render.py, calendar_render.py still imports draw_weather_row unchanged) into a widget that can be placed and sized on its own. Icons are redrawn in the panel's actual ink colors (yellow sun/bolt, blue rain/snow) instead of flat black, and build_multi_city's icon/font sizing now scales with how many cities need to fit rather than the box's height alone -- both fixed after catching them via live browser verification, along with a mode-switch cache-shape crash and a mobile-width dialog overflow. New WeatherWidgetConfig table (migration 24), grid footprint, widget module, common.py fetch/cache helper, router endpoints (location set/ clear, city add/remove, preview), dialog template + JS, and full test coverage (providers, widget render, HTTP endpoints, migration replay). docs/widgets.md and CLAUDE.md's TODO updated accordingly.	2026-07-27 16:16:43 +00:00
tfaour	c323402895	Fix scan-to-download auth and share every photo widget's current photo ... The share QR's URL carried no auth params at all, so it silently fell back through require_device's legacy-token resolution to whichever frame happened to still be flagged legacy -- working only by accident for a single frame, sharing the wrong frame's photos for any other, and going fully dead once that frame's legacy flag was cleared. Move the endpoint to manage.py, keyed on the frame's own manage_token (same pattern /m/<manage_token> already uses) instead of device auth. Since the server now resolves assets itself instead of trusting a caller-supplied asset_id, it naturally generalizes to gather every photo widget's current photo into one Immich share link, not just one "primary" widget's.	2026-07-27 14:38:26 +00:00
Thomas Faour	14c47aa2a0	Let a tasks widget merge multiple task lists, checkbox+color like calendar ... Tasks widgets could only ever point at one CalDAV task list (a radio- button picker, owner-only). Now they merge any number of included task lists across every linked user, same checkbox-inclusion + optional pinned-color shape a calendar widget already has for its calendars -- FrameTaskList mirrors FrameCalendar exactly, down to the same owner- adds/anyone-mutes permission split (api_widget_task_list_select/ api_widget_task_list_color). Reused calendar_render._event_colors/ _draw_color_bar as-is for the per-task color bar -- a task dict's owner_display_name/color_index is exactly that function's single- source fallback shape. Also added an opt-in "show tasks completed in the last 24 hours" toggle (TaskWidgetConfig.show_completed): caldav_client.fetch_tasks now accepts a completed_since cutoff and returns completed VTODOs (with their completion time) instead of silently dropping them, and _draw_tasks gives a completed task a filled checkbox + muted text instead of the normal empty-box/due-date row. Migration 18 splits the single-source TaskWidgetConfig columns (added by 17, splitting tasks out of the calendar widget in the first place) into frame_task_lists, carrying forward each widget's existing single source as its first included list -- same shape migration 9 used carrying forward frame_calendars' old single opt-in. Verified live in the browser (desktop + mobile): the new "Included task lists" + "Recently completed" dialog sections, the show_completed toggle actually persisting through a real HTTP round-trip, and no regression in the calendar widget's own "Included calendars" dialog. Full suite (192 tests, including new merge_tasks/config_save/migration coverage) passes.	2026-07-25 03:39:26 +00:00
Thomas Faour	b5c52004c8	Split the tasks feature out of the calendar widget into its own widget type ... Task lists used to be a week-view-only sub-feature bolted onto calendar widgets (CalendarWidgetConfig.tasks_*), so a task list could only exist tied to a calendar's view and only inside its footprint. Tasks are now a standalone widget type (TaskWidgetConfig, app/widgets/tasks.py) that can be placed and sized independently, same as photos/calendar/ whiteboard -- no separate "enabled" flag either, since being on the grid at all is the on/off switch, matching every other widget type. Migration 17 creates task_widget_configs, extracts any existing calendar widget's configured task source into a new sibling tasks widget (auto-placed in open grid space, source dropped+logged if truly none is left), then drops calendar_widget_configs' now-dead tasks_* columns in the same migration -- this project's usual same-migration- drop convention. Also handles the rarer case of a database jumping straight from before the widget system existed to after this split in one boot, via the legacy Frame.calendar_tasks_* columns. Verified live in the browser at desktop and mobile widths: adding a Tasks widget, its own dialog (task-list source picker + preview), and confirming the calendar widget's dialog no longer mentions tasks at all. Full test suite (180 tests, including new coverage for the widget render/actions, the migration's data-extraction path, and the permission-boundary shape for tasks-source) passes.	2026-07-25 02:11:45 +00:00
tfaour	a33a3a71e4	Widget system Phase 4b: per-widget gear-icon config dialogs ... Replaces the Photos/Calendar/Whiteboard tabs with a single Layout page (now the frame's landing route) where each widget gets a gear icon opening a dialog scoped to that specific widget's own settings. This was the missing piece for genuinely independent same-type widgets -- "the Calendar tab" never made sense once a frame could hold more than one calendar widget with different settings. Data layer: FrameCalendar re-keyed from frame_id to widget_id, so each calendar widget has its own independent included-calendars set. The rekey runs as an unconditional post-startup step (like the existing widget backfill), not a numbered migration -- it depends on calendar widgets already existing, which themselves come from that same backfill step, not from schema migration. Registering it as a numbered migration would have run it first during a real upgrade, silently dropping every row; caught by a new test that exercises the raw-SQL upgrade path instead of the fresh-install create_all() shortcut every other migration test takes. API layer: every endpoint that used to assume "the frame's widget of this type" (photo queue/thumbnail/preview, calendar select/color/ tasks/weather, whiteboard source/browse/preview) moved into api_widgets.py under /api/frames/{id}/widgets/{widget_id}/..., with a new require_widget_view/control dependency pair mirroring the existing frame-level ones. Device status (battery/last-seen/firmware) got its own frame-level /status endpoint, split out of the old photo-specific /queue it used to piggyback on -- fixes the status bar going silently blank on any frame without a photo widget. UI layer: each widget type's existing settings markup/JS was ported into a dialog partial + an explicit init/close function pair (the content is now fetched and injected on demand, not loaded at page load time). window.FRAME_API is repointed to the open dialog's widget-scoped API base for its duration and restored on close; a separate window.FRAME_BASE_API stays stable for the always-present header/ status-bar scripts. Caught during manual browser testing: the consolidated config-save endpoint initially expected a JSON body while the copied-over dialog JS posts form-urlencoded data (the old convention) -- fixed to match, with new HTTP-level test coverage that would have caught it immediately.	2026-07-24 14:31:24 -04:00
tfaour	37bd657299	Widget system Phase 2: full cutover to widget-based rendering ... device.py's mode-keyed dispatch is replaced by a real compositor: load a frame's widgets, compute pixel rects via app/grid.py, render each through its widget module, and composite with render_panel. Physical NEXT/BACK buttons now execute each frame's assigned FrameButtonAction rows instead of one hardcoded per-mode action. api_frames.py, manage.py, and common.py's build_manage_content are repointed to read/write the frame's widget config rows instead of the old Frame columns, and every settings page (Photos/Calendar/ Whiteboard tabs) now pre-fills its form from the same widget config the write endpoints actually save to -- previously the read and write sides would have silently diverged. The old mode selector and photo-inlay checkbox are removed along with their now-inert wiring; arbitrary widget placement subsumes what the fixed inlay split did. Ships together with Phase 1 (per-type render/action modules) since splitting the read/write cutover across deploys would have left settings changes with no visible effect.	2026-07-24 09:26:28 -04:00
tfaour	f48daa71c8	Widget system Phase 1: per-type render/action modules ... New app/widgets/ package (photos.py, calendar.py, whiteboard.py, plus the WIDGET_TYPES registry) -- the widget-system analogue of routers/device.py's old RENDERERS/ADVANCE_RENDERERS/BACK_RENDERERS, generalized from "one mode owns the whole panel" to "each widget renders into its own region and responds to named button actions." Each module exposes render(db, frame, widget, target_w, target_h) -> Image.Image (never raises -- a widget's own fetch hiccup falls back to a small placeholder rather than taking the whole panel's render down) and an ACTIONS registry for NEXT/BACK button assignment. Supporting changes needed to give the widget modules something to call, all mechanical/behavior-preserving for every existing caller: - image_pipeline.py: render_panel(regions, ...) generalizes render_frame's tail (paste, enhance once, overlay once, quantize once, pack once) from one photo to N regions -- not a restructuring, since calendar mode's photo-inlay feature already pastes a second composed image onto the canvas before that single shared pipeline runs. - photo_queue.py: advance_forced/back_forced/remove_from_rotation/ get_current take an explicit `frame` param now that `cfg` won't always be the Frame itself once photo-queue state moves to PhotoWidgetConfig -- caught a real latent bug while doing this: get_current was reading refresh_interval_s off `cfg`, but that's a frame-level wake-cadence setting, not something that becomes per-widget, so it now reads that off `frame` explicitly instead. - routers/common.py: list_assets/fetch_source_and_faces take album_id/ display_mode directly instead of a whole Frame (both only ever read that one attribute off it); new get_or_refresh_*_for_widget siblings of the existing calendar/weather/tasks/whiteboard cache helpers, read/ writing the new per-widget config tables -- the Frame-scoped originals are untouched and still what routers/device.py's actual dispatch calls until the Phase 2 cutover. 26 new tests (95 total): render_panel size/placement/orientation coverage, and per-widget-type render/action tests (unconfigured -> placeholder, a fetch failure -> placeholder not a crash, actions mutate the right state). Full suite passes; diff-reviewed to confirm device.py's actual RENDERERS dispatch and the old Frame-scoped get_or_refresh_* bodies are unchanged, so this is safe to deploy on its own despite being step 1 of a two-step cutover (see the project plan on why the *next* step, not this one, has to ship atomically).	2026-07-24 08:44:53 -04:00
tfaour	b4ca795003	Add a whiteboard file picker and force-refresh ... File picker: an optional WebDAV browse root in Settings (User.webdav_base_url) plus a plain-PROPFIND directory listing (webdav_client.list_directory) power a "Browse..." panel on a frame's Whiteboard tab, so a file can be clicked into rather than typing its exact WebDAV URL. Manual URL entry still works unchanged either way. Force-refresh: get_or_refresh_whiteboard takes a force flag that skips the fetch throttle entirely; the Whiteboard tab's refresh button now passes it, so clicking it always re-fetches and re-renders instead of possibly just re-showing the same cached image from within the last ~20 minutes.	2026-07-23 18:20:39 -04:00
tfaour	644fdefa66	Add whiteboard frame mode (Nextcloud Whiteboard / Excalidraw over WebDAV) ... New third mode alongside photos/calendar: fetches a .whiteboard file over plain WebDAV (Basic auth -- generic, not Nextcloud-specific) and renders it via a small Node.js sidecar using Excalidraw's own real export code (@excalidraw/utils + @resvg/resvg-js, no headless browser), since a .whiteboard file turns out to be Excalidraw scene JSON, not an image. The sidecar runs as a second process inside this same container (Dockerfile installs Node, start.sh backgrounds it before exec'ing uvicorn) rather than a separate docker-compose service -- lightweight, stateless, reachable only at 127.0.0.1 from the Python process, nothing worth independently scaling. The rendered PNG is treated exactly like a photo from there on -- composed/quantized through the existing image_pipeline (letterboxed, never cropped) rather than a second parallel rendering pipeline. WebDAV credentials support the common "it's actually the same Nextcloud account as my CalDAV" case (an explicit opt-in checkbox, not silently inferred) while still working with any WebDAV server generically. Frame-level source (URL + owning account) follows the same owner- controls-their-own-data permission split as calendar sources and the week view's task list: only the account owner can point a frame at it, anyone linked can clear it. Honest limitation: this environment has no Node.js/npm, so render-service/ is written carefully against each library's documented API (verified via the npm registry, including transitive dependency licenses after the CalDAV/AGPL surprise earlier this session) but has never actually been executed. First real docker build is the first true test -- see render-service/README.md.	2026-07-23 17:02:08 -04:00
tfaour	ce8525bee8	Week view flexibility: configurable day count, layout, and a CalDAV task list ... - Day count (2-10, was fixed at 7) -- 5 days trims the weekend clutter without losing the grid format. - Layout choice: days side by side (original behavior) or stacked vertically as full agenda-style sections (reuses _draw_agenda_day, same approach _build_today_tomorrow already used for a fixed 2 days). - Optional task list (CalDAV VTODO collections only -- a plain ICS subscription doesn't meaningfully have one) that takes the space of one day slot instead of adding an extra one. Same owner-controls- their-own-data permission split as calendar sources: only the calendar's owner can point a frame's task list at it, but anyone linked to the frame can clear it. Browse-offset paging now moves by N days (was hardcoded to weeks), identical to the old behavior when days=7. Changing the day count resets the browse offset, same reasoning as changing views already did.	2026-07-23 07:58:13 -04:00
tfaour	01b9e9f1d0	Reject outlier readings in the battery estimate ... A single noisy ADC/regulator glitch (see firmware/main/battery.c) survives the existing recharge filter: whichever way it reads, one of the two steps around it (into a dip, or out of a spike) still looks like an ordinary drop and got averaged straight into the remaining- time estimate, letting one bad reading swing it dramatically. Added a MAD-based modified z-score outlier check on top of the existing recency-weighted average. Had to special-case the standard MAD degenerating to exactly 0, which happens whenever more than half the steps share the same value -- the norm for battery data (most wakes cost the same small integer percent), and exactly the shape a single spliced-in glitch among a steady discharge rate has, so the naive case would have let the outlier this is for sail straight through. Falls back to mean absolute deviation there instead. Verified against constructed glitch scenarios in both directions (spurious dip and spurious spike): estimate now comes out identical to the same series with the glitch removed entirely.	2026-07-23 06:22:12 -04:00
tfaour	27cd6b3703	Manual per-calendar color choice for calendar mode ... Each linked person can pin one of the panel's four non-black/white colors (Yellow/Red/Blue/Green) to their own calendar instead of relying on calendar_render.py's old auto-cycle-by-owner-name order -- owner-only, like adding a calendar in the first place. Colors resolve against whichever palette a frame actually renders with (including a custom Advanced configuration override), so a pinned "Blue" stays this frame's actual blue. Event color bars/dots are also bigger and rounded now across agenda/week/month views, easier to tell apart at a glance.	2026-07-22 22:30:55 -04:00
tfaour	ffce798754	Add weather to calendar mode; fix CalDAV events never showing ... Weather: multiple cities per frame, geocoded via Open-Meteo (no API key), shown above the event list on agenda/today & tomorrow/week views -- never month, no room for it there. Hand-drawn sun/cloud/rain/snow/ thunderstorm icons (no new font/icon asset, same primitives-only approach the rest of calendar_render.py already uses). City geocoding handles "City, State" qualifiers Open-Meteo's own search doesn't (disambiguates same-named cities, e.g. the three "Portland"s). CalDAV fix: events were never showing despite calendars discovering fine, because fetch_calendar_events relied on the calendar-query REPORT's server-side time-range filter, which real servers implement inconsistently (confirmed against a real server, not just guessed -- reproduced locally with Radicale). Switched to fetching every event unfiltered and doing all date-window filtering/expansion client-side, same approach already used for plain ICS feeds.	2026-07-22 22:22:11 -04:00
tfaour	acdb929a99	Move mode picker below device status bar; fix invisible calendar lines; add CalDAV calendar support ... Calendar rule/grid lines were light gray, which dithers away to near-invisible on the 6-color e-ink palette -- now black. CalDAV accounts (Nextcloud, Fastmail, iCloud, ...) can now be linked alongside the existing single ICS subscription, since one account can expose several calendars. A frame's Calendar tab now lists calendars per person rather than one opt-in per person: your own row shows every calendar you have available with a full add/remove toggle, while other linked users' rows show only calendars they've included, toggleable off (mute) but not on -- only a calendar's owner can add it to a shared frame. FrameCalendar replaces the old single-boolean UserFrame.calendar_included; existing opt-ins are migrated forward.	2026-07-22 22:01:05 -04:00
tfaour	95d69a5512	Rewrite battery-remaining estimate around per-wake drop rate ... The old estimate used a single linear percent/second rate from the current discharge cycle's battery_history, which resets to empty on every recharge -- so "not enough data yet" kept showing up despite the frame having plenty of history overall, and the rate it did compute was tied to whatever refresh interval produced it (changing the interval didn't move the estimate until enough new history accumulated under the new setting). Now pulls the last 100 rows from the permanent battery_log table instead, and averages the *per-wake* percent drop (not per-second) -- recharge jumps are skipped rather than counted as negative drain, flat/zero-drop wakes still count so the rate isn't overstated, and more recent steps are weighted more heavily. The per-wake rate then converts to wall-clock time using the frame's current refresh_interval_s and quiet-hours settings, so halving the refresh interval roughly halves the estimate immediately, and quiet hours correctly stretches it out (fewer wakes/day at the same per-wake cost).	2026-07-22 21:21:17 -04:00
tfaour	aa194be09a	Calendar mode polish batch + Today & Tomorrow view ... Responds to post-launch feedback on calendar mode: configurable week-start day for week/month views, crisper non-antialiased text (threshold-masked instead of drawn straight, so Floyd-Steinberg dithering doesn't speckle glyph edges), a color-coded/proportionally filled battery icon on the manage overlay, word-wrapped placeholder text so "Calendar isn't set up yet" no longer clips in portrait, photo inlay support extended from agenda-only to every view, and a fix so manage-overlay face labels reposition correctly when a photo inlay is active (they previously assumed the photo filled the whole canvas). Also adds a fourth calendar view, "Today & Tomorrow" -- a two-day agenda that reuses the same per-day row-layout helper the single-day agenda view already has.	2026-07-22 21:20:44 -04:00
tfaour	c007acde75	Add calendar frame mode + server-side manage overlay (server) ... calendar_feed.py/calendar_render.py: fetch/merge per-user ICS feeds, render agenda/week/month views. manage_overlay.py: composites the manage-button overlay server-side (QR, battery, location/date, share-QR, face labels), reused by every render mode. device.py/common.py wire both together: mode dispatch for /frame/image+advance+back, and the &manage=1 flag. Plus UI (frame_config.html Calendar card, settings calendar URL field) and the icalendar/recurring-ical-events deps.	2026-07-22 19:06:49 -04:00
tfaour	e1bca5a81a	Fix false recharge-cycle detection from a single noisy battery reading ... A report was flagged as "the battery got recharged" (resetting battery_history and stats_recharge_cycles, and re-arming the low-battery alert) whenever it came in >= RECHARGE_JUMP_PCT above the single immediately-previous report. That's exactly what a real recharge looks like, but it's also exactly what a normal reading looks like right after one noisy low report: e.g. 60, 59, 58, then a stray 53, then back to a perfectly normal 58 -- 58 >= 53+5 falsely read as a recharge. Now compared against the max of the last RECHARGE_LOOKBACK (3) reports instead of just the one before it, so a lone stray reading doesn't get to set the bar a normal reading then trips. A real recharge still needs to clear all of them, so genuine recharges are still caught immediately (verified: 18% -> 90% still triggers, history still resets). Paired with the firmware-side battery.c change (trimmed-mean ADC sampling) that reduces how often a stray reading like the 53 above happens in the first place.	2026-07-22 16:51:37 -04:00
tfaour	e48ac50ea1	Color/contrast/dithering sliders + before/after render preview ... Advanced configuration gains three sliders (PIL ImageEnhance factors for color/contrast, 0-2, 1=unchanged; a 0-1 dithering strength) applied to every photo this frame renders. Confirmed the parameter conventions against a similar project (jwchen119/EPF: ImageEnhance.Color/Contrast, 1.0 baseline) before implementing; dithering strength isn't natively exposed by PIL's quantize(), so it's implemented by blending the source toward its own flat/undithered quantization before running Floyd- Steinberg on the blend -- at 0 there's no quantization error left to diffuse (exactly the flat result), at 1 it's the original unmodified behavior, with a smooth continuum between rather than dithering being an on/off toggle. image_pipeline.py split into composition (_compose), enhancement (_enhance), quantization (_quantize), and transpose+pack stages so render_frame (device bytes) and the new render_preview_png (a normal viewable PNG, upright logical orientation) share the same pipeline instead of duplicating it. Named-face overlay label math (face_labels.py) was already routed through the shared _placement_transform, so it needed no changes for the new params. Also added the requested before/after comparison: the Configuration tab's new Preview card shows the current photo's untouched Immich preview next to that same photo run through the frame's actual saved rendering pipeline (two new GET endpoints, /preview/original and /preview/rendered) -- immediate visual feedback for tuning the palette and these new sliders. "Refresh preview" re-fetches after saving. Schema migration v6 adds color_boost/contrast_boost/dither_strength, defaulting to 1.0/1.0/1.0 -- reproduces the exact previous rendering until a frame's Configuration tab changes one. Verified against the live-shaped test database: the migration, sliders persisting and clamping out-of-range input, both preview endpoints (real JPEG passthrough / real PNG at correct logical size+orientation), confirmed dither_strength=0 actually changes the rendered bytes vs. default, and the standing legacy-device curl suite.	2026-07-22 08:46:22 -04:00
tfaour	49bc9f9ec9	Display mode: crop to fill, crop to faces, stretch to fill, shrink to fit ... Replaces the smart_crop_faces boolean with a 4-way display_mode select on each frame's Configuration tab (image_pipeline.DISPLAY_MODES): - Crop to fill / Crop to faces: the previous False/True behavior, unchanged (center-crop trimming excess, optionally shifted to keep faces on screen). - Stretch to fill (new): fills the panel exactly, aspect ratio not preserved -- a plain resize, no crop. - Shrink to fit (new): the whole photo visible, letterboxed with white where it doesn't fill the panel. Named-face overlay label positioning (face_labels.py, the manage menu's "who's in this photo") now goes through a shared _placement_transform() in image_pipeline.py instead of duplicating crop-box math, so label placement stays correct (and in-bounds) under all four modes, not just the two crop ones -- letterbox/stretch never crop a face out, so labels just use straight scale+offset math there. Schema migration v5 adds display_mode, backfills it from the old boolean (True/False -> crop_faces/crop_fill), and drops the boolean. Verified against the live-shaped test database: the migration (existing frames correctly preserved as crop_faces), the config page's new 4-option select, actual renders under letterbox (confirmed real white letterbox padding in the packed panel-code bytes) and stretch_fill, invalid-input fallback, and the standing legacy-device curl suite.	2026-07-22 01:32:52 -04:00
tfaour	5b11f2accb	Per-frame palette calibration + sidebar battery indicator ... Advanced configuration (Configuration tab, collapsed <details> section): a color picker per ink color (black/white/yellow/red/blue/green), overriding image_pipeline.DEFAULT_PALETTE_RGB for that frame's actual panel -- different units can vary enough from the documented approximations to be worth calibrating once you can compare a rendered photo against the real hardware. Stored as Frame.palette_rgb (NULL = default, schema migration v4), threaded through render_frame/ render_placeholder/_quantize_and_pack (which now builds the PIL palette image per call instead of once at import) so both photos and the unclaimed/unconfigured placeholder screen respect it. "Reset to defaults" clears back to NULL. Config-save validates exactly 6 #rrggbb values, rejecting anything else with a 400. Also: each frame's sidebar entry now shows its last-reported battery percent (🔋NN%) next to the name, using the frame_dot's existing recently-seen indicator conventions -- silent when never reported (mains-only frames, or before the first report), matching how battery is hidden everywhere else it's not applicable. Verified against the same live-shaped database as the SMTP work: the v3->v4 migration, save/reload/reset round trip through the real HTTP route, an actual rendered image using a custom palette (confirmed via its packed panel-code bytes), input validation, and the sidebar badge against real battery data -- plus the standing legacy-device curl suite.	2026-07-22 01:19:06 -04:00
tfaour	8ac3fc0de3	Redesign phase D: sidebar app shell, per-frame tabs, namespaced API ... The web UI grows into the multi-frame world: a left sidebar lists the user's frames (with an online dot driven by the same overdue math as the Device panel; collapsible off-canvas with a hamburger on mobile), and each frame gets three tabs -- Photos (album picker, now displaying, the drag-to-reorder upcoming grid), Configuration (name/order/ orientation/refresh/quiet hours/timezone/smart crop + the firmware card), and Stats (device telemetry, lifetime counters, battery chart). Settings and Admin adopt the same shell. / becomes a routing hub: first frame, empty-state onboarding page, setup/login, or the manage-QR redirect. The JSON API moves to /api/frames/{id}/... behind require_frame_view / require_frame_control: any linked user (admins see all) can view; 404 for frames outside your view so ids aren't confirmed; mutations 409 with the holder's name unless you hold the soft control lock, and POST take-control always flips it to you. Config saves are now partial updates -- each tab posts only its own fields (checkboxes always sent explicitly), so the split forms can't clobber each other. All CSS moves to static/theme.css and the old 680-line inline script block splits into static/*.js -- the Pointer Events drag-drop state machine and the canvas battery chart ported intact, not rewritten. The CSRF fetch wrapper now reads a <meta> tag. No build step, still vanilla. Verified end-to-end: page/static/API suites, control-lock handoff in both directions, partial-save field preservation, non-admin frame isolation, and the legacy-device curl suite (still byte-identical responses for the deployed frame).	2026-07-21 23:56:18 -04:00
tfaour	9fbbb8ed2b	Redesign phase A: SQLite storage, per-frame data model, device identity ... Replaces the single global config.json (whole-file pydantic model under one RLock) with SQLite via SQLAlchemy 2.0: users/sessions/frames/links/ pending-claims/battery_log tables (models.py), a per-frame lock registry (db.frame_locked) succeeding config.locked(), and hand-rolled schema versioning (migration.py). A pre-database deployment's config.json is imported verbatim as frame #1 on first boot and left untouched as the rollback path; the old single firmware.bin slot becomes per-frame firmware/<id>.bin. Routes split out of the 900-line main.py into routers/device.py (the frozen /frame/* protocol) and routers/api.py (web UI, still on the old single-frame paths for now). Device auth moves to require_device, which already speaks the full multi-frame protocol: per-frame device tokens pushed via /frame/config and acknowledged on first use, self- registration of unknown device ids as unclaimed frames, pending-claim attachment, and the legacy-token migration window that keeps the currently-deployed firmware (no id, shared MANAGEMENT_TOKEN) resolving to frame #1 -- including the one-time binding of its device id when it first reports one after a future OTA. Externally identical for existing deployments: same paths, same token semantics, same response shapes -- verified with a migration fixture, the legacy-device curl suite, a 20-way concurrent-advance smoke test, and a mutate-restart-assert persistence check against a fake Immich. photo_queue.py ports nearly verbatim onto the Frame ORM row (MutableList JSON columns make its in-place list mutations dirty-track); quiet-hours math extracted unchanged into quiet_hours.py.	2026-07-21 23:21:38 -04:00