4 Commits

Include renames

Author	SHA1	Message	Date
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