5 Commits

Include renames

Author	SHA1	Message	Date
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	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	dcbc71e683	Show "Not enough data yet" instead of hiding the battery-estimate row ... Previously the row just disappeared whenever battery_estimate_s couldn't be computed yet, which looked like the feature was gone. Now it always shows once there's any battery reading at all, with a placeholder until enough discharge history accumulates (matches the "Not enough data yet." wording battery_chart.js already uses for the same situation on the chart).	2026-07-22 11:35:38 -04:00
tfaour	f4d2a23e8a	Drop "On battery for", clarify the remaining-estimate label ... "On battery for" was clutter next to the actual number people care about. Relabeled "Est. remaining" to "Est. battery life left" and dropped the now-unused on_battery_since field from the /queue response. battery_estimate_s itself is unchanged -- it still needs 2h of span and a 2% drop within the current discharge cycle (reset on any 5%+ jump, i.e. a recharge or reflash) before it'll show anything. A frame that's been power-cycled/reflashed recently won't have an estimate yet; that's expected, not a regression.	2026-07-22 11:29:17 -04:00
tfaour	60fcfca4a0	Make the device status card always visible, not just on Stats ... Moved out of the Stats tab's side column into a new horizontal bar shared by every frame page (Photos/Configuration/Stats), sitting between the page title and the tabs so it's on screen regardless of which tab is active. _device_status_bar.html is a new partial included via a device_status block in app_base.html; device_status_bar.js is the fetch/render/poll logic extracted from frame_stats.js and adapted to a wrapping row of label/value pairs instead of a stacked list. frame_stats.html's Device card and now-single-card .side-col are gone -- Battery history and Lifetime stats just stack directly.	2026-07-22 10:46:05 -04:00