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 and PoE-powered compute nodes, 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.

Inputs (WP-01). A field that is not stated takes its documented default and is listed in provenance.defaulted; a field that is stated but invalid — a count of 0, a negative, a fraction or a non-number, true in place of a count, an unknown value of an enumerated input, or an empty string — is rejected with VALIDATION_ERROR naming the field, never replaced by a default.

Input keys (WP-02). The engine accepts one list of input keys — the inputs documented here and their declared backward-compatible aliases. Unknown input keys are rejected with VALIDATION_ERROR naming the key: an invented or misspelt key is never silently ignored, a __ test hook never reaches the engine, and an alias sent together with the key it stands for is rejected too (the engine would read only one of them). export_json.inputs echoes every input the engine honoured, so replaying it reproduces the result.

3. The demand math

• group W = count × (per_camera_w override, else the class's typical draw)
• camera demand W = Σ group W
• node demand W = node count × node pse_w when nodes is provided and the per-node PSE draw resolves
• total demand W = camera demand + node demand
• powered devices = cameras + node count — one powered device, one PoE port
• highest PD ceiling = max(camera PD ceiling, node pse_w) when node PSE is known

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 powered-device maximum that 802.3af publishes for its class. 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.

Node supply resolves in this order: stated nodes.pse_w, else the IEEE class PSE maximum for nodes.pd_class (30 W for 802.3at, 60 W for 802.3bt Type 3, 90 W for Type 4), else unknown. Those IEEE class PSE figures are class D planning derivations from the standard pages, not vendor board measurements.

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. Only evidence that can prove the miss makes a FAIL (elimination authority).
• Else any check is UNKNOWN or REQUIRES VALIDATION → 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. Within one verdict, rows where none of the ports, per-port and budget checks misses come first (a miss demoted to REQUIRES VALIDATION still counts as a miss here), smallest switch first: fewer PoE ports, then a smaller PoE budget, then switch id; rows with a failing capacity check follow, closest miss first: the largest budget margin (an unknown margin last), then the larger port margin, then switch id. When the industrial input is not true, a non-industrial switch ranks before an industrial one within the same verdict and the same capacity group, and the order above applies inside each; it is a preference, not a filter, so an industrial switch still wins when no indoor switch reaches its verdict and capacity group. Price never influences the winner. The winner's verdict is the result's verdict; the top ten rows travel with it as candidates; the largest budget-margin row is still published as most_headroom; the winner itself is switch. The alternatives block also includes an industrial-rated option where one fits. lowest_price is the fitting switch (FIT or FIT WITH RISKS) with the lowest known USD price in the PoE switch price registry, with its price, currency, evidence class and the listing's retrieved and verified dates; a switch with no known price is excluded, never counted as zero, ties go to fewer PoE ports then switch id, and it is null when no fitting switch has a price.

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 four 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 IEEE wattages are not defaults: the power-sourcing maxima (15.4 W for 802.3af, 30 W for 802.3at, 60 W for Type 3, 90 W for Type 4) and the powered-device maxima (12.95 W, 25.5 W, 51 W and 71.3 W) are class A figures quoted from a vendor standards table and cited in every result. The same holds for a camera sized by IEEE PD class (poe_class 0–8): its draw is the class's powered-device power — 12.95 W for classes 0 and 3, 3.84 W for class 1, 6.49 W for class 2, 25.5 W for class 4, 40 W for class 5, 51 W for class 6, 62 W for class 7 and 71.3 W for class 8 — read from the registry's PD class table, each figure quoted from a vendor classification table (Synectics, Perle) and cited in the result. The standard such a camera negotiates comes from the same table: classes 0–3 are 802.3af, class 4 is 802.3at, classes 5 and 6 are 802.3bt Type 3 and classes 7 and 8 are 802.3bt Type 4, so a Class 7 or 8 camera is held against the Type 4 powered-device ceiling (71.3 W) and needs a port that negotiates Type 4 (90 W).

7. The switch registry and its sources

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

Nineteen of the twenty-one publish a total PoE budget and fifteen 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; the power-sourcing and powered-device wattages the vendor standards table quotes; and the per-port check for a camera mix (a class A per-port maximum against the standard's published powered-device maximum, both cited).
• D — the budget check (a class A rated budget compared against demand, with your class E headroom input setting the NEAR LIMIT floor at rated × headroom — not folded into available), the per-port check when a node's PSE figure comes from the IEEE standard rather than a stated value, and the standard check (class A port standards against a class E camera-class assignment).
• E — the per-camera draws, the headroom, and any check whose vendor figure is missing (reported UNKNOWN).

Confidence: HIGH for the port check, MEDIUM for the 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 that were not declared in nodes: access points, intercoms, speakers and extra PoE-powered compute all take budget and ports.
• 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.