Automating My Home: Integrations, Devices, and the Automations That Tie Them Together

The what, why, and how of a ~319-device smart home — the integrations that speak the protocols, the devices that listen, and the automations that make it all useful.

Home Assistant is the brain of my smart home. It’s not the flashiest part, but it’s the part that makes everything else worth having: without it, I’d have a hundred gadgets that each need their own app. With it, every device speaks one language, and the automations do the real work.

This post is about the automation layer — the integrations, the devices, and the automations that connect them. Same spirit as the homelab tour: the what, the why, and the how.

The platform: Home Assistant

At the center is Home Assistant — a free, open-source home-automation platform I run on a dedicated machine in the cluster. It’s not a cloud service; it’s software I own, so nothing leaves the house unless I choose to expose it.

Its scale is easy to understate until you see the numbers. Right now it manages about 319 physical smart-home devices across 23 rooms — plus a pile of software integrations and virtual devices it also tracks behind the scenes. The honest caveat: the raw registry count is higher than that, but it inflates the real number, because it includes software/add-ons and the virtual appliance-profiles a single energy monitor derives by load-shape detection. When you strip those out and count actual hardware, it’s the ~319 that matter.

A “device” is a physical unit — a light, a sensor, a switch, a lock, a thermostat. One smart deadbolt is a single device, and you’d think of it as “the front door lock,” not as its many internal sub-parts.

The honest truth about a setup this size: it didn’t get here by planning. It grew room by room, problem by problem. What makes it manageable is a single platform with a consistent model for every device.

The integrations: how Home Assistant talks to the hardware

A smart home spans many manufacturers and protocols, and none of them talk to each other. Home Assistant’s job is to be the translator. It does this through integrations — and the protocol layer is where that translation really happens. Here’s how my house communicates:

That last one deserves a moment. Frigate is an open-source security-camera NVR that runs on a Coral USB TPU (a tiny AI accelerator) so it can detect people, not just motion. That’s the difference between “the camera saw movement” and “a person is at the front door.”

Beyond the protocol layer, Home Assistant also pulls in cloud and vendor integrations: Ring (alarm + contact sensors), ecobee (thermostat + remote sensors), Flair (zoning vents), Sonos, Roborock (vacuum), Sense (whole-home energy monitoring), iCloud3 (phone presence), and more. The mix matters because no single vendor covers everything — a home is a pile of ecosystems, and Home Assistant is what makes them one system.

Here’s the whole stack at a glance:

The devices: what’s actually in the house

The device catalog is the fun part, because it shows how much a home can hold when it grows incrementally. Here’s how the ~319 physical devices break down by what they do (counts pulled from the live registry):

That totals about 300 strict hardware units, and the last ~19 are the camera feeds handled by the Frigate NVR — which is why the headline number is ~319. Two details worth knowing so the numbers don’t mislead:

• One energy monitor (Sense) reports ~80 “appliances.” Those are virtual load-shape detections the monitor derives from a single physical clamp — not 80 separate devices. This is the biggest single source of an inflated “device count” if you just read the raw registry.
• TP-Link power strips count each socket as a device. A single strip powering an audio stack contributes six devices on one physical plug.

Two wiring lessons from the lighting fleet are worth calling out, because they explain a lot of “is it broken?” confusion:

• Many bulbs sit behind TP-Link Kasa wall switches that physically cut power when off. An “offline” bulb behind an off switch is expected, not broken — the wiring explains it.
• The other light circuits use ESPHome relays (my own “soft switch” design) that switch at the bulb without cutting power, so those never appear offline from switch wiring alone. The tradeoff: they depend on Home Assistant being up.

The automations: what it all actually does

Integrations bring devices in; automations are where the magic happens. An automation is simple: when something happens (a trigger), if some condition is true, do something (an action). The power is in the combinations.

I have 37 automations and 4 scripts, and they fall into a few clear types:

Motion-triggered lighting. The classic. A closet light that turns on when it detects motion and off after a few minutes. A hallway that does the same but only at 10% brightness at night. The garage lights that come on when a door opens or motion is sensed, and off when it clears.

Time-of-day scenes. Lights that come on in the evening — not at a fixed clock time, but when it actually gets dark. I used to trigger these off the sun’s elevation; now I use a real luminance sensor that watches a camera feed, so the lights turn on when it’s actually dark rather than on a schedule.

Presence-based control. When someone is in the office, the desk light and monitor are on; when the room’s been empty five minutes, they go off. Same idea in the family room for the entertainment center. This is driven by tracking family members’ phones (via iCloud3), not just motion sensors.

Per-room switch and scene groups. Each room has its own control — dining room lights on an Inovelli dimmer, breakfast-area lights, bedroom side lights. The naming convention (Switch:, TOD:, Motion:, Presence:, Camera:, NSPanel:) is deliberate tagging so I can filter and find things in a big config.

Security and notifications. When Frigate detects a person at a camera, snapshots are taken and pushed to specific family members’ phones, with a cooldown so you’re not spammed. The alarm and deadbolts tie into a “night mode” lockdown routine.

Scripts for multi-step routines. A nightly lockdown that locks both doors and arms the alarm. A Roborock cleaning schedule that vacuums different room sets on different days. An irrigation program for the sprinklers.

There’s also a category I’d call honest fixes: a “hack” automation that restarts the Ring integration if it comes up unavailable after a reboot, because Ring’s cloud connection is known-flaky. It’s an admission that some integrations need babysitting, and it’s worth naming that as part of the real picture.

The design lessons

A few things I’ve learned that are worth passing on:

• Automation is about the trigger logic, not the device. The device catalog is big, but it’s the automations that make it a home rather than a collection. Start from “what should happen” and work back to the devices.
• Fail in an obvious way. Some of my automations depend on Home Assistant being up (the “soft switch” light circuits switch at the bulb). That’s a real tradeoff — if HA is down, those lights stay as they are. Design that consciously rather than discovering it by surprise.
• Expected “offline” isn’t a fault. The WiZ bulbs behind Kasa switches taught me that. Before diagnosing a device as broken, understand the wiring and the failure modes that are actually designed behavior.
• A config this size accumulates drift. I periodically audit all 37 automations against reality, because entities get renamed and old automations silently point at things that no longer exist. It’s maintenance, and it’s worth doing.

Why this layout, in one line

Like the hardware, none of this was architected up front. It grew one room and one problem at a time — a bulb here, a sensor there, an automation when I got tired of flipping a switch. The result is a home where the tech is layered and sometimes a little messy, but it’s mine, I understand it, and it works.

And that’s the whole point of self-hosted automation: you own it, you understand it, and you can make it better every time you notice something it could do for you.