PoE Zigbee and Thread Radios on UniFi: Placement and Budget

Why does a Zigbee network that behaves perfectly beside the server fall apart at the far end of the house? Usually because the coordinator is in the worst possible place, and adding devices rarely rescues a weak center.

After all, a Zigbee or Thread coordinator is a low-power 2.4 GHz radio. Home Assistant's guidance treats its placement as an RF decision rather than a cabling convenience, which puts it at odds with the rack.

Of course, PoE resolves that argument. The radio goes where the mesh needs it, takes power and data from one cable, and leaves the server wherever it already is.

This guide covers what Home Assistant supports over the network and where the radio belongs. It then works through the switch's power budget and the channel plan that keeps Zigbee, Thread and Wi-Fi apart.

In fact, Home Assistant's ZHA documentation is unusually blunt about it. Electrical noise from computers and their peripherals can partially degrade or fully jam communication between a coordinator and its devices.

Its recommended workaround for a USB adapter shows how serious that is. Use an adequately long shielded USB extension cable, plugged into a USB 2.0 port, to get the radio away from the machine.

As a result, an Ethernet coordinator skips that argument entirely. The cable that carries its data can already run the length of the house, so the radio ends up in a hallway or a landing rather than a cupboard.

Placement interacts with the mesh as well, remember. Mains-powered Zigbee devices act as routers and carry traffic for the rest, so a central coordinator with routers around it beats a corner coordinator with the same device count.

Orientation is worth a few minutes as well. Home Assistant suggests trying different positions and antenna orientations, which costs nothing and occasionally fixes a stubborn corner of the house.

Keep in mind that the distinction is about link quality, not about networking in general. A coordinator needs a stable, uninterrupted connection to its serial interface, which a wired LAN provides and a Wi-Fi bridge does not.

For example, Home Assistant lists PoE models among the adapters it discovers automatically, naming SMLIGHT's SLZB-06 and Tube's PoE-powered coordinator by their mDNS names. Discovery aside, any of them can be entered by hand as socket:// with an address and port.

Official Home Assistant hardware sits in a different category. The Connect ZBT-2 is USB, it is what Home Assistant recommends for a new Zigbee network, and its firmware is maintained by the same team.

The honest trade, then, is vendor support against placement freedom.

Thread follows a similar split, for what it is worth. The OpenThread Border Router app drives a local radio, while a standalone border router is added through its REST API, a plain HTTP URL on port 8081.

Some adapters, naturally, cover both protocols. Home Assistant's Thread documentation describes installing OpenThread firmware on a third-party adapter, so one piece of hardware can serve either mesh, though not both at once on a single radio.

This is the same wall the rest of the series runs into, and the VLAN guide explains why. Discovery is multicast, and multicast is link-local, which the IoT VLAN guide covers along with UniFi's relay and its limits.

Accordingly, the practical answer is a fixed address. In UniFi Network, open the adapter under Client Devices, enable Fixed IP Address, and optionally add a Local DNS Record so the socket path can use a name.

Firewall policy, however, is simpler here than for most IoT devices. Home Assistant opens the connection to the radio, so an allow in that direction is enough and nothing needs to reach back.

The radio belongs, in addition, off any network you would not trust with a shell. A serial bridge exposes the coordinator's interface to anything that can reach the port.

That is an argument for the trusted side, or for a tight policy, rather than an open IoT segment.

Ubiquiti's PoE reference sets out what a port can offer. Plain PoE delivers 15.4 W at the port and 12.95 W to the device, while PoE+ raises that to 30 W and 25.5 W.

Ubiquiti's PoE++ and PoE+++ reach 60 W and 100 W at the port. For instance, a switch offering PoE+ on every port still cannot run every port at 30 W, because the total budget runs out first.

Naturally, a small radio sits at the bottom of that range, so the constraint is rarely the port. It is the total, which Ubiquiti ranges from 45 to 52 W on a Lite switch up to hundreds of watts on Professional and Pro Max models.

Put the coordinator in a budget with the devices that actually consume it. Ubiquiti's published figures run from 8 W for its smallest access point to 51 W for its largest, and its cameras span roughly 4 W to 43 W.

As a result, one extra access point or Protect camera matters more to the budget than the radio ever will.

The PoE budget guide works through the arithmetic across a stack, and the switch lineup lists what each model can supply. Choosing between them is the subject of the switch buying guide.

Finally, one warning from that reference is worth repeating. UniFi and UISP PoE adapters are passive, always outputting voltage with no negotiation, so check a device's requirements before using an adapter to offload a full switch.

Keep in mind that Zigbee, Thread and 2.4 GHz Wi-Fi share one band, and only Wi-Fi is loud. A plan that keeps the three apart is cheaper than any amount of retrospective troubleshooting.

Set the Wi-Fi side deliberately, then, rather than leaving it to chance. UniFi's Channel AI moves 2.4 GHz channels for you, and Ubiquiti documents a channel-omission control under AirView, Channel AI and then Channel Plan, which keeps the optimizer off channels you want protected.

However, changing the Zigbee channel later is slow rather than difficult. Home Assistant warns it can take up to an hour for devices to reconnect, and suggests power-cycling end devices to speed that along.

Naturally, Thread has its own preference, and it does not clash with Zigbee's. Channel 26 sits at the top of the band where Wi-Fi rarely reaches, which the Matter and Thread guide covers along with the rest of Thread's network requirements.

Run both meshes and you are planning three radio systems at once. That is manageable when each has a documented preference: Wi-Fi on 1, 6 or 11, Zigbee on 15, 20 or 25, and Thread on 26.

Work in this order, because each step is harder to undo than the one before it:

1. Pick the location first, central rather than convenient, and run the cable to it.
2. Set the channels before pairing anything, with Wi-Fi pinned, Zigbee on 15, 20 or 25 and Thread on 26. The switch buying guide and PoE budget guide cover the wired side of the same install.
3. Give the radio a DHCP reservation, then add it in Home Assistant by its socket:// address rather than waiting on discovery.
4. Check the switch's PoE headroom after it comes up, comparing everything you have connected against the model's PoE Availability.
5. Pair one device and read the mesh map, which shows whether nearby mains-powered devices are acting as routers.
6. Add the rest in batches, starting with mains-powered devices to build the mesh before the battery ones join it.

Expect the map to look worse before it looks better. A mesh with few routers leans on the coordinator directly, and Home Assistant's guidance is that healthy coverage comes from many routers close enough to each other to pass traffic along.

Overall, the payoff shows up at the edges of the house. A coordinator in the middle with a spread of routers reaches the garage sensor that a rack-mounted USB stick never did, and neither the server nor the switch had to move.