Smart Home Platforms: The Test Is Whether It Works With the Internet Unplugged

A light switch works. It works when the internet is down, when the vendor has been acquired and shut down, when your subscription lapses, and fifteen years after it was installed.

Everything in this article exists to preserve that property as devices get connected. The moment a light switch needs a cloud service to respond, the household has taken on a dependency it did not consent to, and most people only notice it the first time it fails.

Scale, because the platform still has to exist

A platform serving five million homes, with an average of forty connected devices per home.

5,000,000 homes x 40 devices            = 200,000,000 devices

Home devices are mostly quiet. A motion sensor emits a burst when something moves and then nothing for hours. A thermostat emits on change or on a timer. A door sensor emits on change. The rate is driven by state changes, not by polling, so it is far lower than a fleet of industrial sensors and far harder to capacity plan, because it is driven by human behaviour.

average:  ~1 message per device per 5 minutes = ~670,000 msg/sec
evening peak, say 5x                          = ~3.3 million msg/sec

The evening peak is the number to design for, and it is not a technology constraint. It is a consequence of people getting home.

The hub is the architecture

A hub is a small box in the home that speaks the local radio protocols, holds the device database, runs the automations, and answers locally. The cloud is somewhere else.

  [ devices: Zigbee, Thread, Z-Wave, Wi-Fi, BLE ]
                    |
             +------v-------+
             |     HUB      |   <- source of truth
             |  automations |   <- runs here, always
             |  local API   |
             +------+-------+
                    |  optional, when the WAN works
             +------v-------+
             |   CLOUD     |   <- sync, remote access, updates
             |             |      integrations, analytics
             +--------------+

The split is the whole design, and every argument for or against a smart home platform is really an argument about where this line goes.

Putting the line in the wrong place causes three problems at once.

Latency. Someone presses a doorbell button and hears the chime. That is a round trip through a radio to a hub and back. If the chime decision is a cloud call, the doorbell is unusable at 200 ms and broken at 1.5 seconds.

Availability. Cloud providers have bad days. Regions fail, deployments break, and a house that cannot open its own blinds because a load balancer is in a degraded state is a genuine quality-of-life regression against a light switch.

Privacy. A home’s occupancy, when people arrive and leave, what is switched on at 2am, and where the cameras are pointed is among the most intimate household data there is. Every hop that leaves the home is data that has left the user’s control.

The rule that follows, and it is worth stating as a test rather than a principle:

pull the WAN cable
  - do lights, locks, heating, and automations still work?
  - is the response time still imperceptible?
  - is there any feature that is silently degraded rather than clearly unavailable?

A platform that passes this test can be sold honestly. A platform that fails it is selling convenience and hoping nobody tests it.

The radio landscape, briefly and honestly

Wi-Fi is universal and terrible for this. It is power-hungry, congested, and it requires a stable IP address on a network that is already unreliable.

Zigbee and Z-Wave are low-power mesh networks in the low gigahertz bands. They are mature, cheap, and interoperable to a degree. Both need a coordinator, both are mesh, and both reward attention to placement.

Thread is a newer IPv6-based low-power mesh that runs at about 250 kbit/s. Its significant advantage over its predecessors is that it is IP-native, so a device on Thread is addressable in principle rather than being a serial number behind a gateway abstraction.

Bluetooth Low Energy is used for setup, commissioning, and close-range control rather than whole-home coverage.

Matter is the layer above, and it is the reason the previous paragraph matters less than it did. Matter runs over Thread, Wi-Fi, and Ethernet, and it provides a shared application layer: a data model of devices, clusters, endpoints, attributes, commands, and events. Two ecosystems can both control a device because both speak Matter.

The operational points that matter more than the marketing:

• Mesh networks are topology-sensitive. A room with no router reachable is a room with no Thread coverage. Adding a Thread border router improves external access and routing, and placement is not a detail.
• Thread and Matter credentials are not Wi-Fi credentials. Matter fabrics have their own operational credentials and operational discovery, and commissioning involves a trust-on-first-use step that deserves a real security design.
• Commissioning is the weakest link. The moment a user holds a QR code and a password to enrol a device into a home network is the moment a compromised brand’s supply chain becomes someone’s front door. Matter improves this, and it is still the moment.

State, and why a shadow is the right shape

The device management article established the pattern for a fleet: store desired state, compare hashes, converge.

Smart homes use the same idea and it works well here, because a light switch’s desired state is genuinely simple.

