Before you start buying devices or setting up servers, we need to make the most critical engineering decision for your entire home automation deployment: where the system’s intelligence will reside.
At a network topology level, a “smart” device (whether a plug, a light bulb, or a sensor) is nothing more than an execution node. The logic that decides when and how that node should act requires processing. Depending on where this data processing takes place, we divide home automation into two diametrically opposed architectures: Cloud-based architecture and Local control architecture.
Understanding how information flows in both models is fundamental to designing a fast, private, and fault-tolerant system. This isn’t a philosophical discussion; it’s a technical decision that conditions everything that follows.
Cloud-based Home Automation
Cloud architecture is the predominant model in most commercial consumer hardware. In this model, the physical device is “dumb”. Its sole function is to connect to our home router to establish a persistent tunnel or connection (generally via MQTT or WebSockets) with the manufacturer’s servers on the Internet (WAN).
The brain of the house, the database, and the rule engine are not in our home; they are hosted in an external data center (on AWS, Azure, or proprietary servers).
Communication flow in the cloud
To understand the technical inefficiency of this model for basic operations, let’s analyze what happens when we press the “Turn On” button on our phone’s mobile app while sitting in the living room:
- The phone sends an HTTP request through the router to the manufacturer’s servers.
- The server processes the command, looks up our device’s identifier in its database, and generates the command.
- The server sends the command back to our house, crossing our Internet Service Provider (ISP) nodes again.
- The router receives the packet and delivers it to the smart plug.
We are forcing a signal to travel thousands of kilometers to turn on a light bulb that is physically two meters away from us.
The major commercial advantage: remote access and ecosystem
At this point, it’s logical to ask: if sending data thousands of kilometers is inefficient, why does the entire industry do it? The answer is that the Cloud model solves the biggest problem of home networks: external connectivity.
By delegating the infrastructure to the manufacturer, they make their servers, developers, and databases available to us, seemingly for free. This gives us two extremely powerful features:
- Seamless remote access (Away from home): It doesn’t matter if you are connected to your living room WiFi or a 5G network abroad. Your mobile app simply talks to the manufacturer’s cloud server, and this server talks to your plug. It works instantly, without you needing to open ports on your router or know what a public IP address is.
- Third-party integration and Voice Assistants: If you want to tell Google Assistant or Alexa to “turn on the light”, the manufacturer has already programmed and maintained the API (Cloud-to-Cloud) so that Google’s servers can communicate with theirs. It’s a complex service that the manufacturer takes on for us so that it works simply “out of the box”.
Drawbacks and risks of the cloud model
In exchange for this enormous convenience, we hand over total control of our home to an external company, which creates critical problems:
- Latency: The trip to the external network inevitably introduces a delay. A command can take anywhere from hundreds of milliseconds to several seconds to execute.
- Internet connection dependency: This is the Single Point of Failure (SPOF). If our fiber optic provider has an outage, or our router loses connection, the entire house becomes unreachable.
- Privacy and Planned Obsolescence: We constantly send telemetry to third-party servers. Furthermore, if the manufacturer goes bankrupt or shuts down servers for an older model, our device will stop working permanently (known as bricking).
Local Home Automation
Faced with the vulnerability of the cloud, systems engineering offers the Local architecture. This model applies the principles of Edge Computing: bringing data processing as close as possible to where it is generated.
We cut the external dependency by introducing a Central Server or Controller (like a Mini PC running Home Assistant) into our Local Area Network (LAN).
Local communication flow
If we repeat the action of turning on a light bulb, the flow changes drastically:
- The phone communicates directly with the Home Assistant server over the internal WiFi network.
- Home Assistant processes the rule and sends the command to the device over the WiFi network itself, or via a direct radio frequency protocol (such as Zigbee or RF).
In this case, the data packet does not need to leave our local network.
Advantages of the local model
- Low latency: Commands don’t have to make the trip to the manufacturer’s servers, so the response is typically much faster.
- Fault tolerance to Internet outages: If the external connection goes down, local functions remain available. Weather services, notifications, and other external integrations may indeed stop working.
- Independence and Privacy: The hardware truly belongs to us. No external company can “turn off” our plugs, and telemetry is stored on our own hard drive.
The challenge of the local model: external access
Giving up the manufacturer’s servers comes with a high architectural cost. If the house is intentionally isolated from the Internet to protect our privacy and guarantee speed, accessing it from outside or connecting it to Google Assistant becomes a much more serious technical challenge.
To replicate that convenience securely, we will have to configure a VPN, an encrypted tunnel, or a reverse proxy with HTTPS. Solutions like Tailscale or Cloudflare Tunnel avoid directly opening the Home Assistant port to the outside world.
This is a process we will cover in detail in the “Operation” section of this course, but it’s crucial to understand from the beginning that technological independence requires maintenance and learning.
In practice, many robust systems end up being hybrids. They keep critical logic local, but use external services for specific tasks, such as an off-site backup, weather forecast, or integration with voice assistants.
What should always stay local
Not all elements in a house have the same importance. It’s no big deal if the weather forecast comes from an external API. If it fails, at worst an awning won’t lower automatically (we probably won’t cry too much about it).
What should always work locally is everything that affects security, basic comfort, and manual control: main lights, heating, alarms, water leak sensors, critical blinds, or anything that, if it gets stuck, turns the house into a small inferno.
A simple way to decide is to ask yourself this question: if the Internet goes down tomorrow for 24 hours, should this still work? If the answer is yes, that logic should not depend on the cloud.
Our architectural goal
Our stance when designing the system is clear: every critical component of the house must be able to function locally.
Throughout this course, we will use Home Assistant precisely to apply this principle. We will try to integrate commercial devices locally whenever possible and reduce their dependence on external servers whenever feasible.
Having understood the difference between letting our house be controlled from outside or controlling it from within, in the next article we will go down to the real market to see what the main manufacturers (Tuya, Sonoff, Shelly) offer us and how each one fits into these two architectures.
