Chapter 13: Real-World Case Studies and Design Patterns

The preceding chapters covered techniques in isolation. This chapter applies them end-to-end in four realistic scenarios: a solar-powered ESP32 weather station, a battery-backed NUC home server, an always-on low-wattage home lab, and a laptop battery longevity regimen.


13.1 Case Study: Solar-Powered ESP32 Weather Station

Goal: A weatherproof outdoor sensor node that measures temperature, humidity, and UV index, uploads readings to an MQTT broker every 15 minutes, and runs indefinitely on a small solar panel with a LiPo battery.

Hardware

Power Budget

Phase Duration Current Energy
Boot + WiFi connect 3.5 s 200 mA 700 mC
Sensors + MQTT publish 0.5 s 60 mA 30 mC
Deep sleep 896 s 18 µA 16.1 mC
Total per cycle 900 s 746 mC

Average current: 746 mC / 900 s = 0.83 mA

Daily energy: 0.83 mA × 24 h = 19.9 mAh/day

A 1 W solar panel at 5 V in a location with 4 peak sun hours produces: (1 W / 5 V) × 4 h = 800 mAh/day — far exceeding the load. Even at 15% panel efficiency and significant cloud cover, the system is energy-positive.

Key Design Decisions

Static IP: Reduces WiFi connect time from ~1500 ms to ~300 ms, saving ~120 mAh/month.

GPIO power switch for sensors: BME280 and VEML6075 are powered off completely between readings via a P-channel MOSFET. Combined standby current is <0.2 µA vs. ~480 µA if left powered.

Fuel gauge monitoring: The MAX17048 reports SoC via I2C. If SoC falls below 20% (cloudy week), the node extends its sleep interval to 60 minutes automatically — saving battery for the next sun exposure.


13.2 Case Study: Battery-Backed NUC Home Server

Goal: A NUC running Home Assistant and a small media server, backed by a UPS, with automatic workload reduction when on battery.

Baseline Measurement

Wall power (Kill-a-Watt): 14.5 W before optimization.

Optimization Steps

  1. BIOS: Enable all C-states, enable ERP, enable Intel Speed Shift → drops to 11.2 W
  2. TLP on AC: CPU governor schedutil, ASPM powersupersave, audio power save → drops to 9.4 W
  3. Service audit: Disabled Avahi, cups, ModemManager, bluetooth → drops to 8.8 W
  4. Disk spindown (HDD media storage): hdparm spindown after 10 minutes → 7.1 W average (disk spun down most of the time)

Final idle power: 7.1 W — saving 7.4 W × 8760 h/year = 64.8 kWh/year ≈ €16–19/year.

Battery Mode Automation

A udev rule detects AC power loss and triggers a systemd target:

# /etc/udev/rules.d/99-power.rules
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/bin/systemctl start on-battery.target"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/bin/systemctl start on-ac.target"

Services bound to on-battery.target include a script that: pauses the media transcoder, sets the CPU governor to powersave, and disables the LED strips. This reduces battery-mode draw to ~4.5 W, extending UPS runtime from 45 minutes to over 2 hours.


13.3 Case Study: 24/7 Low-Wattage Home Lab

Goal: Replace a standard desktop server (80 W idle) with a purpose-built low-power stack for running CI/CD, a personal VPN, and a home DNS resolver.

Hardware Selection

Component Power
Intel NUC 12 Pro (i5-1240P) 6–8 W idle
Raspberry Pi 5 (DNS + VPN) 3–4 W idle
Netgear GS308E switch 2.5 W
Total ~12–15 W

vs. a desktop PC at 80 W idle = 65 W saved × 8760 h = 569 kWh/year ≈ €140–170/year.

Workload Distribution

The WoL automation script runs on the Pi 5, checks for active SSH sessions and Docker containers every 5 minutes, and powers off the NUC if idle. This saves ~7 W × 4 h/day = 10.2 kWh/month.


13.4 Case Study: Laptop Battery Longevity Regimen

Goal: A ThinkPad X1 Carbon used as a primary work machine, kept on AC most of the time. Objective: maintain battery health above 80% SoH for 5+ years.

Configuration

TLP charge thresholds:

START_CHARGE_THRESH_BAT0=40
STOP_CHARGE_THRESH_BAT0=80

This keeps the battery between 40% and 80% SoC while on AC — avoiding the high-stress full-charge state.

Suspend-then-hibernate: After 1 hour suspended, automatically hibernate.

# /etc/systemd/sleep.conf.d/hibernate.conf
[Sleep]
HibernateDelaySec=3600

Runtime optimization: powertop identified the iwlwifi driver generating 80 wakeups/second when scanning for networks. Reducing WiFi scan interval in NetworkManager:

# /etc/NetworkManager/conf.d/wifi-scan.conf
[device]
wifi.scan-rand-mac-address=no

[connection]
wifi.powersave=3

Result after 3 years: battery SoH at 91% (as reported by upower -d | grep capacity), compared to a colleague’s identical machine at 73% with default settings.


13.5 General Design Patterns

Measure → Optimize → Verify: Every optimization should be accompanied by a before/after measurement. Without verification, you cannot know if a change helped, hurt, or did nothing.

Duty cycle is the most powerful embedded lever: Spending 1% of time active and 99% sleeping delivers 99% of the power savings, regardless of how efficient the active code is.

The standby floor matters: Whatever your device draws in its deepest sleep state determines the theoretical minimum for duty-cycle operation. A sensor that draws 1 mA in sleep can never achieve the battery life of one that draws 10 µA, regardless of how efficient the active phase is.

Defaults are pessimistic: BIOS manufacturers, Linux distributions, and framework authors optimize for compatibility and peak performance, not idle power. Every device class in this book showed significant improvement from simply enabling the power features that already exist in the hardware.

Automate to sustain: A one-time optimization degrades over time as software updates, new services, and changed workloads shift the power profile. Build monitoring and alerting (Chapter 12) to catch regressions before they cost months of wasted power.


← Chapter 12: Cross-Platform Power Monitoring and Automation Table of Contents