Smart home devices are networked sensors, actuators, and controllers that expose the physical functions of a building to software. This page explains how such a system is structured and what determines whether it keeps working, rather than recommending specific devices.
01How the system is layered
A working installation is four layers, and most problems are a mismatch between them.
Devices are the endpoints: switches, plugs, locks, thermostats, cameras, leak and motion sensors. Each does one physical thing and reports one kind of state.
Transport is how those endpoints talk. Wi-Fi devices join the existing network directly and draw more power, which is why they tend to be mains-powered. Low-power mesh protocols such as Zigbee, Z-Wave, and Thread run their own network and require a bridge or border router, but let battery sensors last far longer. Bluetooth is common for setup and for devices only used in the same room.
Control is the hub, controller app, or cloud service that holds device state and exposes it to you. This is the layer that decides whether the system works when the internet does not.
Automation is the rule set: schedules, triggers, and conditions. It is the layer that turns a collection of remote controls into something that reduces work.
02What determines whether it keeps working
The single most consequential question about any smart home device is where the decision is made. A device that evaluates rules locally continues to function during an internet outage. A device that round-trips through a vendor cloud stops when that service does, when the account lapses, or when the vendor discontinues it. Neither is automatically wrong, but the answer should be known before installation rather than discovered during a failure.
Related durability concerns:
- Account and subscription dependency. Some capabilities present at purchase are later moved
behind a subscription. Ask which functions survive without one.
- Firmware and update policy. Networked devices with no update path become long-lived unpatched
hosts on the network.
- Ecosystem lock-in. Interoperability standards have improved this, but "works with" often
means a limited subset of a device's functions is exposed to other systems.
- Physical fallback. A smart lock, switch, or valve should still be operable by hand.
03Evaluating a device before you add it
Work through these in order. They are ordered by how expensive the mistake is to reverse.
- What physical outcome do you actually want, and does a non-networked product achieve it?
- Does it work locally, and what is lost when it cannot reach the internet?
- Which transport does it use, and do you already have the bridge or border router it needs?
- What is the power source, and what is the maintenance burden across every device you plan to add?
- Is it segregated from your primary network, and does it need to reach the internet at all?
- What happens to it if the vendor stops supporting the product?
Network segmentation deserves particular attention. Consumer devices frequently have weak authentication and long support gaps, and they are best placed on an isolated network segment or guest network with no route to systems that matter.