29  Wi-Fi Power Consumption

In 60 Seconds

Wi-Fi was designed for laptops and phones, not battery-powered sensors – TX current (200-300 mA) is 10-20x higher than BLE (10-15 mA), and connection overhead (2-10 seconds) dominates power consumption at 98% of total energy per cycle. An ESP32 temperature sensor sending 100 bytes every 15 minutes on a 3000 mAh battery lasts only 7.6 months because each Wi-Fi connection costs 0.133 mAh while actual data transmission costs just 0.00028 mAh. Five optimization strategies extend battery life: batch transmissions (12x improvement), static IP instead of DHCP (38% savings), reduced TX power (up to 60% current reduction), light sleep between packets (25x less power), and Wi-Fi 6 TWT which negotiates scheduled wake times to achieve 5+ year battery life for low-duty-cycle sensors. The protocol decision matrix shows Wi-Fi fits mains-powered high-bandwidth devices, while BLE/Zigbee/LoRaWAN serve battery-powered sensors better.

  • Wi-Fi Power States: Active TX (150-300 mA), Active RX (50-100 mA), Modem Sleep (15-25 mA), Light Sleep (1-5 mA), Deep Sleep (5-50 µA)
  • DTIM (Delivery Traffic Indication Map): Beacon field indicating buffered multicast/broadcast data; client must wake for DTIM beacon intervals
  • U-APSD (Unscheduled Automatic Power Save Delivery): Wi-Fi standard for triggered power save; client wakes on demand rather than at fixed DTIM intervals
  • TWT (Target Wake Time): Wi-Fi 6 feature scheduling exact wake times with AP; reduces power consumption by 90%+ vs legacy power save
  • Connection Establishment Energy: Energy to scan, associate, and obtain IP address; 10-100 mJ per connection depending on scan duration
  • DTIM Interval: How often the AP sends DTIM beacons (every 1-10 beacons); longer DTIM interval allows deeper client sleep
  • Modem Sleep: Radio sleeps between DTIM intervals while maintaining association; CPU remains active; moderate power saving
  • Deep Sleep vs Reconnect: Deeper sleep saves more power but requires full Wi-Fi reconnection after waking; tradeoff depends on reporting interval

29.1 Sensor Squad: Why Wi-Fi Is a Battery Hog

“Wi-Fi uses SO much power!” groaned Bella the Battery. “When I power a Wi-Fi sensor, 98% of my energy goes to just CONNECTING, not sending data. It is like driving 100 miles to deliver a single letter!”

“Here is the math,” said Max the Microcontroller. “Connecting to Wi-Fi takes 3 seconds at 160 mA. But sending 100 bytes of sensor data takes only 5 milliseconds at 200 mA. The connection is 600 times longer than the actual message!”

“So how do we save battery?” asked Sammy the Sensor. “FIVE tricks! First, BATCH your readings – send 12 at once instead of one at a time. Second, use a STATIC IP so you skip the DHCP dance. Third, turn down your TX POWER if the router is nearby. Fourth, use LIGHT SLEEP between packets. Fifth, if you have Wi-Fi 6, use TWT to schedule wake times!”

“With ALL those tricks,” said Lila the LED, “a sensor can last YEARS instead of months. But if power is really critical, consider BLE or LoRaWAN – they were DESIGNED for battery sensors and use 10-20x less energy per transmission!”

Prerequisites: Wi-Fi Standards Evolution | Wi-Fi Frequency Bands

This enables: Wi-Fi Deployment Planning | Power Management Strategies

29.2 Learning Objectives

