# geekofweek/homeassistant: A Personal YAML Configuration Set

> geekofweek/homeassistant is a personal Home Assistant configuration repository with 500+ automations, YAML integrations, device-specific settings, and both current and legacy setups. It is useful as a reference for experienced Home Assistant users, but it is not a documented installable product.

**geekofweek/homeassistant** — Example Home Assistant Configs

- Repository: https://github.com/geekofweek/homeassistant
- Stars: 1,491 · Forks: 155
- Language: Python
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/geekofweek-homeassistant

## A personal Home Assistant control plane, not a packaged distribution

The repository solves a practical home automation problem: preserving the configuration and automation logic behind one resident's working Home Assistant installation. The README describes it as a collection of personal Home Assistant Operating System configurations containing more than 500 automations. Those are not reusable rules in the sense of a general-purpose library. They represent decisions tied to a house, its devices, and the author's routines. The audience is therefore an engineer or advanced Home Assistant user who can interpret entity names, integration requirements, and YAML automation structure against an existing installation.

The repository is not a Home Assistant distribution. Its top-level files include configuration.yaml, automation/, customize.yaml, groups.yaml, homekit.yaml, ios.yaml, rest_command.yaml, scripts.yaml, template.yaml, and emulated_hue.yaml. That layout shows a configuration tree rather than an application package with a documented installer. The README links to Home Assistant itself, but it does not provide installation commands for Home Assistant, a required Home Assistant version, a container image, or a supported deployment configuration. The repository also contains old_ha_setup, which the README identifies as the previous setup. Keeping both generations can help someone trace how the configuration changed, but it can also make it unclear which files belong to the current setup.

The project is intended for people who want examples of a local-first home automation setup. The README states that the author prioritized local control unless it was impossible and moved away from Amazon Echo devices. That goal is reflected in the emphasis on Z-Wave, Zigbee, ESPHome, Apple TV, and local service configuration rather than a cloud-first device catalogue. It is also a warning about portability. Copying a file without copying its hardware, entity mapping, network design, and authentication context may produce a configuration that parses but does not control anything.

## YAML configuration spanning automations, templates, and integrations

Based on the repository layout, the central design is Home Assistant YAML split into focused files. The automation/ directory contains the larger automation collection, while configuration.yaml holds the main configuration entry point. Supporting files cover templates, groups, customizations, scripts, REST commands, iOS-related settings, HomeKit exposure, and an emulated Hue configuration. This separation is useful because it makes a large home configuration easier to scan than a single monolithic file. It also exposes the dependency problem: a reader must understand Home Assistant's domains and entity names before changing any of these files.

The device inventory shows that the configuration is not built around one protocol. Z-Wave devices are connected through a Connect ZWA-2 described as a Waveshare ESP32 board for PoE, controlling more than 50 Z-Wave devices. Zigbee devices use an SLZB-06M connected by PoE and the ZHA integration. Lutron devices use two Lutron hubs because the author says the first hub reached its device limit. Garage-door control uses a ratgdo32 device through ESPHome, including a second internal garage door setup. This variety demonstrates how one Home Assistant configuration can combine local radios, custom hardware integrations, and vendor integrations.

Other entries cover Ecobee thermostats, IoTaWatt power monitoring, Flume, Roborock, Roomba, Navimow, Apple TV, Sonos, Rachio, and a Fully Kiosk Browser wall display. The README explicitly links each device or service to its stated integration, but it does not provide a complete entity map, event schema, or per-automation explanation. A YAML file can therefore document the author's control design by example without serving as a complete tutorial for reproducing it. The repository's automation count also does not mean that every automation is independent. Some may depend on the exact entities and devices listed in the README, although the README does not identify those dependencies line by line.

## Reading the current setup and comparing the legacy tree

There is no documented installation procedure in the README. It does not give a package manager command, Home Assistant installation method, configuration directory path, or required environment variable. For a first real use, the supported activity is inspection rather than deployment. Start with the README's device table, then read configuration.yaml and the supporting files in the repository root. The automation/ directory is the obvious place to inspect the author's rules. The old_ha_setup/ directory provides a separate historical configuration, but the README does not state that it should be copied into a new installation.

A useful first pass is to classify each file by purpose before editing anything. Treat configuration.yaml as the main entry point, automation/ as the rule set, template.yaml as reusable value or sensor logic, and groups.yaml as an organizational layer. The names do not guarantee that these assumptions match every file's contents, because the README does not reproduce their contents. Do not copy the entire repository into a live Home Assistant directory. The device-specific names, secrets, accounts, network paths, and API access may not exist in another home.

