⚠️ Alpha pre-release. Continues the 3.7 pre-release line from 3.7.0-alpha1 (per-user state framework). Adds opt-in motion compensation for radar transitions plus a handful of related improvements.
Not recommended for production dashboards — install only if you want to exercise the motion-comp pipeline across radar sources and report findings. HACS users: you'll only see this in your update list if you've enabled "Show beta versions" in HACS settings.
What's new
Motion compensation for radar transitions (#183) — built on top of @genericJE's #156. Rain visibly drifts between frames instead of teleporting to its new position while the old fades out. The implementation kept the snapshot-capture infrastructure and the dual-translate animation pattern that @genericJE built in #156, and swapped two pieces:
- Algorithm: SAD block-matcher → pyramidal Lucas-Kanade optical flow.
- Channel extraction: alpha → distance-from-white intensity.
Together those make motion compensation source-agnostic — works for all three radar sources (DWD, RainViewer, NOAA) instead of being effectively DWD-only. LK runs in a Web Worker by default so slow devices stay smooth; falls back to synchronous main-thread execution under strict CSPs. Auto-skipped on frame pairs without enough gradient signal for a confident vector (light rain, clear sky). Default off — enable via the new toggle in the editor's Animation section or in YAML:
type: 'custom:weather-radar-card'
smooth_animation: true
smooth_overlap: 0
motion_compensation: trueFull architecture and design decisions in docs/motion-compensation-feature-design.md.
Changed
NOAA frame interval bumped from 5 → 10 min (SOURCE_CAPS.NOAA.intervalMin). The empirical publication cadence on NOAA's eventdriven WMS service is ~5-9 min (mean ~7), and the server snaps any TIME query within a publication window to the same physical frame. Requesting at the previous 5-min stride was returning duplicate frames for every other request. Behaviour change for NOAA users: the same past_minutes value now yields half as many frames in the loop, but every frame is unique. Legacy frame_count: N configs auto-migrate to the new stride preserving frame count (e.g. frame_count: 12 migrates to past_minutes: 110 instead of the previous 55 — 12 distinct frames covering twice the real time span). Tracking a server-side fix upstream at the NOAA / weather.gov API repo.
Fixed
Stale frames on resume from long-hidden / device-sleep windows. The visibility-visible handler previously did a single _updateRadar to catch the most recent missed publication — enough for a few-minute tab switch. After longer hidden periods (device sleep, hours-tabbed-away) the single-frame update left the rest of the loop holding hour-old timestamps; the displayed radar would show one fresh frame and N-1 stale ones. Now tracks the wall-clock time of the last frame fetch; on visibility-visible, if >10 min (= 2× the refresh period) has elapsed, scraps the loop entirely and re-fetches every slot from scratch. Brief load state on resume from sleep, but the loop content is correct after.
How to report feedback
Open an issue at https://github.com/jpettitt/weather-radar-card/issues — particularly interested in:
- Motion compensation visual quality across DWD / RainViewer / NOAA — does the rain drift look natural?
- Storm core "jumping" on convective storms (known v1 limitation — single global vector can't track within-cell reorganisation; dense per-region flow is a v2 project).
- NOAA cadence change — is the reduced frame count acceptable for your typical loop length?
- Stale-frame re-init — does the resume behavior feel right after sleep / long-hidden windows?
Full Changelog: v3.7.0-alpha1...v3.7.0-alpha2