Advanced Camera Card: a Lovelace camera card that carries its own gallery

From Frigate Card to a general camera card

The Advanced Camera Card is a comprehensive camera card for Home Assistant, and its history is stated in one line at the top of the README: formerly known as Frigate Card. The name change matters because the scope grew with it. The features it lists are not Frigate features alone, they are camera features, and the repository topics have followed, with cctv, frigate, home-assistant and nvr as the tags.

The feature list is the best short description of the card available. It offers live viewing of multiple cameras, clips, snapshot and review browsing via a mini-gallery, and automatic updating to continually show the latest clip or snapshot. It supports filtering events by zone and label, gives arbitrary entity access through a menu, for example reaching a motion sensor, and has a fullscreen mode. Media can be laid out as a grid or as a carousel with swipeable media, thumbnails and cameras, and direct media downloads are supported. It also has Lovelace visual editing, full Picture Elements support, and it is theme friendly.

Two of those lines are about behaviour rather than layout. Automatic updating is what turns a camera card from a static picture into a display that keeps showing what just happened, and the arbitrary entity access through a menu is what lets the same card surface a motion sensor or a door state next to the video.

The project is MIT licensed with the `LICENSE` file at the root, the author is Dermot Duffy, the primary language is TypeScript, and the documentation is published separately from the code at `dermotduffy.github.io/advanced-camera-card`, with a demo site at `card.camera`. The last push was on 2026-10-12 and the recent releases are v8.1.0 from 2026-09-08, v8.0.2 from 2026-09-01 and v8.0.1 from 2026-08-31.

The card ships its own carousel, gallery and timeline

The dependency list in `package.json` shows what a card like this has to build for itself, and the list is long.

  "dependencies": {
    "@cycjimmy/jsmpeg-player": "^6.0.5",
    "@dermotduffy/panzoom": "^4.6.2",
    "@egjs/hammerjs": "^2.0.17",
    "@use-gesture/vanilla": "^10.3.1",
    "embla-carousel": "^8.6.0",
    "embla-carousel-wheel-gestures": "^8.0.1",
    "masonry-layout": "^4.2.2",
    "side-drawer": "^3.1.0",
    "screenfull": "^6.0.2",
    "vis-timeline": "^7.7.3"
  }

The media surface is assembled from several pieces. The carousel is Embla, with a separate wheel gestures package for trackpad and mouse wheel input, and `vis-timeline` provides the timeline used for review browsing, with `vis-data` and `vis-util` beside it. `masonry-layout` is the grid arrangement, `@use-gesture/vanilla` and the HammerJS packages handle touch and pointer gestures, and `side-drawer` and `web-dialog` are the overlay surfaces, with `screenfull` for the fullscreen mode. The pan and zoom behaviour comes from the author's own `@dermotduffy/panzoom` package, and `@cycjimmy/jsmpeg-player` is the video player used for the live view.

That last dependency is worth pausing on. A live camera stream in a browser card is not a video tag, it is a stream format the player has to handle, and the fact that the card brings its own player rather than delegating to the browser's media element is a decision about the camera integrations it wants to work with.

The alternative to all of this is the built-in path. A Home Assistant dashboard can show a camera with a standard picture element and a stream, and can be assembled from several standard cards. The difference in approach is that the standard path is a handful of native elements with no extra download, while this card is one element that carries a media viewer, a timeline, a gallery, gestures and a dialog implementation with it.

Websocket, nunjucks and zod make up the Home Assistant layer

The rest of the dependencies are the plumbing between the card and Home Assistant, and they are where the integration contract lives.

`home-assistant-js-websocket` is the client library for the Home Assistant websocket API, and it is what lets the card read entities and subscribe to state changes. `ha-nunjucks` and `js-yaml` are the templating and YAML layers, `zod` is used for schema validation of the configuration, and `xss` is in the list for escaping. Dates are handled by `date-fns` with `date-fns-tz` for time zones, and `moment` and `any-date-parser` sit alongside them, which is a sign of how many date formats a card that renders timestamps from several sources has to accept.

The user interaction helpers are also in that list. `keycharm` is a keyboard shortcut library, which is what makes the card usable with a remote control or a keyboard-driven dashboard. `quick-lru` is a bounded cache, `p-queue` limits concurrency, `component-emitter` and `uuid` handle events and identifiers, and `lit` at version 3 with `@lit/task` and `@lit-labs/scoped-registry-mixin` is the component framework the card is built on.

Two of the dependencies are worth a second look for an installer. `zod` means a bad configuration should fail with a validation error rather than a blank card, and `xss` means templated content from the dashboard configuration is escaped, which matters because the card renders user-supplied templates.

The user interface is a web component, which is how a Lovelace card integrates with the dashboard: the card registers itself with Home Assistant and receives the configuration the dashboard editor produces.

Installation through HACS and the Lovelace editor

The distribution route is HACS. The repository carries a `hacs.json` at the root and a HACS badge in the README, and HACS is the standard way a Lovelace card that is not part of Home Assistant core reaches a dashboard. The card therefore is not installed through a package manager in the usual sense, it is fetched by HACS and placed in the HACS frontend directory, and the Lovelace visual editing support listed in the features means it can be configured in the dashboard editor rather than by hand-writing YAML.

The card is also usable as a standard card would be, since it supports the full Picture Elements set, so a camera entity can be placed with the same kind of configuration as any other picture element, with the extra features layered on top of that.

