A PoE camera or access point that refuses to power on, or one that powers up and then keeps cycling, almost always traces back to one of three points in the PSE-to-PD negotiation. This is the order that finds it fastest — what to check at each stage, the exact display poe commands to run, and the root causes that account for most of these tickets.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
PSE-to-PD power delivery only has a handful of places it can fail, and each one leaves a different fingerprint in the display poe output.
A PoE camera or AP that won't power up, or one that powers up and then repeatedly drops and reconnects, is one of the most common tickets on any access-layer switch. The instinct is to swap the cable and hope — but it's faster to work through the negotiation the switch itself is running: does the port even support PoE, does the switch detect a powered device at all, and if it does, does the switch actually have the power budget — per-port and total — to turn it on.
What follows is the fault tree this is built on, the display poe / display poe-power commands for each stage, the five root causes that show up again and again once you're past the first couple of checks, and a handful of FAQ answers pulled from real field cases. This is also exactly the power-budget math our own sales engineers walk through before quoting an Atlas industrial PoE switch for a camera or AP rollout — matching total PoE budget and per-port ceiling to the real device count, not just the headline wattage on the datasheet.
PoE power faults split into two shapes: the PD never powers up at all, or it powers up and something about it is still wrong.
Placing the symptom on this tree first tells you which stage below actually applies — there's no point checking the power budget if the switch hasn't even detected the device yet.
Diagram labels are kept in English for engineering clarity.
Almost every PD power fault is one of these six boxes. The three power-up stages are strictly ordered — the switch won't get to checking the power budget if it hasn't detected the PD yet — so read display poe power-state before display poe power, not the other way around.
Three power-up stages, three different things to look at, and the exact command that tells you which one you're stuck in.
Not every switch, board or power module is PoE-capable — confirm the hardware before suspecting the cable or the PD.
<HUAWEI> display poe device
Slot *: PoE
// confirms this slot is PoE-capable
<HUAWEI> display device power
----------------------------------------------------------------------------
PowerNo Present Mode State Current Voltage ActualPower RatedPower
----------------------------------------------------------------------------
PWR1 YES AC Supply 5.6 55.0 306 2500
PWR2 NO -- -- -- -- -- --
// State = Supply -> power module present and supplying; a dash means faulty/absent
<HUAWEI> system-view
[HUAWEI] interface GE1/0/0
[HUAWEI-GE1/0/0] display this
port link-type access
port default vlan 100
undo poe enable
// PoE has been explicitly disabled on this port
[HUAWEI-GE1/0/0] poe enableThe PSE detects a PD by measuring DC resistance in a narrow 19–26.5kΩ window — anything that disturbs that measurement, and detection fails silently.
// non-standard PD alarm on the switch
POE/4/NONSTANDARDPD:An invalid or non-standard PD is connected to the interface [GE1/0/6].
// enable compatibility detection for non-standard PDs on this port
<HUAWEI> system-view
[HUAWEI] interface GE1/0/6
[HUAWEI-GE1/0/6] poe legacy enable
Warning: Is there a valid PD connected to this interface? [Y/N]:y
<HUAWEI> display poe power-state
// powering / detecting / disabled per interface -- move the PD to a confirmed-good
// port and check this field to isolate PD fault vs. port faultDetection succeeding doesn't mean power follows — distance, a configured off-window, or a power budget that's simply too tight will all stop it here.
<HUAWEI> display poe power interface GE1/0/2
PortName: GE1/0/2
PD power(mW) :0
PD class :2
PD reference power(mW) : 30000
user set max power(mW) : 2000
// user set max power (2000mW) < PD reference power (30000mW) -> raise the port cap
[HUAWEI-GE1/0/2] undo poe power
// or set an explicit ceiling above the PD's reference power:
[HUAWEI-GE1/0/2] poe power port-max-power 30000
<HUAWEI> display poe-power
Chassis 1
Total PoE Power(mW) : 534000
Reserved PoE Power Percent : 20 %
Available Power(mW) : 427200
Consumed Power(mW) : 9400
// Available Power is what's actually left for a new PD after the reserve is set aside
[HUAWEI] poe max-power 480000 slot 1
[HUAWEI] poe power-reserved 10 slot 1Two different symptoms here point to two unrelated fixes — read which one you actually have before changing anything.
// partial-function PD -- LLDP disabled is blocking the 802.3at negotiation
<HUAWEI> system-view
[HUAWEI] lldp enable
Info: Global LLDP is enabled successfully.
[HUAWEI] interface GE1/0/16
[HUAWEI-GE1/0/16] lldp dot3-tlv power 802.3at
[HUAWEI-GE1/0/16] undo lldp disable
// repeated power-cycling on a non-standard PD with a high inrush current
[HUAWEI] interface GE1/0/1
[HUAWEI-GE1/0/1] poe af-inrush enable
// re-plug the PD once after this change -- it won't take effect on an already-connected PDOnce the stages above have told you where the problem sits, these five account for most of what's actually wrong with a camera or AP on PoE.
SYMPTOMA PTZ camera powers up and its image works, but it reports "not enough power for camera and pantilt motors" and the pan-tilt never moves — or the PD simply never powers up at all despite the switch clearly having spare capacity.
CAUSEdisplay poe power interface separates PD reference power (what the connected device says it needs) from user set max power (the ceiling configured, or defaulted, on that port). If the port's own ceiling is lower than the PD's reference power — a 2000mW cap against a 30000mW camera, in one real case — the port refuses the PD before the switch's total budget is ever consulted, regardless of how much power is sitting unused elsewhere on the chassis.
FIXRead PD reference power and user set max power side by side on the affected port, and either clear the manual cap with undo poe power or set an explicit ceiling above the PD's reference power. This is exactly the kind of per-port and total power-budget math we run through with a customer before quoting an Atlas industrial PoE switch for a camera or AP deployment — the headline PoE wattage on a datasheet is not the same question as whether every single port is capped high enough for the PD landing on it.
<HUAWEI> display poe power interface GE1/0/2
PortName: GE1/0/2
PD reference power(mW) : 30000
user set max power(mW) : 2000
[HUAWEI-GE1/0/2] undo poe powerSYMPTOMA camera, IP phone or similar device shows basic signs of life — image, dial tone, a responding IP — but a specific sub-module (heater, pan-tilt, expansion keypad) never activates.
CAUSE802.3af devices finish powering up after detection, classification and power-on alone. 802.3at devices need a fourth step — LLDP power-negotiation TLVs exchanged between PSE and PD — before the full budget is released. If LLDP is globally disabled, that fourth step never happens: the base module gets enough power to start, but the extra load never gets authorized.
FIXEnable LLDP globally and the 802.3at power TLV on the specific interface, then re-plug the cable (or disable/re-enable PoE on the port) for the device to renegotiate from scratch.
[HUAWEI] lldp enable
[HUAWEI] interface GE1/0/16
[HUAWEI-GE1/0/16] lldp dot3-tlv power 802.3at
[HUAWEI-GE1/0/16] undo lldp disableSYMPTOMThe switch logs POE/4/NONSTANDARDPD and refuses to power the device at all, even though the PD's own documentation says it runs on ordinary 48V PoE.
CAUSEThe PD market is not tightly standardized. A PSE identifies a device by the characteristic resistance and current it presents during detection and classification; a device that's electrically close to 802.3af/at/bt but not exactly compliant fails that identification and gets refused rather than risk damaging it.
FIXOnce you've confirmed from the PD's own documentation that it does run on standard 48V, enable legacy compatibility detection on that interface to force the classification through.
[HUAWEI] interface GE1/0/6
[HUAWEI-GE1/0/6] poe legacy enable
Warning: Is there a valid PD connected to this interface? [Y/N]:ySYMPTOMThe switch logs PD powered on / PD powered off in a tight, repeating loop for the same interface — the device never settles into a stable powered state.
CAUSEDetection and classification are sensitive measurements. A switch that isn't earthed — one real case involved a PSE placed directly on a carpeted floor rather than grounded in a rack — picks up enough static interference to keep failing and retrying the same measurement. Separately, some non-standard PDs draw a larger inrush current on power-up than the PSE's default 802.3bt-style profile expects, which the PSE's own protection reads as a fault and cycles the port to clear.
FIXGround the switch chassis properly first — it's the more common cause and costs nothing to rule out. If the cycling continues on a confirmed non-standard PD, switch the interface to the smaller 802.3af inrush-current profile, then unplug and replug the PD once for the new profile to take effect.
[HUAWEI] interface GE1/0/1
[HUAWEI-GE1/0/1] poe af-inrush enable
// re-plug the PD once after configuring this -- it does not apply retroactivelySYMPTOMEither the PD simply never powers up over a long outdoor run, or — worse — a camera or AP that's been powering up fine for weeks suddenly goes dead with no configuration change at all.
CAUSEPoE's reliable powering distance is the same 100m as ordinary Ethernet, and going over it is enough to stop power delivery on its own, cabling aside. Separately, an unshielded cable run outdoors to a camera or AP is a lightning-induced surge waiting to happen — the surge can exceed 1500V, and once a common-mode surge gets large enough it becomes a differential-mode surge that passes straight through an isolation transformer and burns out the PHY chip or the PoE daughter card itself.
FIXKeep the PSE-to-PD run under 100m, and route outdoor spans through proper surge protection or convert the last outdoor leg to fiber with a PoE media converter at the far end, rather than running unshielded copper straight from an indoor switch to an outdoor camera.
Pulled straight from the field — the ones worth having an answer ready for.
All three carry power over the same 100m of cable, but the ceiling changes: 802.3af (PoE) delivers up to 15.4W at the PSE, roughly 12.95W of that reaches the PD — enough for a basic camera or IP phone. 802.3at (PoE+) raises that to 30W at the PSE, roughly 25.5W at the PD — enough for a PTZ camera's pan-tilt motor or a higher-power AP. 802.3bt (UPoE+) goes up to 90W at the PSE using all four cable pairs, covering PTZ domes with heaters, high-power Wi-Fi 6/6E APs and similar. Match the standard to the device before assuming a power problem is something else.
Start at Stage 0, not Stage 2. Confirm the port and board are PoE-capable at all with display poe device, then confirm the interface itself doesn't have undo poe enable configured. Only once the port is confirmed PoE-capable and enabled does it make sense to look at detection and power budget.
This is almost always LLDP. The base module powers up on the standard 802.3af detection/classification/power-on sequence, but an 802.3at device needs a further LLDP power-negotiation exchange to unlock the rest of its budget. If LLDP is disabled globally or the 802.3at power TLV isn't enabled on that interface, the negotiation never happens and the extra module stays unpowered even though the device shows every other sign of being up.
Only once you've confirmed from the PD's own documentation that it runs on standard 48V DC. poe legacy enable skips the PSE's detection and classification checks and forces power through, which is exactly what you want for a PD that's electrically fine but not perfectly IEEE-compliant — and exactly what you don't want to do blind, since those checks exist to protect equipment that might not tolerate 48V.
Divide the switch's total PoE power (from display poe-power, after its reserved percentage is set aside) by the average real power draw of your devices — not their classification tier, which is often higher than what they actually pull. A camera's real draw also isn't constant: it rises when it's actively transmitting video versus idling, so budget for the busy state, not the idle one, especially on ports carrying PTZ domes or heated housings.
Interface Up only means the port's data-forwarding state is fine; PoE power-up is a separate negotiation layered on top of it. Walk the three power stages independently: confirm the port is PoE-enabled, confirm the PSE actually detects the PD (cable, grounding, PD compatibility), then confirm the PSE can power what it detected (distance, a configured power-off time window, and the port's own power cap against the PD's reference power). A healthy data link tells you none of this on its own.
This note is built around the Huawei S-series switch's PD power-fault classification model and its display poe / display poe-power / display device power commands, plus the field cases behind them. If your PSE is a different vendor, the exact commands change, but the underlying negotiation logic — detection, classification, power-on, LLDP-based 802.3at negotiation, power budget — carries over directly. It doesn't cover chassis-level PoE daughter-card hardware diagnosis at the register/chip level in depth, or DC-input PoE injector hardware outside the switch itself.
Tell us which stage it's stuck at — detection, classification, or power budget — plus the display poe power / display poe-power output, and we'll help you read it.