By the end of this chapter, you should be able to:

  • Calculate daily energy consumption and battery life for Wi-Fi IoT devices using connection overhead, transmission, and sleep current values
  • Compare Wi-Fi power profiles (TX current, RX current, sleep current, connection time) against BLE, Zigbee, and LoRaWAN for specific IoT use cases
  • Apply five power optimization strategies (batching, static IP, TX power reduction, light sleep, TWT) to extend Wi-Fi sensor battery life by quantified margins
  • Evaluate Wi-Fi 6 TWT requirements, constraints, and battery life improvements to determine suitability for a given deployment
  • Justify protocol selection decisions for battery-powered IoT sensors using a power-budget analysis and decision matrix
  • Design a complete power budget for a battery-operated Wi-Fi sensor that meets a specified target battery life

Wi-Fi is power-hungry compared to protocols like Bluetooth or Zigbee. A Wi-Fi radio can drain a small battery in hours. This chapter explains why Wi-Fi uses so much power and covers techniques to reduce consumption – sleep modes, duty cycling, and the new Target Wake Time feature in Wi-Fi 6.

29.3 The Wi-Fi Power Challenge

Wi-Fi was designed for laptops and phones with large batteries and frequent charging. For IoT sensors that need to run for years on batteries, Wi-Fi presents significant challenges:

Factor Wi-Fi BLE Zigbee LoRaWAN
TX Current 200-300 mA 10-15 mA 25-35 mA 40-120 mA
RX Current 100-150 mA 10-15 mA 20-25 mA 10-15 mA
Sleep Current 10-150 uA 1-2 uA 1-2 uA 1-2 uA
Connection Time 2-10 sec 20-50 ms 20-50 ms <1 sec
Battery Life (sensor)* 3-12 months 2-5 years 2-5 years 5-10 years

*Approximate, sending 100 bytes every 15 minutes on 3000 mAh battery

Key Insight

Wi-Fi’s power problem isn’t the transmission - it’s the connection overhead.

A Wi-Fi device sending 100 bytes: - BLE: Wake up, TX for 2ms, sleep = ~0.02 mAh - Wi-Fi: Wake up, associate (2-5s), TX for 2ms, sleep = ~0.15-0.4 mAh

Wi-Fi uses 10-20x more energy per transmission for the same payload!

29.4 Wi-Fi Power States

Understanding power states is crucial for optimization:

Diagram showing Wi-Fi radio power states and transitions from Deep Sleep at 10 uA through Light Sleep, Modem Sleep, Active RX at 100-150 mA, to Active TX at 200-300 mA with transition times and current draw at each state
Figure 29.1: Wi-Fi power states from Deep Sleep (10 uA) through Active mode (200 mA)

29.4.1 Power State Details (ESP32 Example)

State Current Description Wake Time
Deep Sleep 10 uA CPU off, Wi-Fi off, RTC only 100-200 ms
Light Sleep 0.8-2 mA CPU paused, Wi-Fi tracking beacons 1-10 ms
Modem Sleep 15-20 mA CPU active, Wi-Fi listening Instant
Active RX 100-150 mA Receiving data -
Active TX 200-300 mA Transmitting data -
Connecting 150-200 mA Scanning + associating 2-10 sec

29.5 Calculating Battery Life

29.5.1 Step-by-Step Calculation

Scenario: ESP32 temperature sensor sending 100 bytes every 15 minutes

Why connection overhead dominates Wi-Fi power consumption:

Given a sensor transmitting every \(T = 15\) minutes (96 times/day), the energy cost breaks down as:

Deep sleep energy per day: \[ E_{\text{sleep}} = I_{\text{sleep}} \times t_{\text{sleep}} = 0.01 \text{ mA} \times 23.87 \text{ h} = 0.24 \text{ mAh/day} \]

Connection energy per transmission: \[ E_{\text{connect}} = I_{\text{connect}} \times \frac{t_{\text{connect}}}{3600} = 160 \text{ mA} \times \frac{3 \text{ s}}{3600 \text{ s/h}} = 0.133 \text{ mAh} \]

Daily connection cost: \(0.133 \times 96 = 12.8\) mAh/day

