Hi all ![]()
I've been working on a custom integration and companion Lovelace card that take a different approach to severe weather alerts, and I'd love feedback from people running HA in regions with active weather.
The problem
If you use Home Assistant for severe weather notifications (NWS, MeteoAlarm, ECCC), you've probably run into the same structural limits that motivated this effort. The maintainers of the existing integrations do excellent work, but they're all fighting the same constraints in the HA state machine:
- The 16 KB attribute limit. The recorder won't store a state attribute payload larger than ~16 KB. When a big storm rolls in with detailed multipolygon geometry and long-form text, that data can get dropped before it's persisted.
- The single-sensor bottleneck. Packing several concurrent alerts into one sensor's attributes means a complex regional outbreak has to share one payload, which compounds the size problem above and makes per-alert automations awkward.
- Lifecycle continuity. When a provider upgrades a watch to a warning (or cancels it), it's hard to track that as one evolving event without churning state history or spawning duplicate entities.
The experiment: cap_alerts
Instead of cramming everything into sensor attributes, cap_alerts uses an event-driven model that creates exactly one entity per active alert, spawned and removed as alerts come and go. Alert data is modeled on CAP (Common Alerting Protocol) field names, so the same shape works across providers.
The goal here is NOT to replace the existing integrations. I'm aiming to field-test an architectural pattern and see whether it holds up across providers and regions. If it does, I'd like to write it up as a proposal that could make life easier for all weather integration maintainers.
Here's what that looks like in practice; several concurrent placeholder alerts in a single card:
Two color themes side by side (left to right: normalized severity tiers, NWS event colors) in the default and compact layouts.
How it works
- Externalized payloads. Heavy data like GeoJSON polygons and long descriptions is held in a bounded in-memory cache and served over a lightweight HTTP endpoint the integration registers, rather than stuffed into state attributes. This sidesteps the 16 KB limit and avoids hammering the recorder (and your SD card) with large writes.
- Lifecycle-aware identity. Each alert gets a stable ID hashed from its event identity rather than the message URL (for NWS that's the VTEC event tuple, for ECCC a language-independent key). That keeps one entity (and its state history) intact across the New โ Update โ Cancelled/Expired lifecycle, instead of churning a new entity on every revision.
- Normalized severity. Severity is mapped to canonical CAP tiers (
extreme,severe,moderate,minor) across providers, so a single automation can react to "anything severe or above" regardless of source.
Ships with four providers today: NWS (US), ECCC (Environment Canada), MeteoAlarm (EUMETNET / Europe), and WMO severe-weather feeds.
The companion card
I also maintain weather_alerts_card, which consumes this entity model natively: severity-driven theming and badges for phase transitions.
It now (as of v3.1.0) even puts those externalized payloads to work! Because the full GeoJSON is served from the integration's cache instead of being truncated at the attribute limit, the card can draw the complete affected-area polygon over a map basemap in the alert's detail panel:
The affected area over a CARTO basemap; adaptive svg above, change your theme to see the inverse light/dark example.
Looking for testers and feedback
Before I write up anything formal, I want to make sure the model survives contact with reality. I can't honestly evaluate every condition and region with the attention they deserve; frankly, I need help testing this approach.
Links:
- Integration: GitHub - seevee/cap_alerts: Proof-of-concept HA weather alerts integration exploring an alert entity pattern: one entity per active weather alert, modeled on CAP fields. Solves the 16KB attribute limit. ยท GitHub
- Card: GitHub - seevee/weather_alerts_card: Weather alerts dashboard card with severity indicators and progress timelines ยท GitHub
If you're somewhere with active weather, I'd love for you to run this alongside your current setup and compare. Feedback on edge cases, dropped or duplicated alerts, and UI quirks would all be hugely appreciated. Thanks!