Skip to content

Device Energy + Storage Optimization, 2026-04-21

Companion to frigate-reolink-optimization-2026-04-21.md. Measured from UDev, Finn (192.168.86.67), Frigate CT 108. All numbers captured 2026-04-21 ~17:00 UTC.


TL;DR

Finn is already efficient (~70W). The biggest lever is swapping Frigate's detector from CPU to OpenVINO (iGPU), frees ~15W sustained and a full CPU core, no hardware needed. Next lever: kill record.continuous: 5d, cuts NVMe writes by 60%+. Finn has no UPS and 22 unsafe shutdowns on the boot drive, add one before a bad summer brownout takes down the fleet.

Storage-wise, the workspace NVMe is healthy (0% wear), but /mnt/seagate (a 7.3 TB Seagate sdc2) is returning I/O errors on directory listings, that's an uninvestigated zombie mount worth cleaning up separately.


Per-Machine Power Profile

Best-effort from live data and prior measurements (no power meter at the wall right now, so wall-draw numbers come from 2026-04-03 session history + RAPL sampling + vendor typical values).

Device Idle Typical Peak Source 24/7?
Finn (MS-01, i9-13900H, 32GB DDR5) ~48-50 W ~70 W (Frigate CPU detection) ~95 W (Plex transcode + Frigate + NFS) daily-log 2026-04-03 (wall-meter) yes
↳ Finn (after OpenVINO fix) ~48-50 W ~55-60 W ~80-85 W modelled from -75% of 1 core detector yes
Vector (Ryzen 9 9950X + RTX 5070, 64 GB) ~90-130 W 180-250 W (editing) 500-600 W (gaming/render) vendor + PSU rail typical no
UDev VM (4 vCPU, 12 GB alloc, on Finn) ~0-2 W share 3-8 W share 15-20 W share estimated from vCPU load 0.23 avg yes
Plex LXC (5 vCPU, 5 GB on Finn) ~1-3 W share 5-15 W (streaming direct) 30-40 W (single iGPU transcode) share of Finn power budget yes
n8n LXC (2 vCPU, 1 GB on Finn) ~0-1 W share 1-2 W 5 W very idle yes
Frigate LXC (4 vCPU, 4 GB on Finn) , 12-18 W share (CPU detector) , 75% of 1 P-core → ~15W yes
↳ Frigate (after OpenVINO fix) , 2-3 W share 5-8 W detector drops to 5-8% of 1 core yes
Reolink Floodlight Pro PoE @ cam 5-7 W 8-12 W 14-15 W (IR + flood on) 802.3at class 4; typical per Reolink data sheet yes
Home Assistant VM ~1-2 W share 2-4 W 6 W very idle yes
media-server LXC + Arr stack ~2-3 W share 3-8 W 20 W (download spike + unpack) , yes
AdGuard + Immich + biz-apps ~1-2 W each 2-5 W 10 W (Immich ML) , yes
Seagate 26TB HDD ~5 W (idle spin) 7-9 W (active) 11 W (seek) ST26000NM-3WE103 spec yes
Seagate 7.3TB (sdc2, /mnt/seagate) ~5-7 W , , I/O error on directory read, should unmount if unused unknown

Finn thermal sanity

Sensor Current Thermal headroom
CPU cores (coretemp) 70 °C i9-13900H Tjmax = 100 °C; plenty of room
NVMe 0 (WD SN850X 8TB) 49 °C (probe 1: 61 °C) SN850X throttles at 82 °C; fine
NVMe 1 (Kingston 1TB boot) 48 °C fine
ACPI zone 27 °C fine

CPU governor is performance + turbo enabled, kept from 2026-04-03 tuning session where performance-tuning-back-to-powersave was ruled not worth it (~$1.50/mo savings for real perf loss). Leave as-is.


Storage State (Measured)

Device inventory on Finn

Dev Model Capacity Filesystem Mount Used Role
nvme0n1 WD_BLACK SN850X 8000GB 7.3 TB ext4 /mnt/pve/workspace 3.1 TB (45%) workspace hot tier
nvme1n1 Kingston OM8TAP41024K1 (OEM) 953 GB LVM (boot + LVM-thin pool) / + container disks 100 GB of 94 GB root + ~200 GB thin pool boot + LVM-thin
sda Seagate ST26000NM000C 23.6 TB XFS /mnt/storage 16 TB (66%) media + backups cold tier
sdc2 Unknown Seagate (7.3 TB) 7.3 TB , /mnt/seagate 5.5 TB (75%) ⚠ I/O errors, investigate

NVMe SMART: Workspace (WD SN850X 8TB)

