Zigbee vs Wifi: Which Smart Home Device Belongs on Which Radio

Two radios sharing one band, built for two different jobs

Both technologies in their most common form operate in the same slice of spectrum. The relevant harmonised standard is ETSI EN 300 328, whose published title is Wideband transmission systems; Data transmission equipment operating in the 2,4 GHz band, and whose version 2.2.2 covers access to radio spectrum for exactly this class of equipment. That shared band is why the two interact at all, and why a house with heavy Wi-Fi traffic can make a Zigbee network behave worse than it did on the day it was commissioned.

What differs is everything above the band. Zigbee is a low-rate mesh built on the IEEE 802.15.4 radio layer, designed around devices that send very small messages, very occasionally, from a battery. Wi-Fi, certified by the Wi-Fi Alliance, is built for throughput and connects each device to an access point. Thread, promoted by the Thread Group, uses the same 802.15.4 radio layer as Zigbee but carries internet protocol natively, which is why it increasingly appears alongside both in the same product listings.

What the mesh and star distinction changes inside a real house

A Zigbee network grows its own coverage. Every mains-powered device on it, a plug, a bulb, an in-wall relay, can act as a router for its neighbours, which means adding permanent devices in the middle of the house tends to improve reliability at the edges. A battery sensor at the far end of a building does not need to reach the hub directly; it needs to reach something that can pass the message on. That property is the main reason the technology survives in buildings with thick internal walls.

Wi-Fi does the opposite. Every device needs an adequate link to an access point, so coverage is a property of where you put the access points rather than of how many devices you own. Adding a dozen Wi-Fi smart plugs does not extend coverage; it adds a dozen clients competing for airtime. In exchange, you get throughput that a mesh of low-rate radios cannot approach, which is why cameras, doorbells with video and anything streaming audio sit naturally on Wi-Fi and awkwardly anywhere else.

• Mains-powered Zigbee devices usually relay; battery ones usually do not, so an all-battery network has no backbone
• Moving the hub a short distance can change edge reliability more than adding devices does
• Wi-Fi coverage is set by access point placement, not by device count
• A dense Wi-Fi install competes for airtime with the 2.4 GHz mesh running alongside it
• Repeaters of either kind add a hop, and every hop adds latency to things like switch-to-light response

The shared band is the real constraint, not the protocol argument

Because both sit in the 2.4 GHz band, they are neighbours whether you planned it or not, and so is everything else using that spectrum in a terraced street. Wi-Fi has somewhere to go: where hardware and the access point support it, traffic can move to 5 GHz or 6 GHz, which the Wi-Fi Alliance now covers in its certification programmes. Zigbee has nowhere comparable to go in domestic use, so the practical move is to arrange the Wi-Fi around the mesh rather than the other way round.

This is also why so many commissioning problems are not protocol problems. A mesh that worked for a year and then degraded has usually had its environment changed, by a new router defaulting to a different channel width, by a neighbour's equipment, or by a hub relocated during redecoration. Diagnosing that as a failing of one technology against the other leads people to replace devices that were working, which is an expensive way to discover the band was congested.

What UK law now obliges the manufacturer to publish, whichever radio it uses

Since the Product Security and Telecommunications Infrastructure Act 2022 came into force alongside the Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, three things are no longer optional for connectable consumer products sold in the UK, and they apply regardless of which radio the device uses. Schedule 1 of those Regulations sets them out directly.

First, passwords must be unique per product or defined by the user, and unique-per-product passwords must not be based on incremental counters, on publicly available information, or derived from serial numbers without proper cryptographic treatment. Second, the manufacturer must publish at least one point of contact for reporting security issues, together with when a reporter will get an acknowledgement and status updates, and that information must be free of charge and not conditional on handing over personal details. Third, the defined support period must be published, must be given equal prominence to other product information in an invitation to purchase, and the requirement is explicitly not met if that period is shortened after publication.

Allocating devices by role instead of by protocol loyalty

