A live Home Assistant configuration kept in a public repository

One household's running configuration, published as it is

This repository is a live Home Assistant Core configuration, and the author is unusually clear about the status of the setup. The instance runs Home Assistant 2026.2.3 on a mini-PC with an AMD Ryzen 5 5560U, and the phrase used for the repository is live(-ish) configuration.

The default branch is called live, which is an unusual choice and tells you the intent: this is not a template that gets forked and then diverges, it is the working configuration, committed as it changes. The repository description is simply my Home Assistant configuration files, and the primary language is recorded as HTML, which comes from the custom floorplan rather than from any Home Assistant YAML.

Two conventions make the repository navigable. The first is stated in the documentation: each directory has a short readme explaining what is in there, and the purpose of each file or group of files. The second is visible in the top level listing, where the directories are exactly the Home Assistant domain structure, with alarm, alerts, automation, blueprints, climate, device_tracker, groups, light, media_player, mqtt, notify, scenes, scripts, sensors, switch, template, timers and weather directories, alongside the per-integration YAML files such as configuration.yaml, homeassistant.yaml, lovelace.yaml, telegram.yaml, tts.yaml, go2rtc.yaml, influxdb.yaml, ffmpeg.yaml, samsung_tv.yaml and google_assistant.yaml.

The licence is the Unlicense, which is a public domain dedication rather than a permissive licence. That is the most permissive choice available and it means the whole configuration can be reused without attribution obligations, which is a deliberate choice by someone publishing their home's internals.

The maintenance signal is decent rather than strong. The repository is not archived, the last push was on 2026-10-14, a week before the current date, and there are no releases, which is normal for a configuration that is updated by commit.

Traefik for remote access, Zigbee2MQTT rather than ZHA

The key software list is short and each entry comes with a version, which is what makes a configuration reviewable.

Home Assistant runs 2026.2.3. Traefik at 3.6.9 handles reverse proxying with ZeroSSL for remote access, and the author notes it replaced NGINX, so the change is a recent one. Zigbee2MQTT at 1.42.0 handles Zigbee, running on a separate system. Mosquitto is the MQTT broker.

The Zigbee2MQTT choice is explained rather than asserted. The author uses it instead of ZHA because their experience with Z-Wave taught them the value of separation, and Z-Wave itself is gone now, explained in a separate ZWAVE.md file. That is a real architectural opinion: the radio protocol handling runs outside Home Assistant, with MQTT between them, so a broker outage or a Zigbee stack problem is not a Home Assistant problem.

The Docker compose file shows the separation in practice. Three services are defined. The zigbee2mqtt service uses the koenkk/zigbee2mqtt image with a data volume, passes the USB serial device in directly by its by-id path, publishes port 8080, and has a health check that curls the local port every 30 seconds. The home-assistant service uses the homeassistant/home-assistant:stable image with the config directory mounted, sets the timezone to Europe/London, and runs with network_mode: host, which is a deliberate choice worth understanding before copying it, since it means the container shares the host network stack rather than getting its own. The mosquitto service uses eclipse-mosquitto:2 with config, data and log volumes, publishes 1883, and has a health check that subscribes to the broker uptime topic.

The comment on the mosquitto health check is a security note in passing: the author uses an acl_file that gives the anonymous user only read access to that topic and nothing else.

Three presence trackers, and the reasons the others were dropped

The presence detection section is the most interesting part of the configuration, because it documents four attempts and explains why two of them were abandoned.

Back to using Nmap for device tracking. The author did switch to Fritz!Box device tracking when upgrading the router, but the router ran out of memory, so that went back to Nmap.

A Monitor instance on another Pi3, and an Orange Pi Zero LTS with a CSR 4.0 USB dongle, handles Bluetooth. The author states that this has completely replaced the built-in Bluetooth device tracker and more than halved the startup time of Home Assistant, and that it works with the mobile phones, tablets and beacons of the household.

The HA Companion app handles tracking away from home. The author previously used GPS Logger, but calls the additional sensors in the official app a winner. OwnTracks was also used, through the OwnTracks HTTP integration, but it had an annoying bug that caused it to randomly disable reporting, and it had been abandoned by its developer; version 2.0 of the app solved both problems, but there was no reason to go back.