Metric Value Notes
Percentage Used 0 % new drive, no wear
Available Spare 100 %
Data Units Written 12.35 TB since drive install
Power On Hours 1064 h (44 d) roughly matches Finn uptime history
Unsafe Shutdowns 7
Temperature 49 °C
Media/Data Integrity Errors 0
TBW rating ~4800 TB (8TB SN850X 0.3 DWPD × 5y × 8 TB × 365) consumer-grade DWPD
Current write rate 61.5 GB/day sustained (Finn /proc/diskstats since boot, 40d)
Lifetime at current rate ~215 years effectively infinite for this workload

No endurance concern even at 3-camera scale (projected 170 GB/day after tiering = ~77 year lifetime).

NVMe SMART: Boot (Kingston OM8TAP41024K1-A00)

Metric Value Notes
Percentage Used 1 % slowly wearing
Available Spare 100 %
Data Units Written 3.21 TB
Power Cycles 45
Unsafe Shutdowns 22 ⚠ meaningful, see UPS section
Temperature 48 °C
Current write rate ~43 GB/day (swap churn + LVM-thin container disks)
TBW rating ~600 TB (OEM OM8 estimate) no official Kingston published spec for this OEM SKU
Lifetime at current rate ~38 years fine

The 22 unsafe shutdowns in 45 power cycles is the interesting datum. About half the reboots were not clean. That matches a pattern of wall-power blips, crash reboots, or force-offs.

Write I/O since last Finn boot (40 days)

nvme0n1 (workspace SN850X):  2.46 TB written → 61.5 GB/day
nvme1n1 (boot Kingston):     1.72 TB written → 43 GB/day
sda     (Seagate 26TB):     10.36 TB written → 260 GB/day

Where that 260 GB/day to the HDD goes: - Nightly workspace→HDD rsync (2am) writes new/changed workspace files, currently likely 50-100 GB/day (Frigate recordings dominate) - Plex metadata + downloads landing + library moves (Sonarr/Radarr) - Immich photo ingest + ML feature extraction

Where the 61.5 GB/day to SN850X goes: - Frigate recordings: ~57 GB/day (one cam) - n8n + immich + HA database writes: <1 GB/day - Workspace active file edits: <5 GB/day

So Frigate is ~92 % of your NVMe write volume. Killing record.continuous: 5d and dropping to motion-only would cut daily NVMe writes by ~60% → ~25 GB/day for one camera, ~75 GB/day at 3 cameras.


Memory Pressure on Finn

Layer Allocated In use Comment
Total physical RAM 32 GB , ,
Sum of all container/VM allocations 33.3 GB , intentionally over-provisioned
Currently used (Finn free -h) , 20 GB
buff/cache , 10 GB
Available , ~10 GB plenty
Swap 8 GB 7 GB (88%) ⚠ swap is hot

7 GB of swap in use is not great, that's 7 GB of forced cold-pages living on Kingston NVMe, causing continuous background write churn. Candidates for memory reclaim:

  1. UDev VM (103) allocated 12 GB, internally using 2.8 GB. Drop it to 8 GB, frees 4 GB back to Finn instantly.
  2. Plex LXC allocated 5 GB, typical usage ~2 GB. Drop to 3 GB. Frees 2 GB.
  3. qBittorrent inside media-server LXC is RSS 300 MB with VIRT 306 GB (virtual only, not real). Not a real concern.

Expected outcome: swap usage drops to near-zero, Kingston boot NVMe writes fall ~20 GB/day, load-average spikes stop (15m load of 41 earlier is likely memory-pressure-driven I/O waits).


UPS / Clean Shutdown Posture

There is no UPS. Confirmed by: - No apcupsd/nut/upsc installed on Finn - No UPS USB device on lsusb (only ASMedia SATA bridge, CP210x Zigbee, MediaTek WiFi) - 22 unsafe shutdowns on the boot NVMe over 45 power cycles

For a homelab of this scope (Proxmox + Plex + cameras + HA + business automation) running 24/7, this is the single biggest reliability gap. Recommendation:

Option Capacity Runtime at ~100 W USB/NUT? Price Notes
CyberPower CP1500PFCLCD 1500 VA / 1000 W ~30 min ✅ USB HID ~$200 pure sine wave, fanless, supported by nut
APC Back-UPS Pro BR1500MS2 1500 VA / 900 W ~25 min ✅ USB $225 good alt, heavier
Eaton 5S 1500 1500 VA / 900 W ~25 min $240 solid
CyberPower CP1350PFCLCD 1350 VA / 810 W ~25 min $170 smaller budget

Integration plan: 1. Plug Finn + camera PoE switch + router + switch into UPS. 2. On Finn: apt install nut nut-client nut-server, configure /etc/nut/ups.conf with usbhid-ups, /etc/nut/upsd.conf, /etc/nut/upsmon.conf. 3. On every LXC/VM: nut-client monitoring the Finn NUT server → auto-shutdown at 3 minutes remaining. 4. Expose ups.status via nut-cgi → MQTT → HA dashboard (battery %, runtime, events).

