Your Smart Home Is a Pile of Web Servers in a Trench Coat
What a smart bulb, a smart plug and a smart thermostat actually are once you open one up
Contents
Open the case on a smart bulb and you will find, alongside the LED array, a small system-on-chip running a real operating system, a network stack, and — more often than not — a tiny embedded web server. The bulb you screwed into a lamp socket is a computer with an IP address. So is the plug, the thermostat, the doorbell, and the robot vacuum mapping your floor plan. The industry sells these as appliances. Underneath, every single one is a general-purpose computer wearing a costume, and understanding that costume is the difference between a smart home that works when your internet does not, and one that becomes an expensive brick the moment a vendor’s cloud service has a bad day.
This isn’t a knock on the category — the convenience is real and I run plenty of this gear myself. It’s an argument for knowing what you actually bought, because that knowledge changes which products you choose and how you set them up.
What’s actually inside
Crack open almost any modern smart device and the bill of materials looks the same regardless of brand: a low-power SoC (frequently something in the ESP32 or Realtek family for cheap gear, more capable ARM chips for anything running a camera or display), a few megabytes of flash storage, a radio (Wi-Fi, Zigbee, Bluetooth, sometimes Thread), and firmware built on an embedded Linux or RTOS. That firmware runs a network stack because the device needs to receive commands and report state, and the easiest, most well-understood way to do that over IP is HTTP — so it runs a web server, usually a minimal one like lighttpd, mongoose, or a bespoke embedded HTTP implementation, listening on a port either on your local network or reachable only through the vendor’s cloud relay.
This is not a metaphor. If you put a smart plug on your network and scan it, you will frequently find an open port serving a JSON API or even a small web UI, the same shape of thing you would find looking at any self-hosted service in your homelab. The bulb doesn’t know it’s a bulb. It knows it’s a small computer that turns a GPIO pin on when it receives a particular request.
| |
That is a fairly typical result for a budget smart plug: an HTTP port for local control, an MQTT broker (or client) for message-based state updates, and a proprietary port the vendor uses for cloud communication. None of this is unusual for the category — it is unusual only in how rarely the box it came in mentions any of it.
Why “the cloud” is in the loop at all
If the device is a tiny web server sitting on your own network, why does turning on a lamp from an app usually involve a round trip to a server on another continent? Mostly for reasons that have nothing to do with your convenience. Cloud relay solves NAT traversal cheaply — your phone on mobile data cannot reach a device behind your home router without something brokering the connection, and running that broker centrally is far simpler for a vendor than shipping every customer a working remote-access solution. It also gives the vendor telemetry, a natural point to push firmware updates, and — less charitably — a lock-in mechanism, since a cloud-dependent device stops working the day the company shuts the service down, discontinues the product line, or pivots the business.
This is why devices marketed as “smart” sometimes have a worse user experience than a dumb equivalent: a light switch that used to be instant now waits on a request to a data centre, over your internet connection, bounced back down to a device sitting two metres away from the switch that just sent the command. The latency isn’t a bug in your network. It’s the direct cost of routing a local action through a remote server because the local-only path was never built.
The case for local control
The alternative is devices, or firmware, that skip the cloud relay for anything that can be handled on your own network. This is the entire premise behind MQTT as the protocol underneath most smart-home traffic: a lightweight publish-subscribe message bus that lets a bulb announce “I am now on” and a hub subscribe to that announcement, all without either one needing internet access. Home Assistant, openHAB, and similar hubs exist largely to give these small, chatty web servers one place to talk to each other, on your terms, using your own broker rather than a vendor’s.
Some devices ship with genuinely open local APIs from the factory — Shelly relays are the most commonly cited example, offering a documented local HTTP API alongside their cloud option, no reflashing required. Others need alternative firmware (Tasmota, ESPHome, or reflashed Zigbee firmware) before they will talk locally at all, because the original firmware deliberately routes everything through the vendor’s servers even though the hardware is perfectly capable of local HTTP. Buying decisions in this category are really firmware decisions in a plastic shell — two devices with near-identical hardware can have completely different privacy and reliability characteristics based on what’s flashed onto that shared SoC.
The protocols underneath the costume
Once you accept that each device is a small networked computer, the alphabet soup of smart-home standards stops being marketing noise and starts being a list of network stacks with real trade-offs. Wi-Fi devices are the simplest conceptually — they’re full IP citizens on your LAN, reachable with normal tools like curl or nmap — but they’re also the most power-hungry, which is why battery sensors rarely use it. Zigbee and Z-Wave are low-power mesh radio protocols built specifically for battery-operated devices; they don’t speak IP at all, so they need a coordinator/hub device (often USB-attached to something running Home Assistant) to bridge them onto your network. Thread is the newer entrant — an IPv6-based low-power mesh designed to combine Zigbee’s battery life with Wi-Fi’s native IP addressing, and it’s the transport underneath the Matter standard.
Matter itself is not a radio protocol; it’s an application-layer standard that rides on top of Wi-Fi, Thread, or Ethernet, meant to let a device from one vendor be controlled by a hub from another without a proprietary bridge. It’s a genuine improvement over the fragmented state of the previous decade, though it inherits the same principle this whole piece is built on: a Matter device is still a small computer running a network stack, just one speaking a more standardised dialect.
Reading the traffic yourself
You don’t need special tools to confirm any of this — a device that claims to be simple will show you exactly how un-simple it is the moment you look. Point a packet capture at a smart plug for five minutes after power-on and you’ll usually see it: a DNS lookup for a vendor domain, a TLS handshake to a cloud endpoint, then periodic keepalive traffic even when nothing in the room has changed state.
| |
That thirty-second cadence of small, identically-sized packets after the initial handshake is a keepalive heartbeat, telling the vendor’s servers “I’m still here” regardless of whether you’ve touched the device. Multiply that by every gadget in the house and you have a constant low-level hum of outbound connections that most people never look at, let alone decide whether they’re comfortable with. Running this capture once, on any new device before it joins your main network, is a cheap way to see exactly what it phones home to and how often — and it takes less time than reading the privacy policy that almost certainly doesn’t disclose it in this much detail anyway.
What this means for your network
Because every one of these devices is a small computer, it deserves the same network hygiene you would apply to any other host — arguably more, since IoT firmware update cadence is usually worse than a normal Linux box’s. Put smart-home devices on their own VLAN or at minimum an isolated Wi-Fi network, separate from the one your laptop and phone use for anything sensitive. This limits the blast radius if one of these devices turns out to have a vulnerable embedded web server (a recurring category of CVE across cheap IoT hardware), and stops a compromised bulb from being a stepping stone to the rest of your network.
| |
This is the same argument made in more depth for VLANs generally: segmentation costs a bit of setup time once and pays for itself every time a device turns out to be less trustworthy than its marketing implied.
Choosing gear with your eyes open
None of this is an argument to avoid smart-home gear; it’s an argument to shop like you’re buying a small server rather than an appliance, because that’s what’s actually arriving in the box. A few questions are worth asking before you buy, not after: does the vendor document a local API, or is local control something the community reverse-engineered out of necessity? Does the device keep working — lights still switch, sensors still report to a local hub — if your internet connection drops for an afternoon? Is there a published or community-maintained alternative firmware for this specific model, in case the vendor’s cloud service is discontinued in three years, which happens to this category of hardware more often than any of us would like?
None of these questions show up on the product page, which is precisely why they’re worth asking yourself rather than trusting the packaging. The gap between “smart” as marketed and “smart” as built is almost always in the answers to exactly these three questions, and it’s the gap that determines whether a five-year-old device still does its job or becomes e-waste the day a startup runs out of runway.
Troubleshooting: when the device goes dark
App says offline, device LED is on and steady: almost always a cloud-relay problem, not a device problem — the device itself is fine on your LAN but cannot reach the vendor’s servers, or the vendor’s servers are having an outage. Check whether local control (Shelly’s local API, an ESPHome integration, or the device’s own local web UI) still works; if it does, the issue lives entirely outside your house.
Device drops off Wi-Fi randomly: frequently a power-saving or channel-width mismatch between a 2.4GHz-only IoT radio and an access point that’s aggressively switching channel width for its 5GHz clients. Pin the IoT SSID to a fixed 20MHz channel width if your AP supports per-SSID radio settings; most of these chipsets are considerably less tolerant of channel changes than a modern laptop’s radio.
MQTT messages arrive late or not at all: check the broker’s connection count and retained-message settings before assuming the device is faulty — a broker under memory pressure, or a topic that never had its “retain” flag set, produces exactly this symptom and is a broker misconfiguration, not a device fault.
Firmware update bricked the device: the risk that comes with alternative firmware. Keep a serial or UART recovery method documented for anything you reflash, and never update multiple devices of the same batch simultaneously in case a firmware build has a batch-specific bug.
Worth knowing, even if you don’t act on it
You don’t have to reflash every bulb in the house to get value from this. Knowing that the “smart” part of your smart home is a small, occasionally insecure, network-attached computer changes what you check before buying (does it have a documented local API?), where you put it on the network (its own segment, not next to your NAS), and what you expect when the internet goes down (nothing, if you’ve built any local fallback at all). The trench coat is doing exactly what a trench coat does — making several small things look like one simple thing — and pulling it back is usually worth the five minutes it takes.
Related Content
