QualifiedLow risk

PoE device (camera/AP/phone) not powering up

A Power-over-Ethernet device (IP camera, wireless AP, VoIP phone) won't power on over its data cable — pointing at the PoE source, the budget, the cable, or the device's PoE class.

Safety first

PoE energises the data pairs — generally low risk, but treat the cabling carefully and don't connect non-PoE equipment to a forced-injector incorrectly.

Isolate, lock out / tag out, and prove dead before working unless a live test is specifically required, authorised, and carried out under proper supervision. Always follow local regulations, your site procedures, and the equipment manufacturer's documentation.

Full detail — causes, the why, and common mistakes.

Likely causes

Ranked from most to least likely.

  1. 1

    Switch port not providing PoE / disabled

    Most likely

    The port isn't a PoE port, PoE is disabled, or the switch's PoE budget is exhausted.

  2. 2

    PoE class/standard mismatch

    #2

    The device needs more power (higher PoE class/standard) than the source provides.

  3. 3

    Cable fault / excessive length losing power

    #3

    A poor run or excessive length drops too much voltage to power the device.

  4. 4

    Faulty injector / midspan

    #4

    A separate PoE injector has failed or isn't inline correctly.

  5. 5

    Faulty device

    Least likely

    The device's PoE input has failed.

Reports are saved on this device to reflect what you actually find.

Testing sequence

Work through one test at a time. Expected reading and what each result means.

Test 1 of 3
1

Confirm the source provides PoE (right port/injector, enabled) and the PoE budget isn't exhausted.

Expected reading

An enabled PoE source with budget available.

If it passes

Source provides PoE — check class match and the cable.

If it fails

No PoE / budget exhausted — enable PoE / free up budget / use a suitable injector.

View all expected readings at once
1. Confirm the source provides PoE (right port/injector, enabled) and the PoE budget isn't exhausted.
An enabled PoE source with budget available.
2. Check the device's required PoE class/standard against the source's capability.
Source meets the device's PoE class/standard.
3. Test the cable run (wiremap/length) and try the device on a known-good PoE port/lead.
Good run; device powers on a known-good source.

Fault-finding flowchart

The same logic as a decision tree.

  1. 1
    start

    PoE device not powering

    → step 2
  2. 2
    decision

    Does the source provide PoE with budget available?

    Yes→ step 3No→ step 4
  3. 3
    decision

    Does the source meet the device's PoE class/standard?

    Yes→ step 5No→ step 6
  4. 4
    result

    Enable PoE / free budget / use a suitable injector.

  5. 5
    decision

    Does the device power on a known-good PoE port/lead?

    Yes→ step 7No→ step 8
  6. 6
    result

    Class mismatch — use a source that meets the device's needs.

  7. 7
    result

    Original run/port at fault — test/repair the cabling.

  8. 8
    result

    Device PoE input faulty — replace.

Common mistakes apprentices make

  • Assuming any port supplies PoE.
  • Overlooking an exhausted PoE budget on the switch.
  • Class/standard mismatch (device needs more power).
  • Ignoring cable length/quality dropping power.

When to stop & escalate

Switch PoE config/budget is usually the network team's area; cabling faults the cabling installer's. A faulty device goes back to its supplier/installer.

If you're past your competence, authorisation, or the safe limits of the job — stop and hand it on. There's no fault worth getting hurt over.

Related faults