PoE Budget Planning for AV and IT Devices
By WireFlow Team · Published 2026-07-11 · Updated 2026-07-11 · 9 min read
A PoE budget is the total power a switch can supply across all of its PoE ports, shared as one pool. Planning one means adding up what your connected devices will pull, from their datasheets, not from memory, and comparing that sum against the switch's stated budget with headroom left over. Most switches cannot power every port at the full per-port limit at once, so the budget runs out before the ports do. Plan against roughly 70–80% of the pool and write the per-port assignments into the switch schedule.
What is a PoE budget?
Every PoE switch has two numbers that matter: the per-port limit, set by the PoE standard and class each port supports, and the total PoE budget, the shared pool of watts the switch's power supply can deliver across all ports combined. PoE budget planning is the arithmetic that compares that shared pool against the sum of the devices you intend to hang off it, PTZ cameras, touch panels, access points, phones, intercom stations, before the switch ships to site.
The failure mode is quiet. A switch that runs out of budget doesn't dim the lights: depending on the model it refuses power to new devices, sheds ports by priority, or power-cycles gear as loads shift. On a show network that reads as "the stage-right PTZ randomly reboots," and nobody connects it to the fifth touch panel that got added at load-in.
PoE standards: 802.3af, at, and bt at a glance
Three IEEE standards cover nearly everything you'll rig. Treat the tiers below as planning shorthand, the binding numbers are the IEEE class your device actually negotiates and the figures printed in the device and switch datasheets.
| Standard | Common name | Nominal tier (verify per datasheet) | Typical loads |
|---|---|---|---|
| IEEE 802.3af (Type 1) | PoE | Commonly associated with up to ~15 W class range at the port | VoIP phones, small IP cameras, wall controllers |
| IEEE 802.3at (Type 2) | PoE+ | Commonly associated with up to ~30 W class range at the port | PTZ cameras, touch panels, most Wi-Fi APs |
| IEEE 802.3bt (Type 3/4) | PoE++ / 4-pair | Commonly associated with the ~60–90 W class range | Large touch displays, high-power APs, small amplified endpoints |
Why 24 PoE ports doesn't mean 24 powered devices
A spec sheet that says "24 PoE+ ports" is describing what each port can do individually, not what all 24 can do at once. Powering every port at the full PoE+ tier simultaneously would take a supply dedicating several hundred watts to PoE alone, and most access switches ship with far less. That gap between per-port capability and the shared pool is deliberate oversubscription, and it's the entire reason budget planning exists.
- A 24-port PoE+ switch with a pool in the ~370 W range, a common spec shape, covers roughly a dozen ports at the full PoE+ tier, not 24.
- Switches decide who loses differently: some deny the newest device, many shed by port priority, others by class. The behavior lives in the switch documentation, and it matters at 2 a.m.
- Empty PoE ports cost nothing. The pool drains only for connected devices that negotiate power, which is why a half-loaded switch can still be over budget.
Worked example: loading a hypothetical 24-port switch
Here is the arithmetic on a hypothetical example switch: 24 PoE+ ports, 370 W total PoE budget. The device figures are honest typical ranges, a PTZ camera commonly draws in the 12–25 W range, a PoE touch panel commonly sits in the 12–30 W range, a Wi-Fi AP commonly in the 10–20 W range. Your datasheets replace every one of these numbers.
Switch PoE budget (hypothetical example): 370 W 6 × PTZ camera @ 25 W planning figure = 150 W 4 × touch panel @ 30 W planning figure = 120 W 3 × wireless AP @ 20 W planning figure = 60 W Planned load = 150 + 120 + 60 = 330 W Budget used = 330 ÷ 370 ≈ 89%
Thirteen devices on a 24-port switch, half the ports still empty, and the budget is nearly gone. Ports were never the constraint.
6 × PTZ camera @ ~18 W typical = 108 W 4 × touch panel @ ~15 W typical = 60 W 3 × wireless AP @ ~13 W typical = 39 W Typical running load = 108 + 60 + 39 = 207 W Budget used ≈ 207 ÷ 370 ≈ 56%
The 123 W gap between step 1 and step 2 is the class-versus-draw gap, read the next two sections before you spend it.
Plan on the step-1 numbers, not the step-2 numbers. Devices hit the top of their range at the worst times: PTZ motors slewing to a preset, IR illuminators kicking on, heaters in outdoor housings, radios under peak load. The typical-draw view is for verification after install, not for sizing before it.
How much headroom to leave
Working crews plan to roughly 70–80% of the stated budget and treat the rest as margin. That is field practice, not a standard, it absorbs the device nobody told you about, firmware that changes draw behavior, and the show-day addition that always happens.
Field-practice ceiling: 370 W × 0.75 ≈ 277 W usable for planning Planned load from step 1: 330 W 330 W > 277 W → over the line Options: move ~2 devices to a second switch, feed the largest loads locally, or spec a bigger PoE budget
The rig fit the raw budget at 89%, it fails the headroom test. That distinction is the plan working.
Negotiated class vs. actual draw
Every powered device has two numbers: what it reserves and what it draws. At connect time the device and switch negotiate a power class, through hardware classification and, on many managed switches, LLDP refinement. Many switches then subtract the full class allocation from the pool even if the device idles far below it; others track actual consumption and allocate dynamically. Which model your switch uses changes your math, so check its documentation.
The practical consequence: a touch panel that negotiates as a ~30 W-class device but draws 14 W still eats ~30 W of a class-allocating switch's budget on paper. Managed switches show allocated versus delivered power per port in the CLI or GUI, that view is how you verify the plan after install and reclaim reality from the class math. But when sizing, assume the reservation, because that is what the switch may enforce.
Put per-port PoE in the switch schedule
The PoE plan belongs in the same document set as the IP schedule and the VLAN plan: a switch/port schedule that lists, for every port, the far-end device, VLAN, IP, PoE on/off, the planning wattage, and the port's priority. When the switch refuses one more device at load-in, that sheet is the difference between shedding the right load in one minute and unplugging things to see what breaks. It is the same single-source-of-truth discipline that prevents duplicate IP addresses.
In WireFlow this lives on the diagram's network layer: switches and endpoints are devices on the same drawing as the signal flow, every link is documented port to port, and VLANs, IPs, and PoE notes ride on the same source of truth, so the PoE math happens during preproduction, while it's still a spec change instead of a truck roll.
Frequently asked questions
- What happens when a PoE budget is exceeded?
- It depends on the switch. Some deny power to the next device that asks, many shed by port priority (low-priority ports drop first), and some drop whatever negotiated last. The symptom is devices that refuse to power up or power-cycle when other loads join. The exact behavior is in the switch documentation, and managed switches log the events.
- How do I find my switch's PoE budget?
- It's on the datasheet, usually as "PoE power budget" or "PoE capacity," and it varies by model and sometimes by power supply option in the same product line. On managed switches the CLI or web GUI also reports the pool plus allocated and delivered watts per port, which is the ground truth once gear is connected.
- Should I calculate with the device's class or its actual draw?
- Size with the class or datasheet-max figure, verify with actual draw after install. Many switches reserve the full class allocation regardless of real consumption, and devices spike toward datasheet max under motor load, illuminators, or heaters. Actual-draw numbers are for confirming headroom, not for spending it.
- Do PoE injectors count against the switch budget?
- No, a midspan injector carries its own power supply, so it adds nothing to the switch's pool. Injectors are the standard escape hatch when one high-draw device won't fit the budget. Document them in the switch schedule anyway, or they become the mystery wall-wart nobody can explain in a year.
- Is high-power PoE safe on any cable?
- Higher-power PoE warms cable, and heat rises with bundle size and cable category. This is genuinely code-adjacent territory: follow the cable manufacturer's guidance and applicable local requirements, and involve a qualified installer for dense bundles or long high-power runs rather than treating it as a pure network question.
Document your AV network in WireFlow
VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.