Transmission energy per 100 bytes: \[ E_{\text{tx}} = 200 \text{ mA} \times \frac{0.005 \text{ s}}{3600 \text{ s/h}} = 0.00028 \text{ mAh} \]

Daily transmission cost: \(0.00028 \times 96 = 0.027\) mAh/day (negligible!)

Total daily consumption: \[ E_{\text{total}} = 0.24 + 12.8 + 0.027 = 13.07 \text{ mAh/day} \]

Battery life: \[ \text{Days} = \frac{3000 \text{ mAh}}{13.07 \text{ mAh/day}} = 230 \text{ days} \approx 7.6 \text{ months} \]

Key insight: Connection overhead (12.8 mAh) is 460× larger than actual data transmission (0.027 mAh). This is why optimizing TX power or data rate has minimal battery impact—you must reduce connection events instead.

Power Budget Calculation:

GIVEN:
- Battery: 2 x AA (3000 mAh @ 3V)
- Transmission interval: 15 minutes (96 times/day)
- Payload: 100 bytes
- Wi-Fi module: ESP32 (Wi-Fi 4)

STEP 1: Deep Sleep Time
- 23 hours 52 minutes per day in deep sleep
- Current: 10 uA
- Daily usage: 23.87h x 0.01mA = 0.24 mAh/day

STEP 2: Connection Overhead
- Time to connect: 3 seconds average
- Current during connect: 160 mA
- Per connection: 160mA x 3s / 3600 = 0.133 mAh
- Daily (96 connections): 0.133 x 96 = 12.8 mAh/day

STEP 3: Data Transmission
- TX time: 5 ms per 100 bytes
- Current: 200 mA
- Per transmission: 200mA x 0.005s / 3600 = 0.00028 mAh
- Daily: 0.00028 x 96 = 0.027 mAh/day (negligible!)

STEP 4: Total Daily Consumption
- Deep sleep: 0.24 mAh
- Connecting: 12.8 mAh
- Transmitting: 0.03 mAh
- TOTAL: 13.07 mAh/day

STEP 5: Battery Life
- Battery: 3000 mAh
- Daily usage: 13.07 mAh
- Battery life: 3000 / 13.07 = 230 days (7.6 months)
Key Observation

98% of power is spent on connection overhead, not data transmission!

  • Connection: 12.8 mAh/day (98%)
  • Actual TX: 0.03 mAh/day (0.2%)
  • Sleep: 0.24 mAh/day (1.8%)

Optimization strategy: Reduce connection events, not transmission time.

Estimate battery life for your Wi-Fi IoT sensor by adjusting the parameters below.

29.6 Wi-Fi 6 TWT: The Battery Saver

29.6.1 How TWT Changes the Equation

Without TWT (Wi-Fi 4/5):

Device must wake for every beacon (every 100ms typically)
- Beacon wakeups: ~864,000/day
- Even with DTIM skip, still ~100,000 wakeups/day
- Each wakeup: 1-5 ms at 15-20 mA
- Idle listening overhead: 5-15 mAh/day

With TWT (Wi-Fi 6):

Device negotiates specific wake times with AP
- Wake only when scheduled (e.g., 4x/day)
- AP buffers all data until wake window
- No beacon listening required between sessions
- Idle overhead: <0.1 mAh/day

29.6.2 TWT Battery Impact Example

Scenario Without TWT With TWT Improvement
Sensor (4 readings/day) 6 months 5+ years 10x
Door sensor (event-based) 3 months 2+ years 8x
Thermostat (hourly) 4 months 3 years 9x
Camera (continuous) Same Same 0x
TWT Requirements

TWT only works when:

  1. Access Point supports Wi-Fi 6 (802.11ax)
  2. IoT device has Wi-Fi 6 chip
  3. Both have TWT enabled in firmware
  4. Device workload allows scheduled wake times

Current ESP32 TWT Support:

  • ESP32 (original): No Wi-Fi 6 - no TWT
  • ESP32-S2, S3, C3: No Wi-Fi 6 - no TWT
  • ESP32-C6: Wi-Fi 6 - TWT supported!