device:  kitchen-light-3
desired: { on: true, brightness: 60, colourTemp: 2700 }
reported:{ on: true, brightness: 60, colourTemp: 2700, reachable: true, firmware: "2.4.1" }

A scene sets many devices at once, which means the interesting question is not the individual state but whether the scene as a whole was achieved. A movie scene is not correct because five of the eight devices changed; it is correct when the eighth one also changed, and something needs to know the difference.

scene: movie-night
  set 8 devices to their desired state
  -> poll the hub for up to N seconds
  -> report per-device: applied | failed | unreachable
  -> report the scene as: complete | partial | failed

Partial is a real and common outcome, and a scene UI that reports eight green ticks because the hub optimistically believed its own commands is worse than one that says five succeeded and a light is unreachable.

The hub is authoritative for desired state and the device is authoritative for actual state, and the difference between them is the diagnostic surface. When a user says “the automation did not work”, the first question is which of the two is wrong.

Automations belong on the hub

This is the part where platforms most often get it wrong, and the reason is that cloud automations are easier to build and easier to update.

A cloud automation is:

device event -> publish to cloud -> cloud evaluates rule -> cloud sends command -> hub executes

The same automation on the hub is:

device event -> hub evaluates rule -> hub sends command -> device executes

The second one is faster, works offline, and does not send every light switch event in the house to a data centre. The first is easier to update centrally.

A cloud automation has a further problem that is not a performance issue. Consider “when the last person leaves, turn off all lights”. The occupancy sensor has to tell somebody it detected the departure, the somebody evaluates who the last person is using presence data from four other devices, and the decision arrives at the house over the internet. Every one of those is a failure point in a rule whose entire purpose is to save money and work reliably for years.

So the rule is: automations run on the hub, the cloud distributes and synchronises them. The cloud pushes automation definitions down, the hub executes them, and the hub reports what happened. A cloud-side edit is a definition update, not an execution path.

There is a real argument for the other side, and it should not be waved away. Some rules genuinely need data that only exists in the cloud: a utility tariff, a weather forecast, a person’s calendar, a machine-learning inference. The resolution is a two-tier automation model.

local   -> anything decidable from home data
remote  -> anything needing external data
          and it must have a defined local fallback

A remote automation with no fallback is an outage waiting for a bad day, and the honest requirement is that every remote rule declares what the house does when the cloud is unreachable.

The video question

Video is the workload that decides a smart home platform’s infrastructure cost, and it is a straightforward storage problem before it is anything else.

Assume one million homes with two cameras, 1080p, H.265 at roughly 2 Mbps.

continuous recording:
  2 Mbps x 86,400 sec = 21.6 GB per camera per day
  1M homes x 2 cameras = 43.2 PB per day

event clips, 30 events/day, 8 seconds each:
  240 sec of video per camera per day
  1M x 2 x 240 sec x 0.25 MB = 120 TB per day
                                              360x less

Three hundred and sixty times less, and most of the continuous stream is a driveway nobody drove down. That is not an argument for cheap storage, it is an argument that continuous cloud recording is a product nobody asked for, and the money is better spent on a local buffer.

The design that works:

local NVR / hub storage
  continuous ring buffer, 3 to 7 days, overwritten
  motion or object detection selects clips
  clips retained locally for 30 days
  user opens the app -> stream from the hub over the local network
  user shares or exports a clip -> upload to the cloud, on demand

The streaming case is the one that most needs local serving. Watching your own front door camera should not route through a data centre 200 kilometres away, and the difference in latency between a local stream and a cloud one is the difference between a live view and a security recording with extra steps.

There is one real operational reason cloud streaming exists, and it should be stated honestly: when the user’s internet is down, a local camera is unreachable. Remote access for the specific case of “the user’s connection is broken” is genuinely valuable, and it is the only case that justifies keeping egress.

Presence, and what a house reveals

Presence detection is the feature people use most and think about least, because the naive implementation is a map of when each person is home.

A motion sensor network can determine, with considerable accuracy, which rooms are occupied. Combined with a door sensor, that gives arrival and departure times. Combined with the smart meter and the thermostat, it gives a much more detailed picture: how many people, when they eat, when they sleep, whether anyone is ill.

Nobody signs a terms-of-service agreement for that. It arrives as a feature.

The controls that matter are therefore about the derived data, not the sensors:

