43  Wi-Fi for IoT: Implementations

In 60 Seconds

This index organizes four Wi-Fi implementation chapters into a progressive learning path: ESP32 Basics covers station mode, access point mode, network scanning, and SmartConfig provisioning; Power Optimization teaches sleep modes (deep sleep at 10 uA vs active at 260 mA) and duty cycle design for multi-year battery life; HTTP and WebSocket covers REST APIs, real-time streaming, and CSMA/CA capacity modeling; and the Comprehensive Lab provides 500+ lines of production-ready code integrating connection management, RSSI monitoring, power cycling, HTTP communication, and mDNS discovery.

The Sensor Squad was ready to build REAL Wi-Fi projects, and they had a learning plan!

“Start with the BASICS,” said Max the Microcontroller. “Learn to connect to Wi-Fi, create your own hotspot, and scan for networks. These are the building blocks for everything else!”

“Then learn about POWER,” added Bella the Battery. “If you do not optimize power, a battery device lasts days instead of years. Deep sleep is the most important trick – it uses 2000 times less current than modem sleep!”

“Next, learn to COMMUNICATE,” said Sammy the Sensor. “HTTP REST APIs let browsers read your data. WebSocket lets you stream data in real-time. And MQTT lets you publish to topics that many subscribers can listen to!”

“Finally, put it ALL TOGETHER in the Comprehensive Lab,” said Lila the LED. “It has 500 lines of production-ready code showing how to handle connection drops gracefully, monitor signal strength, cycle through power modes, and discover other devices on the network!”

43.1 Learning Objectives

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

  • Implement Wi-Fi Connectivity: Program ESP32 devices for Wi-Fi station mode, access point mode, and SmartConfig provisioning
  • Design Reconnection Logic: Construct event-driven connection handlers with exponential backoff and status monitoring
  • Evaluate Power Management Trade-offs: Compare modem sleep, light sleep, and deep sleep modes to justify the optimal strategy for a given battery budget
  • Develop Wi-Fi Applications: Build HTTP REST clients, WebSocket servers, and MQTT publishers over Wi-Fi on ESP32
  • Diagnose Connectivity Failures: Analyze Wi-Fi connection issues using RSSI monitoring, scan results, and debugging tools
  • Assess Network Performance: Calculate duty cycle battery life, model CSMA/CA throughput, and select channel and roaming parameters

43.2 Chapter Overview

This comprehensive guide to Wi-Fi IoT implementations has been organized into focused chapters for easier learning and reference. Each chapter builds on the previous, progressing from basic connectivity to production-ready implementations.

Recommended Learning Path

For Beginners: Start with ESP32 Basics, then proceed through each chapter in order.

For Experienced Developers: Jump directly to the specific topic you need.

For Quick Reference: Use the Comprehensive Lab as a complete code reference.

43.3 Implementation Chapters

43.3.1 ESP32 Wi-Fi Basics

Foundation chapter covering essential Wi-Fi connectivity

  • Station mode configuration and connection handling
  • Access point (Soft AP) mode for device configuration
  • Network scanning and security type detection
  • SmartConfig provisioning for credential setup
  • Raspberry Pi Wi-Fi configuration (nmcli, wpa_supplicant)
  • Python MQTT client example

Key Topics: WiFi.begin(), WiFi.softAP(), WiFi.scanNetworks(), auto-reconnect, SmartConfig

43.3.2 Power Optimization

Extend battery life from days to years

  • Wi-Fi power-saving modes (modem sleep, light sleep, deep sleep)
  • Battery life calculations and duty cycle analysis
  • Static IP optimization to reduce connection time
  • Wi-Fi 6 TWT (Target Wake Time) configuration
  • Troubleshooting common Wi-Fi issues
  • Worked examples with detailed calculations

Key Topics: WiFi.setSleep(), esp_deep_sleep_start(), static IP, TWT, battery life estimation

43.3.3 HTTP and WebSocket Communication

Web protocols for IoT applications

  • HTTP REST API implementation on ESP32
  • HTTP GET/POST client requests
  • WebSocket real-time bidirectional streaming
  • Protocol comparison (HTTP vs WebSocket vs MQTT)
  • Network capacity analysis and throughput modeling
  • CSMA/CA model equations for capacity planning

Key Topics: HTTPClient, WebSocket frames, REST API design, bandwidth optimization

43.3.4 Comprehensive Lab

Production-ready implementation with all features

  • Complete ESP32 code (~500 lines) demonstrating all concepts
  • Robust connection management with exponential backoff
  • RSSI monitoring and signal quality assessment
  • Power mode management and cycling
  • HTTP client communication with error handling
  • mDNS service discovery and advertisement
  • Challenge exercises for deeper learning

