Atomic Calendar Revive: a configurable calendar card for Home Assistant

Two viewing modes, and the reason the card exists at all

Atomic Calendar Revive is a Calendar Card for Home Assistant, and the README describes it as adding advanced settings to allow much more flexibility than other available calendar cards. The card supports both Google Calendars and CalDav, and it offers two main viewing modes.

Event List Mode is the vertical list of upcoming events, with variants in the screenshots for different configurations. Calendar View Mode is the month grid, and the screenshots show it rendering all-day events and marking today. The README notes that the screenshots show a basic configuration, because the card allows far more customisation than the images convey.

The framing matters. This is a third-party Lovelace card, so it sits in the same category as the other custom cards people install to replace or extend a built-in dashboard element. What distinguishes it is the size of the settings surface rather than the visual design.

The project was not written from scratch. The acknowledgements credit the original author atomic7777, and the card is now maintained by Total Debug, with the copyright line in the README under that name. It is MIT licensed according to the README badge and the licence shield, although the `license` field inside the package manifest reads `ISC`, which is a discrepancy worth resolving before the code is redistributed in a form that carries a licence notice.

The feature list is where the card's value actually is

The README's feature list is long enough to be worth reading item by item, because each entry maps to a specific problem with a shared calendar.

There is Event List and Calendar Views, and Lovelace UI Editor Support, which means the card can be configured from the dashboard editor rather than only through YAML. Keyword allow and block lists filter on event text, hide finished events removes what has already happened, and an Event Progress bar shows how far through a multi-hour event you are. Language Translations localize the card. Limit total number of events caps the list, Relative time until events swaps absolute times for phrases like in two hours, and Sort events by start times controls ordering. Only show events between specific times restricts the window, Event Limits and Soft Event Limits bound how many entries appear, and Disable Links stops a tap from opening the underlying event.

Two of those are the ones that separate this from a basic card. MDI Icon support lets each event carry an icon from the Material Design Icons set rather than a generic dot. And Split multi-day events to show on each day with part numbers breaks a long event into per-day entries labeled with which part you are looking at, which is the difference between one line and a day-by-day view for a conference or a trip.

The card is also pre-compiled with the required libraries, which matters for a Lovelace card because it ships as a single JavaScript file that Home Assistant loads into the dashboard.

Configuration lives on an external documentation site, not in the repository

The Getting Started section of the README is three links and nothing else. There is a QuickStart Guide, the Full Documentation, and the Release Notes, and the first two both point to docs.totaldebug.uk.

This is the single most important thing to know before evaluating the project, because a card with a large settings surface is only as usable as its documentation, and none of that documentation is in the repository. The top level entries show where the rest of the project lives: there is a `docs/` directory, an `info.md` and a `review.md`, plus `hacs.json` and `tracker.json` for the HACS custom card repository, and the TypeScript source under `src/`.

The `tracker.json` and `info.md` files exist for HACS, the Home Assistant Community Store, which is the standard installation path for a card of this kind. The README carries a HACS badge, and the repository topics include hacs, lovelace and homeassistant, which confirms the distribution channel even though the README does not spell out the install steps.

The consequence for a reader is that the repository README tells you what the card can do but not how to configure it, and the configuration keys, the YAML shape of the card and the available options all have to be read on the external site. The contributing guide is there too, at the same documentation domain, rather than in a CONTRIBUTING file in the repository.

The compatibility table is where version mistakes happen

The README carries a compatibility table mapping card versions to Home Assistant versions, and it is short enough to reproduce. Card version v7.0.0 requires Home Assistant 2022.6 upwards. v6.0.0 requires 2021.11 upwards, with the note that the progress bar will not work on older Home Assistant versions. v5.0.0 through v5.2.2 covers 2021.6 to 2021.10.x, with the note that it may work on older versions but the `hoursFormat` option will need to be set manually. v4.1.1 covers 0.117 upwards.

One line sits below the table as a warning of its own: Home Assistant 2022.5 will not work with the card, so you must upgrade to 2022.6.

The table is also old. Its newest row is v7.0.0, while the current release line is v10, with v10.4.0-beta.2 tagged on 2026-09-22, v10.4.0-beta.1 on 2026-08-22 and v10.3.1-beta.3 on 2026-08-07. The default branch is `beta`, and every listed release carries a beta suffix. So the compatibility table covers a generation of the card that is three major versions behind, and a user on a current Home Assistant has to work out for themselves that the modern releases are the ones to install.

