Planning PoE Power Budgets Across a UniFi Switch Stack

Do you know how much power your PoE switch is handing out right now, or only the total wattage printed on the spec sheet? Most installs know the second number and nothing about the first, which is how a rack that looked comfortable in the quote starts shedding cameras on the first cold night of the year.

A PoE budget gets quoted as one figure, and the natural assumption is that you spend it like a bank balance until it runs out. In practice that figure is a ceiling on what the internal supply can push out at the port side, and a real deployment loses part of it to class allocation, per-port ceilings, and the cable-loss allowance the standard already bakes in.

This guide covers what the budget number measures, how 802.3af, 802.3at, and 802.3bt class draw translates into watts actually reserved, why the per-port limit constrains you as hard as the total, and how to size a multi-switch deployment so the next four cameras do not force a hardware swap. If you are still picking hardware, work through our guide to choosing a UniFi switch first and come back here to size the power.

The total PoE budget on a switch describes what the internal power supply can deliver across all PoE ports at once, measured at the switch port — the PSE side — rather than at the device. That distinction is where most planning errors begin, because every device datasheet quotes what the device consumes, which is a smaller number than what the switch spends to deliver it.

Keep in mind that the budget is a property of one chassis and one power supply. Two 24-port PoE switches sitting in the same rack and linked over a 10G uplink do not share a power pool, so a camera on the switch that has run out of budget stays dark no matter how much headroom the switch beside it is holding.

Uplink ports, SFP+ cages, the switching fabric, and the fans all sit outside the PoE budget, even though they draw from the same supply. Some switches additionally derate available PoE at high ambient temperature or when a large number of high-power ports come up at once, which is worth reading the fine print for on any model you intend to load near its limit.

There is one more thing the single figure hides: the gap between the watts a switch supplies and the watts a device is guaranteed to receive. That gap is not a manufacturer hedge — it is the cable-loss allowance written into the IEEE standard, and it is the reason a 30W port is paired with a 25.5W device rating.

When a powered device is plugged in, it signals a power class during detection and classification, and the switch allocates against that class rather than against whatever the device eventually settles into drawing. The classes and their two numbers — what the switch supplies at the port versus what the device is guaranteed at the other end — are the arithmetic your budget actually runs on:

• Class 1 (802.3af). Up to 4W at the port and 3.84W guaranteed at the device. Typical of small sensors and low-power adapters.
• Class 2 (802.3af). Up to 7W at the port and 6.49W at the device.
• Class 3 (802.3af). Up to 15.4W at the port and 12.95W at the device. This is standard PoE, and it covers most fixed indoor cameras and older access points.
• Class 4 (802.3at). Up to 30W at the port and 25.5W at the device. This is PoE+, and it is what current Wi-Fi 6 and Wi-Fi 7 access points, pan-tilt-zoom cameras, and PoE-powered compact switches generally expect.
• Classes 5 and 6 (802.3bt Type 3). Up to 45W and 60W at the port, and 40W and 51W at the device, delivered across all four pairs rather than two.
• Classes 7 and 8 (802.3bt Type 4). Up to 75W and 90W at the port, and 62W and 71.3W at the device. This is the PoE++ tier, and it is usually present on only a handful of ports on a given switch.

Note that a Class 0 device also exists in the standard, and it asks the switch to reserve the full 15.4W of a Class 3 port without committing to a narrower range. Whether your switch holds the class allocation statically or tracks actual consumption dynamically changes the math considerably, so confirm which behaviour your model uses before you fill the last few ports.

We plan against class allocation either way, because dynamic allocation only protects you until every device peaks simultaneously. Cameras with infrared illuminators peak after dark, outdoor housings with heaters peak in winter, and access points peak when the client count does, and those peaks tend to coincide rather than spread neatly across the day.

Underpowering is also a quieter failure than it sounds. Several access point and camera families will come up on insufficient power in a reduced-functionality mode rather than refusing to boot at all.

As a result, a site can run for months with a radio disabled or a secondary port dead before anyone connects the symptom to the switch power budget. If you are matching devices to ports, start from our guides on choosing a UniFi access point and choosing a UniFi camera, then confirm the power method and maximum consumption on each model spec sheet before you commit a port.

A switch imposes two independent constraints, and clearing one does not clear the other. The total budget governs the sum of all ports, while the per-port limit governs the maximum any single port will deliver, and it is common to exhaust one while the other still looks comfortable.

For instance, eight Class 4 devices reserve 240W between them at 30W apiece, which will consume an 8-port PoE switch of modest budget entirely even though no single port is anywhere near its ceiling. Conversely, a switch with a generous total budget may still cap every port at 802.3at, which makes it the wrong chassis for a 60W PoE++ device regardless of how much aggregate headroom the label promises.

Mixed port groups are the specific thing to check on any switch you are specifying. Many models deliver 802.3bt on a small subset of ports and 802.3af or 802.3at on the rest, so the physical port you patch a high-draw device into determines whether it powers up at all.