29.7 Protocol Comparison for Battery IoT

29.7.1 Detailed Power Comparison

Bar chart comparing power consumption across Wi-Fi, BLE, Zigbee, and LoRaWAN protocols showing TX current, RX current, sleep current, and connection time for each protocol
Figure 29.2: Power consumption comparison: Wi-Fi vs BLE vs Zigbee vs LoRaWAN

29.7.2 Decision Matrix

Requirement Best Protocol Avoid
Battery life >2 years BLE, Zigbee, LoRaWAN Wi-Fi (unless Wi-Fi 6 TWT)
High bandwidth (>1 Mbps) Wi-Fi LoRaWAN, Sigfox
Long range (>1 km) LoRaWAN, Sigfox Wi-Fi, BLE
Low latency (<100 ms) Wi-Fi, BLE LoRaWAN
Mesh networking Zigbee, Thread Wi-Fi (without mesh)
Existing infrastructure Wi-Fi LoRaWAN (needs gateway)

29.8 Power Optimization Strategies

29.8.1 Strategy 1: Batch Transmissions

Instead of sending each reading immediately, batch multiple readings:

BEFORE (send every 5 min):
- 288 connections/day
- 288 x 0.133 mAh = 38.3 mAh/day

AFTER (batch hourly, 12 readings at once):
- 24 connections/day
- 24 x 0.133 mAh = 3.2 mAh/day

IMPROVEMENT: 12x better battery life!

29.8.2 Strategy 2: Static IP Instead of DHCP

DHCP adds 0.5-2 seconds to connection time:

BEFORE (DHCP):
- Connection time: 4 seconds
- Energy: 4s x 160mA = 0.178 mAh per connection

AFTER (Static IP):
- Connection time: 2.5 seconds
- Energy: 2.5s x 160mA = 0.111 mAh per connection

IMPROVEMENT: 38% energy savings

29.8.3 Strategy 3: Reduce TX Power

Many devices default to maximum TX power. Reducing it saves energy:

ESP32 TX Power Settings:
- +20 dBm (max): 200 mA
- +15 dBm: 160 mA (-20%)
- +10 dBm: 120 mA (-40%)
- +5 dBm: 80 mA (-60%)

Trade-off: Lower power = shorter range
Use minimum power that maintains reliable connection

29.8.4 Strategy 4: Light Sleep Between Transmissions

For devices sending multiple packets per session:

// Instead of staying in active mode between packets
void sendMultipleReadings() {
    for (int i = 0; i < 10; i++) {
        sendReading(i);
        // Bad: busy wait
        // delay(100);  // 20 mA for 100ms

        // Good: light sleep
        esp_light_sleep_start();  // 0.8 mA for 100ms
        // 25x less power between packets!
    }
}

29.8.5 Strategy 5: Use Wi-Fi 6 TWT (When Available)

For ESP32-C6 or other Wi-Fi 6 devices:

// Enable TWT in ESP32-C6
wifi_config_t wifi_config = {
    .sta = {
        // ... SSID and password
        .twt = {
            .twt_enable = true,
            .twt_wake_interval = 300,  // Wake every 5 minutes
            .twt_wake_duration = 5,    // Stay awake 5 TUs
        }
    }
};

29.9 Knowledge Check

29.10 Worked Example: Power Budget Analysis

Scenario: Design a battery-powered Wi-Fi environmental sensor with 2-year target battery life.

Requirements:

  • Temperature + humidity reading every 30 minutes
  • 2 x AA batteries (3000 mAh)
  • Wi-Fi 4 module (no TWT)
  • Target: 2 years minimum battery life

Analysis:

STEP 1: Power Budget (2 years)
- Available: 3000 mAh
- Duration: 730 days
- Daily budget: 3000 / 730 = 4.1 mAh/day