The `hoursFormat` note is a good example of why the table is worth reading. It is not a feature, it is a manual step that only shows up on older cards, and a user who skipped it would find times rendered in a format they did not choose.

Rollup, Babel and pnpm define the build a contributor joins

The card is TypeScript, bundled with Rollup, and the manifest lists the toolchain with a specific package manager, `[email protected]`, alongside a `pnpm-lock.yaml` and a `pnpm-workspace.yaml` in the repository.

The scripts give a clear picture of the workflow. `test` runs `vitest run` and `test:watch` runs `vitest`, so the test suite is Vitest rather than the Jest that older Home Assistant cards tended to use. The lint scripts are split into a general `eslint src/*.ts` pass and a dedicated one for `src/index.ts` and `src/index-editor.ts`, which makes sense given that the editor entry point is a separate bundle from the card itself.

The bundle steps are two-stage. `rollup` runs `rollup -c`, `build` runs the same with the `--bundleConfigAsCjs` flag, and there is a separate `babel` script that runs `babel dist/index.js --out-file dist/atomic-calendar-revive.js`. The Babel preset in the dependency list includes the TypeScript preset and a decorator proposal plugin, so the pipeline is Rollup producing an intermediate bundle in `dist/` and Babel then emitting the final `atomic-calendar-revive.js` that matches the `main` field in the manifest and the file a Home Assistant user actually loads.

The relevant scripts from the manifest are:

		"test": "vitest run",
		"babel": "babel dist/index.js --out-file dist/atomic-calendar-revive.js",
		"rollup": "rollup -c",
		"build": "rollup -c --bundleConfigAsCjs",
		"start": "rollup -c --watch --bundleConfigAsCjs",

There is a dev mode as well, `start` running Rollup in watch mode with the config bundled as CommonJS, and a separate `watch` script pointing at `rollup-dev.config.mjs`. The `commit` script is `cz`, commitizen, and the dev dependencies include the conventional changelog tooling and semantic-release packages, so the release process is automated from commit messages rather than by hand-editing a changelog.

Compared with the built-in Home Assistant calendar card

Home Assistant ships a calendar card of its own, and the honest comparison is between a native element with a narrow configuration surface and a custom card with a wide one.

The built-in card does the job it was designed for: it shows a configured calendar entity in a list, with a modest set of options. Atomic Calendar Revive's argument, in the README's own words, is that it adds advanced settings to allow much more flexibility than other available calendar cards. The specific advantages are the ones listed above: multiple calendars in one view, keyword allow and block lists, hard and soft event limits, relative times, sorting, a time window filter, and splitting multi-day events across days with part numbers.

The cost of taking the custom route is real and specific. It is a third-party card with an MIT or ISC licensing question to settle, an external documentation site you depend on, a beta release line, and a compatibility table that has not been updated for the current major version. It also runs on your Home Assistant instance, so a card that throws on a Home Assistant release can take a dashboard with it. The built-in card cannot do that, because it ships with the platform.

The decision comes down to the volume and shape of your calendar. One calendar, a simple list, no filtering: the built-in card is the lower-friction choice. Several calendars that need to be merged and filtered, events that span days, and a dashboard where you want a month grid next to your other panels: that is the case this card is built for.

There is also a middle path worth naming, since it is a difference in approach rather than a feature. A Home Assistant template can render calendar entities through Jinja with a fully custom layout, which is more adjustable than either card, at the cost of writing and maintaining that template yourself. The trade is that the template has no settings UI, no documentation site to lean on, and no release cycle tied to Home Assistant versions.

Editorial conclusion

Adopt Atomic Calendar Revive if you run Home Assistant with Lovelace, need several calendars in one card, and want filtering and per-day event splitting that the built-in card does not offer. Do not adopt it if you need a stable non-beta release, if your Home Assistant is older than 2022.6, or if you want the configuration documented in the repository itself, since the README defers to an external documentation site. Verify first which card version matches your Home Assistant release, and read the `hoursFormat` note for v5.x installs, since it is not set automatically on older versions.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. totaldebug/atomic-calendar-revive on GitHub