The README also records a planned transition for climate control. It says the author's previous Ecobee API access remained intact but that HomeKit would be used if that access failed. That statement is useful context for evaluating the configuration's fallback direction, but it is not a documented migration procedure. Likewise, the Roomba entry says the author intends to phase those devices out in favor of Roborock. These are personal maintenance decisions, not general product recommendations.

## Local control is the design priority, but device limits remain operational constraints

The repository's strongest documented design choice is preference for local control. The author lists local protocol hardware prominently and says the setup was designed to get rid of Amazon Echo devices. The configuration also includes HomeKit and emulated Hue files, which can expose or bridge entities for other clients, but those files do not by themselves establish where each integration's control path runs. The README does not document network topology, firewall rules, pairing credentials, or fallback behavior, so a reviewer cannot infer that every listed device is fully local.

There are concrete capacity and device-management constraints. Two Lutron hubs are used because the first one hit a device limit. The Connect ZWA-2 is described as controlling more than 50 Z-Wave devices, while the Zigbee controller serves multiple bulb brands. These are not merely decorative integrations. They indicate that the configuration was shaped around controller capacity, radio coverage, PoE, and the number of entities exposed to Home Assistant. A new user with a smaller home may find the architecture heavier than necessary. A user with many devices may need to check whether the same controller limits apply.

The configuration also depends on a broad mixture of hardware and services. Six Apple TV devices are listed, more than 20 Sonos devices, three Roborock units, and several climate, cleaning, irrigation, power, and display devices. The README does not describe automation load, startup time, recovery behavior after an outage, or how conflicting rules are resolved. The repository is consequently better evidence of a large personal system than evidence of a generally optimal setup.

## Maintenance and licensing boundaries for a configuration archive

The repository is not archived according to the repository metadata, and the last push was on 2026-05-15. That date indicates recent repository activity, but it does not establish a release schedule, compatibility policy, or promise that the configuration remains aligned with Home Assistant changes. There are no GitHub releases. The README itself says the author may preserve the setup for a while because Home Assistant has moved toward UI-based automations, making the older YAML style less useful to some users. That is an admission of maintenance uncertainty, not evidence of continuous maintenance.

An adopter should expect upgrade work to involve checking Home Assistant release notes, integration changes, YAML syntax changes, device firmware, and credentials outside this repository. The README does not document a rollback process, test suite, schema validation command, changelog, or versioning scheme. It also does not identify a license. The repository metadata says the license is unknown, so source reuse should not be assumed. The absence of a stated license is a practical reuse boundary, not legal advice.

Compared with an official integration or a documented starter configuration, this repository offers a larger personal example but less predictable packaging. Compared with a blank Home Assistant setup, it offers concrete examples of naming, grouping, local device choices, and automation organization. Compared with a maintained community blueprint, it lacks a stated compatibility target and release process. Those differences make it most useful for study and selective adaptation.

## Conclusion

Adopt this repository as a configuration reference if you already operate Home Assistant and want to study YAML automations across Z-Wave, Zigbee, Lutron, ESPHome, climate, audio, and other integrations. Do not treat it as a turnkey installation or as a substitute for official integration documentation. Verify compatibility with your Home Assistant version and local devices first. The last push was on 2026-05-15, and the repository has no GitHub releases, so an upgrade plan must account for unannounced configuration changes.

## FAQ

### What is geekofweek/homeassistant used for?

It is a personal Home Assistant configuration repository containing more than 500 automations and YAML files for the author's home devices. The README does not describe it as a general-purpose Home Assistant distribution.

### How do I install geekofweek/homeassistant?

The README does not provide installation steps for this repository. It points readers to Home Assistant and describes the repository as configuration files, so using it safely would require inspecting the files and understanding the referenced devices first.

### Does geekofweek/homeassistant support Z-Wave, Zigbee, and ESPHome?

Yes, the device table lists Z-Wave and Zigbee controllers and a ratgdo32 garage-door device using ESPHome. It also lists Lutron, Ecobee, Apple TV, Sonos, Roborock, Roomba, Navimow, Rachio, and other integrations.

## Sources

- [geekofweek/homeassistant on GitHub](https://github.com/geekofweek/homeassistant)
- [Issues](https://github.com/geekofweek/homeassistant/issues)
- [README](https://github.com/geekofweek/homeassistant/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/geekofweek-homeassistant