The design decision is stated at the end: three different trackers, two for home, Nmap and Bluetooth, and one for away, the HA app. The trackers are not merged, and groups are used again. The Bayesian sensor was experimented with but found not flexible enough compared with what the author can do with automations.

That last point is a common finding. Bayesian sensors are good at combining noisy signals into a single yes or no, and bad at expressing the conditional logic that a household with an office window and a motion sensor actually wants. The link to the author's own blog series is offered for the longer history.

The repository has a device_tracker/ directory and the documentation notes that a separate hardware.md file lists the current and previous hardware, which is the file to consult before trying to reproduce any of this.

A floorplan drawn over the purchase paperwork

The floorplan is the part of this repository that is genuinely unusual, and it is worth understanding because it is a pattern rather than a one-off.

The Floorplan integration from ha-floorplan gives a high level overview of the house, and the documentation walks through what the colours mean. The grey bin is due for collection tomorrow and would have a red outline if it were due today. The family room and home office are occupied. The office window is open, shown red with a yellow outline, while all others are closed in green. All outside doors are closed in green, as are many interior doors in brown, with open interior doors in green. Motion has been detected in the office, shown yellow with a red outline, and nowhere else. The family room TV is on in blue. The car is not in the garage, so it is faded, and the freezer lid is closed in blue. All the mobiles are home and the author is working from home. Temperatures and humidity are good in all rooms, in green. The printer's consumables are unknown, in blue.

The construction method is documented. The floorplan was created in Inkscape by importing the image of the house's floorplan from the purchase paperwork and then drawing over it. The SVG is built up in layers, one for the foundation, one for the structure and one for the sensors. The author says the layers are not really used except to make sure the right things are on top, namely the sensors.

That last remark is the honest bit, and it is instructive. A layered SVG gives you a maintainable structure for a complex drawing, and using it only for z-order is a case of a good idea arriving before the need for it. The floorplan.html file at the repository root is the viewer, and the custom_ui/floorplan/floorplan.svg is the drawing itself.

For anyone building something similar, the transferable part is the pipeline: a real floor plan as a vector base, the house data drawn on top, and a sensor state that drives the colours.

Notifications, media and the rest of the house

The remaining sections cover the parts of a home that every configuration has to solve, and the choices are worth scanning for the same reason.

Notifications are layered. Telegram handles some of them. Apprise handles most, sending to Telegram, Discord, Signal, Google Chat, LaMetric and many other places. An Ulanzi TC001 running Awtrix Light does non-interrupting visual notifications, and LaMetric does non-interrupting notifications in person while being a clock the rest of the time. Text to speech goes to the Google Home Minis, the Sonos speakers and the Squeezeboxes, aided by a Sonos Cloud component to avoid interrupting music.

The design pattern is consistent: interrupting notifications go to a device that can make noise, non-interrupting ones go to a display. That is a small decision with a large effect on whether a household keeps the notifications on.

Media covers Symfonisk and Sonos speakers with the Sonos integration, a Squeezebox Radio as a smart alarm clock with its integration, and Cast devices, a bunch of Google Home Minis and a couple of Google Home Hubs.

Lighting is Zigbee bulbs and strips in various rooms, plus the WLED integration and LED strips, which replaced some Yeelight strips and are described as good enough lighting to read by at night and helpful for waking up in the morning.

The directory listing shows the scale of it. There are alarm/ and alerts/ directories, an auth_providers.yaml, blueprints/, intent_scripts/, shell_commands/, a scripts/ directory, an input_boolean/ directory with several other input domains, a proximity/ directory, a custom_components/ directory, a local/ directory, and a ui-lovelace-admin.yaml file alongside the other Lovelace configuration files, which points to a custom admin panel in the frontend.

Editorial conclusion

This configuration suits a Home Assistant user who wants a working, opinionated example rather than a blank template, especially one running Zigbee2MQTT and who wants to see how presence detection was solved with three separate trackers. It does not suit anyone who wants a supported product, since it is one household's setup with a personal naming scheme and a floorplan drawn on the actual house, and it does not suit a Z-Wave user, because that route was removed. Before copying it, read the hardware list, note that the docker compose file uses host networking for Home Assistant, and expect to replace the devices, addresses and secrets.

Frequently asked questions

Official sources

1. DubhAd/Home-AssistantConfig on GitHub
2. Issues
3. License: Unlicense
4. README