• Store transitions, not a continuous trail. The house cares that the last person left at 07:42, not about every intermediate motion event.
• Keep occupancy state on the hub. “Is anyone home” is a boolean and it belongs in the house.
• Retention for historical presence is short. A month of arrival times is enough for most automations and is a genuine behavioural profile.
• Every occupant, not just the account holder. A household with two adults, a teenager, and a guest produces presence data about people who never consented to anything.
• Audio and video are different. A camera is an obvious sensor and people make a decision about it. A passive occupancy signal is invisible and produces the same information.

The honest summary is that a smart home already knows more about its occupants than any individual in it would be comfortable with if it were described to them, and a platform that is not uncomfortable about that has not thought about it.

Voice assistants

A voice assistant is a small technical problem with a large product surface.

The technically interesting part is that almost all of it should be local:

wake word detection        on-device, always listening, low power
command parsing and intent on-device, for the common commands
cloud                      for the long tail, general knowledge, and music

Wake word detection is a small model running continuously on a constrained SoC, and it is the part that must never be a network call, both for latency and for a reason that is obvious once stated: a device that is always listening cannot be asking a cloud server for permission to listen on every frame.

The privacy line that actually matters is whether raw audio leaves the house. Two acceptable designs:

• Fully local recognition. Nothing leaves. Simple to explain, and recognition quality is bounded by the model on the device.
• Local wake detection, cloud intent. A short clipped utterance is uploaded when a wake word fires. Far better recognition, and the user’s decision has to be informed and revocable.

The unacceptable design is continuous audio streaming with a wake word somewhere in the middle, which is what several products shipped, and which should be treated as a bug rather than a trade-off.

Firmware, and the one thing hubs make easy

A hub is an enormous operational advantage. It is a single device that can reach every other device in the home, and updating the whole house is one operation.

push firmware to hub
  -> hub stages, verifies signature
  -> hub pushes to devices that report the capability
  -> device reboots and reports
  -> hub retries the ones that did not

Compare that to the vehicle case, where a campaign is a logistics operation because the client moves. The hub is stationary, mains-powered, and connected. Updating a whole home is a batch job, and a rollback is the same operation with the previous version.

The one hard problem is the device that is not reachable right now, which is usually a sensor in a closet that has lost its mesh route after a hub replacement. It will pick up the update when it reappears, and the platform’s job is to keep a visible list of what is pending rather than declaring the update complete.

Failure stories worth testing

Unplug the WAN and pull the cloud’s DNS

Everything in the house should work identically. Time anything: light response, lock actuation, and a scene. Then try a cloud-only integration and confirm it fails clearly rather than half-working.

Kill the hub

The house loses automations, scenes, and remote access, and the raw device control in each vendor’s own app should still work if the devices support it. Then reboot the hub and confirm state converges without a manual resync.

Set a scene with one device switched off at the wall

The scene should report partial, not complete. This is the test for whether the platform is lying about optimism.

Change an automation in the cloud while the hub is offline

It should sync on reconnect and only then. Confirm the hub does not run a stale rule it believes was updated.

Trigger a fire alarm automation with the cloud unreachable

The local rule must fire. Smoke, leak, and occupancy automations are the ones where a cloud dependency is unacceptable, and they should be designated as safety-relevant in the same way an industrial design designates a safety function.

Fill the camera’s local storage

The ring buffer should overwrite oldest, clip retention should be independent, and the app should say which is which.

Revoke cloud access from the hub

Local control should be unaffected, and the hub should report a degraded-but-working state rather than an error.

Have a second ecosystem control a shared device

Multi-admin should work, and revoking one admin should not break the other.

Deprecate a device integration the vendor abandoned

This is the fifteen year problem in miniature. A hub bought in 2026 must be able to run a device bought in 2031 whose vendor no longer exists, and that requires either local protocol support the hub controls, or an honest answer about when the hub itself will need replacing.

A production-ready architecture

  [ home devices ]
        |  Zigbee / Thread / Z-Wave / Wi-Fi / BLE
        v
  +----------------------------------------------------+
  | HUB                                                 |
  |  device database (source of truth)                  |
  |  local automation engine                            |
  |  state machine + diffing                            |
  |  local video buffer, ring + clips                   |
  |  local presence state                               |
  |  local API (LAN)                                    |
  +----------------+-----------------------------------+
                   |  optional, authenticated, encrypted
        +----------v----------+
        | CLOUD               |
        |  sync + backup      |
        |  remote access      |
        |  firmware delivery  |
        |  integrations       |
        |  analytics          |
        +---------------------+

Two explicit states for every feature:

