How to Find Why a PoE Camera Keeps Rebooting

Why this matters

A camera that reboots does not look broken during the day, which is when the service call happens. It shows a clean picture, the tech reseats the plug, and the customer calls back after the next cold night with three gaps in the recording. The usual first move, replacing the camera, often fixes nothing, because the camera was the one part that was working: it rebooted because something stopped feeding it. This card is a sequence of checks that tells power from network, then pins down which power problem it is, before any part comes off the truck.

How PoE classes, budgets and injectors work is in Power over Ethernet for Cameras and Access Points. This card assumes that and goes straight to the hunt.

Before you start

A cable tester that can qualify a run (not only show continuity), the recorder or switch login, the camera's own login, and the camera's spec sheet. If the camera sits on a ladder-height mount, set the ladder at about 4 to 1 on firm ground and do not reach past the rails. PoE runs at low voltage, but the recorder, switch or injector plugs into 120 V; do not open any of them.

Step 1: Read the logs and line up the times

Pull two logs for the same nights: the camera's own system log and the recorder's (or switch's) event log. Look for two different kinds of entry.

• A boot or power-on entry on the camera. The camera lost power or crashed and restarted. That points at power, or at the camera itself.
• A video-loss or network-disconnect entry on the recorder with no boot entry on the camera. The camera stayed up and the recorder lost it. That points at the network: a cable fault, a port, or an address conflict (step 6).

Then note the times. Reboots that cluster at night, or in cold weather, are a strong lead toward power, for reasons step 2 explains.

Why first: this one comparison splits the possible causes into two groups that share almost no fixes. Skip it and you test cables for a power budget problem, or swap power supplies for an IP conflict.

Step 2: Check the power budget against maximum draw, at night

Every PoE recorder and switch has a total PoE budget (the watts it can supply across all ports at once) as well as a per-port limit set by the PoE standard it supports. Add up the maximum consumption from each connected camera's spec sheet, not the figure on the status page at noon.

Why maximum, and why night: a camera's draw is not fixed. Infrared illuminators turn on at dusk and add load. A camera with a heater or a defroster turns it on in cold weather and adds more. A daytime readout of the recorder's PoE page can sit comfortably under the budget while the 2 am draw is over it. When total draw exceeds the budget, the power source cuts one or more ports to protect itself, and which port it sheds is set by its port priority rules, often the highest-numbered port when priorities are equal; the manual says which.

Also note how the device manages the budget. Some count the class each camera announces when it connects, others count measured draw. A class-based device can refuse to power the last few cameras at all; a draw-based one powers everything at noon and sheds at night.

One more allowance. Spec-sheet figures are what the camera consumes. The port supplies that plus what the cable loses; the PoE standards build this in (802.3af allows 15.4 W at the port to deliver 12.95 W at the device, 802.3at 30 W to deliver 25.5 W), and the recorder's per-port readout shows the port side.

Step 3: Qualify the cable and both terminations

Test the run end to end with a qualification tester. A poor termination or a nicked conductor adds resistance on one pair, and resistance turns into voltage drop that grows with current. That produces exactly the same night-only signature as a budget problem: fine at 4 W, failing at 7 W. Copper-clad aluminum cable does the same thing across the whole run, because its resistance is higher than solid copper's.

Why it comes third and not first: a cable that passes takes the voltage-drop explanation off the table in minutes, but a cable that fails does not prove the budget was fine. Do both.

Step 4: Check the length

The tester reports length. The Ethernet channel under TIA-568 is 100 m including patch cords. A run past that can carry video and still sag on power under load, again worst at night.

Step 5: Swap ports to see whether the fault follows the camera or the port

Move the rebooting camera to a different port, and move that port's camera to the original one. Then watch the next night, or the next cold night if cold is the pattern.

• The fault follows the camera (it reboots on its new port): the camera, its cable or its own termination. Steps 3 and 4 should already have told you which.
• The fault stays with the port number (the other camera now reboots there): either that port is bad, or the recorder is shedding that port first when the budget runs out. A bad port usually fails in daytime too and with any load; budget shedding happens at peak draw, and many recorders log it as a PoE overload.

Step 6: Rule out an address conflict

If step 1 showed video loss without camera reboots, check addressing. Two devices with the same IP address knock each other off the network intermittently. Cameras on the recorder's own PoE ports usually get addresses from the recorder; the conflict tends to come from a camera with a static address on the home network, or a new device on the customer's network that took an address a camera already had. The recorder's network page or the camera list shows each camera's address; look for a duplicate or a camera whose address changes.

A driveway camera that died every cold night

An 8-port PoE recorder runs seven turret cameras and one bullet camera with a heater on the driveway. The customer reports gaps in the driveway recording on cold nights, never during the day. The camera was replaced once by another company. It still drops.

Step 1. The camera log shows boot entries at 02:14, 03:41 and 05:06 on a night that reached 24 F. The recorder log shows a PoE overload event on port 8 at each of those three minutes. Power, not network.

Step 2. Reading the labels and spec sheets (the figures here are illustrative; use the ones on your equipment): the recorder's total PoE budget is 50 W. Each turret's maximum with infrared on is 6.5 W; the bullet's maximum with infrared and heater on is 12 W.

POE BUDGET, 8-PORT RECORDER, MAX DRAW
turrets   7 x 6.5 W              = 45.5 W
bullet    1 x 12 W               = 12.0 W
total at worst case              = 57.5 W
budget on recorder label         = 50.0 W
over budget by 57.5 - 50.0       =  7.5 W
noon readout on PoE page         = 33 W

The noon readout of 33 W is what the earlier tech saw, and it looked fine. The worst case is 7.5 W over. On a cold night the turrets' infrared is on and the bullet's heater cycles on, and when the total crosses 50 W the recorder sheds port 8. The camera reboots with its heater off, the total falls, the port comes back, the camera warms up, the heater comes on, and the cycle repeats. That is why the boots come at irregular intervals on cold nights and never in summer.

Step 3. The driveway run qualifies end to end. Step 4. It is 31 m. The voltage-drop explanation is ruled out.

Step 5. The tech moved the bullet to port 2 and port 2's turret to port 8. The next cold night the bullet held all night, and the turret now on port 8 rebooted once at 03:20 with a PoE overload entry. The fault stayed with port 8, the lowest-priority port. Shedding, not a bad port. (On paper, shedding one 6.5 W turret still leaves 51 W against 50 W; one shed was enough that night because spec-sheet maximums seldom all land at the same moment. The fix below does not rely on that.)

Step 6 did not apply, since the log showed boots, not network drops.

The fix. The bullet came off the recorder's budget: a single-port PoE injector rated for 802.3at sits beside the recorder, its data input patched from port 8 and its output feeding the driveway camera. The recorder does not power its own port 8 now, since the injector's input announces no PoE device, so its worst case is the seven turrets: 45.5 W against 50 W. That margin of 4.5 W is thin, and the ticket says so: the next camera added to this recorder needs its own injector or a larger PoE switch, not a free port. Port priorities were also set so the front door camera is the last to be shed if the budget is ever exceeded again.

What the replaced camera taught. The first company's new camera had the same heater and the same maximum draw, on the same port. Replacing it could not have changed the arithmetic.

What changes the answer

Reboots in daytime too, at random. Budget shedding tracks peak load; random daytime boots with no overload entry point to the camera itself, a failing port, or a marginal termination that a test caught only at the tester's gentle current. Re-terminate before replacing anything.

Several cameras rebooting together. One shed port reboots one camera. Several at once points at the power source itself: an overheating recorder in a closed cabinet, a failing switch power supply, or a power strip shared with something that trips.

A customer's own switch. If the cameras run from a PoE switch the customer bought, its budget may be well below the sum of its ports' ratings. Read the total, not the per-port figure.

Finish test

The camera holds through a full night, in the conditions it failed in (cold, if cold was the pattern), with its own log showing no boot entries and the recorder's log showing no PoE overload. Write the per-camera maximum draws and the new worst-case total against the budget on the ticket, so the next added camera is checked against the same sum.

References

• IEEE 802.3af and 802.3at, port output and powered-device power levels
• TIA-568 cabling standard, 100 m channel limit
• See related: Power over Ethernet for Cameras and Access Points
• See related: Terminating and Testing an Ethernet Cable
• See related: Camera Network Layouts: Recorder Ports, Switches and the Home LAN