Home Assistant Automation System — Local Smart Home Control Done Right

By Dmitry Drezyulya · Updated May 3, 2026 · ~14 min read

Home Assistant is the open-source platform that lets your smart home keep working when the cloud goes down, the company that made your devices goes out of business, or your internet provider has a bad day. It runs on a small computer in your house, connects to all your devices over local protocols, and exposes them as a unified system you can automate, visualize, and control.

This guide covers what Home Assistant is, the four ways to install it, how it integrates with HomeMaster controllers, the automation patterns you will actually use, and how to back it up so you can recover from disaster. By the end you should know how to get a stable Home Assistant installation running and integrated with industrial-grade hardware.

What is a Home Assistant automation system?

A Home Assistant automation system is a local control platform that connects devices, processes data, and executes automation logic without depending on external services. It acts as a central layer where:

• Devices provide data
• Automation rules evaluate conditions
• Actions are executed
• Users monitor and control the system

This approach makes the system predictable, fast, and independent from internet connectivity. Sensors send data. Logic decides what should happen. Devices react. And all of this is visible in one interface.

The important part is that it runs locally. You do not need to send data outside just to decide whether a pump should start. That decision can be made inside your own system.

Home Assistant installation options: HA OS vs Container vs Core

Home Assistant offers four official installation methods, and the choice has real consequences for what you can do later. Understanding the trade-offs upfront saves migration pain.

Home Assistant OS (recommended for most users). A purpose-built operating system that runs Home Assistant plus its supervisor, add-ons, and full hardware management. You install it on a Raspberry Pi, a small NUC-class mini-PC, or a virtual machine. Updates are managed through the UI. Add-ons (ESPHome Dashboard, Mosquitto MQTT broker, AdGuard Home, Frigate, etc.) install with one click. This is the path the Home Assistant team recommends and the one most installer-friendly. Pick this unless you have a specific reason not to.

Home Assistant Container (for Docker-comfortable users). Just the Home Assistant Core application running as a Docker container on a Linux host you already manage. No supervisor, no add-on store — anything outside HA itself you install yourself (separate Docker containers for MQTT, Node-RED, etc.). Pick this if you already run a NAS, server, or homelab and want HA as one container among many. You give up one-click add-ons; you gain integration with your existing infrastructure.

Home Assistant Supervised (advanced, increasingly rare). Same architecture as HA OS — supervisor plus add-ons — but installed on top of an existing Debian-based Linux distribution. Useful for hardware where HA OS does not have official images. Requires careful setup; the supervisor is sensitive to underlying OS changes. Not recommended unless you specifically need it.

Home Assistant Core (manual Python install). The HA application installed via pip into a Python virtual environment. Maximum flexibility, maximum maintenance burden. You handle all dependencies, services, restarts, and upgrades manually. Pick this only if you are an experienced Linux administrator and want full control of every layer. Most production installations should not use Core.

For first installations and most HomeMaster users, Home Assistant OS on a Raspberry Pi 4/5 or a small Intel mini-PC is the right answer. It just works, integrates with HomeMaster controllers via the ESPHome add-on, and survives reboots without intervention.

How HomeMaster integrates with Home Assistant

Every HomeMaster ESPHome device — MiniPLC, MicroPLC, and OpenTherm Gateway — appears in Home Assistant automatically through the ESPHome native API integration, which is built into Home Assistant by default.

Home Assistant is not the brain of the system. The controllers are. The MiniPLC or MicroPLC reads sensors, controls relays, and executes logic directly. They run ESPHome, so everything happens on the device itself. Home Assistant connects to them, shows what is going on, and adds the dashboard, automations across multiple devices, and the mobile app.

For example, the controller decides to start a pump when temperature rises. Home Assistant simply shows that the pump is running and records it. This separation makes things simpler. The controller deals with real signals. Home Assistant deals with visualization and control across the whole house.

Home Assistant + HomeMaster: integration walkthrough

Here is the full path from unboxing a HomeMaster controller to having its entities in Home Assistant.