Key Topics: State machines, event-driven architecture, mDNS, statistics tracking

43.4 Quick Reference

Topic Chapter Key Functions
Connect to Wi-Fi ESP32 Basics WiFi.begin(), WiFi.status()
Create hotspot ESP32 Basics WiFi.softAP()
Scan networks ESP32 Basics WiFi.scanNetworks()
Enable sleep Power Optimization WiFi.setSleep()
Deep sleep Power Optimization esp_deep_sleep_start()
HTTP requests HTTP/WebSocket HTTPClient
WebSocket HTTP/WebSocket WebSocket library
mDNS Comprehensive Lab MDNS.begin()

43.5 Prerequisites

Before diving into these chapters, you should be familiar with:

  • Wi-Fi IoT Architecture: Pattern of IoT sensors connecting via Wi-Fi to local gateways or directly to cloud via HTTP/MQTT
  • MQTT Broker: Publish-subscribe message broker (Mosquitto, AWS IoT Core) receiving sensor data and routing to subscribers
  • HTTP REST API: Request-response pattern for IoT data; simpler than MQTT but less efficient for high-frequency sensor reporting
  • WebSocket: Full-duplex TCP-based protocol enabling real-time bidirectional communication between IoT devices and cloud
  • TLS/SSL Mutual Authentication: Both device and server authenticate with certificates; higher security than one-way TLS
  • Wi-Fi Provisioning: Process of configuring SSID and credentials in a new device; methods include BLE provisioning, AP mode, or QR code
  • Over-the-Air (OTA) Updates: Firmware delivery via Wi-Fi to deployed devices; requires secure download and rollback capability
  • Local vs Cloud Processing: Deciding what data to process locally on the device vs transmit to cloud for processing
Common Mistake: Using Modem Sleep Instead of Deep Sleep for Battery Devices

A frequent error in Wi-Fi IoT projects is choosing modem sleep mode thinking it provides adequate power savings while maintaining network connectivity. This mistake can reduce battery life by 100x or more.

The Mistake: Developer configures ESP32 with WiFi.setSleep(WIFI_PS_MIN_MODEM) to “save power while staying connected to Wi-Fi,” expecting multi-month battery life on a 3000 mAh battery.

Why It Fails:

  • Modem sleep current: 15-20 mA (radio off, CPU active)
  • Deep sleep current: 10-150 µA (everything off except RTC)
  • Power ratio: Modem sleep draws 150-2000x more current than deep sleep
  • Battery life impact: 3000 mAh battery lasts only 6-8 days with modem sleep vs 1-2 years with deep sleep

Real Numbers:

Mode Current 3000 mAh Battery Life Use Case
Active TX 240 mA 12.5 hours Transmitting data
Modem sleep 20 mA 6.25 days Connected but idle
Light sleep 0.8 mA 156 days Quick wake, maintains Wi-Fi state
Deep sleep 10 µA 34 years* Periodic sensing

*Practical limit: battery self-discharge (~2%/year) caps real life at ~10 years

Let’s calculate precise battery life for a real IoT weather station that wakes every 10 minutes to transmit data:

Device specifications:

  • Battery: 3,000 mAh LiPo (usable 80% DoD = 2,400 mAh)
  • Active mode: 260 mA (Wi-Fi TX + CPU)
  • Deep sleep: 10 µA
  • Wake cycle: Every 600 seconds

Time breakdown per cycle:

  • Deep sleep: 598 seconds (99.67% of time)
  • Active (wake + connect + TX): 2 seconds (0.33% of time)

Energy consumption per cycle:

\[E_{cycle} = E_{active} + E_{sleep}\]

\[E_{active} = 260\ \text{mA} \times 2\ \text{s} \times \frac{1\ \text{h}}{3600\ \text{s}} = 0.144\ \text{mAh}\]

\[E_{sleep} = 0.01\ \text{mA} \times 598\ \text{s} \times \frac{1\ \text{h}}{3600\ \text{s}} = 0.0017\ \text{mAh}\]

\[E_{cycle} = 0.144 + 0.0017 \approx 0.146\ \text{mAh}\]

Daily energy consumption:

\[E_{daily} = \frac{24\ \text{hours} \times 60\ \text{minutes}}{10\ \text{minutes}} \times 0.146\ \text{mAh} = 144 \times 0.146 = 21.0\ \text{mAh/day}\]

Battery life:

\[\text{Life} = \frac{2400\ \text{mAh}}{21.0\ \text{mAh/day}} \approx 114\ \text{days}\]

Optimization with static IP (reduces active time to 0.7 seconds):

