The network setup a smart home wants
Four requirements, one of which your router probably fails today, and all of which are settings rather than purchases.
The four requirements#
Everything on this page comes from four properties, and it helps to know which one you are fixing.
| Requirement | Why | What breaks without it |
|---|---|---|
| A reachable 2.4 GHz network | The overwhelming majority of smart devices are 2.4 GHz only, for range, wall penetration and chip cost | Setup fails partway, usually at "connecting to your network" |
| Multicast that flows | mDNS and DNS-SD are how controllers find Matter, HomeKit, AirPlay and Thread services | Devices pair, then show as unresponsive or vanish from the app |
| IPv6 on the router | Thread is IPv6-only, and Matter relies on local IPv6 | Setup seems to succeed and control fails later |
| Stable addressing | Hubs, bridges and recorders get referenced by address in dozens of places | Integrations break silently after a power cut |
Why a separate 2.4 GHz SSID#
Band steering is the most common cause of "my smart plug will not set up". Here is the mechanism, because knowing it saves you from guessing.
A device that has never been on your network cannot join it yet, so setup happens one of two ways: the device broadcasts its own temporary access point and your phone hops onto it to hand over credentials, or provisioning runs over Bluetooth LE. Either way your phone has to end up back on the same 2.4 GHz network the device just joined, able to talk to it.
A single combined SSID with band steering fights this. Your phone is on 5 GHz, the plug is on 2.4 GHz, the access point decides where clients belong, and the app times out waiting for a device it cannot see. Some IoT Wi-Fi stacks also handle 802.11k, v and r roaming badly, and WPA3 transitional mode confuses older chipsets.
The fix is a permanently separate 2.4 GHz SSID. It is not only for setup: it also stops a laptop steering onto 2.4 GHz and consuming airtime that thirty low-power devices are sharing. Wi-Fi smart devices: the hidden costs covers airtime, and the device will not join 2.4 GHz Wi-Fi is the full diagnosis when setup fails anyway.
Create a dedicated 2.4 GHz SSID
Add a second SSID, 2.4 GHz only, with WPA2 or WPA2/WPA3 mixed rather than WPA3 only. Give it its own name, such as your main SSID with "-IoT" appended. Leave the main SSID for phones, laptops and TVs on 5 and 6 GHz.
Turn off band steering on the IoT SSID
Band steering, and any "smart connect" or "one name for all bands" feature, must not apply to the IoT network. If your router cannot separate them, look for a per-SSID band selection setting, or split the main SSID into distinct 2.4 and 5 GHz names.
Turn off client isolation on the IoT SSID
Client isolation stops devices on the same network from talking to each other, which is exactly what a phone finding a Matter accessory or a controller reaching a Thread border router needs to do. Keep isolation for a genuine guest network, not for IoT.
Set the 2.4 GHz channel manually to 1, 6 or 11, at 20 MHz
Those three are the only non-overlapping US channels. Never use 40 MHz on 2.4 GHz: it doubles your interference footprint over Zigbee and Thread for bandwidth that IoT devices cannot use anyway. Then pick 802.15.4 channels that clear it with the channel planner.
Enable IPv6 on the router
Leave it on the default automatic or SLAAC configuration. Google states directly that without IPv6 on your home wireless network, Matter setup may appear to succeed and control eventually fails. Thread needs it too.
Reserve addresses for the infrastructure
In the DHCP server, create reservations for your hub, access points, border routers, bridges, NVR and printer. Leave everything else on dynamic addresses.
Verify before you add devices
From a phone on the IoT SSID, confirm you can reach your hub's web interface and that your controller app lists its accessories. Then move a single device over and test it before migrating the rest.
VLANs, and the mDNS consequence#
A VLAN is a real security control: it contains a compromised camera so it cannot reach your laptop or your hub's admin page. It also breaks smart home discovery by default, and it is worth being precise about why.
mDNS is deliberately link-local. Multicast DNS sends queries to a multicast group on UDP port 5353 with a hop limit of one, so the packets are designed not to leave the local link. That is the protocol's scoping rule, not a bug. A VLAN is a separate link, so an iPhone on your main VLAN cannot see a Matter accessory or a Thread border router on the IoT VLAN however permissive your firewall rules are, because the announcements never arrive.
Three things must be right, and all three are easy to get half right.
- An mDNS reflector or repeater on the router, enabled for exactly the VLAN pair you care about. Vendors call it mDNS forwarding, Avahi reflection or Bonjour forwarding. Reflect between the two VLANs you need and no others, because reflecting everywhere produces duplicate announcements and controllers that see the same device twice.
- IGMP snooping with a querier. Snooping stops multicast flooding every port, but with no querier on the segment the switch has no membership information and prunes traffic it should forward. Enable both together or neither. Snooping alone is the classic way to break AirPlay and Thread discovery.
- Firewall rules that allow the return traffic. After a controller finds a device it opens a unicast session to it, so the VLANs must be able to talk on the relevant ports. Allow discovery and block the session and devices appear, then fail to respond.
Home Assistant's Matter documentation puts it plainly: Matter is designed for regular residential networks, expects IPv6 and mDNS to travel freely, and behaves badly with VLANs, multicast filtering and aggressive IGMP snooping. Its recommendation is to keep the network as flat as possible, and to keep Wi-Fi Matter devices on the same VLAN as the controller.
IPv6, and why Thread makes it non-negotiable#
Thread is an IPv6-only protocol. Every Thread device has an IPv6 address, and a border router does bidirectional IPv6 routing between the mesh and your LAN, advertises an on-mesh prefix, and registers Thread services so your controllers can find them. Turn IPv6 off on your router and you have removed the thing the border router is trying to route.
Matter over Wi-Fi is in the same position. Google's own Matter readiness guidance says that without IPv6 enabled, setup can appear to succeed and control and other functionality eventually fail, which is precisely the confusing symptom people report. Home Assistant's Thread documentation goes further and lists the layers that all need working IPv6: the host, the router, the hypervisor if you use one, and the Docker daemon if you run in containers.
You do not need IPv6 from your ISP for any of this. What matters is IPv6 on your local network, which routers provide whether or not the WAN side has it. Leave it enabled, leave it automatic, and do not follow old advice that tells you to disable it to simplify things.
DHCP reservations, and what actually needs one#
Dynamic addresses are fine for most devices. Matter, HomeKit and AirPlay find things by name over mDNS rather than by address, so a bulb changing IP is a non-event.
Reservations matter for the things that other things point at: your hub or controller, bridges and border routers, an NVR and its cameras, access points and switches, and anything reached by a script or an integration configured with an address.
While you are in there, check that the DHCP pool is large enough for your device count plus headroom, because pool exhaustion looks exactly like a Wi-Fi problem. Leave lease times at the default.
The physical layer, briefly#
Two hardware realities undo good configuration.
Spectrum. Zigbee and Thread share the 2.4 GHz band with your Wi-Fi and use the same IEEE 802.15.4 radio as each other. Put Wi-Fi on channel 1 or 11 at 20 MHz, then choose 802.15.4 channels clear of it, and keep Zigbee and Thread on different channels from each other. 2.4 GHz interference and channel planning has the arithmetic.
USB 3.0 noise. If your coordinator or border router is a USB dongle, USB 3.0 ports and cables emit broadband noise across the 2.4 GHz band. Intel documented this in 2012 and it is in-band, so it cannot be filtered. Use a one to two meter USB 2.0 extension cable to move the radio away from the host, which is why Home Assistant's ZBT-2 ships with one.
When it still does not work#
Symptoms map to causes fairly reliably.
- Setup fails at "connecting": band steering, WPA3-only, hidden SSID or a captive portal. See the device will not join 2.4 GHz Wi-Fi.
- Pairs, then unresponsive: multicast. Client isolation, snooping with no querier, a VLAN with no reflector. See a device shows as unresponsive.
- Works in one app, not another: each controller runs its own discovery, so this is nearly always mDNS reaching one and not the other, or Thread network fragmentation.
- Everything slows when many devices are active: 2.4 GHz airtime. Move high-throughput clients to 5 GHz and consider whether some devices belong on Zigbee or Z-Wave.
- Intermittent Thread dropouts: start with Thread troubleshooting, which puts discovery ahead of radio.
Do I really need a separate 2.4 GHz SSID?
If you own more than a handful of Wi-Fi smart devices, yes. It removes the most common setup failure, keeps band steering from moving your phone at the wrong moment, and stops laptops from consuming 2.4 GHz airtime that low-power devices are sharing. It costs nothing and takes five minutes on any router that supports multiple SSIDs.
Why do my Matter devices stop working after I set up VLANs?
Because mDNS is link-local by design: the queries are sent with a hop limit that keeps them on the local link, so they never cross to another VLAN. You need an mDNS reflector between the two VLANs, IGMP snooping paired with a querier, and firewall rules that allow the unicast session after discovery. Missing any one produces devices that pair and then go unresponsive.
Does Matter need IPv6?
Yes, locally. Thread is IPv6-only and Matter relies on local IPv6 and mDNS moving freely. Google's Matter guidance warns that without IPv6 enabled, setup may appear to work and control eventually fails. You do not need IPv6 service from your ISP, only IPv6 enabled on your own router, which is the default on most modern hardware.
Should I turn off IGMP snooping?
Either enable it together with a querier, or turn it off. Snooping with no querier is the worst of both: the switch has no membership information, so it prunes multicast that discovery depends on. On a small home network turning snooping off entirely is a reasonable choice, because the flooding it prevents is not a real problem at that scale.
Will a mesh Wi-Fi system work for a smart home?
Usually, with two caveats. Many mesh systems insist on one SSID for all bands, which reintroduces band steering, so look for a setting to split them or to disable steering. And some mesh nodes filter multicast between nodes, which breaks discovery. Home Assistant's Thread documentation calls out mesh access points blocking multicast as a known cause of devices not being found.
How many Wi-Fi smart devices can my router handle?
There is no published number worth trusting, because the limits are DHCP pool size, per-radio association tables, connection tracking, CPU and airtime, and vendors rarely document any of them. The practical signal is behavioral: when devices start dropping and rejoining under load, you are at the limit. Past roughly fifty Wi-Fi IoT devices, the real answer is a dedicated access point or moving devices to a mesh radio.
Primary sources
Specification and vendor documentation we checked while writing this page. Where a claim depends on firmware behaviour rather than a published spec, the page says so inline.