local   -> works with the WAN down
remote  -> works with the WAN up
              and degrades to a defined local behaviour when it is not

A sensible delivery checklist:

1. Write down, per feature, whether it works with the WAN disconnected. Then test it that way.
2. Put the device state and the automations on the hub, and treat the cloud as distribution and sync only.
3. Give every remote automation a defined local fallback, and require it explicitly.
4. Report scenes as complete, partial, or failed, based on what the devices actually reported.
5. Use desired and reported state with a diffing reconciler, not a fire-and-forget command path.
6. Keep presence state on the hub, store transitions rather than trails, and keep the history short.
7. Serve video from a local ring buffer with event clips, and stream over the LAN.
8. Run wake word detection on the device, and make raw audio streaming a decision the user can see and revoke.
9. Design mesh placement and border routing as a real deployment discipline, because commissioning is the weak link.
10. Use the hub as the fleet update vector, and keep a visible pending-update list rather than declaring victory early.

Common mistakes

Mistake	What actually happens	Better decision
Cloud-only control	The house stops working when a cloud region is unhealthy	Hub is the source of truth, cloud is sync
Cloud automations with no fallback	A rule that should save energy fails during an outage	Local automation engine, declared fallbacks
Optimistic scene reporting	The app says eight devices changed and six did	Poll and report applied, failed, unreachable
Continuous cloud video recording	360x the storage for footage nobody watches	Local ring buffer, event clips, on-demand upload
Cloud video streaming	Live view has the latency of a security recording	Serve from the hub over the LAN
Continuous audio streaming	Always-listening without a local gate	Local wake word, cloud intent only on wake
Raw history for presence	A behavioural profile of every occupant is retained	Store transitions, keep state local, short retention
Fire and forget commands	A dropped command leaves the house in the wrong state	Desired and reported state with reconciliation
Ignoring mesh topology	Half the house has no route after a hub move	Plan router placement, monitor per-device reachability
No visible pending-update list	A rollout is declared complete with devices still on old firmware	Track per-device reported version
A single account per house	A partner, a tenant, or a housemate cannot be given scoped access	Multi-user, per-user authorisation
Time and geography from the cloud as hard dependencies	Automations that should be local break at 3am	Resolve local time and presence on the hub
No consideration for the vendor disappearing	The platform rots in five years	Local protocol support, honest hub support horizon
Treating safety automations like any other	Smoke and leak rules inherit a network dependency	Designate them local-only, like a safety function

The complete story in one minute

A hub sits in the home and speaks Zigbee, Thread, Z-Wave, and Wi-Fi. It holds the device database, it is the source of truth for desired state, and it runs the automations. The cloud synchronises, delivers updates, provides remote access, and holds integrations. It is not in the control path for anything that has to work when the internet does not.

Devices report state to the hub. The hub computes a diff against desired state, applies what is needed, and reconciles what the devices report back. Scenes set many devices at once and are reported as complete, partial, or failed based on what actually happened, so a scene with one unreachable light says so.

Automations run on the hub because a rule that decides whether to turn off the lights should not need a round trip. Rules that genuinely need cloud data, such as a tariff or a forecast, run remotely but must declare what the house does when the cloud is unreachable, and safety-related rules such as smoke and leak detection are local-only by design.

Video lives in a local ring buffer with event clips, is retained locally, and streams over the LAN. Continuous cloud recording is three hundred and sixty times the storage for footage that is almost never watched. Wake word detection is on the device, and audio only leaves the house when a wake word fires.

Presence is stored as transitions on the hub rather than a continuous trail, because a house already knows more about its occupants than any of them would be comfortable with if it were described to them.

That is the whole path:

devices <-> hub (state + automations + video) <-> cloud (sync + remote + updates)
                |
                +-> works with the WAN disconnected

The hard parts were never the radio protocols. They were drawing the line between the hub and the cloud in the right place, and then testing that decision by pulling the cable out.

What this team still owns

Local-first does not mean cloud-never. Classify every automation by what data it needs, its maximum tolerable latency, and its offline fallback. Locks, leak valves, smoke-related actions, and basic lighting need an explicit local path and a safe behaviour after hub restart; weather, tariff, and calendar rules can declare cloud dependence. Matter interoperability does not remove device attestation, fabric lifecycle, least-privilege access, signed update metadata, rollback protection, or a support policy for abandoned devices.

Technical references

• Connectivity Standards Alliance: Matter specification
• Thread Group: Thread technical overview
• The Update Framework specification