\[E_{active,opt} = 260\ \text{mA} \times 0.7\ \text{s} \times \frac{1}{3600} = 0.050\ \text{mAh}\]

\[E_{cycle,opt} = 0.050 + 0.0017 = 0.052\ \text{mAh}\]

\[E_{daily,opt} = 144 \times 0.052 = 7.5\ \text{mAh/day}\]

\[\text{Life}_{opt} = \frac{2400}{7.5} \approx 320\ \text{days} \approx 10.5\ \text{months}\]

Key insight: With deep sleep, 99.67% of battery capacity is preserved during sleep periods. The remaining 0.33% of time in active mode still dominates energy consumption (98.8% of daily energy), demonstrating why connection time optimization (static IP, pre-shared keys) is critical even with deep sleep.

Comparison to modem sleep:

If using modem sleep (15 mA) instead:

\[E_{daily,modem} = 15\ \text{mA} \times 24\ \text{h} = 360\ \text{mAh/day}\]

\[\text{Life}_{modem} = \frac{2400}{360} = 6.7\ \text{days}\]

Battery life improvement: Deep sleep provides \(\frac{320}{6.7} \approx 48\times\) longer battery life than modem sleep for this duty cycle.

When Modem Sleep Makes Sense (Rare):

  • Device is mains-powered or USB-powered
  • Must respond to network messages within milliseconds
  • Connection re-establishment time (2-5 seconds) is unacceptable
  • Example: Smart speaker that must respond to voice commands instantly

Correct Approach for Battery Devices:

  1. Use deep sleep between sensor readings
  2. Wake via RTC timer or external interrupt
  3. Connect to Wi-Fi, transmit data, disconnect
  4. Return to deep sleep immediately
  5. Optimize connection time with static IP (500 ms vs 2-5 seconds for DHCP)

Code Pattern:

// WRONG: Modem sleep for battery device
WiFi.setSleep(WIFI_PS_MIN_MODEM);  // Still draws 20 mA!

// RIGHT: Deep sleep between transmissions
void loop() {
  takeSensorReading();
  connectToWiFi();       // 500 ms with static IP
  sendData();            // 200 ms
  WiFi.disconnect(true); // Turn off radio
  esp_deep_sleep(10 * 60 * 1000000); // 10 minutes deep sleep
}

Bottom Line: Unless you have a compelling real-time requirement that justifies 100x worse battery life, ALWAYS use deep sleep for battery-powered Wi-Fi IoT devices. There is no middle ground.

43.7 Concept Relationships

Understanding how these implementation chapters relate to each other:

Concept Depends On Enables Trade-off
Station Mode AP configuration, credentials Internet connectivity Dependency on infrastructure
Deep Sleep Timer/GPIO wake sources Multi-year battery life Latency vs power savings
WebSocket HTTP upgrade, persistent TCP Real-time bidirectional streaming Connection management vs efficiency
mDNS Discovery Multicast DNS support Device auto-discovery Network overhead vs convenience
Static IP DHCP reservation Fast connection Configuration overhead vs speed

Common Pitfalls

HTTP long-polling (repeatedly querying the server) consumes significantly more power and bandwidth than persistent WebSocket or MQTT connections. For IoT devices expecting server-initiated messages (commands, configuration updates), use WebSocket or MQTT to avoid constant polling overhead.

IoT devices that discard sensor readings during Wi-Fi disconnections lose critical data. Implement local data buffering (in flash or RAM with circular buffer) to store readings during outages and transmit them when connectivity is restored.

IoT devices sending JSON with field names over Wi-Fi waste bandwidth. A temperature reading as {“temperature_celsius”: 23.5} uses 27 bytes; encoded as a 4-byte float it uses 4 bytes. Use binary protocols or compressed JSON for high-frequency sensor data to reduce bandwidth and power.

OTA updates that fail midway can leave devices in an unbootable state. Always implement a fail-safe dual-partition scheme with rollback capability: boot new firmware, verify it operates correctly for 5 minutes, then commit. Never deploy OTA without a rollback mechanism.

43.8 Summary

This chapter series provides comprehensive coverage of Wi-Fi implementation for IoT:

43.9 See Also

For deeper exploration of related topics:

43.10 Knowledge Check

43.11 What’s Next

If you want to… Read this
Implement ESP32 Wi-Fi basics Wi-Fi Implementation: ESP32 Basics
Add HTTP and WebSocket to your IoT device Wi-Fi HTTP & WebSocket
Optimize power consumption Wi-Fi Power Optimization
Secure and provision Wi-Fi devices Wi-Fi Security and Provisioning
Work through comprehensive labs Wi-Fi Comprehensive Lab