ESP32 vs ESP8266 for ESPHome: Which Board?

Almost every wired pairing in this index names a host board, and for an ESPHome node the choice is between the ESP8266 and a member of the ESP32 family. 108 of the curated ESPHome configs here target an ESP32-family chip and 10 target the ESP8266. Both run ESPHome well, so the useful question is not which one works but which one runs out first for the node you are building: memory, serial ports, analog pins, or a radio the chip does not have.

The short answer

Start a new node on an ESP32-family board. Reach for an ESP8266 when the node has one bus and one job and the board is already in the drawer. Within the ESP32 family:

• Classic ESP32: the most analog inputs you can use with Wi-Fi on, three UARTs that route to almost any pin, Bluetooth Classic and LE, and an Ethernet MAC on the chip. The reference host for most configs in this index.
• ESP32-C3: a single RISC-V core, Bluetooth LE and USB on the chip, in small, low-cost boards. The modern stand-in for an ESP8266.
• ESP32-S3: two cores, USB on the chip and optional PSRAM in the package. The one for cameras, colour displays, speakers and microphones.
• ESP32-C6: Wi-Fi 6 plus an 802.15.4 radio, so the node can join Thread or Zigbee instead of Wi-Fi.
• ESP32-S2: no Bluetooth at all. Fine for a Wi-Fi sensor, no use as a Bluetooth proxy.
• ESP32-H2 and ESP32-P4: no Wi-Fi of their own. The H2 talks Thread or Zigbee only; the P4 needs a second ESP32 as its radio.

The chips side by side

Figures from Espressif's datasheets for each chip, and the ESP8266's RAM line is Espressif's figure for a chip connected to a router. The transmit rows are not like-for-like: the ESP8266 and ESP32 sheets give a typical figure at a 50% duty cycle, the newer sheets a peak at full power. The ESP32-S2 is not in the table; ESPHome lists it as a single-core LX7 with 43 GPIOs, USB OTG and no Bluetooth.

What this index's configs and planner assume

The conflict planner uses these numbers when it checks whether a parts list fits a board. Its UART count leaves out the port the USB console usually occupies, which is why it is lower than the chip totals above. Camera and dev-board variants count towards their chip.

Where the ESP8266 still earns its place

The one-job node: an I²C climate sensor, a relay, a button, an infrared blaster. ESPHome supports the chip fully, boards built on it are everywhere, and a node that will never gain a second bus will never meet its limits. The 10 ESP8266 pairings with a curated config in this index are mostly that shape:

• 5V Active-Low Relay Module
• AHT20 Humidity & Temperature Sensor
• BH1750 Ambient Light Sensor
• BMP280 Barometric Pressure & Temp Sensor
• DHT22 AM2302 Temp & Humidity Sensor
• HTU21D Temp & Humidity Sensor
• KY-005 IR Transmitter & Receiver
• PCF8574 8-bit I2C GPIO Expander
• SH1106 1.3 Inch OLED Display (128x64)
• TTP223 Capacitive Touch Button Module

Where the ESP8266 runs out first

Memory

Espressif puts the heap and data space left to a program at around 50 kB once an ESP8266 is connected to a router. ESPHome's Wi-Fi, API connection and every component you add share that space, so the margin is measured in kilobytes. ESPHome's documentation warns that the web server component takes a lot of memory and can make a node less stable, especially on the ESP8266. A small colour display shows the scale: the full 16-bit frame buffer of a 128 × 160 panel is about 40 kB, a rounding error on an ESP32 and the difference between building and not on an ESP8266, which is why the ST7735 page discusses 8-bit colour. ESPHome also documents encrypted MQTT, with a CA certificate, on the ESP32. A node that needs a web page, a display and a TLS broker wants an ESP32.

One and a half serial ports

The ESP8266 has two hardware UARTs, and only one of them can receive. UART0 sits on GPIO1 and GPIO3, shared with the USB converter and the boot messages, or can be swapped to GPIO15 (TX) and GPIO13 (RX). UART1 is transmit-only, on GPIO2. Ask ESPHome for a UART on any other pins and it falls back to software serial, which its documentation says can glitch, especially at higher baud rates. In practice that is one receiving serial part per ESP8266, with serial logging switched off (baud_rate: 0 under logger:) so the logger does not talk over it. A PMS5003 and an MH-Z19B on one node is an ESP32 job, and the LD2450 radar, which only talks at 256000 baud, is no candidate for software serial.

Pins that are already spoken for

The chip has 17 GPIOs, and few come without conditions. GPIO6 to GPIO11 connect to the flash. GPIO0, GPIO2 and GPIO15 choose the boot mode: GPIO0 and GPIO2 must be high and GPIO15 low for the chip to start from flash, so a part that pulls one the wrong way at power-on leaves the node stuck before ESPHome runs. GPIO1 and GPIO3 are the serial port. GPIO16 is the deep-sleep wake line and has a pull-down but no pull-up. ESPHome's documentation names GPIO4, GPIO5 and GPIO12 to GPIO14 as the pins without boot-time restrictions, and GPIO12 to GPIO14 are also the hardware SPI bus. A relay that clicks at every power cycle is usually wired to one of the boot-mode pins, which is why the ESP8266 relay pairing puts its input on GPIO5.

