This release adds two new regions and makes multi-source setups more honest when something breaks.
MeteoSwiss (Switzerland)
If you run the hass-swissweather integration, the card now auto-detects its weather_warnings_at_<postcode> sensor and shows MeteoSwiss warnings with the usual severity colors, progress, and expandable detail.
NSW RFS — Australian bushfire alerts
New provider for the built-in NSW Rural Fire Service feed. It surfaces live bushfire, grass-fire, and hazard-reduction incidents, colored by the Australian Warning System (Emergency Warning / Watch and Act / Advice).
Because that integration creates one entity per incident (without a parent device) and those come and go, there’s a new sources config option that just collects them all for you — no need to hand-list volatile geo_location.* entities:
Degraded-source indicator
If you OR several alert sensors into one card and one of them goes unavailable, the card used to quietly show “No active alerts” — hiding the fact that a source had gone dark. Now it shows a badge naming the broken source instead, and stays on screen even with hideNoAlerts by default. You can tune this with unavailableBehavior: message | compact | hide.
Also in this release
Zone filtering now reads CAP geocodes for better matching
Alerts from sensors in unknown/unavailable state are no longer dropped
Affected-area mini-map renders its geometry as a proper basemap
Bundle downleveled to ES2019 so it loads on older Android WebViews
“Ongoing” metadata verbiage for open-ended warnings
Update via HACS (search “Weather Alerts Card”). Full notes on GitHub:
As always, bug reports and feature/provider requests welcome on GitHub.
v3.3.0-alpha.3 — tap actions, detail pop-ups, progress styling
There’s a lot in this one, and three of the four features started as requests in this thread. It’s a pre-release, so you’ll need “show beta versions” enabled for the card in HACS.
Tapping a row opens that alert in a modal with the whole thing in it: icon, title, headline, area, badges, progress bar, metadata, description and instructions. It’s genuinely per-alert for every provider, so an aggregate sensor holding five warnings gives you five separate pop-ups rather than one shared panel listing everything.
The full Home Assistant action schema works too, so more-info, navigate, url, toggle and the rest all do what you’d expect on a row. If you use Bubble Card, navigate to a pop-up hash still works and is documented in the README.
All of it is configurable from the visual editor — there’s a Tap action dropdown in the Behavior section. That part only landed this morning, so if you tried alpha.2 and went looking for it, it genuinely wasn’t there.
You asked back in June for a straight line instead of the diagonal dashes on the active range. It’s in, and it turned into a per-phase setting rather than a single toggle, so each phase of an alert’s life can carry its own treatment:
solid, striped, shimmer and pulse are the options, and there’s a matching iconBorderStyle for the ring around the alert icon. Both are in the visual editor. If plain everywhere is what you were after, the config above is it.
Your second request, un-hiding dismissed alerts on a timer, hasn’t been built yet. Restore-all in the editor is still the manual answer.
Bubble-style whole-row progress
Instead of a thin progress bar, the row itself can fill:
progressFill: background
A low-opacity wash grows across the row as the alert progresses, behind the text, with the thin track hidden. It picks up the alert’s severity color and dims on expired rows. Tunable through the --wac-* tokens if the default strength isn’t right for your theme.
You asked in the very first reply whether there’d be a Home Assistant theme to match the card, and I said a proper theme was a someday item. This isn’t that, but it’s the groundwork: the card now exposes a set of --wac-* CSS tokens for its surfaces, and alert bodies default to transparent so they inherit whatever your theme is doing rather than painting their own background.
That means a translucent or glassy theme now shows through the card instead of fighting it, and you can restyle the surfaces without reaching into internal class names:
The full token list is in the README under Surface theming.
This is the change I’d most like eyes on. Alert bodies used to paint a solid background and now don’t, which is a visual change that affects every user regardless of config. It’s been in the alpha channel since 20 July with no reports either way, and I’d rather hear about it now than after it ships. If you’re on a translucent, glass, or heavily customised theme, a screenshot would be genuinely useful.
Also
Simplified Chinese joins English, French, Spanish, Italian and German. And there’s a documentation site now at Weather Alerts Card — the README is still the complete reference, but the site is easier to read on a phone.
What I’m asking for
If you run this alpha, I’d like to know about three things specifically: whether the card looks wrong on your theme now that backgrounds are transparent, whether the detail pop-up behaves on mobile, and whether the tap-action dropdown in the editor does what you expect. Everything else is a bonus.
Bug reports are better on GitHub than buried in the thread:
Everything from the 3.3.0 alpha series is now GA, so if you turned on “show beta versions” in HACS to follow along, you can turn it back off.
The three headline features are the ones I wrote up in the alpha post above — tap actions with the built-in detail pop-up, per-phase progress styling, and the --wac-* surface tokens — and they ship unchanged. Rather than repeat all of that, here’s what’s landed since.
NINA — German civil protection. Tenth provider, reading the built-in nina integration. It carries DWD weather warnings, LHP flood warnings, and MoWaS / KATWARN / BIWAPP civil-protection messages alike, with real CAP severity and working onset and expiry times. NINA creates one binary_sensor per region per message slot, so point the card at the NINA device and warnings get picked up as they land in the slots.
One caveat I want to be upfront about: this adapter has a known expiry date. The nina integration is removing its entire entity attribute surface in HA 2026.11 (core#161882), and the replacement hides description and recommended_actions behind an action a dashboard card can’t call while it’s rendering. So the adapter is correct through HA 2026.10 and stops working after that. The route past it is cap_alerts#66, reading BBK’s CAP feed directly, which also gets you polygons, certainty, urgency, eventCode and multilingual bodies that the integration never exposed. Follow that issue if you’re on NINA.
Editor dropdowns work again on Home Assistant older than 2026.02. The visual editor was emitting only the newer selection component’s event shape, which left every dropdown inert on older cores: the menu opened, you just couldn’t pick anything. The card now detects which component set is registered at render time and talks to whichever is there. That fixed all 18 dropdowns, not just the ones that were originally reported.
Dutch joins English, French, Spanish, Italian, German and Simplified Chinese, auto-detected from your Home Assistant locale. Thanks to @BaszzV and @MF-142 for those two.
On the transparency change: it soaked in the alpha channel for a couple of weeks and nobody reported anything either way, so it’s now live for everyone. Alert bodies no longer paint their own background, which means a translucent theme renders its alpha once instead of compounding into a solid look. If your card looks off after updating, that’s the change to suspect, and I’d like to see a screenshot.
Update via HACS (search “Weather Alerts Card”). Full notes on GitHub:
There’s also a documentation site now at Weather Alerts Card if the README is getting unwieldy on a phone.
As always, bug reports and provider requests are welcome on GitHub.
Small release, but if you use geometryStyle: map for the affected-area mini-map, take this one.
The basemap was watermarked, and now it isn’t. CARTO started requiring an API key on the public tiles the mini-map defaulted to at the end of August, so every card on the default basemap has been showing “API KEY REQUIRED” tiles since. Same thing that hit HA’s own map in 2026.8.3. I didn’t want to ship a shared key in a public bundle, and hotlinking OSM directly gets a 403, so the card now draws its basemap from the map_tiles proxy that core 2026.9 added for exactly this. The tiles come through your own instance, no third party sees the alert’s bounding box, dark themes get the same inversion HA’s map uses, and the credit reads OpenStreetMap contributors.
The catch: it needs HA 2026.9 or later. On an older core the proxy doesn’t exist and the card falls back to the plain outline, which is what geometryStyle: shape draws anyway. If you’d rather stay on CARTO with your own key, or point at a tile server you run, geometryTileUrl takes any slippy template and the configuration page shows both forms.
Missed polygons are retried. Related fix in the same area. A CAP Alerts polygon that 404’d once (evicted from the integration’s store, or the store was empty after a restart) stayed blank for the rest of the session. Now it’s retried after a minute, a few times, then left alone.
maxDistanceKm for point incidents. Hides NSW RFS incidents further than a set distance from your HA home location:
It only narrows. The RFS integration already trims at its own radius (20 km by default) from the same home point, so a card value wider than that changes nothing until you raise the integration’s radius. Area warnings from CAP, NWS, BoM and the rest are never touched by it.
Also in: four Dutch editor strings that were still in English, and a guide to getting alert text in your own language, since that question comes up a lot and the answer depends on the provider.
Update via HACS (search “Weather Alerts Card”). Full notes on GitHub:
If your map still shows the watermark after updating, hard-refresh first, then send me a screenshot.
Three main features: multiple alert devices per card, a marker for point incidents on the mini-map, and an editor you can find your way around.
devices: collects from several alert devices.device: only ever took one, while entities: and sources: both took lists. Now devices: does too, so a home-zone CAP Alerts device and a GPS-tracker one can share a card:
type: custom:weather-alerts-card
device: 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d # home zone
devices:
- 9f8e7d6c5b4a39281706f5e4d3c2b1a0 # tracker in the car
An alert both devices carry shows once. A device that goes dark is named on its own. One-device configs behave exactly as before, and the device picker in the editor is multi-select now.
Point incidents get a marker.showGeometry: true on an NSW RFS incident used to draw nothing, there’s no area to outline. It now draws a severity-colored marker inside a ~20 km frame, town scale on the map style. Polygon alerts are untouched, and any future point feed gets the marker for free, CAP Alerts included. Point incidents also pick up a Distance row in the detail panel, km or mi to match your unit system.
An opt-in ring for your own location.showMyLocation: true puts a small neutral ring at your reference point under the marker. Off by default, since it draws your location on a display that might be shared. myLocationEntity takes a device_tracker, person or zone and moves the reference point there. That moves the ring, the distance row AND the maxDistanceKm origin together, so the card never filters from somewhere it isn’t showing.
The editor is seven panels instead of one long scroll. Same 45 controls, laid out in HA house style. A collapsed header names what you’ve changed, each changed row gets a Reset to default link, and every dropdown marks its default. Settings that only matter when another is on stay hidden until it is.
Also fixed: the editor’s text fields rendered as nothing on HA 2026.9, since ha-textfield is gone from that frontend. Title, zones, event code lists, radius, tap paths… all back.
One behavior change if you feed two NWS entities to one card. The same alert from both used to zone-merge with a “2 zones” badge. It now collapses on the alert’s id first, so that badge goes away, and an alert you’d hidden that way shows up once more after updating.
Update via HACS (search “Weather Alerts Card”). Full notes on GitHub:
The device picker only lists CAP Alerts and NINA devices for now. If you’ve got another integration that hands out alert devices, please submit a provider request and I’ll look at adding it.
Released 26 September, later to this thread than I’d like. INMET for Brazil, a nearest-first sort, agency colors on any theme, and the point-incident mini-map finished off.
INMET (Brazil) is the eleventh provider, via the sigrist/inmet integration. sources: [inmet] and you’re done, the card auto-collects every alert it publishes. Thanks to @caiohsilveira for the adapter and the pt-BR translation that came with it. One caveat: the integration puts every alert at the city you configured, not where the weather is, so the marker and distance row point at that city and the editor doesn’t offer maxDistanceKm for it.
providerColors: true paints each alert in the color its agency published, on top of whatever colorTheme you picked. ECCC’s colour tag, MeteoAlarm’s awareness colour, INMET’s hex. Off by default, so nothing repaints when you update. colorTheme: eccc implies it, that theme always meant it.
sortOrder: distance lists point incidents nearest your reference point first, and follows a moving myLocationEntity. Area warnings sort ahead of them, they already cover you.
CAP Alerts point incidents now frame at town scale with a marker, instead of one blurred tile stretched across the card. maxDistanceKm and the distance row work on them too. Together with the marker and the you-are-here ring from 3.4.0, that makes the point-incident setup one block of YAML. The NSW RFS version:
geometryStyle: map needs core 2026.9 for the tile proxy and goes online, drop it for the offline outline. Leave maxDistanceKm off for RFS, the integration already trims its feed at 20 km from home.
Also fixed: swapping the entity with hideNoAlerts on used to leave the old entity’s visibility condition behind. And the providers page now ends with a capability matrix, one row per feed: what shape it carries, where severity comes from, which filters act.
If you’re on NINA, the route past HA 2026.11 shipped today.CAP Alerts 0.6.0 adds a BBK provider that reads the NINA app’s own CAP feed directly: MoWaS, KATWARN, BIWAPP and LHP flood warnings alongside the DWD relay, with polygons the nina integration never exposed. The card’s nina adapter keeps working through 2026.10, so there’s no rush, but that’s the move. 0.6.0 also brings NSW, Queensland, WA and Tasmania under one Australian provider, and its point alerts need this card release or later to draw.
Update via HACS (search “Weather Alerts Card”). Full notes on GitHub:
If you do switch from NINA to the BBK provider, I’d like to hear how the two compare side by side for a week. Anything the per-slot setup showed you that the CAP entities don’t?
MeteoSwiss (Switzerland)
NSW RFS — Australian bushfire alerts
Degraded-source indicator
NINA — German civil protection. Tenth provider, reading the built-in 
