HA-Animated-cards is a copy-and-paste library of animated Home Assistant cards

There is no plugin to install, only YAML to copy

HA-Animated-cards is not a Home Assistant integration, a HACS repository or a custom component. It is a set of markdown documents, and each one contains YAML snippets you place into a dashboard. The top level of the repository holds files such as appliances.md, appliances_v2.md, battery.md, climate.md, climate_collection.md, env_with_graph.md, env_with_graph_v2.md, badge_maker.md and mushroom-legacy-template-card.md, plus a collections/ directory.

The README presents these as categories in a table, and each row links to one of the markdown files: appliances for washer, dryer and dishwasher, a second appliances version, battery level and charging animations, graph cards for temperature and humidity, a badge and button maker, and climate and weather. The batch files inside collections/ group cards that arrived in waves, and the README anchors its video series to those same batch names.

What this means for adoption is that the burden of use sits entirely on the person editing the dashboard. There is no version pinning, no dependency resolution and no update path in the repository, and the project has no GitHub releases. A change to the repository reaches you only if you go back and copy the new snippet yourself.

The instructions point at YouTube. The README links five batch videos, from Batch 1 through Batch 5, and says they explain how to do it. That is the entire walkthrough: the visual demos carry the tutorial, and the markdown files carry the code.

The animation is a card_mod style that reacts to entity state

The mechanism is worth understanding before you paste anything, because the snippets are not static CSS. Each card wraps a Mushroom entity card with a card_mod style block, and inside that style a Jinja2 template decides whether the animation should be running.

The template exposes a small user configuration section. A boolean chooses between two modes, and the rest of the variables name the entities and the comparison to apply:

{% set use_number      = false %}
{% set state_entity    = 'switch.plug_6_local' %}
{% set active_value    = 'on' %}
{% set number_entity   = 'sensor.plug_power' %}
{% set number_operator = '>' %}
{% set threshold       = 0.0 %}

In state mode the template compares the state of the named entity with the active value. In number mode it reads the numeric entity, applies the operator against the threshold, and produces a boolean. Either way the result lands in a single variable, trigger_active, and that variable decides the style:

{% if trigger_active %}
  --shape-animation: ring-breathe 1.8s ease-out infinite;
  opacity: 1;
{% else %}
  --shape-animation: none;
  opacity: 0.7;
{% endif %}

So the animation is a named CSS animation assigned through a custom property, and it is either running infinitely or switched off. The keyframes that make it visible are a box-shadow expansion, referenced through the card's own icon color:

@keyframes ring-breathe {
  0%   { box-shadow: 0 0 0 0 rgba(var(--rgb-{{ config.icon_color }}), 0.9); }
  70%  { box-shadow: 0 0 0 14px rgba(var(--rgb-{{ config.icon_color }}), 0.0); }
}

That is the whole pattern. It runs in the browser on the dashboard client, driven by state changes Home Assistant already publishes.

A card is a Mushroom entity card with a style attached

The Batch 1 example shows the shape of a card entry. The card type is a Mushroom entity card, the entity is a switch, the tap action toggles it, and the card_mod block carries the style that does the animating:

type: custom:mushroom-entity-card
entity: switch.plug_6_local
tap_action:
   action: toggle
icon: mdi:power-plug
icon_color: green
name: Smart Plug
card_mod:
  style:
    mushroom-shape-icon$: |

The icon itself is restyled in the same block, with a large icon size and a negative margin to pull the graphic into the card's layout. The rest of the style adds the breathing ring and the opacity change shown earlier.

Two dependencies are implied by the snippet rather than installed by this project: a Mushroom card for the custom:mushroom-entity-card type, and card_mod for the card_mod style key to take effect. The repository does not bundle either, and it does not check for them. If your dashboard has not already got those in place, the YAML will be accepted and the animation will simply not appear, which is the most likely reason a copied card looks static.

There is also a separate file, mushroom-legacy-template-card.md, which suggests a variant aimed at the older Mushroom template card type. If you are unsure which of the two your installation supports, that file is the place to compare the type strings before you paste.

The Sections view needs rows set to 1.5

One concrete formatting note appears in the README, and it is the kind of detail that saves an afternoon. If you are using the Sections view type, the card may look compressed unless you give it more room:

grid_options:
  rows: 1.5

The note is marked as a fix to use only if you have the issue, which tells you the default grid behaviour differs between view types. A card that renders as a squashed block in a Sections panel is a layout problem, not a broken animation.

The second tip covers appearance rather than layout. The README offers a colour override aimed at light-mode dashboards, adding a few declarations to the ha-card:

background: #1C1C1C !important;
--card-primary-color: white !important;
--card-secondary-color: white !important;

The README is explicit that the values are yours to play with, including rgb and hex forms. These are plain CSS custom properties, so the override works because the card's own theming variables are being replaced rather than because the repository offers a theme setting.

Where the template logic gets rough

The number mode of the trigger logic is where a careful reader should slow down. The numeric value is read with a float(0) filter, so a missing or unavailable sensor does not produce an error but silently becomes zero, and zero is then compared against your threshold. If your threshold is negative, an absent sensor will read as a passing condition and the animation will run. That is a property of the fallback value, not a bug the project documents.

Equality is the other rough edge. The operator set includes '=', and comparing a float for equality against a decimal threshold is a fragile thing to rely on, since the sensor value rarely lands exactly on the number you typed. The '>' , '<' , '>=' and '<=' comparisons behave sensibly with a float filter, so a threshold that triggers on '>' is a safer choice than one that triggers on '='.

None of this is argued in the README. It offers the operator list and says to play with the values, and leaves the arithmetic to the user. That is a fair approach for a card template, but it means the difference between a card that behaves and a card that flickers is entirely in the configuration you paste.

A second limit is the animation itself. The ring uses a box-shadow that expands to 14px on a repeating 1.8 second cycle, and it runs infinitely while the condition holds. On a dashboard showing many such cards, the browser is animating continuously rather than on change, which is a cost you inherit with the design rather than with the implementation.

Custom licence, no releases, and the video as documentation

The repository carries a LICENSE file that GitHub cannot classify as a standard open source licence, so the permissions for reuse are whatever that file says and have to be read directly. The README itself does not describe terms. If you plan to republish a card or bundle these snippets into a shared configuration, reading the LICENSE file is the step that matters, and there is no version of the file quoted here that would settle it.

Maintenance is visible but informal. The last push was on 2026-10-12, and the repository is not archived, so work is happening. There are no GitHub releases, which means there is no tagged version to depend on and no changelog to diff against; the git history is the only record of what changed between batches.

The documentation is split between the markdown files and the YouTube channel linked from the README, and the project also links donation pages for Revolut, PayPal, Ko-Fi, Buy Me a Coffee and Patreon. That tells you the project is maintained by one person who publishes work on a schedule tied to video batches. For a set of dashboard snippets, that cadence is arguably a good fit, since a new batch arrives with a demonstration. For anything that has to keep working unattended, it is not a dependency you can pin.

Editorial conclusion

HA-Animated-cards fits people who want a livelier Home Assistant dashboard and are willing to paste YAML into a card, and it does nothing for people who want an installable integration. Before using a card from it, check that the card_mod and Mushroom card names in the snippet match what your own dashboard already runs, because the repository ships plain YAML with no version checks. If you need a maintained, versioned component with release notes, this repository is the wrong shape, since it has no GitHub releases and carries a custom licence file rather than a standard one.

Frequently asked questions

Official sources

1. Anashost/HA-Animated-cards on GitHub
2. Issues
3. Project website
4. README