How Power over Ethernet works for IP cameras: the 802.3af, at and bt standards, power budgeting for a camera fleet, cable and distance limits, and the failure modes a VMS actually sees.
Power over Ethernet delivers electrical power and network data to a camera down a single cable, which is why almost every modern IP camera installation uses it and why it is the biggest single installation saving of IP over analog.
Budget on peak draw with infrared illuminators, housing heaters and PTZ motors all active, never on idle draw. The worst case is a cold dark night, which is also the night you least want cameras dropping.
Check the total PoE budget of a switch rather than its per port maximum. A 24 port switch advertising PoE+ on every port almost never has 24 times 30W available.
Specify solid bare copper cable. Copper clad aluminium is the most common hidden cause of PoE faults, because it tests fine on the bench and browns out at the end of a long run under load.
Marginal power rarely presents as a camera that is simply off. It presents as a camera that reboots when its illuminator engages, which is why per camera uptime history in your video management system is what actually catches it.
Power over Ethernet lets a single Ethernet cable carry both the network connection and the electrical supply for a device. For a camera that removes the second cable run, the local socket, and the electrician visit that an analog or DC powered camera would need.
Three consequences follow, and they matter more than the cable saving itself. The first is centralised power: every camera on a PoE switch draws from the same place, so putting that switch on an uninterruptible power supply lets the entire camera segment ride through a power cut, cameras included. With local power adapters at each camera you would need a UPS at every camera to achieve the same thing.
The second is remote power cycling. A PoE port can be turned off and on from the switch management interface, so a camera that has locked up can be rebooted without anyone travelling to it. On a distributed estate this alone repays the cost of a managed switch.
The third is negotiated and protected delivery. The standards require the switch to detect a valid powered device before energising the port, and to classify how much power that device needs. A PoE port will not push power into a laptop or a non PoE device plugged in by mistake.
Power is quoted twice in every specification, and confusing the two numbers is the most common budgeting error. The power sourcing equipment figure, usually the switch, is what is delivered at the port. The powered device figure is what actually arrives at the camera after cable losses. Budget switches on the port figure and select cameras on the device figure.
IEEE 802.3af, ratified in 2003 and known simply as PoE, is Type 1. It supplies 15.4W at the port and about 12.95W at the device over two pairs, which suits a fixed dome or bullet camera with no heater.
IEEE 802.3at, ratified in 2009 and known as PoE+, is Type 2. It supplies 30W at the port and about 25.5W at the device over two pairs, which covers PTZ cameras, infrared illuminators and mild heaters.
IEEE 802.3bt, ratified in 2018 and known as PoE++, covers Type 3 and Type 4. Type 3 supplies 60W at the port and about 51W at the device, and Type 4 supplies 90W at the port and about 71.3W at the device. Both use all four pairs, and they are what multisensor cameras, heated PTZ housings and cameras running their own onboard analytics require.
Two details catch people out. The first is that passive PoE is not PoE at all: some budget cameras and wireless equipment ship with injectors that put a fixed voltage on the cable with no detection and no negotiation, and plugging a standards compliant device into a passive injector at the wrong voltage can destroy it. If a datasheet says 24V passive, it is not 802.3 anything and it will not work correctly with a standard PoE switch. The second is that power class and power type are different things. Devices advertise a class from 0 to 8 during negotiation, and switch datasheets sometimes quote maximum supported class and sometimes quote type, so read carefully which one is being claimed.
Understanding the handshake explains most of the failures you will see in the field. It runs in four stages.
First comes detection. The switch applies a low voltage to the pair and looks for a signature resistance of about 25 kilohms. No signature means no power, and this is exactly what protects non PoE devices from damage.
Second comes classification. The switch measures the current the device draws under a defined test voltage, which places the device in a power class, and the switch then reserves that much of its total budget for the port.
Third, full power is applied, typically between 44V and 57V DC, and the device boots.
Fourth, and optionally under 802.3at and 802.3bt, the device and the switch refine the allocation using Link Layer Discovery Protocol once the link is up. A camera that boots at a high class but only needs a fraction of it in normal conditions can hand the reservation back, freeing switch budget for other ports. This step is worth enabling deliberately, because on a switch with a tight budget it is often the difference between every camera powering up and the last two ports staying dark. It requires LLDP-MED to be enabled on the switch, which is not always the default.
This is where installations go wrong, so it is worth doing the arithmetic explicitly rather than trusting a rule of thumb.
A switch has a total PoE budget that is entirely separate from its per port maximum. A 24 port switch advertising PoE+ on every port rarely has 24 times 30W, or 720W, available. A typical figure is around 370W, which is roughly twelve PoE+ ports at full draw rather than twenty four.
Budget on peak draw, not typical draw. A fixed camera that idles at 5W can more than double when several loads engage together: infrared illuminators at full output after dark, housing heaters and defrosters below their trigger temperature, PTZ motors during a tour or an autotracking move, and onboard analytics if the camera runs its own inference. The worst case is a cold dark night, which is precisely the night you least want cameras dropping, so assume every environmental load is active simultaneously because on that night it will be.
A worked example makes the shape of it clear. Take a 24 camera site with sixteen fixed domes peaking at 9W with infrared on, four PTZ cameras with heaters peaking at 25W while moving, and four multisensor cameras peaking at 30W. That is 144W plus 100W plus 120W, or 364W of device draw. Add roughly ten percent for cable loss and the requirement is about 400W at the switch.
Then add headroom. Two rules have held up well in practice. Size the switch for at least 25 percent above the calculated peak, so a 400W requirement wants a 500W or larger switch. And leave spare ports and spare watts for the cameras that will be added later, because they always are. If the total exceeds what one switch offers, split the estate across two switches rather than buying one very large one, since two switches also mean a switch failure takes out half the cameras rather than all of them.
No special cable is needed for PoE, but the quality of ordinary cable matters considerably more than it does for data alone.
On category, Cat5e is sufficient for 802.3af and 802.3at. For 802.3bt Type 3 and Type 4, use Cat6 or better, because the higher current raises conductor temperature and thicker conductors dissipate that heat better.
On conductor material, insist on solid bare copper rather than copper clad aluminium. This is the single most common cause of mysterious PoE faults in cost driven installations. Copper clad aluminium has substantially higher resistance than solid copper, so voltage drop is worse and heat is worse, and the camera at the end of a long run browns out under load while testing perfectly on the bench. It is also not compliant with the TIA cabling standards. Specify solid copper and then check what was actually delivered to site, because these are not the same thing.
On distance, the 100 metre limit is an Ethernet limit and it covers the whole channel including the patch leads at both ends. It is not strictly a PoE limit, but voltage drop over distance is real: a device at 95 metres receives noticeably less than one at 5 metres, which is exactly why the device power figures are lower than the port figures. On a long run at high power that margin disappears entirely.
Beyond 100 metres the options are a PoE extender, which repeats both data and power and costs a slice of budget per hop, a fibre run with a media converter and local power at the far end, or a switch in a cabinet nearer the cameras. For anything permanent the switch in a cabinet is usually cheapest and always easiest to troubleshoot.
One further practical caveat is bundling. A large bundle of cables all carrying near maximum current will heat in the centre of the bundle, and heat raises resistance, which increases voltage drop. For dense bundles at Type 3 or Type 4 power, use Cat6A and keep bundle sizes modest.
An injector adds power to a single Ethernet run between a non PoE switch and one device. It is the right answer for one or two cameras, or for a single camera hanging off a network segment that has no PoE nearby.
Beyond a handful of devices a PoE switch wins on every axis: one power supply instead of many, one management interface, per port power monitoring, remote power cycling, and no injector sitting on the floor of a cupboard waiting to be unplugged by someone looking for a socket. Injectors also give you no visibility at all, so when a camera browns out there are no port statistics to examine.
A reasonable rule of thumb is that three or more cameras justifies the switch.
An honest list is worth having, because most guides skip this part entirely.
PoE creates a single point of failure. One switch failure takes down every camera on it, power and network together. Analog cameras with local power at least kept running into a local recorder. This is mitigated with a UPS, spares on the shelf, and splitting large sites across multiple switches, but it does not disappear.
The distance ceiling of 100 metres is short for perimeters, car parks and industrial sites, and both extenders and fibre add cost and complexity.
Budget exhaustion is silent until it is not. Switches under deliver in different ways when oversubscribed: some deny power to the newest port, some shed the lowest priority port, and some brown out several devices together. The failure is intermittent and load dependent, which makes it genuinely hard to diagnose after the fact.
Heat is a real consideration rather than a theoretical one when running high power PoE across dense bundles in a warm riser. And cheap components fail expensively, because copper clad aluminium cable and passive injectors save a small amount at installation and cost a great deal in return visits.
Start by inventorying peak draw for every camera model from its datasheet rather than its idle figure, then size the switch to the peak total plus cable loss plus 25 percent headroom, checking the total budget rather than the per port maximum.
Specify solid copper cable of the right category and verify what arrives on site. Keep every channel under 100 metres including patch leads, and plan fibre or a local cabinet where that is not achievable.
Put the switch on a UPS sized for the runtime the site actually needs, and enable LLDP-MED so cameras can hand back reserved budget they do not use. Set port priorities so that if the budget is ever exceeded the switch sheds a low value camera rather than the one covering the main entrance.
Segment the network by putting cameras on their own VLAN or physical switch, away from general traffic. Record the per port wattage each camera draws once commissioned, because that baseline is your reference when something changes months later.
Finally, load test after dark. Commissioning at two in the afternoon in summer tests nothing that matters. Verify the estate with infrared and heaters active, under the conditions that will actually stress the power budget.
This is where power engineering meets daily operations, and it is usually where the problem is noticed first even though it is rarely recognised for what it is.
Marginal PoE seldom presents as a camera that is simply off. It presents as a camera that reboots when its illuminator engages, comes back, records for a while, and drops again. From the operator chair that looks like a flaky camera or a network fault, and it is frequently misdiagnosed as both for months before anyone checks the power budget.
The signature to look for is correlation with load rather than with time. Outages that cluster after dusk, in cold weather, or during PTZ tours are power symptoms. Outages spread evenly across the day are more likely to be network or camera firmware.
Visylix includes an in product device health console that makes this pattern visible rather than anecdotal. It reconstructs per camera uptime over a chosen window from recorded state transitions, and reports availability, the number and duration of outages, recording coverage and last seen time for each camera, flagging cameras below 99 percent availability as degraded and below 90 percent as critical. Because uptime is reconstructed from state history rather than sampled at intervals, a camera that has been flapping nightly appears as a pattern of repeated short outages rather than as a single stale status.
There are two practical uses for this. At commissioning, run the estate for a week and read the health console before signing off, because cameras with a marginal power budget will already be separating from the rest. In operation, cross reference a degraded camera outage times against sunset and temperature, and if they line up, check the PoE port statistics before replacing the camera.
The general point holds whichever platform you run. If your video management system cannot tell you how long each camera was actually up over the last month, you will not catch marginal power at all.
PoE is IEEE 802.3af and delivers 15.4W at the switch port, which is about 12.95W once it reaches the device. PoE+ is IEEE 802.3at and delivers 30W at the port, about 25.5W at the device. PoE+ exists because fixed cameras with infrared illuminators, and any PTZ or heated housing, exceed what 802.3af can supply.
A fixed dome or bullet without a heater typically peaks around 5 to 9W. A PTZ or a heated housing commonly reaches 20 to 25W and needs PoE+. Multisensor and high power PTZ cameras can require 802.3bt. Always take the figure from the maximum on the datasheet, not the typical figure, because the maximum is what you will hit on a cold night.
Yes. Negotiation happens per port, so each device is classified and allocated power independently. What you must not assume is that the switch can supply every port at its maximum simultaneously. Check the total PoE budget of the switch, which is a separate and much smaller number than the per port maximum multiplied by the port count.
No. Power and data travel on the same cable without interfering with each other, and PoE does not reduce link speed. Bandwidth problems on a camera network are almost always switch uplink capacity or stream configuration rather than anything to do with PoE.
Behaviour depends on the switch. Some deny power to newly connected devices, some shed the lowest priority ports, and some allow a brownout that causes several cameras to reboot repeatedly. Setting explicit port priorities is what turns this from an unpredictable failure into a controlled and diagnosable one.
Not on a single standard run. The Ethernet channel limit is 100 metres including the patch leads at both ends. Beyond that, use a PoE extender which repeats power and data at the cost of some budget per hop, run fibre with a media converter and local power at the far end, or place a switch in a cabinet closer to the cameras.
For one or two cameras an injector is fine and cheaper. Beyond that a switch is better in every respect: one power supply instead of several, central management, per port power monitoring, remote reboot of a hung camera, and port priorities. Injectors also give you no visibility, so when a camera misbehaves you have no port statistics to look at.
The most likely cause is that the infrared illuminator or the housing heater pushes the camera past what the port or the total switch budget can supply. Test by disabling infrared temporarily, or by moving the camera to a lightly loaded switch, and check the per port wattage the switch reports under night conditions rather than during the day.