PoE Node Planner — methodology

Contents

1. What it decides, and what it does not
2. Inputs
3. The demand math
4. The four checks
5. Verdict and ranking rules
6. Class E engineering defaults
7. The switch registry and its sources
8. Evidence classes and confidence
9. What invalidates a result
10. Method changelog

1. What it decides, and what it does not

The planner answers one procurement question: for this mix of PoE cameras, will this switch — or the best switch in the registry that matches your filters — have the ports, the per-port ceiling, the total budget and the right IEEE standard to power them? It returns FIT, FIT WITH RISKS, NEEDS VALIDATION or NO FIT.

It does not model cable resistance, per-pair current, negotiation timing, class-event signalling or a switch's port-priority behaviour when its budget is exhausted. The IEEE standard specifies a 100 m channel and the vendor's per-port and budget figures already account for the loss inside it; beyond 100 m the result carries a warning and the engine models no derate, because a derate curve would be a guess.

It is also not the Power Budget engine, which sizes the whole node's supply including the compute module. This one is about the PoE switch and the cameras hanging off it.

2. Inputs

Nothing is required. Naming a switch pins the result to that model and the candidate list holds one row; leaving it out ranks every row that matches the filters and reports the winner.

3. The demand math

• group W = count × (per_camera_w override, else the class's typical draw)
• demand W = Σ group W
• cameras = Σ count — one camera, one PoE port
• highest PD ceiling = max over the classes present of that class's IEEE powered-device wattage

The two figures do different jobs. The typical draw is a planning number and drives the total budget: a fixed dome that draws 7 W consumes 7 W of the switch's budget, not the 12.95 W its class is entitled to. The powered-device ceiling is the entitlement and drives the per-port check: a port has to be able to deliver the class the camera negotiates, whatever it actually draws.

4. The four checks

The result also reports max_cameras_of_class: for each of the three camera classes, how many the chosen switch can hold once ports, budget and standard are all applied. A class the switch cannot negotiate reports zero.

5. Verdict and ranking rules

• Any check FAILs → NO FIT.
• Else any check is UNKNOWN → NEEDS VALIDATION.
• Else any check is NEAR LIMIT → FIT WITH RISKS.
• Else FIT.

With filters rather than a named switch, every matching row is evaluated and ranked by verdict first, then by the largest budget margin, then by the most PoE ports. The winner's verdict is the result's verdict; the top ten rows travel with it as candidates, and the alternatives block names the smallest switch that still fits, the one with the most headroom and an industrial-rated option where one fits.

Every non-PASS check that has a fix lists it in remediations: add a second switch, move the heated PTZs to their own budget or an 802.3bt injector, or choose a model with more ports, a higher per-port ceiling or a larger budget.

6. Class E engineering defaults

All five are class E engineering figures. The per-camera draws and the headroom are named in the assumptions of every result and are overridable from the Advanced panel and the API; the nominal powered-device wattages are disclosed in the planning notes whenever they are used. The power-sourcing wattages the research could quote (30 W for 802.3at, 60 W for Type 3, 90 W for Type 4) are class A and are shown alongside them.

7. The switch registry and its sources

Seventeen switches across five vendors, every row carrying the vendor tech-specs page or datasheet it was read from, with a verbatim quote and a link:

Fifteen of the seventeen publish a total PoE budget and eleven publish a per-port ceiling; the rest report UNKNOWN rather than a guess. A source record without a resolvable URL is dropped when the registry is built, and a row left with no source at all is dropped and listed in the dataset's gaps. Known holes travel with every result: no vendor MSRP could be quoted for any row; the MikroTik netPower 16P publishes only per-rail current limits, so its budget and per-port ceiling are null; NETGEAR's product pages do not state per-port watts or operating temperature; and Ubiquiti's pages label ports “PoE+” / “PoE++” rather than by IEEE number, so those standards are mapped from that labelling and the per-port ceiling rather than from a verbatim IEEE citation.

8. Evidence classes and confidence

• A — every switch figure: port counts, PoE budget, per-port maximum, standards, uplink, industrial rating, operating range; and the power-sourcing wattages the standards pages quote.
• D — the budget check (a class A budget times a class E headroom), the per-port check (a class A ceiling against a class E nominal), and the standard check (class A port standards against a class E camera-class assignment).
• E — the per-camera draws, the headroom, the nominal powered-device wattages, and any check whose vendor figure is missing (reported UNKNOWN).

Confidence: HIGH for the port check, MEDIUM for the derived per-port, budget and standard checks, LOW for any UNKNOWN. The overall confidence is the lowest of the four.

9. What invalidates a result

• Cameras that draw more than their class default — heaters, wipers, illuminators and edge analytics all raise the figure. Override it with the camera datasheet.
• Non-camera powered devices sharing the switch: access points, intercoms, speakers and PoE-powered compute all take budget the planner has not been told about.
• A cable run longer than the 100 m channel the standard specifies — the result warns, but models no derate.
• Cable that is not up to the standard's specification, or a patch path with extra connectors, which raises the loss inside the channel.
• A switch whose PoE budget is shared with a stacking or uplink module, or that derates its budget at high ambient temperature.
• Redundant-supply expectations: the budget in the registry is the single-supply figure the vendor publishes.
• Any figure the vendor page does not publish — the check reports UNKNOWN and the verdict becomes NEEDS VALIDATION rather than a number.

10. Method changelog

Method changes bump the method version; new or re-verified switch rows bump the dataset version. Both are in every result and in the citation block.