maxi1134 Home Assistant Config: one smart home setup documented end to end

The interesting part is the history of hubs, not the YAML

The README tells the story of how the setup arrived at its current shape, and the story is a sequence of consolidations. It started in 2018 after losing keys twice, when a former roommate bought a Schlage Z-Wave lock and a 2018 Samsung SmartThings hub. That led to Philips Hue on its own hub and Xiaomi sensors on yet another, and to custom Zigbee integrations, until there were three hubs with overlapping frequencies and rising frustration. The fix was consolidation onto a single HUSBZB-1 stick running ZHA, then a move to Zigbee2MQTT with a ZBT-2 coordinator, and later a ZWA-2 added for locks. The stated outcome is no more Zigbee drops and no more Z-Wave issues, just unified device management. For a reader setting up their own house, that sequence is the useful part, because the hardware decisions in the current config are the residue of those attempts.

The repository is a working Home Assistant config, not a set of examples

The top level is a Home Assistant configuration directory, and the file names show it. There is a .HA_VERSION file, a .ha_run.lock, a .gitignore, a configuration.yaml, an automations.yaml, a scripts.yaml, and a .storage/ directory holding the Lovelace interfaces. Alongside them sit packages/, includes/, blueprints/, custom_templates/, custom_zha_quirks/, themes/, intent_scripts/, and a dwains-dashboard/ directory. There is also an espresense/ tree, an appdaemon/ directory, a local_openai_stt_sessions/ directory, a .shopping_list.json, an aircast.xml, an mqtt_dump.txt, a quotra.js and a QV-RGBCCT.js, plus assets/ and image/ for the media the dashboards use. The primary language of the repository is recorded as Jinja, which fits, since most of the YAML is templates. This is a deployment, not a library, so nothing here is designed to be imported.

Lovelace dashboards are committed, which makes the UI reviewable

One of the more unusual choices is committing the.storage/ directory, which is where Home Assistant keeps the dashboard and other frontend state. That directory is normally excluded from version control because it is machine-generated, so including it means the dashboards are reviewable in a diff, that a UI change shows up as a pull request, and that a broken dashboard can be reverted like any other file. The screenshots in the README show what that buys you: wall display panels on two tablets, a framed light panel, and an interactive floor plan with projected shadows and lights. For anyone who has fought with a YAML dashboard change that only broke on the wall tablet, having the interface under version control is the difference between a fix and a mystery.

Indoor localization is the most reusable piece of engineering here

The indoor localization document covers presence detection through ESPresense, floorplans and proximity tracking, and there is a separate directory, espresense/floorplan_creator/, holding a GUI tool and workflow for producing floorplans for ESP-based indoor localization. The root also carries an everything-presence-zone-configurator/ directory, which suggests another custom tool in the same vein. This is the part of the repository that generalises best, because presence detection in a house is a hard problem that everyone solves differently, and here you get both the configuration and the tool that was written to support it. The assets for the interactive plan demo live under assets/interactive_plan/. A floorplan creator is a small idea with a disproportionate effect on whether presence zones are worth the effort.

Zigbee device inventory and the hardware notes answer the questions you cannot Google

The documentation set is where the institutional knowledge sits, and the badge row at the top of the README maps it. Automations List v2 and v3 give detailed descriptions of all the automations including triggers, routines, special modes and security. Hardware covers the host server specs, expansion devices, Z-Wave and Zigbee sticks and network gear. Zigbee Devices lists all the Zigbee devices with their types and placement, which is the document that saves you a weekend of trial and error on whether a particular sensor works well in a particular room. Software covers operating systems, the Home Assistant config, tooling, add-ons and VM specs. WiFi and Networking covers VLANs, network architecture, access strategies and buy-again notes. There is also a voice assistant guide covering an Ollama and ESPHome stack, and a general thoughts document with lessons learned, network and point-of-sale planning, VLANs and, in the author's words, rants.

The three custom components are the parts worth reading the code for

Three directories in the root are clearly hand-written rather than copied. The custom_zha_quirks/ directory holds quirks for ZHA, which is how you patch behaviour in a Zigbee integration when a device misbehaves, and this is a common need in a house with mixed vendors. The custom_templates/ directory holds shared Jinja templates that the configuration reuses elsewhere. The everything-presence-zone-configurator/ directory appears to be a helper for building presence zones, tying back to the ESPresense work. The repository also carries a.vscode/ directory and a themes/ directory, and the.HA_VERSION file pins the Home Assistant version the configuration was written against, which is the kind of detail that saves an upgrade from becoming archaeology.

The documentation is inconsistent about its own age, so check both dates

There is a discrepancy worth flagging. The README footer states Last Updated: January 2026 and Status: Active and Evolving, while the repository's last push was on 2026-10-08. The homepage field points at a Buy Me a Coffee page rather than a project site, and the licence is not declared, with the repository metadata recording it as unknown. The README also encourages forking, opening issues and reaching out, and describes the repository as covering everything from core configs to documentation, hardware and software details and personal lessons learned, with the stated aim of being useful for replicating the setup, troubleshooting your own, or simply browsing home automation stories. The honest way to read that is that it is a personal project with an active changelog rather than a maintained product, so anything you copy should be checked against your own hardware and against the Home Assistant version you run.

Editorial conclusion

This repository is worth reading as a reference if you are running Home Assistant with Zigbee, Lovelace dashboards and indoor presence detection, because the Zigbee device list, the VLAN architecture notes and the automation write-ups are the parts that generalise beyond the author's own house, and having the reasoning recorded next to the YAML saves hours of guessing. It is a poor fit as a template to fork, since the automations, entities and dashboard layouts are tied to one set of devices, and the licensing is not declared in the repository. Verify first which of the pieces you actually need, and treat the automations list and the general thoughts document as the entry points before copying any configuration into your own install.

Frequently asked questions

Official sources

1. Issues
2. maxi1134/Home-Assistant-Config on GitHub
3. Project website
4. README