homelab

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

9/15/2026

Integrations, devices, and automations, and the what/why/how behind each.

Home Assistant is the brain of my smart home. 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 work.

This post covers the automation layer: the integrations, the devices, and the automations that tie them together. Same spirit as the homelab tour.


The platform: Home Assistant

Home Assistant is a free, open-source home-automation platform. I run it 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 decide to expose it.

Right now it manages about 320 devices across 20+ rooms and zones. That number needs a caveat, because the raw count in the registry is higher and the difference isn’t hardware. It includes software add-ons and the virtual appliance-profiles my energy monitor derives by watching load shapes. Count only the physical gear and you land around 320.

By “device” I mean a physical thing: a light, a sensor, a lock, a thermostat. One smart deadbolt counts once, no matter how many internal readings it reports.

A setup this size didn’t come from planning. It grew room by room, problem by problem. What keeps it manageable is one platform with the same model for every device.


The integrations: how Home Assistant talks to the hardware

A smart home is a pile of manufacturers that don’t talk to each other. Home Assistant is the translator, through integrations. The protocol layer is where most of that work happens:

Protocol What it is How I use it
Zigbee A low-power mesh radio standard The backbone for sensors, switches, dimmers, and plugs, via two USB radios
Z-Wave Another low-power radio standard, stricter about interference Locks, dimmers, and the water valve
MQTT A lightweight pub/sub message broker The backbone for custom and DIY devices
ESPHome Custom firmware that turns cheap ESP chips into HA-native devices My self-built Shelly relays and MJSP outlets
Frigate A self-hosted NVR with on-device AI Camera feeds, analyzed for person and object detection

Frigate is worth explaining. It’s an open-source NVR that runs on a Coral USB TPU, a small AI accelerator, so it detects people rather than motion. “A person is at the front door” is not the same as “something moved.”

On top of the protocols come the cloud and vendor integrations: Ring for the alarm and contact sensors, ecobee for the thermostat, Flair for the vents, plus Sonos, Roborock, Sense, iCloud3, and others. A home accumulates ecosystems, and Home Assistant is what makes them one system.

The whole stack at a glance:

Home Assistant automation stack: physical protocol layer feeding the brain, which drives the automations that control the house


The devices: what’s actually in the house

The device table shows how much a house can hold when you never planned it. These counts come from the live registry:

Category Devices Notes
Lighting 82 WiZ (49), Leedarson, Tapo, Govee, IKEA TRADFRI, and one-offs, all controlled uniformly
Switches & plugs 73 TP-Link Kasa strips and switches, Third Reality, SONOFF, Leviton, eWeLink
Security & access ~40 Ring alarm + 25 contact sensors, 2 Kwikset deadbolts, Reolink cameras, First Alert smoke/CO, water valve
Climate & comfort 48 1 ecobee + 10 sensors, 31 Flair vents/zones, heaters, fans, air purifiers
Sensors 19 Motion, contact, leak, presence, temp/humidity
Voice & control 14 4 NSPanel touch panels, 3 HA Voice satellites, IKEA buttons, phone ATA
Media & entertainment 11 Sonos, Denon, WiiM, Vizio, Google Nest Hub, Echo
Infrastructure 5 Zigbee + Z-Wave radios
Appliances 5 Roborock vacuum + dock, LG washer/dryer, smart faucet
Energy & irrigation 2 Sense whole-home monitor, OpenSprinkler
Maker / other 1 3D printer monitoring (OctoPrint)

About 300 of those are strict hardware, and the rest are the camera feeds behind the Frigate NVR, which is where the ~320 comes from. Two things can inflate the count if you’re not careful: the Sense energy monitor reports around 80 “appliances” that are really load-shape guesses from one physical clamp, and each socket on a TP-Link power strip counts as its own device.

The lighting fleet taught me two wiring lessons that explain most “is it broken?” confusion. Many bulbs sit behind TP-Link Kasa wall switches that cut power when switched off, so a bulb that reads offline behind an off switch is behaving correctly. The other circuits use ESPHome relays (my soft-switch design) that switch at the bulb and leave its power on, so they never look offline from wiring alone. The tradeoff is that they depend on Home Assistant being up.


The automations: what it all actually does

An automation is when something happens, if a condition holds, then do something. The interesting part is the combinations.

I have 37 automations and 4 scripts. They fall into a few types.

Motion-triggered lighting is the classic case. A closet light comes on when it senses motion and goes off a few minutes later. The hallway does the same but at 10% brightness at night. The garage lights come on when a door opens or motion triggers, and off when it clears.

Time-of-day scenes handle the evenings. I used to trip these on the sun’s elevation; now a luminance sensor watches a camera feed, so the lights come on when it’s actually dark instead of at a scheduled guess.

Presence-based control follows people. The office desk light and monitor switch on when someone is in the room, and off after five minutes empty. The family room entertainment center works the same way. It keys off the family’s phones through iCloud3, not just motion.

Per-room switch and scene groups give each room its own control: dining room lights on an Inovelli dimmer, breakfast area, bedroom sidelights. I prefix automation names (Switch:, TOD:, Motion:, Presence:, Camera:, NSPanel:) so I can find them in a config this big.

Security notifications come from Frigate. When it spots a person, it grabs a snapshot and pushes it to the right family member’s phone, with a cooldown so nobody gets spammed. The alarm and deadbolts hook into a night-mode lockdown.

Scripts cover the multi-step routines: a nightly lockdown that locks both doors and arms the alarm, a Roborock schedule that vacuums different rooms on different days, and a sprinkler program.

One automation is a plain hack. It restarts the Ring integration if it comes up unavailable after a reboot, because Ring’s cloud link is flaky. Not everything here is elegant.


The design lessons

Automation is about trigger logic, not devices. The catalog is big, but what makes this a home instead of a collection is the automations. Start from what should happen and work back to the hardware.

Some things should fail in ways you chose on purpose. A few of my light circuits depend on Home Assistant being up, because they switch at the bulb. If HA is down, those lights stay as they are. I’d rather pick that tradeoff than discover it by accident.

Not every offline device is broken. The WiZ bulbs behind Kasa switches taught me that. Check the wiring and the designed failure modes before you start diagnosing.

Configs this size drift. I audit all 37 automations against reality now and then, because entities get renamed and old automations quietly point at things that no longer exist.


Why this layout, in one line

None of this was designed up front, any more than the hardware was. It grew one room and one problem at a time: a bulb here, a sensor there, an automation the day I got tired of flipping a switch. The result is layered, occasionally messy, and mine.

That’s the appeal of self-hosted automation. You own it, you understand it, and you keep improving it whenever you notice something it should be doing for you.

Comments

Loading comments…

© 2026 Kunaal Mahanti · Built with Astro