For a reliable smart home, put lights, sensors and switches on Zigbee. Keep Wi-Fi for mains-powered devices that need bandwidth or already live on your network, such as cameras, speakers, TVs and metering plugs. Add Thread once your Home Assistant host can run it natively, not through workarounds. That is where we landed after building a full Home Assistant install in about a week: 22 of the house’s 24 lights are Zigbee, 2 are Wi-Fi, and one of our three radio sticks is reserved for Thread on the host we are moving to. Below is how we got there, what broke, what it cost and what we would change.
The problem: a real house, and a host with limits
We weren’t comparing protocols in the abstract. The house needed 24 lights, 9 motion sensors, 2 cube controllers, a six-button scene switch, 3 smart plugs, 3 IP cameras, 2 TVs, 5 Sonos speakers and a handful of Google Cast and Nest devices, all spread across 12 areas. We had to decide which radio each device belonged on, and which radios our host could physically support. The second question mattered more.
The host was Docker Desktop on a Mac mini-class desktop with 16 GB of RAM. Home Assistant, Mosquitto, Zigbee2MQTT, Z-Wave JS UI, the Wyoming voice containers and Frigate all ran on it as containers. We built it with Claude Code as a working partner. The agent researched, wrote the compose stacks and debugged, while the physical work and every judgement call stayed with a human. The full story is in Home Assistant with Claude Code: A Full Smart Home in a Week. This article covers just the network layer, because the network decides whether the lights come on at 2am.
A short refresher on what we were choosing between. Zigbee is a low-power 2.4 GHz mesh built on IEEE 802.15.4. Mains-powered devices such as bulbs act as routers, and battery sensors attach to a parent router, all coordinated by a USB stick on the host. Thread uses the same 802.15.4 radio layer but is IP-based and needs a border router. Matter is the application standard that runs on top of Thread, Wi-Fi or Ethernet. Wi-Fi is the network you already have: high bandwidth, power-hungry, and every device is one more client competing for your router’s attention and DHCP pool.
Why Zigbee carries most of the house
Lights and sensors produce lots of small messages and very little data. Many of the sensors run on batteries, and we track 13 battery devices in this house. A local, low-power mesh that doesn’t depend on the Wi-Fi router suits that workload well, and it is why 22 of the 24 lights went on Zigbee: 13 IKEA bulbs, 8 Hue bulbs and 1 Hue strip.
Zigbee2MQTT rather than ZHA
Home Assistant ships its own Zigbee integration, ZHA, and it is a reasonable choice. We went with Zigbee2MQTT for four specific reasons. It has the best IKEA device support, it handles OTA firmware updates, it supports groups, and it has a bulk-rename API over MQTT. Groups mean a whole-house or per-fixture command goes out as one synchronised message, so bulbs don’t pop on one after another. The rename API mattered more than we expected. When the agent couldn’t tell which bulb was which, it made one blink or glow a colour, a human walked around and said where it was, and the agent renamed it over MQTT. An evening of mass pairing and naming would have been several evenings without that.
Running Zigbee2MQTT as its own container also matched how we prefer to build: maintained components wired together, not hand-rolled glue. The same reasoning appears in our guide to custom software vs off the shelf, and it is why Adaptive Lighting from HACS later replaced two hand-built light curves.
Picking a channel that doesn’t fight the Wi-Fi
Zigbee and 2.4 GHz Wi-Fi share the same spectrum. A Wi-Fi channel is wide enough to blanket several Zigbee channels, so a poor choice puts your mesh under constant contention. The first thing to check is which 2.4 GHz channel your Wi-Fi actually uses. Then choose a Zigbee channel clear of that band. We did exactly that. The two most common Zigbee picks, 20 and 25, sat on the edges of our Wi-Fi channel’s band, so we chose neither. The effort is small, and changing the channel later means re-pairing the whole network.
Old bulbs that wouldn’t let go
Some older IKEA bulbs were still attached to a previous Zigbee network on another channel and refused to join. The fix was a Touchlink factory reset sent from the coordinator, followed by a single power cycle. It is worth knowing before you spend an evening flicking switches at a ceiling.
The other IKEA quirk is about fades. These bulbs ignore transition times on plain on/off commands but do fade brightness changes. So the motion lights now switch on at 1% and fade up over 2 seconds, which gives a soft ramp that the plain on command can’t. Getting that order wrong caused one bug: the 1% step ran before the darkness check, so lights came on after sunrise. It was introduced and fixed within about 9 hours, but it shows that radio behaviour leaks into your automation logic.
Where Wi-Fi earns its place
Wi-Fi wasn’t the villain here. It is the right home for devices that are always on mains power, move a lot of data, or are designed around your IP network anyway. That covered the cameras, TVs, Sonos speakers and Cast devices, plus 2 lights and one smart plug with energy metering. Putting a TV on Zigbee was never an option, and forcing a metering plug onto a mesh because it seems neater gains you nothing.
What Wi-Fi does demand is discipline about addressing and discovery. Our Cast devices kept changing IP addresses through DHCP drift. Docker Desktop on macOS has no host networking and no mDNS, so we couldn’t rely on discovery and had to add Cast devices by known IP. Each time an address moved, an integration broke quietly. The fix was unglamorous. We set DHCP reservations for every media and IoT device, and changed the deploy script to follow the default route instead of assuming one. Wake-on-LAN had the same issue: broadcast packets can’t leave Docker Desktop’s VM, so the TVs wake by unicast WoL. If you put a device on Wi-Fi, reserve its address the same day.
Thread and Matter: why we parked them
Thread is the protocol we expect to use more of, and that is exactly why we didn’t force it onto the wrong host. The obvious shortcut is multiprotocol firmware, where one stick runs Zigbee and Thread together. That approach is deprecated, so we ruled it out. The second shortcut was running Thread over the same network bridge we used for the other sticks. Thread over a network bridge is unreliable, and a flaky Thread network is worse than none, because Matter devices then misbehave in ways that look like device faults. So the third radio stick is set aside for Thread on the Proxmox host.
Matter hit the same wall from another direction. We tried a Matter bridge first to expose Home Assistant devices to Google Home. Phones couldn’t pair with it, because pairing depends on mDNS and host networking, and Docker Desktop has neither. We parked it for Proxmox and used the free manual cloud-to-cloud Google Assistant link instead. That now exposes 45 devices, up from 16, with English and Polish aliases. The Matter bridge wasn’t wrong. Our host simply couldn’t support it yet.
The plumbing nobody mentions: USB on Docker Desktop
Whatever radio you choose, the stick has to reach the container. Docker Desktop on macOS has no USB passthrough, so we used ser2net on the host to expose each stick as a TCP port on localhost, and the containers connect via host.docker.internal. macOS has no /var/lock, so ser2net needs the nouucplock option. macOS also names serial devices after their USB port, so moving a stick to another port means re-running the bridge script. None of this is hard, but every piece is another place where a reboot can quietly break your radios.
Z-Wave sits alongside Zigbee on its own sub-GHz band. It runs through Z-Wave JS UI and connects to Home Assistant’s Z-Wave integration over its websocket server, because a containerised Home Assistant has no add-ons. The UI handles S2 security and controller NVM backups. We turned off its soft-reset option, because old Z-Wave sticks can lock up with it enabled. The deploy script generates the Zigbee network key locally along with the MQTT credentials, so no secrets pass through the agent’s context. If you are applying AI agents to infrastructure, that boundary matters; our notes on data security and privacy in AI projects explain why.
What it cost
The radios were the cheap part. Most of the cost was time and hands. About a week of sessions covered the whole house, and one full evening went on factory-resetting, pairing and naming every light. A human had to reset and pair every bulb and sensor, replace a flickering bulb and walk-test each motion sensor. An agent can’t do any of that. The coordinator and the Z-Wave NVM now go into the nightly backups, because re-pairing 22 bulbs after a failed stick is a cost we only want to pay once.
The hidden cost was the host. A 16 GB desktop running Home Assistant, Frigate, voice models and unrelated stacks was swapping heavily. Combined with no USB passthrough and no mDNS, that made single-host Docker Desktop the real bottleneck, not any radio. Hence the planned move to Proxmox on two small-form-factor PCs. The same compose files carry over, and we gain proper USB passthrough, host networking, and with them Thread and Matter.
What we would do differently
We would start with the host and work out to the radios. Choosing a platform with real USB passthrough and host networking from day one would have saved the ser2net bridge, the Matter detour and the Cast-by-IP workaround, and Thread would have been an option from the start. We would set DHCP reservations before adding the first Wi-Fi device rather than after the third broken integration. We would also add monitoring before we needed it. Our weekly report now checks Zigbee devices offline, link quality and battery trends, but it only arrived at the end of the week, after one automation had targeted a non-existent entity for days. Silent failures like that are the theme of AI automation challenges to plan for before you build, and they apply just as much to a mesh network.
The most common way this goes wrong: smart bulbs behind ordinary wall switches
The fastest way to wreck a Zigbee mesh is to let someone use the wall switch. A bulb with its power cut doesn’t just go dark. It goes unavailable, and because mains bulbs are routers, any battery sensor using that bulb as its parent drops off too. One flicked switch can take out a motion sensor in the next room. It gets worse: flipping a wall switch six times resets every bulb on that circuit, after which the groups need re-checking. A related bug hit us directly. A bulb powered back on at the wall booted OFF while the sensor still saw someone, and we needed a dedicated “light came back” trigger to fix it. To avoid all this, decide which circuits must stay live before buying bulbs. Add an alert for when a smart bulb drops off because its wall switch went off. Fit Zigbee switch controllers so the physical switch sends a command instead of cutting power; we added that alert and ordered clip-on controllers. And keep enough always-powered routers that a sensor’s parent never disappears.
This is the kind of problem D3X Solutions LABS works on: getting automation from a weekend experiment to something that runs unattended and tells you when it is sick. We start by mapping the constraints of the host, the network and the people using it, then choose components that can be maintained, and add monitoring before calling anything finished. The same approach applies whether the system controls lightbulbs or business workflows run by AI agents. If you are weighing a similar build or putting AI into an operational system, book a free 30-minute call and we will go through your constraints with you.
Frequently Asked Questions
Is Zigbee more reliable than Wi-Fi for smart lights?
For lights and sensors, usually yes. Zigbee is a local low-power mesh in which mains-powered bulbs act as routers, so it doesn't depend on your Wi-Fi router or add dozens of clients to it. Wi-Fi remains the better fit for high-bandwidth, always-powered devices such as cameras, TVs and speakers.
Do I need Thread to use Matter?
No. Matter can run over Wi-Fi and Ethernet as well as Thread. Thread suits low-power Matter devices, but it needs a border router and a host that gives the radio direct access. Matter pairing also depends on mDNS and host networking, which some container setups such as Docker Desktop on macOS don't provide.
Should I use Zigbee2MQTT or ZHA with Home Assistant?
Both work. We chose Zigbee2MQTT for its strong IKEA device support, OTA updates, groups and a bulk-rename API over MQTT, which made naming 22 bulbs much faster. ZHA is simpler if you don't want to run an MQTT broker.
Does Zigbee interfere with 2.4 GHz Wi-Fi?
They share the 2.4 GHz band, and one Wi-Fi channel overlaps several Zigbee channels. Check which channel your Wi-Fi uses and pick a Zigbee channel clear of it before pairing anything. Changing the channel later means re-pairing the network.
Why do my Zigbee bulbs keep going unavailable?
The most common cause is a wall switch cutting power to the bulb. Because mains bulbs act as routers, battery sensors that use them as a parent can drop off too. Keep those circuits powered and use Zigbee switch controllers instead of the physical switch.
Can I run Zigbee in Home Assistant on Docker Desktop for Mac?
Yes, but Docker Desktop on macOS has no USB passthrough, so you need a bridge such as ser2net exposing the stick over TCP. It works, but the bridge must be re-run if the stick changes USB port. Thread over this kind of network bridge is unreliable, so plan a Linux or Proxmox host if you want Thread.
Want this working in your business?
D3X Solutions LABS builds AI agents and automation that pay back fast. Book a free 30-minute call and we'll map where this fits in your business.
Get in touch
