mushroom-strategy: generated Home Assistant dashboards from a few lines of YAML

The problem is that lovelace YAML does not scale by hand

The Mushroom Dashboard Strategy exists to answer a specific complaint, and the readme states it in the voice of a user. Are you tired of manually configuring your Home Assistant dashboards, and do you love the elegant design of Mushroom cards but wish for a simpler way to organize your entities, devices and areas?

Home Assistant's dashboard is a YAML document, and a real installation accumulates. Every new device, every new area, every new sensor is another entry to write, and the maintenance burden grows with the house rather than with the number of distinct screens. The strategy's answer is to derive the dashboard from the model Home Assistant already has, which is the device and area registry, and to lay it out in Mushroom cards.

The four headline features describe the scope. Automatic dashboard generation takes you from zero to a dashboard with a few lines of YAML. Intelligent organization creates views for devices, areas and entities. High customization tailors the result to a specific setup with extensive options. Integrated insights displays mini graph cards for sensor data.

The one that matters most is the second. A generated view that simply lists every entity grouped by area is a modest thing, but it removes the maintenance, and the customization options are what let it stop being merely a starting point.

The project is by DigiLive, the author in the package manifest is Ferry Cools, and the homepage documentation sits at digilive.github.io/mushroom-strategy.

Installing means adding a HACS custom repository

The strategy is distributed through HACS, the Home Assistant Community Store, which is the standard route for a community integration. The readme points at the detailed documentation for installation and usage guides, and the release badge and HACS badge in the readme header are the visible confirmation of that path.

There is no Python package to pip install and no npm package to add to a build, which is the point of the distribution choice. HACS copies the strategy into the Home Assistant configuration directory, and Home Assistant picks it up as a strategy in the same way it would pick up any other custom strategy, and it is then selected by name in the dashboard settings.

The repository contents show what the project actually is at build time. There is a src directory holding the TypeScript source, a dist directory holding the built output that gets shipped, a hacs.json file describing the integration to HACS, and a webpack.config.ts with a separate webpack.dev.config.ts for the development build. The maintainer-notes.md file at the root is where release notes for Home Assistant users live, distinct from the GitHub release notes.

The versioning is worth a note. The recent releases are v3.2.0 from 2026-06-20, v3.1.2 from 2026-06-14 and v3.1.1 from 2026-06-12, and the package version in the manifest matches the 3.2.0 tag, so the shipped artifact and the source are in step. The last push was on 2026-09-25, so work is continuing after that release.

A TypeScript build with exactly one runtime dependency

The build side of the project is well specified in the package manifest, and the striking thing is how small the runtime surface is.

The entire dependencies block is one entry:

  "dependencies": {
    "deepmerge": "^4"
  },

deepmerge is what does the merging of a generated view with your own configuration, and having it as the only runtime dependency tells you the strategy itself contributes no framework of its own. It is a builder that produces YAML, not a running application.

The devDependencies are where the tooling lives. The TypeScript toolchain is there with typescript, ts-loader, ts-node and typescript-eslint, the bundler is webpack with webpack-cli, and there is a husky directory plus a is-ci dependency for commit hooks. Two of the dev dependencies are more telling than the rest. home-assistant-js-websocket is the client library for talking to a Home Assistant instance over its websocket API, which is how the project can check a configuration against a real instance during development. superstruct is a runtime validation library, and its presence in devDependencies rather than dependencies says the validation is a build time check on the strategy's own configuration schema, not something the shipped code does.

The scripts reflect the same shape, with format and lint tasks separated by file type, a markdownlint task with an autofix variant, and the documentation served separately:

    "ts:format": "prettier --write \"**/*.ts\"",
    "json:format": "prettier --write \"**/*.json\"",
    "md:lint": "markdownlint-cli2 \"**/*.md\" \"#node_modules\" \"#dist\"  \"#venv\"",
    "docs:serve": "mkdocs serve",

The markdownlint invocation excludes node_modules, dist and venv, which are the three directories where a documentation lint would otherwise drown in generated or third party content.

The documentation is Python tooling for a TypeScript project

One detail in the repository is worth explaining, because it looks wrong at first glance and is actually a deliberate choice.

The requirements.txt file is the documentation toolchain, and nothing else:

mkdocs>=1.5.0
mkdocs-material>=9.0.0
pymdown-extensions>=10.16.1
mike>=2.0.0

There is no Python runtime dependency anywhere in the strategy. These four packages exist because the documentation site is built with MkDocs using its Material theme, with pymdown-extensions supplying the Markdown extensions that theme needs, and mike handling versioned documentation. The mike scripts in the package manifest make that explicit, with docs:serve, docs:serve-versioned and docs:list as separate commands.

The practical consequence is that the project has two toolchains, one for the strategy and one for the docs, and the requirements file covers only the second. A contributor setting up the repository needs Node for the strategy and Python for the documentation, and the mkdocs.yml file at the root is the site configuration.

The documentation structure is the thing a user actually consumes, and the readme is candid that it lives elsewhere. The detailed installation and usage guides are on the documentation site rather than in the repository readme, which is the right call for something with as many options as this project claims, and it means the readme you read on GitHub is a summary rather than the manual.

Where a generated dashboard stops being the right answer

The approach has a clear limit, and it is worth being honest about it before you restructure your Home Assistant configuration around it.

A generated dashboard is derived from the area and device registry, and that registry is a good model for a house organised by room. It is a poor model for a dashboard organised by task. If your ideal front page is a single glance view with the living room lights, the outside temperature and whether the front door is locked, and everything else hidden behind separate views, a strategy that generates one view per area does not describe that. You would be fighting the generator.

The same applies to a dashboard that mixes rooms, such as an all downstairs view, or one whose ordering is a deliberate priority rather than an alphabetical one. Those are exactly the cases where hand written YAML is faster.

The realistic model is that the strategy gets you a complete, tidy baseline for the majority of your entities, and you then customise the views you care about. The customisation options the readme advertises are what make that workable, and the readme is explicit that the result is something to tailor to your setup rather than a finished product.

There is also a dependency worth being aware of. The strategy is built on top of Mushroom cards, so it is coupled to that card set's look and to its availability in your installation. The cards are not part of this project, and the strategy's output is meaningless without them.

On licensing, the details do not quite line up and you should resolve that before you redistribute anything. The project is recorded under a BSD-3-Clause licence, while the package manifest declares MIT. The LICENSE file at the repository root and the package manifest are both there to read, and which one governs is a question worth settling rather than assuming.

Editorial conclusion

Adopt mushroom-strategy if you run Home Assistant with the Mushroom card set and you want a complete, tidy dashboard built from your areas and entities instead of a hand assembled lovelace YAML file. Do not adopt it if your dashboard layout is genuinely bespoke, since a generated view is a starting point you then customise, and check the licence before redistributing, because the npm manifest declares MIT while the project licence is recorded as BSD-3-Clause. Before you commit, install it through HACS, add one area at a time, and compare the generated view against the manual YAML you would have written.

Frequently asked questions

Official sources

1. DigiLive/mushroom-strategy on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases