A Smart Home Gateway Is Not a Router, and That Difference Decides What Survives an Outage

People buy a smart home gateway expecting a wireless router with a different label, then spend a week confused about why it does not behave like one. A router moves packets between networks that already agree on what a packet is. A gateway translates between networks that do not: ZigBee, 433 MHz, BLE and Wi-Fi share no frame format, addressing scheme or security model. The gateway holds an identity in each world and converts between them. Seen as a translator rather than a pipe, most confusing behaviour stops being confusing.

It is a bridge, and a bridge is a single point of failure

A router can usually be bypassed: two Wi-Fi devices still reach each other through the access point, and if the router loses its internet connection the local network keeps working. A gateway has no equivalent bypass. ZigBee devices cannot talk to Wi-Fi devices except through it, so when the gateway is down, every cross-protocol automation is down with it.

Worth planning for. A gateway is one box on one socket, and a whole house of devices depends on it. It belongs on the same uninterruptible supply as the network equipment, not on a switched socket someone will eventually turn off.

What survives when the internet drops

This is the question that matters, and the answer depends on where the logic lives, not on the gateway:

• Device-side logic survives. A schedule stored on a switch, a direct ZigBee binding between a button and a lamp, a thermostat's own algorithm — these run on the device with no cloud involvement.
• Hub-side local logic survives. Most modern hubs execute automations locally and use the cloud only for remote access, voice integration and firmware. A rule written in the hub's own engine keeps firing when the broadband drops.
• Cloud-side logic does not survive. Routines inside a voice assistant, cross-account integrations, and anything needing a round trip to a vendor's server stop the moment the uplink does.

The honest test: unplug the broadband, leave Wi-Fi up, and walk the house pressing buttons. What still works is your local system. What stopped is your cloud dependency.

Why "it works in the app" proves almost nothing

The single most misleading diagnostic in this category is that the app shows the device as online. The app talks to the cloud; the cloud talks to the gateway; the gateway talks to the device. A green icon confirms the first hop and the last hop are both alive at that moment — it says nothing about the middle, and nothing about latency.

The failure mode this hides: a device that reports perfectly to the cloud but responds to commands several seconds late, or not at all, because the gateway is busy, the ZigBee channel is congested, or the route has degraded. The status is derived from periodic reporting, not from a live probe.

The gateway is also a radio placement problem

A gateway sits wherever the ethernet cable reaches, which is almost always wherever the router is. That is frequently the worst corner of the house for the low-power radios it carries:

• ZigBee shares 2.4 GHz with Wi-Fi. A gateway sitting on top of an access point puts its receiver next to a transmitter running at twenty times the power.
• Metal network cabinets, the steel case of a cheap switch, and foil-backed insulation behind plasterboard all attenuate it.
• USB 3.0 peripherals and some HDMI cables radiate 2.4 GHz noise. A gateway in a USB 3 port on the router is a known own goal.

A one to two metre extension — short ethernet cable, off the cabinet, away from the access point — fixes more ZigBee problems than any amount of re-pairing.

What a gateway is genuinely for

Stripped of marketing, a gateway does five things, and it is worth checking which you actually need:

1. Protocol translation between the low-power mesh and IP. Not optional if you have ZigBee devices.
2. Local automation execution, which is what lets scenes run without the internet.
3. Device onboarding and key management, which is why a device joined to one gateway cannot be handed to another without re-pairing.
4. Remote access, a cloud feature even when the box is local.
5. A single inventory — one place that knows what is installed, on which protocol, in which room.

Point three has a consequence people discover during upgrades: the gateway is the trust anchor. Move to a different gateway and you re-pair everything. That is how the security model works, but it is a real switching cost.

Choosing one, in order

• Start from the devices, not the hub. A ZigBee-only gateway is useless if half your kit is 433 MHz.
• Ask where automations execute. Local execution is the difference between a system that degrades and one that stops.
• Check whether it needs the internet to set up. Some require a cloud account before they function at all, which tells you where the logic is designed to live.
• Decide the failure budget. If the gateway is unavailable for a day, what stops? If the answer is "everything," the system is built around one box.

A gateway is not the brain of a smart home in the way marketing suggests. It is the translator, the local executor, and the point of failure — three jobs worth keeping straight when deciding what to plug in where.

Gateway and hub options are covered in the smart home gateway range, with integrated panel options at the Tuya smart home control panel page. Device-side choices are in the smart switch category, and system-level integration is described under the smart home automation programme.