We plan total load to roughly 70 to 80 percent of the rated budget, and we treat that as a design rule rather than a suggestion. The remaining margin absorbs seasonal heater draw, night-time infrared load, devices added after handover without a budget review, and the fact that a supply running flat out runs hotter and ages faster than one running at three-quarters.

Be aware of what happens when the budget is genuinely exceeded, because it is rarely graceful. The switch begins shedding ports — by configured PoE priority where that is available, and by port order or last-connected where it is not.

That means the device which goes dark is chosen by a default policy rather than by how much you care about it. Setting PoE priority explicitly on the ports carrying your entry cameras and your primary access points is a short configuration change that decides which failure you get.

Power loss between the switch and the device is resistive, and it scales with the loop resistance of the copper and with the square of the current. The IEEE channel specifications bound that resistance — on the order of 20 ohms for two-pair 802.3af and 802.3at channels, and roughly 12.5 ohms for four-pair 802.3bt — and the guaranteed device figures in the class list above already reflect worst-case loss at those limits.

On a compliant channel, in other words, the derating has already been applied for you inside the standard itself. What breaks that assumption is a channel that is not compliant.

Copper-clad aluminium cable, 28AWG slim patch cords, an extra pair of punchdowns, and a 90-metre horizontal run finished with two long patch leads all push loop resistance toward or past the specified limit. When that happens the device may not receive its class power even though the switch reports the full allocation as spent, which is a diagnostic trap worth remembering — the controller shows you the budget consumed, not the watts that arrived.

The loss costs you budget as well as delivery. Whatever is dissipated in the copper is drawn from the switch, so a device that needs 20W at the far end of a marginal long run pulls more than 20W from the total, and a long, thin, warm run is simply a more expensive port than a short one feeding the same device.

Two levers help here, and both are cheap at install time rather than after. Four-pair 802.3bt spreads the same delivered power across twice the conductors and cuts resistive loss substantially, and 23AWG solid Cat6 carries lower loop resistance than 24AWG Cat5e over the same distance.

Furthermore, large bundles of cable carrying four-pair PoE through conduit run hotter than single cables, and copper resistance climbs with temperature. Bundle size and pathway ventilation are therefore power decisions as much as they are cable-management decisions.

Start the inventory by class rather than by device count. Ten Class 3 cameras and ten Class 4 access points reserve 154W and 300W respectively, and a device count of twenty tells you neither figure.

Write the port-side allocation for every planned endpoint, sum it per chassis, and compare each sum against 70 to 80 percent of that chassis rated budget. This is the whole exercise, and it takes a spreadsheet rather than a site visit.

Then spread the high-draw devices deliberately instead of by patch-panel convenience. Putting every PoE+ access point on one switch and every low-draw sensor on another concentrates your risk, whereas alternating them leaves each chassis with usable headroom and each failure domain with partial coverage.

Reserve growth explicitly, in ports and in watts. A site that adds two cameras a year needs both a free port and roughly 30W of unspent budget per addition, and the watts are what quietly disappear first.

Be careful with PoE-powered switches at the edge. Some compact UniFi switches can be powered over their uplink and pass a portion of that power through to downstream ports, which is genuinely useful for a desk cluster or a small camera group.

That convenience makes one upstream port allocation the hard ceiling for everything behind it, and it places two power dependencies in series. Check the specific model input requirement and passthrough capability before you design around it.

Finally, remember that PoE load is UPS load. A rack pushing several hundred watts of PoE will burn through runtime considerably faster than the switches alone would, so if you have built gateway WAN failover to keep a site reachable through an outage, the PoE budget is what decides whether the cameras and access points are still up when the failover matters.

Segmentation planning belongs in the same document, since PoE mode and VLAN assignment are both per-port properties of the same port map. Our guide to UniFi VLANs covers the addressing half of that map.

The UniFi Network application reports PoE power per port and total PoE consumption per switch, which turns everything above from an estimate into a measurement. Open the switch device page, read the per-port draw against the class you expected, and reconcile the total against the rated budget.

Watch it across at least a full day and night before you trust it. Infrared illuminators, heaters, and evening client load all push consumption up at predictable times, and a mid-afternoon reading will understate your real peak by a wide margin.

Per-port PoE mode is worth auditing at the same time. Ports left in a lower mode will not power a device that needs PoE+, and ports set to passive 24V on the models that offer it will not negotiate with a standards-compliant device at all, which produces a dead port that presents exactly like a cable fault.

If your observed peak sits above roughly 80 percent of the rated budget, treat it as a capacity problem now rather than a surprise later. The options, in ascending order of cost, are moving a high-draw device to a switch with headroom, setting PoE priority so the shedding order matches your priorities, and adding a chassis.

Comparing candidates on total budget and per-port capability across our UniFi switch lineup, and checking power method across the UniFi camera lineup, is the fastest way to work out which of the three you are actually looking at. Remember that port count is the least useful number on either page.

If you are sizing a stack now, list every planned endpoint with its class allocation and its run length before you pick a chassis. That one table answers the budget question, the per-port question, and the growth question at the same time, and it is far cheaper to build than a second switch bought in a hurry.