Listening at the Router: A Week of Traffic from a British Smart Home

A smart thermostat is usually judged by its app, its schedule and its ability to learn when the house is empty. Its network behaviour is less visible. Yet every cloud-controlled heating system is also a small, always-on telemetry device. To see what actually leaves a British home, we mirrored the WAN port of a three-bedroom semi-detached house in Reading for seven days in October 2026 and logged DNS queries, flow metadata and TLS server names. We did not decrypt payloads.

Method and what we could see

The test network had a fibre ONT, a domestic router and a managed switch with port mirroring. A local resolver handled DNS, and a small Linux box ran Zeek, ntopng and a lightweight flow collector. The mirror captured traffic between the router and the ONT, so it included every device behind the router without installing agents on each one. TLS inspection was out of scope; we recorded SNI names, destination addresses, byte counts and timing.

The device set was deliberately ordinary: a Hive Hub controlling a gas boiler, a Nest Learning Thermostat, a Honeywell Home T6R, a Philips Hue Bridge, a SmartThings Hub, a Shelly Plus 1PM relay and an Amazon Echo Show. All were in normal use. The household consented to the capture, and the data was retained only for the analysis.

The traffic map

Across the week the smart-home group transferred 1.4 GB, but the distribution was heavily skewed. One firmware download for the SmartThings Hub accounted for 1.1 GB. Excluding that update, background traffic averaged 8–14 MB per day for the whole group, with the Echo Show responsible for most of it. The heating devices were far quieter: the Hive Hub averaged 2.1 MB per day, the Nest 1.7 MB and the Honeywell 0.9 MB.

DNS logging showed recurring names for each vendor: hivehome.com, nest.com, honeywellhome.com, meethue.com, smartthings.com and shelly.cloud. The Hue Bridge resolved meethue.com mostly for time and update checks; its local control traffic stayed on the LAN. The Shelly relay used MQTT over TLS to a European endpoint and also answered local requests. The thermostats and hubs maintained persistent TLS sessions to cloud endpoints, with small POSTs at intervals of 60 seconds to 5 minutes. NTP traffic was frequent and ordinary, but it provided a useful timing baseline for the telemetry pattern.

Firmware versus telemetry

The largest single event was a firmware update. It arrived as a long TLS download from a content delivery network, followed by a reboot and a short burst of registration traffic. Smaller updates appeared for the Hue Bridge and the Shelly relay. These are the easy flows to justify: they are infrequent, sizeable and clearly tied to version changes.

Telemetry is harder to classify. The thermostat flows were small, often under 2 kB per request, but they were persistent. Their timing suggested periodic state uploads: current temperature, setpoint, schedule mode and, in some cases, occupancy-related signals. We could not see the payloads, so we cannot say exactly what was sent. What the metadata does show is that the devices remain in conversation with their vendors even when the heating is idle. The Nest was the most talkative in terms of session frequency; the Honeywell was the most restrained.

Can local-only control work?

The short answer is: sometimes, and only with careful device selection. The Hue Bridge exposes a local API, and the Shelly relay can be controlled over local MQTT or HTTP without a cloud round trip. With the WAN blocked for 30 minutes, both continued to respond to local commands. The SmartThings Hub retained some local automations but lost app control for cloud-dependent devices.

The Hive and Nest systems were more cloud-bound. Blocking WAN access did not stop the boiler receiver from maintaining its existing schedule in every case, but app control and remote adjustment failed. The Nest thermostat continued to run its local schedule, yet the familiar app view disappeared. That distinction matters: local scheduling is not the same as local control. A household that wants genuine local-only operation needs to verify both the device API and the controller that drives it.

Matter and Thread may improve this over time, but they do not automatically make a product local-first. The application layer still decides whether a command can be executed on the LAN. Buyers should look for documented local APIs, not just a Matter logo.

Privacy, standards and the reasonable middle

The traffic metadata does not prove that a thermostat is collecting personal data, but it does show that occupancy inference is technically plausible. A device that reports temperature, setpoint and mode every few minutes creates a pattern that can be correlated with presence. Under the UK GDPR and the Data Protection Act 2018, manufacturers must be transparent about such processing; from a network perspective, transparency is easier to audit when the flows are documented and the user can see them.

There are practical mitigations. Put smart-home devices on a separate VLAN, log DNS locally, block outbound access for devices that do not need it, and prefer products with local APIs. None of these is a complete solution, and some will break app features. But they turn an opaque always-on cloud dependency into a measured one. The house does phone home; the useful question is how often, to whom, and whether you can still control the heating when the answer is no.