PoE budgeting and power classes
Sizing Power over Ethernet against real device draw and real switch budgets, not against the number of ports on the front panel.
What it is
Power over Ethernet delivers device power over the same cable as data, in classes defined by IEEE 802.3af, then 802.3at, then 802.3bt at progressively higher power. The power sourcing equipment negotiates a class with the powered device, and the switch allocates from a shared budget. Two numbers matter and they are different: what a single port can supply, and what the switch as a whole can supply across all ports at once. There is also loss on the run, so a powered device always receives less than the source allocates, and the margin narrows as cable length and quality degrade. Access points, tracking sensors, cameras, panels and small nodes all land in this budget together.
Why it matters
PoE failures are rarely clean. A switch at the edge of its budget does not usually go dark; it sheds ports by priority, or brings devices up and drops them under load, or comes back after a power event with a different subset of devices alive than it had before. That produces a fault that looks like a device problem, a firmware problem, or a ghost, and it moves around. On a long run the risk is cumulative: a rig that was comfortable on opening gains a couple of sensors and an access point over the first month and is now marginal, with nothing in the paperwork saying how much headroom there was. Budgeting with margin and recording it is what keeps that from being a discovery.
The switch-wide PoE budget, not the per-port class, is usually the limit that bites first
A powered device receives less than the source allocates; loss on long runs is where marginal designs fail
A device wanting 802.3bt power on an 802.3at switch may come up in a reduced mode rather than refusing to start
Redundant switch supplies do not help if the PoE budget was only ever sized with both supplies present
How do we size a PoE switch?
Add the negotiated class draw of every device you intend to hang on it, add the devices you expect to add during the run, then leave headroom on top of that. Compare the total against the switch-wide budget rather than the per-port rating, and check what the budget becomes if one power supply is lost. Record the resulting margin so the next person adding a device knows what is left.
Do we need 802.3bt?
Only if a device on the rig actually requires it. The relevant question is what each powered device negotiates and what it does when it gets less. Some devices refuse to boot below their class, others come up with functions disabled, and the second case is worse because it looks like a working system. Confirm the behavior per device rather than assuming the class number is the whole story.
Injectors or a PoE switch?
Injectors are useful for one or two high-draw devices, or to reach a device beyond a non-PoE switch, and they keep those loads off the switch budget. The cost is another box in the signal path, another power connection, and another thing to label and carry a spare of. A PoE switch gives central budget management and monitoring, which is generally worth more on a rig that will be maintained by other people.