When building networked IoT hardware, software events need physical feedback. You might have your firmware perfectly configured to catch an esp async webserver connect event, but without the correct copper traces, that software event remains trapped in the silicon. This guide walks through the physical wiring diagram for an ESP32-WROOM-32E circuit designed to illuminate a 'Client Active' status LED and latch a 5V relay the moment a web client connects to your server.
We are bridging the gap between network stack callbacks and physical GPIO manipulation. Below, you will find the exact terminal mappings, a node-by-node trace of the power and signal paths, and the multimeter verification steps to ensure your hardware won't brownout when the relay coil energizes.
Diagram Symbols and Physical Terminal Mapping
Before tracing the wires, we need to decode the schematic symbols used in this specific drawing and map them to the physical terminals on your workbench. In this diagram, VCC and VDD represent positive voltage rails (5V for the relay, 3.3V for the ESP32 logic). GND and VSS denote the common ground return path. IN on the relay module refers to the optocoupler input, while COM, NO (Normally Open), and NC (Normally Closed) represent the dry-contact relay switching terminals.
Here is the exact terminal and pin mapping table for this build. All wire gauges are 22 AWG stranded for breadboard flexibility.
| Source Terminal | Destination Terminal | Wire Color | Function / Symbol Meaning |
|---|---|---|---|
| 5V PSU Positive (+) | Relay Module VCC | Red | Provides 5V / 70mA for the relay coil |
| 5V PSU Negative (-) | ESP32 GND & Relay GND | Black | Common ground (Equipotential bonding) |
| ESP32 GPIO 25 | Relay Module IN | Yellow | Active-LOW signal to trigger optocoupler |
| ESP32 3V3 Pin | LED Anode (via 100Ω Resistor) | Orange | 3.3V logic HIGH source for status LED |
| ESP32 GPIO 26 | LED Cathode | Green | Active-LOW sink to complete LED circuit |
| Relay COM | 12V Load Positive | White | Common terminal for the switched load |
| Relay NO | 12V PSU Positive | Blue | Normally Open contact (closes on event) |
Node-by-Node Trace: Power, Ground, and Signal Paths
A wiring diagram is useless if you don't understand the flow of electrons. Let's trace this circuit node-by-node, starting from the power sources, through the control logic, and out to the loads.
The 5V Power and Ground Path
Current leaves the 5V 2A barrel jack power supply's positive terminal (red wire) and flows directly into the VCC pin of the relay module. It does not pass through the ESP32. The return path for this 5V rail begins at the relay module's GND pin (black wire). This black wire routes to the ESP32's GND pin and then continues back to the 5V PSU's negative terminal. This creates a shared ground reference. If you skip bonding the 5V PSU ground to the ESP32 ground, the 3.3V logic signal from GPIO 25 will have no reference potential to forward-bias the relay's internal optocoupler LED, and the relay will never click.
The Logic Signal Path (The Connect Event Trigger)
When the firmware detects the esp async webserver connect event, it drives GPIO 25 LOW (0V). Current flows from the 5V relay module's VCC rail, through the relay module's internal current-limiting resistor, through the optocoupler's internal LED, and out the IN terminal. It travels via the yellow wire into ESP32 GPIO 25, which is currently acting as a current sink to ground. This energizes the optocoupler, which in turn triggers the transistor that drives the 5V relay coil. The mechanical contacts close, bridging COM to NO.
The Status LED Path
Simultaneously, the firmware drives GPIO 26 LOW. Current leaves the ESP32's 3V3 pin (orange wire), passes through a 100Ω current-limiting resistor (dropping the voltage from 3.3V to the LED's 2.0V forward voltage at 13mA), enters the 5mm red LED's anode, exits the cathode, and travels via the green wire into GPIO 26 to ground. The LED illuminates, providing immediate visual confirmation of the network event.
Verifying the Wiring with a Multimeter
Do not apply power until you have verified the physical connections. Grab your digital multimeter (DMM) and follow this exact sequence to prevent frying your ESP32-WROOM-32E.
- Verify Common Ground (Continuity): Set your DMM to continuity mode (the beep/diode symbol). Place the black probe on the metal shield of the ESP32's micro-USB port (a known, reliable ground). Place the red probe on the GND terminal of the 5V relay module. You must read < 1.0 ohms. If it reads OL (Open Loop), your ground bond is missing.
- Check for Short Circuits (Resistance): With the ESP32 unplugged, set the DMM to the 20kΩ resistance range. Probe between the ESP32's 3V3 pin and GND. You should see a high resistance (typically 10kΩ to 50kΩ due to onboard pull-ups and regulator impedance). If you read near 0 ohms, you have a solder bridge or a misplaced wire on the breadboard.
- Verify Optocoupler Polarity (Diode Test): Set the DMM to diode test mode. Place the red probe on the relay module's VCC pin and the black probe on the IN pin. You should read a forward voltage drop of approximately 1.1V to 1.4V (the internal IR LED of the optocoupler). If it reads OL, reverse the probes. If it reads 0.00V, the optocoupler is shorted.
- Live Voltage Check: Power on the 5V PSU and plug in the ESP32. Set the DMM to DC Voltage (20V range). Probe the 5V PSU output at the relay VCC pin; it must read between 4.9V and 5.1V. Probe the ESP32 3V3 pin; it must read 3.25V to 3.35V. If the 3.3V rail sags below 3.1V when the relay clicks, your USB cable or onboard regulator is inadequate.
Bridging Hardware to the ESP Async WebServer Connect Event
With the copper verified, we tie the physical wiring to the network stack. In the modern 2026 ESP32 ecosystem, the original me-no-dev ESPAsyncWebServer repository is archived. Most developers now use actively maintained forks, such as the mathieucarbou/ESPAsyncWebServer library, which supports the latest ESP-IDF Arduino core versions.
To trigger our wired GPIOs upon a client connection, we utilize the server's event tracking. While the library doesn't have a single native 'onClientConnect' callback in the base routing, we track connections via WebSocket events or by wrapping the request handler to toggle our hardware.
For pure TCP connection tracking, many engineers implement a customAsyncClientwrapper or use theonEventhandler if utilizing WebSockets, pulling GPIO 25 and 26 LOW the moment the handshake completes.
Here is how the hardware mapping translates to the setup logic:
- GPIO 25 (Relay): Configured as
OUTPUT. SetHIGHinsetup()to keep the active-LOW relay OFF during boot. When the connect event fires, writeLOW. - GPIO 26 (LED): Configured as
OUTPUT. SetHIGHinsetup()to keep the LED OFF. WriteLOWon the connect event.
By wiring the relay input to an active-LOW GPIO like 25 (which is safe from ESP32 boot-strapping conflicts, unlike GPIO 0, 2, or 12), you ensure that the relay won't violently chatter while the ESP32 is negotiating its WiFi handshake or reading from the SPIFFS/LittleFS filesystem. The physical hardware remains stable until the esp async webserver connect event explicitly commands the optocoupler to close the circuit, delivering a robust, noise-free translation from network packets to physical work.
For deeper reading on protecting your relay contacts from inductive kickback when the event ends and the relay opens, review the principles of flyback diodes in inductive circuits. The Songle module includes this diode onboard, but understanding the physics ensures you know exactly what is happening on the copper when your webserver drops the connection.