1. Power on and provision Wi-Fi. Mount the controller on DIN rail, connect power. Open improv-wifi.com in a Chrome-based browser, connect to the device over USB-C or Bluetooth, enter your Wi-Fi credentials. The device joins your network in 30 seconds.

2. Discover in Home Assistant. Within a minute of joining your Wi-Fi, the controller appears under Settings → Devices & Services → Discovered. Home Assistant detects it through mDNS auto-discovery. Click "Add" and confirm. The ESPHome integration is built in — no setup required.

3. Take Control in ESPHome Dashboard. Open the ESPHome add-on (install from the Home Assistant Add-on Store if you have not already). The newly provisioned controller appears in the dashboard because each device's YAML includes a dashboard_import: block pointing at its default firmware on GitHub. Click "Take Control" to import the full configuration.

4. Edit the YAML to declare expansion modules. For a MicroPLC with connected modules, add packages: to bring in each module's default ESPHome package. A typical config looks like this:

yaml

uart:
  tx_pin: 17
  rx_pin: 16
  baud_rate: 19200
  id: uart_modbus

modbus:
  id: modbus_bus
  uart_id: uart_modbus

packages:
  enm1:
    url: https://github.com/isystemsautomation/homemaster-dev
    ref: main
    files:
      - path: ENM-223-R1/Firmware/default_enm_223_r1_plc/default_enm_223_r1_plc.yaml
        vars:
          enm_prefix: "ENM#1"
          enm_id: enm_1
          enm_address: 4

5. Install the firmware. Click "Install" in ESPHome Dashboard. ESPHome compiles your YAML and OTA-flashes the controller over Wi-Fi. No USB cable needed after the first power-on.

6. Use the entities in Home Assistant. Go to Settings → Devices & Services → ESPHome → your device. Every sensor, switch, number, and light from the module's package shows up as a Home Assistant entity. Add them to dashboards, use them in automations, expose them to voice assistants, log them to InfluxDB, alert on them through your phone — they behave like any other Home Assistant entity from this point on.

The entire integration is local. No cloud account, no external server, no MQTT broker required. The controller talks to Home Assistant directly over your local network through the ESPHome native API.

Native API vs MQTT — which to choose

Home Assistant supports both protocols for talking to ESPHome devices, and the choice matters for installations beyond a couple of sensors.

Native API is a custom protocol designed by ESPHome specifically for fast local communication with Home Assistant. It uses persistent TCP connections, binary serialization, and supports low-latency streaming sensor updates (typically tens to low hundreds of milliseconds on a local network). It requires no broker — Home Assistant connects directly to each ESPHome device. This is the path HomeMaster controllers use by default; you do nothing extra to enable it.

MQTT is a generic publish-subscribe protocol that works with any MQTT broker (Mosquitto is the standard, available as a Home Assistant add-on). Messages flow through the broker, and every subscriber sees them. ESPHome devices can publish to MQTT instead of (or in addition to) the native API.

Pick Native API if Home Assistant is your only consumer of device data — which is the case for 95% of installations. It is faster, simpler, requires no broker, and "just works" out of the box with HomeMaster controllers.

Pick MQTT when you have multiple subscribers — typically Home Assistant plus InfluxDB, Node-RED, a custom logger, or a separate dashboard. MQTT lets all of them subscribe to the same topic and receive the same data without each separately polling Home Assistant. MQTT is also the standard for non-ESPHome integrations (Tasmota, Zigbee2MQTT, custom firmware), so if you have a mixed ecosystem, the MQTT broker becomes a natural integration point.

The two are not mutually exclusive — you can run an ESPHome device on the native API for Home Assistant while a separate Tasmota device publishes through MQTT. Home Assistant handles both simultaneously.

Common automation patterns: scenes, scripts, blueprints

Home Assistant offers three primary tools for automating behavior, and they solve different problems. Understanding when to use each saves a lot of refactoring later.