Ongoing UPS power draw: ~3-8 W for the UPS electronics themselves (amortized over preventing boot-drive corruption and wasted Frigate SSD writes during unclean reboots, it's a net win).


Storage Tiering Recommendation

Current pattern (good): - NVMe workspace (hot): video projects, Google Drive cache, camera recordings, active brand files - HDD storage (warm/cold): Plex library, photos archive, nightly workspace backup, downloads staging

Proposed refinements:

Tier changes

Data Current Recommended Why
Frigate recordings older than 7 days on NVMe up to 30 days Daily move NVMe→HDD via cron NVMe is overkill for cold archive; HDD plenty fast for occasional scrubbing
Frigate live/rolling 7d (continuous portion) on NVMe delete continuous, motion-only bulk of savings
Plex metadata appdata on HDD move to NVMe under /mnt/pve/workspace/plex-metadata Plex responsiveness (library browse) dramatically better on NVMe
Immich originals on HDD /mnt/storage/photo-storage keep (correct) big cold archive
Immich ML/thumbnails in LXC LVM move to NVMe hot tier, thumbnail generation + face recog runs hot
workspace-backup-versions/ on HDD keep, but prune older than 90 days currently unbounded? check size

Proposed Frigate tiering cron on Finn

# /etc/cron.d/frigate-archive
# Daily at 03:30: move recordings >7d from NVMe to HDD archive
30 3 * * *  root  find /mnt/pve/workspace/security-cameras/recordings -mindepth 1 -maxdepth 1 -type d -mtime +7 -exec mv {} /mnt/storage/security-cameras-archive/ \;

(Frigate won't complain, it expects its own folder structure, and it prunes by SQL date lookup against what it knows. Better: use Frigate's own record.preserve setting, or mount a second location.)

Actually, the cleaner path is to set Frigate's storage location to a union mount or use record.export.timelapse with a separate archive target. Deep enough to warrant its own task, don't DIY-move files under Frigate's feet without reading docs first.


Zombie Mount, /mnt/seagate

During investigation, ls /mnt/seagate/ returned Input/output error. df -h still reports the mount as 7.3 TB (5.5 TB used), but lsblk does not list an sdc device.

Interpretation: The drive behind /dev/sdc2 has disconnected (physical/USB-SATA issue) or failed. The filesystem mount is orphaned. Data that was on it may be inaccessible and this was not documented anywhere in the fleet docs.

Action needed (separate task, not blocking):

ssh finn 'ls /dev/sdc* 2>&1; cat /proc/mounts | grep seagate; dmesg -T | grep -iE "sdc|usb disk" | tail -30'
ssh finn 'umount /mnt/seagate'   # if truly gone
# or — if drive re-scans: systemctl restart udev or replug enclosure

Whatever was on that drive (flagged as 5.5 TB of something) deserves a look, it's not documented in architecture.md and wasn't in the backup rotation.


Concrete Savings Summary

Change Watts (sustained) NVMe writes/day NVMe capacity Reliability
Switch detector CPU → OpenVINO iGPU –15 W , , ,
Kill record.continuous: 5d –1 to –2 W –30 to –40 GB/day (1 cam) +60% free ,
Tier Frigate recordings >7d to HDD –2 to –3 W , frees ~700-900 GB ,
Trim UDev RAM 12 GB → 8 GB small (less swap pressure) –10-20 GB/day (swap churn) , load-avg stabilizes
Trim Plex RAM 5 GB → 3 GB small small , same
Drop bird/bicycle from tracking –2 W (less detector load) slightly less sqlite churn , fewer alarm-spam events
Install CyberPower CP1500 + NUT +3-5 W (UPS electronics) , , prevents next unsafe shutdown
Net sustained –15 to –20 W –40-60 GB/day +700 GB hot-tier headroom dramatically improved

Annual electricity savings at ~17 W × 24 × 365 × $0.12/kWh ≈ $18/yr, small in absolute dollars, but the CPU core freed up matters more than the watts. The disk-write savings free headroom for the 2 incoming cameras and extend NVMe life by ~2-3× (not a worry now, but good hygiene).


Priority Queue (do-this-next)

  1. Apply OpenVINO detector config (Fix 1 in Frigate report), 10 min, reversible
  2. Drop record.continuous (Fix 2 in Frigate report), 2 min
  3. Trim UDev RAM to 8 GB, ssh finn 'qm set 103 -memory 8192' then reboot UDev at next safe window
  4. Order UPS (CyberPower CP1500PFCLCD), ~$200 one-time
  5. Investigate /mnt/seagate zombie mount, figure out what's on the failed drive before umount
  6. Rotate Reolink + MQTT passwords out of config.yml (Fix 4 in Frigate report), 20 min
  7. Defer Coral TPU until you actually need > 6 cameras or want YOLOv8-class models

Measurements captured live 2026-04-21 by cam-energy specialist session. Power numbers on Finn rely on the 2026-04-03 wall-meter session for absolute anchoring; relative deltas are derived from RAPL and CPU load. [Claude Code]