Once the obligations and the band constraint are clear, allocation becomes fairly mechanical. Anything running from a coin cell or a pair of cells and reporting a state change goes on the low-power mesh, because that is what the mesh exists for. Anything moving a continuous stream of data goes on Wi-Fi, because nothing else in the house can carry it. Devices that are mains-powered but send small messages can go either way, and are usually worth putting on the mesh deliberately, because they then do double duty as relays.

The one allocation worth being stubborn about is anything whose failure is inconvenient at a bad moment: a lock, a heating control, a smoke alarm. For those, the question is not which radio but whether control survives a broadband outage and whether the published support period is long enough to justify embedding the device in a wall. A device with an unstated or short support period is a device you have agreed to replace on someone else's schedule.

• Battery contact, motion, leak and temperature sensors: low-power mesh
• Video doorbells, cameras, streaming speakers: Wi-Fi, ideally on 5 GHz where coverage allows
• Mains plugs, in-wall relays and bulbs: mesh by preference, so they relay for the battery devices
• Heating controls and locks: decide on local control and support period first, radio second
• Anything to be plastered into a wall: check the published support period before the wall closes

Recording the decision so the next change does not undo it

The failure mode of a mixed household is not the day it is commissioned, it is 18 months later when a router is replaced and nobody remembers which settings the mesh depended on. Writing down the mesh channel, the Wi-Fi channels and widths in use, where the coordinator physically sits, and the published support period for each embedded device costs very little and prevents most of the expensive confusion.

Keep that note with the installation documentation rather than in an app, because the app is often the thing that changes. When a device reaches the end of its published support period, the note is what tells you which replacement has to fit which role, and whether a swap means touching the radio plan at all.

Before you buy

• Sort every planned device into battery, mains-with-small-messages, or throughput
• Put battery devices on the low-power mesh and throughput devices on Wi-Fi
• Place mains mesh devices deliberately so they relay for the edges
• Note the mesh channel and the Wi-Fi channels and widths in use
• Check that the defined support period is published for every device
• Find the manufacturer's security reporting contact before you buy, not after
• Confirm whether local control survives a broadband outage for locks and heating
• Re-read the saved notes before replacing a router, and again after 12 months

Questions readers ask

Is Zigbee or Wi-Fi more reliable?

Neither, in the abstract. The mesh is more reliable for small messages from battery devices across a building with thick walls, because intermediate mains-powered devices relay. Wi-Fi is more reliable for anything needing throughput. Most reliability complaints trace to the shared 2.4 GHz band or to a cloud dependency, not to the protocol.

Do I need a hub if I choose Zigbee?

Yes. A Zigbee network requires a coordinator, which in a household normally means a hub or a bridge. Wi-Fi devices do not need one because the router is already the infrastructure, although many still route their control path through a manufacturer's cloud service.

Will a new router break my Zigbee devices?

Not directly, but it frequently degrades them. A replacement router often resets to a different 2.4 GHz channel and channel width, which can overlap the mesh. If a stable system deteriorates immediately after a router swap, change the Wi-Fi configuration before replacing any mesh device.

What is the support period and why does it matter more than the radio?

It is the minimum length of time the manufacturer will provide security updates. Under Schedule 1 of the 2023 Regulations it must be published, must be given equal prominence to other purchase information, and the requirement is not met if the period is shortened after publication. For a device being fixed into a wall, it effectively sets the replacement date.

Can I just use 5 GHz Wi-Fi for everything and avoid the problem?

For throughput devices, often yes, and that is a good reason to move cameras off the crowded band. But battery sensors are not designed to run on Wi-Fi at all, so moving everything to 5 GHz changes which devices you can own rather than solving the allocation question.

Sources

1. The Product Security and Telecommunications Infrastructure (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1 — checked 2026-11-06
2. Product Security and Telecommunications Infrastructure Act 2022 — checked 2026-11-06
3. Code of Practice for Consumer IoT Security (Department for Science, Innovation and Technology) — checked 2026-11-06
4. ETSI EN 300 328 V2.2.2 — Data transmission equipment operating in the 2,4 GHz band — checked 2026-11-06
5. Wi-Fi Alliance — Discover Wi-Fi — checked 2026-11-06
6. Thread Group — checked 2026-11-06