Scenes capture a snapshot of entity states. "Movie night" sets the living-room lights to 30% warm white, the TV to HDMI 1, the AC to 22°C, and arms a "do not disturb" mode on phones. Scenes are fire-and-forget — once activated, the entities go to those states, but the scene does not monitor or maintain them. If someone changes a light afterward, the scene does not push it back. Scenes are perfect for moods and predefined contexts; they are weak for ongoing logic.

Scripts are sequences of actions, optionally with delays, conditions, and parallel branches. A "leaving home" script might: arm the alarm, close all blinds, set heating to away mode, send a phone notification confirming departure, and turn off all non-essential outlets — in that exact order, with appropriate timing between steps. Scripts are reusable: you call them from automations, dashboard buttons, voice assistants, or other scripts. Use scripts for any multi-step action that you want to invoke from multiple places.

Automations are the most general — they pair triggers (something happened) with conditions (the situation makes the action relevant) and actions (do this). A trigger might be "front door opened after 22:00", the condition might be "alarm not disarmed", and the action might be "send notification, turn on hallway light, start camera recording for 60 seconds". Automations are the default tool for "when X happens, do Y". They live in the YAML or in the Automations UI.

Blueprints are templates for automations. Someone writes a blueprint once — for example, "motion-activated lighting with adjustable timeout and night mode" — and shares it. You import the blueprint, fill in three or four parameters (which motion sensor, which lights, what timeout, what hours count as night), and you have a working automation in 30 seconds without writing YAML. The Home Assistant community has thousands of blueprints; check the Blueprint Exchange before writing your own automation from scratch.

In practice, a HomeMaster + Home Assistant installation uses all four: scripts for canonical multi-step actions, scenes for contextual presets, automations for sensor-driven behavior, blueprints to avoid reinventing common patterns. Keep complex logic on the controller (in ESPHome YAML) where it does not depend on Home Assistant being up; keep visualization, voice control, and cross-device coordination in Home Assistant.

A real system example

Consider a chimney heat recovery system. There are several parts working together: a water jacket, an air heating, pumps, valves, flow meters, and a backup gas heater.

If you look at it physically, it is quite complex. But from the control side, it is straightforward. The MiniPLC reads temperatures (PT100 RTDs, DS18B20 sensors over 1-Wire) and switches pumps and valves depending on conditions. It does this continuously through ESPHome's local logic. Home Assistant shows what is happening — you can see how temperature rises, how heat is transferred, how the system reacts. You do not need to guess. You just look at the data.

Once everything is connected, devices are no longer isolated. A temperature sensor is part of a heating process. A relay is not just a switch — it is a pump or a valve. Home Assistant shows this through entities. Instead of working with registers, you work with real values from your system. This makes the system easier to understand.

The control logic — when to start the pump, when to switch to backup heating, when to close the valve — runs on the MiniPLC, not on Home Assistant. If the Home Assistant server reboots, restarts, the chimney system keeps working. The controller restores its state from the hardware RTC and continues where it left off. The full chimney walkthrough — wiring, YAML, automation logic, fail-safe design — is documented in Smart Chimney with MiniPLC, ESPHome & Home Assistant.

More integration examples

The same architectural pattern (controller runs the logic, Home Assistant adds dashboards and cross-device automation) appears across very different installations:

• Smart Solar Heating with MiniPLC. A legacy closed-loop solar water heating system upgraded with MiniPLC, PT100/PT1000 RTDs, and four DS18B20 sensors. ΔT-based circulation pump logic runs on the controller (activate when collector minus boiler exceeds 10°C, deactivate at 3°C); Home Assistant visualizes the heat flow and energy capture over time. Pumps default to ON via NC relay terminals for fail-safe behavior if the controller loses power.
• RGB-621-R1 LED Controller with MicroPLC. A residential ambient lighting installation using the RGB-621-R1 5-channel RGB+CCT LED driver behind a MicroPLC. Modbus packages expose all five PWM channels as Home Assistant light entities. Smooth, flicker-free dimming at low brightness; scenes and color automations run from Home Assistant.
• AIO-422-R1 Wind Monitoring with MicroPLC. Industrial wind speed and direction sensors (4–20 mA outputs) wired through 510 Ω resistors to convert current signals into 0–10 V for the AIO-422-R1 analog inputs, plus a PT100 RTD for temperature. The MicroPLC polls the AIO module over Modbus RTU and exposes wind data as Home Assistant sensors that drive weather-based automations (close shutters in high wind, log gust events, alert on extreme conditions).