The theme friendly claim is the one that usually decides whether a card survives a dashboard redesign. A card that hard-codes colours and sizes looks wrong the moment a user switches theme, and a card that reads the theme tokens from the surrounding dashboard does not. The dependencies support that reading, with `ha-nunjucks` for template rendering and the presence of a separate `stylelint.config.js` at the root, which is a style checker for the stylesheets, alongside `prettier.config.js` for formatting and `.prettierignore`.

The documentation site is separate from the repository and the README does not duplicate it, which is the right call for a project of this size, and it is also why the repository itself is mostly code: the `docs/` directory holds the images, and the substantive documentation lives on the site.

A devcontainer with Home Assistant, Frigate and MQTT

The `docker-compose.yml` in the repository root is the development environment, and it is a good description of what the card is tested against.

services:
  homeassistant:
    extends:
      file: .devcontainer/frigate-hass-integration/docker-compose.yml
      service: homeassistant
    volumes:
      - .devcontainer/homeassistant_preconfig:/preconfig.d/02-card:ro
  frigate:
    extends:
      file: .devcontainer/frigate-hass-integration/docker-compose.yml
      service: frigate
  mqtt:
    extends:
      file: .devcontainer/frigate-hass-integration/docker-compose.yml
      service: mqtt

Three services, all of them extended from a shared compose file in `.devcontainer/frigate-hass-integration/`: Home Assistant itself, Frigate, and an MQTT broker. The card is mounted into Home Assistant through a preconfiguration directory, as `/preconfig.d/02-card:ro`, read only, which is how a card is registered with a Home Assistant instance without rebuilding an image.

The devcontainer service mounts the Docker socket and the local environment file, and the whole thing runs through the `.devcontainer/` directory, with a `.devcontainer/` build target in the compose file.

What this tells you about the project is that the card is developed against a real Home Assistant instance talking to a real Frigate instance over MQTT, with the card preloaded. That is a heavier development environment than a mock, and it is the reason the card can be tested against the integrations that matter, in particular the Frigate ones that provide events with zones and labels, which is what the event filtering feature works on.

Semantic releases, three test configs and a strict toolchain

The repository is a serious piece of engineering tooling, and the file list shows it.

Releases are cut with semantic-release, using the `@semantic-release/github` plugin, which is why the tags are v8.1.0, v8.0.2 and v8.0.1 and why the `package.json` version field is the placeholder `0.0.0-dev`. A consumer pinning a version therefore pins a tag, and the version in the file is not something to rely on.

There are three test configurations: `vitest.config.ts` for unit tests, `vitest.browser.config.ts` for browser tests, and `vitest.dist.config.ts` for the built distribution. The last one is the interesting choice, because testing the built artefact catches the problems that only appear after bundling, such as a dependency that behaves differently when it is a package rather than a source file.

The build is Vite, with `vite.config.ts` at the root, and the linting is layered: `eslint.config.mjs` and a separate `eslint.dist.config.mjs` for the distribution, `stylelint.config.js` for the stylesheets, `prettier.config.js` with the import sorting plugin, and `knip.jsonc` to find unused files and dependencies. `lychee.toml` is a configuration for a link checker, which is what keeps a documentation site's internal links from rotting. `project.inlang.json` and the `project.inlang/` directory hold the translation setup, and `.browserslistrc` declares the browser targets the build has to support.

The repository also carries a `.claude/` directory, a `.cursor/` directory, and `AGENTS.md`, `CLAUDE.md`, `GEMINI.md` and `INSTRUCTIONS.md` at the root, which is a fairly complete set of instructions for coding assistants working in the tree, and a sign of how the project expects to be worked on.

Where this card is the wrong choice

The obvious case is a dashboard with one camera in one tile. The standard Picture Elements support already covers that, the card is a large dependency tree to install for it, and every extra card in a dashboard is load time in the browser.

The second case is a user who wants a card that stays in step with Home Assistant core. This one is a third party card with its own release train, its own versioning and its own dependency list, and it will lag or lead the platform depending on the week. The features that need the Frigate integration, and the event filtering by zone and label in particular, are the ones that tie it most closely to one camera stack, so a user with a different NVR has to check which parts of the card apply to them at all.

The third is an operational one. The dependency list is long, with a video player, a carousel, a timeline, a masonry layout, a gesture library, a drawer's worth of overlays and a validation library, and every one of them is code running in the browser of every dashboard that uses the card. On a wall-mounted tablet with limited memory, that matters, and the card's own feature list, with live view of multiple cameras and a mini-gallery, is exactly the configuration where it will be heaviest.

The alternative is the composition approach: build the view from the standard cards and picture elements, keep the live view in the standard stream element, and accept that the gallery, the timeline and the filters have to be built separately or left out. The difference in approach is that the standard route is a dashboard you assemble from pieces the platform already updates, while this card is one element that arrives complete, with the release cadence and the browser cost that implies.

Editorial conclusion

The Advanced Camera Card fits a Home Assistant user running several cameras who wants live view, recorded clips and event filtering in one Lovelace element, and who is willing to install a third party card with a large dependency tree rather than compose the standard picture-elements card by hand. It is the wrong choice for a dashboard that only needs a single camera in a picture element, and for a user who wants a card that stays small and updates with Home Assistant core, because this one ships its own carousel, timeline, gallery and dialog implementations. Before installing it, read the documentation at `dermotduffy.github.io/advanced-camera-card` for the configuration options, check that the release you pull through HACS matches the Home Assistant version you run, and note that the repository is on version 8 with tags cut by semantic-release, so a pinned version is a real option rather than a theoretical one.

Frequently asked questions

Official sources

1. dermotduffy/advanced-camera-card on GitHub
2. License: MIT
3. Project website
4. README
5. Releases