STEP 2: Current Wi-Fi Design (every 30 min)
- Transmissions: 48/day
- Per transmission (3s connect + 5ms TX):
  - Connect: 3s x 160mA = 480mAs = 0.133 mAh
  - TX: 0.005s x 200mA = 1mAs = 0.0003 mAh
  - Total: 0.133 mAh
- Daily: 48 x 0.133 = 6.4 mAh/day

PROBLEM: 6.4 mAh/day > 4.1 mAh budget!
Expected life: 3000/6.4 = 469 days (1.3 years)

Solution Options:

Option Change New Daily Usage Battery Life
Baseline Every 30 min 6.4 mAh 1.3 years
Batch hourly 24 TX/day 3.2 mAh 2.6 years
Batch 2-hourly 12 TX/day 1.6 mAh 5.1 years
Use BLE instead N/A 0.3 mAh 27 years
Wi-Fi 6 + TWT Scheduled wake 1.2 mAh 6.8 years

Recommendation:

  • For Wi-Fi constraint: Batch readings every 2 hours
  • Better solution: Use BLE beacon or Zigbee for this use case
  • If Wi-Fi required: Upgrade to Wi-Fi 6 device with TWT

29.11 Case Study: Hotel Chain Migrates from Wi-Fi to BLE for Room Sensors

Background: A 300-room hotel deployed ESP32-based Wi-Fi temperature and humidity sensors in 2023 to optimize HVAC energy usage. Each sensor reported every 5 minutes via Wi-Fi to a central building management system.

The Problem:

Original deployment:
  Sensors per room: 1 (ESP32 + DHT22 + 2xAA batteries)
  Reporting interval: 5 minutes (288 reports/day)
  Connection overhead per report: 0.133 mAh (3s x 160mA)
  Daily consumption: 288 x 0.133 = 38.3 mAh/day
  Battery life: 3000 / 38.3 = 78 days (2.6 months)

Maintenance cost:
  Battery changes per year per sensor: 4.7
  Battery cost: $1.50 per pair of AA
  Labor per change: 10 minutes x $25/hour = $4.17
  Annual cost per sensor: 4.7 x ($1.50 + $4.17) = $26.64
  Annual cost (300 sensors): $7,993/year

  Plus 1,410 battery changes per year disrupted housekeeping schedules

The Migration:

The hotel replaced Wi-Fi sensors with BLE 5.0 beacons (Nordic nRF52840) that advertise temperature/humidity data. BLE-to-IP gateways (1 per floor, 10 total) bridge data to the BMS.

BLE deployment:
  Beacon advertising interval: 5 minutes
  TX current: 8 mA for 2ms per advertisement
  Sleep current: 1.5 uA
  Daily consumption:
    TX: 288 x (8mA x 0.002s / 3600) = 0.0013 mAh/day
    Sleep: 24h x 0.0015mA = 0.036 mAh/day
    Total: 0.037 mAh/day
  Battery life: 3000 / 0.037 = 81,081 days (222 years theoretical)
  Practical life: 5-7 years (battery self-discharge limited)

Cost Comparison (5-Year TCO for 300 Sensors):

Cost Item Wi-Fi (ESP32) BLE (nRF52840)
Sensor hardware $3,000 ($10 each) $4,500 ($15 each)
Gateway hardware $0 (existing APs) $1,500 ($150 x 10)
Batteries (5 years) $2,250 $450 (one change)
Labor (battery changes) $18,750 $1,250 (one change)
Network load Significant (288 associations/day/sensor) Negligible (passive scan)
5-Year Total $24,000 $7,700

Savings: $16,300 (68% reduction)

Key Insight: The hotel’s original decision was driven by familiarity (“everyone knows Wi-Fi”) rather than technical fit. For small, infrequent sensor payloads, Wi-Fi’s connection overhead makes it 100x less power-efficient than BLE. The gateway cost ($1,500) paid for itself in 3.5 months through reduced battery labor alone.