In all four cases, the Home Assistant integration is the same: native API auto-discovery, packages: blocks in the controller YAML, no MQTT broker, no cloud. The hardware-specific logic stays on the controller; Home Assistant gets the high-level entities and orchestrates across the whole installation.

Backup and recovery strategies for HA

A working Home Assistant install accumulates value over time — automations, dashboards, integrations, history, custom scripts, exposed entities. Losing it without a backup is days of rebuilding. Plan for backup before you have a problem.

Native backups (Home Assistant OS / Supervised). From Settings → System → Backups, create a full backup with one click. It includes the database, configuration, add-on data, and add-on configurations. Back up before every major Home Assistant update — if the update breaks something, you restore in 5 minutes. Set the backup to repeat on a schedule (daily or weekly) under the same Backups page.

Off-device storage. Local backups protect you from software failures but not from hardware loss. Configure the Google Drive Backup add-on (free, well-maintained) or copy backups to a NAS. Store at least one copy off the device that runs Home Assistant. The Google Drive add-on uploads automatically and keeps configurable retention (e.g., 7 daily + 4 weekly + 6 monthly).

Test your restore procedure. A backup you have not tested is hope, not a plan. Once a year, restore your latest backup onto a fresh Home Assistant install in a VM and verify it works. The first time you restore should not be during an outage at midnight.

For Container and Core users. No supervisor means no built-in backup tool. Instead, snapshot the config/ directory and the database file (home-assistant_v2.db) to off-device storage on a schedule. A nightly tar to a NAS, or a Restic/Borg backup to S3, both work fine.

HomeMaster controllers do not need separate backup. Their YAML lives in your ESPHome Dashboard (which is part of Home Assistant backups) and on GitHub if you contribute changes. Module configuration lives on each module's persistent storage and survives any Home Assistant disaster. If your Home Assistant disk dies, you restore the backup, the controllers reconnect automatically, and the modules keep doing what they were doing without interruption.

Where Home Assistant fits in the layered architecture

A common mistake is trying to put all logic into Home Assistant. It works, but it makes the system dependent on it.

In real installations, Home Assistant is better used for seeing what is happening, recording data, and adjusting behavior. Controllers handle the rest. This way, the system keeps working even if Home Assistant is restarted or temporarily unavailable.

The architecture works in three layers, each independent:

1. HomeMaster expansion modules keep doing their physical I/O job through their RP2350 Arduino firmware even if the controller is rebooting.
2. Controllers keep orchestrating modules through ESPHome — and keep accurate time through the hardware RTC — even if Home Assistant and the internet are both down.
3. Home Assistant adds the dashboard, mobile app, voice control, complex multi-step automations, and historical data on top.

If Home Assistant goes down for an hour, your house keeps working. If your internet goes down for a week, your scheduled automations still fire on time. That is what local-first means in practice.

What you get in the end

When Home Assistant is set up correctly with HomeMaster controllers, you stop thinking about the firmware layer. Devices appear automatically. Automations run reliably. Dashboards show what you need. The mobile app gives you remote access without exposing your home to the cloud. Voice control works through Home Assistant Cloud (paid, optional) or local options like Wyoming protocol with self-hosted speech.

This is not zero-maintenance — Home Assistant releases monthly updates, integrations occasionally need attention, and add-ons benefit from periodic upgrades. But it is far less work than maintaining a cloud-connected smart home, and the system is yours forever. No vendor can decide tomorrow that your smart home is unsupported.

That is what local automation means in practice.