What smart home automation actually is

Smart home automation is one system that runs the things a house already does — the lights, the climate, the locks and cameras, the music and the screens — so they respond to a time, a button or a condition instead of to four separate apps. That is the definition. The rest of this page answers the question underneath it: which of the three architectures that definition can be built on is the one being quoted to you.

It is a control problem before it is a product problem, and the architecture is where the control lives.

The three layers

Every automated house has the same three layers under it, whatever it cost and whoever built it. Separate them in your head before anyone quotes you anything.

The devices. Dimmers and keypads where the switches used to be. A thermostat. Locks, cameras, shades, speakers, screens. These are the parts you see and touch, and the parts that get replaced soonest. A device is a consumable.

The network they ride on. Every one of those devices is talking — over wired ethernet, over Wi-Fi, or over a low-power radio. The traffic is tiny. It also has to arrive every time, in the same fraction of a second, for years. When an automated house feels slow or unpredictable, the network is usually the reason and the devices usually get the blame.

The one system that runs them. Somewhere there is logic holding what a button means, what happens at sunset, what the word “away” does to eleven devices at once. This is the layer that turns a shelf of products into a house that behaves. It is also the layer people skip.

The third layer is where the three architectures differ. In one of them it sits on a manufacturer’s server. In another it sits in a small hub in a closet. In the third it sits on a processor wired to the house. Everything you will later like or resent about the system follows from which.

Architecture one: point products, each on its own cloud

A connected thermostat, a video doorbell, a few app-controlled bulbs, a speaker that answers questions. Each product is complete on its own and each one keeps its logic on the manufacturer’s server. They coordinate, when they coordinate at all, through a voice assistant or a phone.

This is the cheapest way in and the easiest to start. It also has no third layer of its own. The house is integrated by the person living in it, which works until there are four apps, two accounts nobody remembers, and a rule that stops firing because a vendor changed something on a Tuesday.

Architecture two: a hub and a radio

One hub in a closet, talking to devices over a low-power radio built for the job. Lutron RadioRA 3 and Caseta are the versions of this we build on. The logic is real, it lives in the hub, and it runs in the house rather than in a data center.

This is the architecture that fits a finished house. No wire has to be pulled to a switch leg that does not exist, plaster stays where it is, and the dimmers go in where the old ones came out. What you accept in return is a radio budget: a finite number of devices, distances that have to be respected, and a hub whose reach is decided by where it sits.

Architecture three: a processor on a wired backbone

A controller in a rack, an engineered network under it, and cable to every keypad, display, camera and access point that can be reached. Control4, Crestron and Lutron HomeWorks are built this way. The logic is written by a person, stored on the processor, and runs whether or not the internet is up.

This is the architecture that scales past lighting into audio, video, cameras and climate as one system, and the one that survives a device going out of production, because the wire and the processor outlive whatever is hanging off them. It also asks for decisions early, while walls are open or while a remodel is still on paper.

The houses we work in end up mixed. A processor and wire where the house allows it, radio devices where it does not, and a small number of point products left alone because nothing is gained by dragging them in. What matters is that the mixing is deliberate and that one layer is still in charge.

How to tell which one you are being sold

Ask where the logic lives, in those words. An answer that names a processor or a hub in your house is architecture two or three. An answer about an app, an account or a subscription is architecture one wearing a proposal.

Then ask the follow-up: what still works with the internet off. Architecture three keeps keypads, scenes, schedules, lighting and climate running and loses only what has to leave the house. Architecture one mostly stops. That single question sorts a bid faster than any feature list on it.

The decision that comes first

Pick the architecture, then the platform, then the devices. In that order. The platform decides which keypads can go on a wall, which locks and thermostats will report back, how a scene gets written, and what happens in year ten when a part you own is discontinued.

Devices chosen first will box in the platform. A platform chosen first will take almost any device. Everything else can be staged over years — how many rooms, how much lighting, whether the audio goes in the ceiling or on a shelf, whether the cameras come this year or next. The architecture cannot be staged, which is why we ask about it on the first walk through a house.

What it costs follows from the same decision: how many systems join, how big the house is, what tier of equipment goes in, and whether the walls are open. Any integrator worth hiring gives you a fixed price after walking the house rather than a range by email. Whether the work changes what the house is worth is a separate question, and a later one.

Plenty of the device layer can be self-installed. The layer that ties it together — the programming, the network under it, the part that still has to work in year ten — is where a professional home automation install earns its place.

Start with the architecture. The devices can wait.

— Daniel Alon, founder, IntegrateIT. Overland Park, KS. December 2025.