Cameras

PoE camera selection: what actually matters

Choose a PoE camera on protocol-verifiable criteria — standard RTSP, ONVIF Profile T, a usable substream, PoE class within your switch budget, and local recording — not a fake per-model matrix.

Problem summary

Buy on what you can actually verify: the camera exposes standard RTSP and a documented substream, publishes ONVIF Profile T conformance, fits your switch's PoE budget (class and watts, including IR/heater draw), records locally without a cloud account, and gets security updates. Megapixels and app polish don't decide whether it works with your NVR.

Operator snapshotEvidence first

First proof

Confirm the camera exposes standard RTSP with a substream.

Screen to open

ffprobe -rtsp_transport tcp "rtsp://USER:PASS@IP:554/<path>" (on a sample unit)

Expected signal

There's a documented RTSP main + low-res sub stream.

Stop boundary

Don't fill every port assuming the switch can power them all.

Layer path

1Choose a PoE camera on protocol-verifiable criteria — what you can confirm yourself — not a vendor's per-model compatibility table: standard RTSP + a documented substream, published ONVIF Profile T conformance, PoE class within your switch budget, local recording without a cloud account, and a security-update track record.

2PoE fit is about watts and budget, not port count: sum each camera's rated draw (including IR illuminators and heaters that spike at night) and keep the total under ~80% of the switch's total PoE budget, remembering switches deliver less than the source rating.

3Resolution and app polish don't decide integration — a reliable 1080p substream beats a flaky 4K stream for an NVR, and 'AI' marketing rarely survives contact with a self-hosted NVR.

4'ONVIF compatible' marketing is not a conformance listing, and ONVIF has ended Profile S support in favor of Profile T — verify behavior with ffprobe/ONVIF Device Manager before buying in bulk.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

List the protocol must-haves

Check: Require standard RTSP + substream, ONVIF (prefer Profile T), and local recording.

Expected result: You're filtering on verifiable criteria, not marketing.

If not: Drop cloud-only cameras from the list.

Verify on a sample unit

Check: Buy one, then ffprobe the RTSP and check ONVIF in ONVIF Device Manager.

Expected result: The sample exposes standard RTSP/ONVIF as claimed.

If not: Firmware changes paths, so verify rather than trusting a per-model table.

Size the power

Check: Add up rated draw (with IR/heaters) and compare to the switch's total PoE budget at 80%.

Expected result: The switch can power all cameras with headroom.

If not: If not, pick lower-draw cameras, a higher-budget switch, or injectors.

Right-size resolution to decode

Check: Match resolution/codec to what the NVR host can decode at your camera count.

Expected result: The host decodes all streams; detection runs on substreams.

If not: Don't buy 4K/H.265 everywhere if the host can't decode it.

Plan isolation and updates

Check: Choose maintained-firmware cameras and plan to isolate them on a no-internet VLAN.

Expected result: Cameras stay patchable and contained.

If not: See /cameras/isolate-cameras-on-vlan for the segmentation pattern.

Decision tree

If: Camera is cloud-only / no standard RTSP.

Then: Poor fit for a self-hosted NVR.

Action: Skip it; choose a camera that exposes standard RTSP/ONVIF.

If: Only 'ONVIF compatible', no Profile listing.

Then: Conformance is uncertain.

Action: Prefer a Profile T conformant camera; verify behavior with ONVIF Device Manager.

If: Camera's PoE class pushes the switch over budget.

Then: Power, not ports, is the constraint.

Action: Choose a lower-draw camera, a higher-budget switch, or injectors; size with the calculator.

Safe stop: Don't fill every port assuming the switch can power them all.

If: Vendor firmware looks abandoned.

Then: Security/longevity risk.

Action: Prefer maintained firmware; isolate cameras on a VLAN with no internet regardless.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Evaluating a candidate camera.	Whether it exposes standard RTSP + substream.	Stream / protocol	Require RTSP + sub; verify with ffprobe.
Checking ONVIF support.	Published Profile T conformance vs 'compatible' label.	ONVIF conformance	Prefer Profile T; verify on onvif.org.
Will it fit my PoE switch?	Camera rated watts (with IR/heater) vs switch total budget.	PoE budget	Keep total under ~80%; size with the calculator.
Self-hosting concern.	Local recording without a cloud account.	Cloud dependence	Require local RTSP recording.