One analog input, 0 to 1.0 V

The ESP8266 has a single 10-bit ADC pin, and the chip itself reads 0 to 1.0 V on it. Development boards usually put a divider in front of A0 so it accepts more. Using A0 for a sensor also rules out ESPHome's supply-voltage reading, which needs the pin left unconnected. A second analog sensor means an ADS1115 on the I²C bus, or a second board.

No Bluetooth, no RMT driver, timer-only sleep

There is no Bluetooth radio, so no Bluetooth proxy and no BLE sensors. ESPHome's RMT LED strip driver is ESP32-only, so addressable strips go through NeoPixelBus, which ESPHome recommends running on GPIO3 with its DMA method to reduce flicker; GPIO3 is also UART0's receive pin. Deep sleep wakes only on a timer: GPIO16 has to be wired to RST, and ESPHome offers no wake-up pin on this chip.

Pins to leave alone on each ESP32

• ESP32: GPIO0, 2, 5, 12 and 15 are strapping pins, and GPIO12 sets the flash supply voltage at reset, so a part that pulls it high can stop a module booting. GPIO6 to 11 belong to the flash. On WROVER modules GPIO16 and 17 belong to the PSRAM, which is why the GPS and A4988 pages tell WROVER owners to move those lines. GPIO34 to 39 are input-only with no internal pull-ups, so a rotary encoder wants other pins or external resistors.
• ESP32-C3: GPIO2, 8 and 9 are strapping pins, GPIO12 to 17 connect to the flash, and GPIO18 and 19 carry the on-chip USB. GPIO9 is the one that decides the boot: held low at reset, it puts the chip in download mode instead of starting ESPHome. This index's C3 configs put I²C on GPIO8 and GPIO9, where the bus pull-ups keep GPIO9 high, which is what a normal boot needs; a part that drags GPIO9 low at power-on belongs on another pin.
• ESP32-S3: GPIO0, 3, 45 and 46 are strapping pins. GPIO26 to 32 serve the flash and PSRAM, and modules with octal PSRAM, such as the one on the XIAO ESP32S3 Sense, take GPIO33 to 37 as well. GPIO19 and 20 are the USB pins.
• ESP32-C6: GPIO4, 5, 8, 9 and 15 are strapping pins, GPIO24 to 30 serve the flash, and GPIO12 and 13 are the USB pins.

Espressif's GPIO reference for each chip lists these in full: ESP32, ESP32-C3, ESP32-S3 and ESP32-C6.

Analog: ADC1 or nothing

On the classic ESP32, ADC2 shares hardware with the Wi-Fi radio, and Espressif's advice is to use ADC1 pins when Wi-Fi is running. An ESPHome node has Wi-Fi running all the time, so plan analog sensors onto GPIO32 to 39; the capacitive soil probe sits on GPIO34 for that reason. The S2 and S3 split the same way, with ADC1 on GPIO1 to 10 and ADC2 on GPIO11 to 20. The C3's only ADC2 channel, on GPIO5, is no longer supported by ESP-IDF because of a hardware erratum, and the C6 and H2 have ADC1 alone.

Range is the second catch. The attenuation option in ESPHome's ADC sensor sets how much voltage a pin accepts. At the highest setting, 12 dB, Espressif specifies the classic ESP32's effective range as 150 mV to 2450 mV. With attenuation: auto, ESPHome picks the setting per reading, and its own testing found a usable range of roughly 0.075 V to 3.12 V. Neither reaches 3.3 V, so a sensor with a full-rail output wants a divider. When a node needs more inputs or better resolution than the chip gives, an ADS1115 adds four 16-bit channels on I²C.

Serial, I²C and SPI

The classic ESP32 and the S3 each have three UARTs and two I²C controllers, and the UARTs can be routed to almost any free pin. The C3 and C6 have two UARTs and one main I²C controller, and the C6 adds low-power versions of both. On boards whose USB socket goes through a converter chip, UART0 is the console. ESPHome has no software serial on the ESP32 family, and with hardware ports to spare it rarely needs one: a CO2 sensor and a mmWave radar fit on one classic ESP32 with the console still on UART0. A second I²C bus is the cheapest way out of an address clash, as the I²C address conflicts guide explains, and a TCA9548A multiplexer covers the case where two buses are not enough.

LED strips and PWM

On ESP32 chips with RMT hardware, addressable strips use esp32_rmt_led_strip, which works on both frameworks. ESPHome deprecated NeoPixelBus's ESP32 support in 2026.6 because the library does not build on ESP-IDF, and its migration guide names esp32_rmt_led_strip as the replacement for both NeoPixelBus and FastLED's clockless driver. The ESP32-C2 and C61 have no RMT hardware and cannot drive a strip this way. On the S3, RMT memory comes in 48-symbol blocks and long strips can flicker under Wi-Fi load until rmt_symbols is raised, as the WS2812B page explains. Plain PWM for dimmers, buzzers and motors is ledc on the ESP32 family and esp8266_pwm on the ESP8266.

