Installing cameras is usually the easy half of a video surveillance project. The hard half is the recording side: where the footage lives, what survives the environment, and what the whole thing costs per year. At industrial sites, the three conventional answers each fail differently. Consumer NVR appliances are not built for dusty cabinets and −25 °C winters. Cloud subscriptions run $144–216 per year, indefinitely, and keep the footage on third-party servers. Desktop PCs can run the software but arrive with fans, dust sensitivity, and office-grade power expectations — a poor fit for a wall cabinet at a remote site.
A fourth pattern has been spreading from homelab workshops into industrial projects: an industrial computer working as the NVR, paired with a small PoE switch, running open recording software on it. What follows is an application analysis — the architecture, the division of labor, the selection logic, and the economics.
The mainstream pattern is two devices:
IP cameras → PoE switch → industrial computer
The PoE switch powers every camera over the same Cat5e/Cat6 cable that carries its video. A standard 802.3af camera draws 4–13 W; a PTZ model with a heater can peak near 25 W. Eight cameras sit comfortably inside a switch with a 120–150 W PoE budget, and roughly 1.5× headroom over the calculated load covers boot surges and night-time IR LEDs.
The industrial computer pulls the streams, records, runs detection, and serves the interface. One uplink between switch and computer carries everything.
Why the split? Because the RJ45 ports on most industrial computers — PUSR's included — are data ports. Sourcing 802.3af/at power requires dedicated magnetics, PD controllers, and per-port power budgeting: switch hardware, not compute-board hardware.
The one-box pattern does exist. One documented case in the homelab community involved a fanless machine with 10 Ethernet ports, 8 of them PoE+, an Intel 6500TE CPU, and 4 GB of DDR4 — bought largely out of curiosity, measured at 23 W idle and about 30 W during video playback, running Debian, and originally earmarked as a NAS. Machines like that collapse the architecture into a single chassis: cameras plug straight in, and the box powers them while it records. They remain rare, though, and the two-box split has its own advantages: camera power stays isolated from the compute board, and adding camera capacity means a bigger switch, not a new computer.
Strip the labels away, and a PoE NVR does four jobs:
Power the camerasover Ethernet — handled by the switch in this architecture.
Pull the video streams— nearly every IP camera speaks RTSP.
Recordcontinuously or on motion, reliably, for weeks.
Detect and notify— without shipping video to a cloud service.
A consumer NVR does jobs 2–3 out of the box and job 4 poorly or not at all. An industrial computer does all four, because the software is a choice rather than fixed firmware:
① On ARM models with Ubuntu and Docker pre-installed,Frigateis the common pick — free, open-source, AI-backed event detection with a web UI, deployed as a Docker container rather than a weekend project. ZoneMinder and Shinobi cover classic continuous recording.
② On x86 models running Windows,Blue Irisis the mature option under a one-time license.
That is the real division of labor: the switch owns the power, and the industrial computer owns everything past the network cable. In practice it replaces the NVR appliance, the per-camera licensing, the cloud subscription, and — in projects that wanted analytics — a separate server as well.
Camera count is the visible sizing number, but three factors decide the selection better.
This is what rules industrial computers in and consumer gear out. A fanless aluminum chassis has no filter to clean and no bearing to fail in year two. A −25 °C to +75 °C operating range survives an outdoor cabinet with no air conditioning. A 9–36 V DC input with reverse-polarity protection runs off the same supply as the rest of the cabinet — or off solar and battery power at sites with no grid. A hardware watchdog reboots the box after a power dip and brings the recording stack back without a site visit. NVR databases are exactly the kind of workload that corrupts on dirty shutdowns, so this matters more than it sounds.
How much detection, and on how many streams? This decides whether a plain CPU is enough or an NPU earns its keep.
① 2–4 cameras at 1080p, motion recording:modest. An ARM industrial computer such as the EG528 — quad-core Cortex-A53 at 2.0 GHz, Ubuntu 24.04, TF-card storage — paired with a 4-port PoE switch covers a small workshop or shop floor.
② 8–16 cameras with detection:an NPU changes the math. The EG828-GL (RK3568 quad-core at 2.0 GHz, 1 TOPS NPU, 4 GB RAM, 32 GB SSD, Gigabit Ethernet) runs face and object recognition models locally — TensorFlow, ONNX, Darknet and the rest — with no cloud and no per-camera fee. Frigate runs in its pre-installed Docker.
③ Up to 32 cameras, 4K streams, plate recognition:the EG928A. Its RK3588J combines an 8-core CPU with a 6 TOPS NPU, 8 GB RAM, and 128 GB eMMC, decoding 8K@60fps H.265/H.264. It is specified for up to 32 network cameras and runs face, license-plate, and object detection on-device; the HDMI output doubles as a live-view monitor. Gigabit Ethernet, Wi-Fi 6, and optional 5G/4G cover sites with weak or no wired backhaul.
If the site already runs a Windows VMS — Blue Iris, Milestone, or an existing SCADA-adjacent stack — x86 is a requirement, not a preference. The EC500 (i5-7200U, 5× RJ45, 8× serial, HDMI + VGA) carries that load, and its five LAN ports keep the camera network, the management network, and the uplink physically separate without an extra switch. The EC300 and EC100 cover the same software ecosystem at lower port counts.
Viewing deserves its own line. A gate or reception that needs a live wall does not need another PC: an SH800 touch panel PC next to the door runs the NVR's web dashboard on the wall — one device, no separate monitor, no keyboard.
Storage is bitrate math, not guesswork. One 1080p camera at 4 Mbps writes about 1.8 GB per hour — roughly 43 GB per day. Four cameras, two weeks of continuous retention: about 2.4 TB. Motion-only recording cuts that by 70–90% on quiet sites, less on busy ones, because cameras pointed at a street trigger constantly. The practical split: continuous recording on entrances, motion-only elsewhere, OS and detection models on the eMMC/SSD, and footage on a separate large drive — surveillance-grade, sized for the retention period rather than the camera count.
Running costs are where the pattern wins outright. The documented homelab machine idled at 23 W — about 17 kWh per month — and peaked around 30 W during playback. A recording box that draws less than a light bulb runs 24/7 for a couple of dollars a month in electricity. Against that: cloud plans at $144–216 per year, recurring, with footage off-site. The two-box build is a one-time hardware cost — computer, PoE switch, surveillance-grade drive — and the footage never leaves the property.
Two honest limits. First, a two-camera setup in an air-conditioned office is a job for a cheap consumer NVR; the industrial argument only begins where dust, temperature, power quality, or 24/7 unattended operation enter the picture. Second, camera selection gates everything: cameras must expose RTSP, ideally ONVIF. Cloud-locked consumer cameras cannot join this architecture at all, whatever recorder sits behind them.
The industrial computer does not replace the PoE switch; it replaces the NVR appliance, the subscription, and usually the analytics server. The architecture is two small boxes — or one, on the rare machine with PoE+ ports — that record unattended from −25 °C to +75 °C, reboot themselves after power dips, and leave the software choice open. For a site