Common Mistake: Ignoring Connection Overhead in Power Budgets

Scenario: An engineer designs a Wi-Fi weather station to run on 2× AA batteries (3000 mAh). The sensor reports every 10 minutes. The engineer calculates power budget based ONLY on transmission time.

Flawed calculation (transmission time only):

Data transmission: 200 bytes at 54 Mbps
- TX time: 200 bytes × 8 bits / 54 Mbps = 0.03 ms
- Current: 200 mA
- Energy per TX: 200 mA × 0.00003 s / 3600 = 0.0000017 mAh

Transmissions per day: 144 (every 10 min)
Daily TX energy: 144 × 0.0000017 = 0.00024 mAh

Battery life estimate: 3000 / 0.00024 = 12.5 million days (!!)

Engineer concludes: “Battery will last forever! Wi-Fi is perfect!”

Reality check - actual power consumption:

ACTUAL cycle for each 10-minute interval:

1. Deep sleep: 9 minutes 55 seconds at 10 µA
   Energy: (9.92 min / 60 min/h) × 0.01 mA = 0.00165 mAh

2. Wake up and associate: 3 seconds at 160 mA
   Energy: 3 s × 160 mA / 3600 = 0.133 mAh

3. DHCP request/response: 0.5 seconds at 120 mA
   Energy: 0.5 s × 120 mA / 3600 = 0.017 mAh

4. Transmit data: 0.03 ms at 200 mA
   Energy: 0.00003 s × 200 mA / 3600 = 0.0000017 mAh (negligible!)

5. Wait for ACK: 5 ms at 120 mA
   Energy: 0.005 s × 120 mA / 3600 = 0.00017 mAh (negligible!)

6. Disassociate: 0.2 seconds at 120 mA
   Energy: 0.2 s × 120 mA / 3600 = 0.0067 mAh

Total per cycle: 0.00165 + 0.133 + 0.017 + 0.0067 = 0.158 mAh
Daily consumption: 144 cycles × 0.158 = 22.8 mAh/day

ACTUAL battery life: 3000 / 22.8 = 132 days (4.4 months)

Breakdown of energy consumption:

Component Energy per cycle % of total
Deep sleep 0.00165 mAh 1.0%
Wi-Fi association 0.133 mAh 84.2%
DHCP 0.017 mAh 10.8%
Actual data TX 0.0000017 mAh 0.001%
ACK wait 0.00017 mAh 0.1%
Disassociation 0.0067 mAh 4.2%

Over 99% of energy goes to connection overhead, not data transmission!

Fixes to extend battery life:

Optimization Daily consumption Battery life Improvement
Baseline (above) 22.8 mAh 132 days –
Static IP (skip DHCP) 20.3 mAh 148 days +12%
Reduce TX power (-6 dBm) 18.7 mAh 160 days +21%
Batch 6 readings (hourly) 3.8 mAh 789 days +498%
Use BLE instead 0.26 mAh 11,538 days (31 years) +8,644%

Key Lesson: For battery-powered sensors, the data transmission itself is almost free. Connection establishment and association overhead dominate power consumption. Either batch aggressively, use static IP + persistent connection, or choose a protocol designed for battery operation (BLE, Zigbee, LoRaWAN).

29.12 Wi-Fi vs Alternatives: When to Choose What

29.12.1 Summary Flowchart

Flowchart guiding IoT protocol selection based on power source, bandwidth requirements, range needs, and device density, recommending Wi-Fi for mains-powered high-bandwidth devices and BLE, Zigbee, or LoRaWAN for battery-powered sensors
Figure 29.3: Protocol selection flowchart based on power requirements and use case

29.12.2 Quick Reference Table