Bluetooth proxies and BLE sensors

Neither the ESP8266 nor the ESP32-S2 has a Bluetooth radio. ESP32 variants that do can scan for BLE sensors and run as a Home Assistant Bluetooth proxy with active connections. The limits are memory and radio time. ESPHome warns that the BLE stack takes a large share of RAM and that crashes become likely with too many other components on the node. Each active connection slot costs about 1 kB: the default is three, the ceiling nine, and ESPHome advises staying at five or fewer. It recommends ESP-IDF over Arduino for a proxy because it uses less memory, and a board on Ethernet so the radio is not also carrying Wi-Fi traffic. On single-core chips such as the C3, Wi-Fi and BLE scanning share the one core, which ESPHome notes has caused trouble connecting to Wi-Fi. The comfortable proxy is a dual-core classic ESP32 or S3 doing nothing else, ideally on Ethernet. The Bluetooth hub lists the Bluetooth devices in this index.

Thread and Zigbee on the C6 and H2

The C6 and H2 carry an IEEE 802.15.4 radio, and ESPHome has two ways to use it. The openthread component puts the node on a Thread network instead of Wi-Fi. It needs the ESP-IDF framework and a Thread border router already on your network, since the node cannot be one, and ESPHome notes that OTA updates do not work while a polling period is set for a sleepy device. The zigbee component makes the node a Zigbee end device, or a router if you ask, exposing sensors and binary sensors on ESP32 chips. A C6 can stay on Wi-Fi as a station while acting as a Zigbee end device, but ESPHome reports that Wi-Fi plus a Zigbee router is unstable, and that the H2 has proved more reliable than the C6, with some C6 boards working only beside the coordinator. The H2 has no Wi-Fi, so on that chip it is Thread or Zigbee. The P4 has no radio at all; the esp32_hosted component gives it Wi-Fi and Bluetooth through a second chip such as a C6. See the Thread and Zigbee hubs for devices on those networks.

Framework: ESP-IDF is the default

Since ESPHome 2026.1.0, an esp32: block with no framework builds with ESP-IDF. Arduino is still available on the classic ESP32, S2, S3 and C3, now packaged as an ESP-IDF component; the C5, C6, C61, H2 and P4 are ESP-IDF only. ESPHome's migration guide claims binaries up to 40% smaller on ESP-IDF, since an Arduino build carries both frameworks. A few components still need Arduino, among them heatpumpir, midea and the WLED effect, and others have ESP-IDF replacements, such as bme68x_bsec2 for bme680_bsec. The dependency also runs the other way: the speaker media player on the MAX98357A page refuses Arduino. Every ESP32-family board block in this index's own configs declares ESP-IDF explicitly; the finished products built from a vendor package, such as the Apollo AIR-1, take whatever framework the vendor's YAML chooses. The ESP8266 has one framework, so there is nothing to choose.

USB, flashing and logs

ESP8266 and classic ESP32 boards reach your computer through a USB-serial converter on UART0, and flashing and logs both go that way. The C3, C6 and S3 have a USB-Serial-JTAG peripheral on the chip, and the S2 and S3 have USB OTG, so many boards wire the socket straight to the chip and leave the converter out. That changes where ESPHome's logger has to write. It can target USB_SERIAL_JTAG (C3, C6, S3), USB_CDC (S2, S3) or a UART, and a node logging to a port your socket is not wired to boots silently. Some C3 and S3 boards still put a converter on UART0, so check the board's schematic and set hardware_uart to match, as the XIAO ESP32S3 config in this index does. Reusing the USB pins as ordinary GPIOs switches the on-chip USB off.

Power, brownouts and battery nodes

Wi-Fi transmits in bursts, and the newer chips' datasheets put those peaks at 335 to 354 mA at full power. A thin USB lead, a computer's USB port or an adapter's 3.3 V pin that sags under them shows up as brownout resets just as Wi-Fi or a camera starts, the failure the ESP32-CAM page sees most often. Give camera and LED nodes a proper 5 V supply sized for everything on it.

For battery sensors the deep-sleep row matters more: 20 µA for the ESP8266 against 5 µA for the C3, for the chip alone. The ESP8266 wakes only on its timer, through the GPIO16-to-RST wire. The classic ESP32 can also wake on an RTC-capable pin or a touch pad, and ESPHome documents waking on a group of pins with esp32_ext1_wakeup for the S2, S3, C6 and H2 among others. The C3 is not on that list, so check the deep sleep documentation before planning a C3 node around a pin wake-up. On a development board the regulator, converter chip and power LED can draw far more than the sleeping chip, so measure the whole board before promising a battery life.

Which board for which node

Where to go next

Every device page with a curated config names its host and pins, and the ESPHome hub lists them all. The conflict planner checks a parts list against the host limits above before you wire anything. Browse by bus with I²C, UART, analog and I²S parts, or by job in the function categories. For the chips themselves, ESPHome's ESP8266 and ESP32 platform pages are the reference.