Reference

Commands and settings paths

Verify the RTSP stream before buying in bulk

ffprobe -rtsp_transport tcp "rtsp://USER:PASS@IP:554/<path>" (on a sample unit)

Where: On the LAN against one test camera.

Expected: ffprobe reports a main and sub stream with codec/resolution.

Failure means: No usable RTSP/substream means poor NVR integration.

Safe next step: Only standardize on a model after a sample verifies standard RTSP.

Check ONVIF conformance/behavior

ONVIF Device Manager (connect, enumerate profiles) + ONVIF conformant-products listing

Where: On the LAN and onvif.org.

Expected: The camera shows real ONVIF behavior (and ideally a Profile T listing).

Failure means: 'Compatible' marketing without conformance is a red flag.

Safe next step: Prefer Profile T conformant models; verify behavior on a sample.

Size the PoE budget

Sum rated watts (with IR/heaters) vs the switch's total PoE budget; keep under ~80%

Where: In the PoE budget calculator / switch datasheet.

Expected: Total draw fits the switch's delivered budget with headroom.

Failure means: Near/over budget means cameras drop under load (worse at night).

Safe next step: Choose lower-draw cameras, a bigger switch, or injectors.

Hardware boundary

Hardware and platform boundary

Change only when

Standardize on a camera only after a sample verifies standard RTSP/ONVIF and the PoE math fits — then buy in quantity with confidence.

Evidence that matters

Standard RTSP + substream, published ONVIF Profile T conformance, PoE class within the switch budget, local recording, and maintained firmware.

Evidence that does not matter

Headline megapixels, app aesthetics, and 'AI' marketing — none of which guarantee NVR integration.

Avoid

Trusting a per-model compatibility matrix or an 'ONVIF compatible' label without verifying RTSP/ONVIF on a real unit.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

PoE budget calculator

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from June-2026 research verified against ONVIF (Profile T, end of Profile S), Reolink RTSP formats as a representative pattern, FS.com PoE standards, and Frigate's detect-on-substream guidance; states protocol-verifiable selection criteria only and explicitly rejects fake per-model matrices, cross-linking the PoE calculator and the VLAN-isolation page.

Sources/assumptions

Assumes a self-hosted NVR setup where the camera must integrate via standard RTSP/ONVIF, not a vendor cloud.
Compatibility is protocol-verifiable only — 'ONVIF compatible' marketing is not the same as a published Profile conformance listing.
PoE draw varies with IR/heater state; size on the camera's rated watts and your switch's total budget, not a guess.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setupUsed for the detect-on-substream / record-on-main pattern and recommended stream roles.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.ONVIF: Profile TUsed for the Profile T feature set and the 2025 end-of-support for Profile S (Profile T is the recommended replacement).FS.com: Running 10GBASE-T over Cat6 vs Cat6a vs Cat7Used for the 10GBASE-T distance facts (Cat6a 100m, Cat6 ~55m) and the 2.5/5GBASE-T (802.3bz) on-Cat5e-to-100m point behind 'why does my 2.5GbE only link at 1GbE'.Reolink: Introduction to RTSPUsed for the Reolink RTSP URL format (main vs sub stream) as a representative per-vendor pattern.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

What specs actually decide if a PoE camera works with my NVR?

The protocol-verifiable ones: it exposes a standard RTSP stream (with a low-res substream for detection), publishes ONVIF Profile T conformance (for discovery/PTZ/events), records to your NVR without a cloud account, and its PoE class/watts fit your switch budget. Those determine integration. Resolution, app design, and marketing 'AI' features don't — a 4K camera with a flaky stream is worse than a reliable 1080p one.

How do I know it'll fit my PoE switch?

Add up each camera's rated draw (use the datasheet, and account for IR illuminators and heaters that spike at night) and keep the total under ~80% of the switch's total PoE budget — the budget is the binding limit, not the port count, and switches deliver less than the source rating. Size it with the PoE budget calculator; over-budget switches shed cameras under load.

Is an 'ONVIF compatible' label enough?

No. 'ONVIF compatible' marketing often means partial conformance, and ONVIF has ended Profile S support in favor of Profile T. Prefer cameras with a published Profile T conformance listing, and verify the actual RTSP/ONVIF behavior with ffprobe / ONVIF Device Manager before buying in bulk — don't trust a static per-model compatibility table.