My Home Assistant Setup

What is Home Assistant?

Home Assistant is an open-source home automation platform that brings all your smart-home devices, sensors, and automations together in one place. It supports hardware from countless manufacturers, thus creating a unified and flexible smart home. This frees the users from the limitations of any one brand or ecosystem.

The Problem that Home Assistant solves.

Most times, smart-home setups are kind of a hodgepodge of different devices from different brands, each with their own little app or ecosystem. This makes things so much more cumbersome to use, and people are then forced to just deal with one or a few brands just so everything works properly together. Because devices from different manufacturers don't easily share information, the home is never quite as truly "smart" or seamless as it could be.

Solution attempt: Matter
This is an issue the smart-home industry is trying to overcome by developing the Matter standard, a single protocol that all devices can recognize and on which various manufacturers can agree. Although that is a very promising effort, it doesn't solve the situation completely-not for existing or new smart homes.
Read more why here.

Why This Project?

Home Assistant will replace a fragmented smart-home setup with a clear, reliable, scalable system. By centralizing everything in Home Assistant, the home becomes easier to manage, more consistent, and more capable of advanced automations that improve comfort and everyday life.

Who Is It For?

This project is for whomever wants a smarter, more unified home: From the tech-savvy tinkerer that I am, to those who just want the lights to “do the right thing”, all the way to the households seeking comfort and convenience without having to juggle multiple applications.

My Solution

Hardware Setup

I wanted to run Home Assistant on dedicated, standalone hardware for reliability and stability. Mission-critical systems, relying on direct connections like USB Zigbee or Z-Wave radios, generally are more consistent when not virtualized or containerized.
For this reason, I use an Intel NUC:

• More powerful and responsive than a Raspberry Pi.
• Energy-efficient enough for 24/7 uptime.
• Able to handle complex automations without performance issues.

This provides a production environment that is stable and can scale with my smart home.

Hardware & Sensors

I rely on a mix of well-tested sensors from reputable manufacturers: No unreliable €2 AliExpress sensors allowed! Just dependable, high-quality hardware.
In cases where it's absolutely non-critical, I pick devices that are very affordable but proven. For critical functions like lighting and presence detection, I use top-tier hardware that performs predictably.

Why this approach?
A smart home should work for you, not against you. If the lights need to turn on, they should do so every single time. When something only works “9 out of 10 times”, the magic disappears quickly. Reliability is not optional, it’s the foundation.

Core Device Choices

Lighting: Philips Hue
More expensive, yes, but Philips Hue offers reliability, smooth dimming, and excellent integration. For lighting, which needs to work pretty much 100% of the time, Hue is simply the most reliable option available.

Presence Sensors: Aqara FP2
The Aqara FP2 is best-in-class for room-level and zone-level presence detection, detecting not only if someone is in a room but where they are. More data means more intelligent automations, especially for Heating, Ventilation, and Air Conditioning (HVAC), lighting, and safety scenarios.
I use millimeter-wave sensors because they perform better than traditional motion sensors. With a regular motion sensor, if you sit still for a while, it eventually stops detecting your presence. Millimeter-wave sensors avoid this problem by sensing even subtle movement, so you don’t have to awkwardly wave at your smart home to keep the lights on. 🙋‍♂️

Speakers: Sonos
Great sound quality, strong ecosystem support, and a high "Wife approval factor". They're used both for media playback and for broadcasting text-to-speech announcements throughout the home.

Architecture Decisions

One of the most important early decisions in designing a Home Assistant setup is its architecture. Changes in core structures are difficult and require extensive refactoring later on, so it's worth investing the time upfront to get it right.

Another important choice I made was to lean heavily on input booleans as the backbone of my automation logic. By setting booleans that represent states, such as “It's dark inside”, “Person X is sleeping”, or “The house is occupied”, I avoid repeating the same conditions and logic over dozens of automations.

For example, instead of every light automation checking separately if it's dark enough to turn on the lights, I calculate this once and store the result in a boolean. All lighting automations can then reference this single, reliable state.

This approach keeps the system:

• Consistent: One place to define core logic.
• Maintainable: Update or tweak the logic once and not in each automation.
• Scalable: New devices and automations slot in without duplicating work

By treating booleans as reusable building blocks, the whole system becomes more robust, more understandable, and far easier to extend over time.

Booleans I currently use:
- Someone home
- There are guests
- Person X is sleeping
- Everyone sleeping
- Broadcast Push Notifications
- The home is speaking
- Dark outside
- Dark inside
- Room X occupied

Note of Caution:
It’s important to never create too many booleans. Each boolean should be generic enough to be reused across multiple unified blueprints. Creating too many highly specific booleans over-complicates the architecture and leads to unmaintainable blueprints, so adding a new boolean is a conscious decision.

Blueprints

Home Assistant Blueprints make it possible for anyone to import reusable automation templates without writing code. A blueprint-friendly automation should expose only the essential settings, hide the underlying complexity, and allow users to connect their own devices with minimal effort.

The Problem With Most Blueprints

Many community created blueprints try to do everything at once.
They attempt to determine internal state logic - Should the lights be on? Should that depend on lux levels? Sun angle? A fallback if no sensor is available? - while also controlling the automation itself.

This approach leads to:

• Complex logic.
• Unnecessary dependencies on specific sensors or entities.
• Tightly coupled designs that are difficult to reuse, share, or adapt.
• Blueprints that break easily when used in different environments.

Because of these issues, I introduced a clearer architectural structure built around separation of concerns.

My Blueprints Architecture

Core Boolean Manager Blueprint
This blueprint handles the primary state logic and exposes it as simple boolean.
Its purpose is to provide a clean, predictable layer of state management.

Key points:

• Offers ready-to-use logic that integrates quickly and consistently.
• Makes onboarding into the architecture fast and simple.
• Allows complete flexibility - You can replace or override its logic with your own if needed.

Think of it as the “truth source” for states such as dark outside, occupied, asleep, etc.

Advanced Automation Blueprint
This blueprint builds on the boolean layer to create powerful automations with minimal configuration.

Instead of figuring out when it’s dark, or how to handle edge conditions, the blueprint simply asks you to select your "Dark outside" boolean - no logic duplication, no sensor complexities, no guessing.

The Result

Together, these blueprints create a clean, extensible architecture:

• One blueprint manages state in a reliable, standardized way.
• The other uses that state to enable advanced, flexible automations.
• Users gain customization without complexity.
• Blueprints become easier to share, maintain, and adapt across different setups.

It's all about separation of concerns.

Example:
Simple blueprint for "Dark outside" boolean.

More advance blueprint that usages "Dark outside boolean" to turn on the "Garden lights"