Use Case Power Source Recommended Avoid
Security camera Mains Wi-Fi 5/6 LPWAN
Smart thermostat Mains/battery Wi-Fi or Zigbee LoRaWAN
Door/window sensor Battery (5+ years) Zigbee, Z-Wave Wi-Fi 4/5
Soil moisture sensor Solar + battery LoRaWAN, BLE Wi-Fi
Wearable fitness Battery (1 week) BLE Wi-Fi
Industrial pressure Mains Wi-Fi 6 -
Smart meter Battery (10 years) LoRaWAN, NB-IoT Wi-Fi, BLE

29.13 Concept Relationships

Understanding how power optimization concepts relate:

Concept Depends On Enables Trade-off
Deep Sleep RTC timer, wake sources 2000x current reduction Wake latency vs power savings
Wi-Fi 6 TWT AP support, negotiation Predictable wake windows Protocol complexity vs beacon elimination
Static IP DHCP reservation 38% connection time savings Configuration vs speed
TX Power Reduction Strong RSSI margin Up to 60% TX savings Range vs power consumption
Data Batching Buffer management Fewer connections Memory vs connection overhead

Common Pitfalls

Wi-Fi module power in transmit state (200 mA) represents only a small fraction of total energy for IoT devices. Association, DHCP, and DNS resolution before the first transmission may consume 100x more energy than the actual data send. Measure the complete cycle from wake to sleep.

DTIM=1 means the device wakes every beacon (102 ms) to check for buffered data. DTIM=10 means waking every 1020 ms. For IoT sensors that initiate all communication (no downlink commands), DTIM=10 reduces average power by ~10x with no functional impact. Always tune DTIM for your traffic pattern.

Devices using deep sleep between measurements must fully reconnect to Wi-Fi after waking. Reconnection (scan + authenticate + associate + DHCP) takes 500 ms - 2 seconds and consumes 1-10 mJ per cycle. For sensors reporting every 10 minutes, reconnection energy dominates total consumption. Use modem sleep or light sleep for reporting intervals under 30 minutes.

AP configuration affects client power consumption. DTIM interval, maximum number of buffered frames, and U-APSD support are AP settings that impact client power. Coordinate AP configuration with IoT device power requirements — client-side optimization is limited without AP cooperation.

29.14 Summary

This chapter covered Wi-Fi power consumption challenges and optimization strategies for IoT:

  • Power Challenge: Wi-Fi TX current (200-300 mA) is 10-20x higher than BLE or Zigbee; connection overhead (2-10 seconds) consumes 98% of energy per cycle while actual data transmission is negligible
  • Power States: ESP32 ranges from deep sleep (10 uA) through light sleep (0.8 mA), modem sleep (15-20 mA), to active TX (200-300 mA); deep sleep provides 2000x current reduction vs modem sleep
  • Battery Life Calculation: A 3000 mAh battery powering an ESP32 sensor every 15 minutes lasts approximately 7.6 months with standard Wi-Fi connection/disconnect cycles
  • Optimization Strategies: Batch transmissions (12x improvement), static IP (38% savings), reduced TX power (up to 60%), light sleep between packets (25x savings), and Wi-Fi 6 TWT (5+ year battery life)
  • Wi-Fi 6 TWT: Target Wake Time negotiates scheduled wake windows, eliminating beacon listening and achieving 8-10x battery improvement for low-duty-cycle sensors – requires both AP and device to support Wi-Fi 6
  • Protocol Decision: Wi-Fi suits mains-powered high-bandwidth devices; BLE/Zigbee serve battery devices needing 2-5 year life; LoRaWAN handles long-range battery sensors needing 5-10 year life

29.15 See Also

For deeper exploration of related topics:

29.16 What’s Next

Chapter Focus
Wi-Fi Deployment Planning Capacity planning, common deployment mistakes, and real-world case studies for Wi-Fi IoT implementations
Wi-Fi Implementation: Power Optimization ESP32 code examples for deep sleep, light sleep, and TWT configuration
Wi-Fi 6 Dense Deployment Review TWT configuration details and multi-user efficiency in dense environments