A Home Assistant config kept in Git, with 100+ automations and a README table of contents

This is a running config, not a distributable package

The repository description says it plainly: Home Assistant config files, rewritten to use the latest features, with 100 or more documented automations and an automatically generated table of contents. There are no GitHub releases, and requirements.txt names only `homeassistant`.

That file names homeassistant and nothing else at the Python level. Everything else the setup needs comes through Home Assistant itself, which is the first clue about how this repository is meant to be read. It is not a library, it is somebody's house, and the value is in the patterns rather than in an installable artifact.

The top level looks like a working config directory rather than a project skeleton: configuration.yaml at the root, scenes.yaml, scripts.yaml, automations.yaml, a themes directory, includes/, custom_components/, appdaemon/, pyscript/, rhasspy/, utils/, www/ and a chores file. A.HA_VERSION file records the Home Assistant version the config is aligned with.

Licensing is MIT, so reuse is subject to its licence terms.

Automations are split into a root file plus an includes directory

automations.yaml sits at the top level, and a directory named automations/ carries the rest. The README points at includes/binary_sensors.yaml for per room presence detection built from binary template sensors, which is the clearest sign of the structure: shared logic lives in includes/ and is pulled into automations rather than duplicated.

That pattern matters because it is the difference between a config you can maintain and one you cannot. A presence model expressed once as template sensors and referenced from every room automation stays correct when the underlying sensor changes.

The featured automations the README highlights cover an alarm clock that uses the AppDaemon volume ramp and a sunrise app, arriving and leaving logic, dishwasher and washing machine completion notifications, robot vacuum behaviour, work schedule tracking, and a security rule that notifies when the front door has been open too long or when motion is detected with nobody home.

Lights are handled through several paths at once: automated light behaviour, Philips Hue dimmer switches paired with Xiaomi Aqara switches, and music and light control from an Aqara Magic Cube gesture controller. The overlap is intentional in a house where different family members use different physical controls.

AppDaemon apps carry the stateful logic that YAML cannot

Three Python apps under appdaemon/apps do the work YAML handles badly.

wake_up_light.py is a sunrise emulator, so it ramps brightness over time instead of switching a light on. wake_up_with_spotify.py slowly ramps the volume as part of waking up. battery_monitor.py sends low battery level notifications.

The volume ramp is the design point. An automation with a repeat and delay can approximate it, but the timing is tied to the automation's lifecycle and to what happens when the trigger re-fires. In AppDaemon it is a class with state.

The AppDaemon tags and appdaemon directory at the top level confirm this is a deliberate architectural choice rather than an add-on, and the fact that the primary language of the repository is JavaScript points at the Lovelace side of the setup rather than at the automations.

The README is generated, which is why the automation index stays current

The most reusable idea in this repository is documentation automation. One of the highlighted automations is a converter that turns lovelace.json into lovelace-ui.yaml for version control. Another is the README table of contents, described on the subreddit as making it easier to copy YAML from GitHub because the README automatically lists all automations and the entities they use, with links to the relevant parts of the YAML.

Read that as an architecture. Lovelace dashboards are edited as JSON in the UI, which is hostile to version control, so the JSON is converted to YAML for storage and kept under Git. Automations get parsed and indexed into the README, so the documentation cannot drift from the code. The repository carries a Yaml Lint workflow badge and a scripts.yaml at the root, which is where such tooling is wired.

The theme switching between light and dark mode is listed under the frontend section, along with iOS themes the author publishes separately as lovelace-ios-themes.

Pinned to a monthly Home Assistant release

The README carries a badge stating the running Home Assistant version, currently 2026.10.0, linking to the corresponding core release tag. The.HA_VERSION file at the repository root exists for the same purpose in machine readable form.

That pinning is the maintenance story. The repository describes the config as rewritten to use the latest features.

The last push was on 2026-10-08, and the repository is not archived. There is no changelog and no release history beyond the commits, so if you are diffing against an older fork you are reading git history directly.

The repository also contains a CLAUDE.md file at the root, a marker that some of the automation is written or edited with an AI assistant and that conventions for it are documented in the repository.

What you can and cannot take from it

The parts that generalise are the structural ones. Splitting presence logic into binary template sensors under includes/ is a pattern for any house. Moving long ramps into AppDaemon instead of stretching an automation is a pattern for any wake-up routine. Converting Lovelace JSON to YAML before committing, and generating the README index from the automation files, are patterns for anyone who wants their config reviewable in pull requests.

The parts that do not generalise are the entity names. Lights, sensors, media players and the vacuum are addressed by names from one household, and the Apple Watch, MacBook Pro touch bar and iMac speaker integrations depend on hardware that is not in the repository. The HA-Menu integration for controlling speakers on the author's iMac and the home-assistant-macbook-touch-bar component are both external projects this config consumes.

There is also a guide.md described as a guide written for the author's girlfriend, which is the honest signal about how much of this config assumes context you will not have. The device tables in the README, with unit counts and euro prices totalling 137.52 for the switches, describe specific hardware rather than a shopping list.

The Ideas section at the end of the README, suggesting a notification when a window is open and it is raining and a budget keeper using the Bunq API, is a to-do list, not a feature list.

Editorial conclusion

Treat this repository as a reference implementation rather than a config to install: the entity IDs, device names and AppDaemon apps assume the author's own hardware, so copying it wholesale gives you a broken instance, while reading automations/, includes/binary_sensors.yaml and the appdaemon/apps Python files gives you patterns you can adapt. Check .HA_VERSION and the HA Version badge before borrowing anything, since the config tracks a specific monthly Home Assistant release. If you want the documentation discipline without the personal hardware, copy the generated table of contents workflow instead of the automations.

Frequently asked questions

Official sources

1. basnijholt/home-assistant-config on GitHub
2. Issues
3. License: MIT
4. README