The ESP32-H2 is the odd one out in Espressif's lineup, and it's odd on purpose: it has no WiFi at all. Where every other chip in the family leads with WiFi and treats everything else as an add-on, the H2 strips WiFi out entirely and focuses on two things -- Bluetooth LE and an 802.15.4 radio for Zigbee, Thread, and Matter-over-Thread. That sounds like a downgrade until you see where it's actually used: as the Thread/Zigbee radio sitting next to a WiFi-capable chip like the C6, handling the mesh side of a Matter setup while something else handles the internet-facing side.
Dropping WiFi isn't just a feature cut -- it changes the chip's whole power profile. Without a WiFi radio to feed, the H2 posts some of the lowest deep-sleep and active-radio power numbers in the ESP32 family, which is exactly what a battery-powered Zigbee sensor or a coin-cell Thread end device needs. If a project's only wireless requirement is Zigbee, Thread, or BLE -- no WiFi, ever -- the H2 is usually the more efficient and cheaper choice over a C6.
This guide covers the pinout on a typical ESP32-H2 DevKitM-1 layout -- GPIO, ADC, the radio set, and the exact strapping pins worth knowing before a project depends on this chip booting reliably every time.
GPIO Pins and Numbering
The H2 is a smaller chip than its C6 and C3 siblings, with a correspondingly smaller pin count -- 27 physical GPIOs on the chip (GPIO0-27, minus a couple of gaps), with typical devkits breaking out somewhere in the 18-19 usable GPIO range.
pinMode(2, OUTPUT);
digitalWrite(2, HIGH);
Strapping Pins -- The Exact List
Per Espressif's own datasheet, boot mode on the H2 is controlled specifically by GPIO8 and GPIO9 -- the same pin numbers and the same table structure as the C6 and C3:
| GPIO8 | GPIO9 | Result |
|---|---|---|
| Any value | HIGH (default) | Normal SPI flash boot -- runs your program |
| HIGH | LOW | Download Boot (USB or UART flashing mode) |
| LOW | LOW | Invalid combination |
GPIO9 carries an internal pull-up/pull-down of roughly 45kΩ, so it reads high and boots normally by default when left unconnected -- this is why the BOOT button on most H2 devkits wires to GPIO9, pulling it low only while held. If a custom board wires a switch to GPIO9 for manual bootloader entry, Espressif specifically recommends a strong pull-down (around 10kΩ to ground) rather than relying on a bare switch, since the internal pull-up alone can be too weak to guarantee a clean LOW read in some board layouts. GPIO8 must also read HIGH alongside GPIO9 LOW for the serial bootloader to engage reliably -- GPIO8=LOW combined with GPIO9=LOW is an invalid, undefined combination.
A Single RISC-V Core, No LP Core
Unlike the C6, the H2 doesn't have a separate low-power core -- it's a single RISC-V core running up to 96MHz, full stop. That's a reasonable trade given the chip's job: a dedicated Zigbee/Thread radio node doesn't need to juggle WiFi, Bluetooth, and 802.15.4 stacks simultaneously the way a C6 sometimes does, so the extra core the C6 carries for background tasks matters less here.
ADC Pins
The H2 has a single ADC with a modest handful of usable channels -- enough for a basic battery-voltage check or a simple analog sensor, but not a chip built around heavy analog work.
int reading = analogRead(1); // example ADC-capable pin
If a project needs serious analog capability alongside Thread or Zigbee, it's often cleaner to pair the H2 with a dedicated ADC breakout over I2C than to lean on its limited onboard analog pins.
PWM
Same software-mapped approach as the rest of the family -- the LEDC peripheral can drive a PWM signal on essentially any GPIO.
ledcAttach(2, 5000, 8);
ledcWrite(2, 128); // ~50% duty cycle
Wireless: BLE 5.3 and 802.15.4 -- No WiFi
This is the entire reason the chip exists, so it's worth stating plainly: no WiFi radio, at all, on any H2 variant. What it does have is Bluetooth 5.3 LE and an 802.15.4 radio covering Zigbee, Thread, and Matter-over-Thread -- the same 802.15.4 standard the C6 carries, just without WiFi riding alongside it.
| Radio | Standard | Present on H2? |
|---|---|---|
| WiFi | 802.11 (any generation) | No |
| Bluetooth | BLE 5.3 | Yes |
| 802.15.4 | Zigbee / Thread / Matter-over-Thread | Yes |
In a typical Matter/Thread border-router setup, the H2 is the chip handling the Thread mesh side, while a WiFi-capable device (a C6, a classic ESP32, or even a Raspberry Pi) bridges that mesh out to the internet. Buying an H2 expecting it to also join a home WiFi network directly is the single most common misunderstanding about this chip.
I2C, SPI, and UART
I2C: Software-mapped to any two free GPIOs via Wire.begin(sda, scl), same as the rest of the ESP32 family.
Wire.begin(1, 0); // SDA, SCL — adjust to your board's free pins
SPI: Software-assignable via SPI.begin(sck, miso, mosi, cs).
UART: Multiple hardware UARTs are available, with one typically tied to the onboard USB-serial chip on a devkit for flashing and debugging.
Common Pairings: H2 as a Thread/Zigbee Coprocessor
The most common real-world H2 deployment isn't as a standalone general-purpose board -- it's as a dedicated radio coprocessor sitting next to a more capable, WiFi-equipped host. In that role, the H2 talks to the host chip over UART or SPI, running the Thread or Zigbee stack and handing processed mesh data up to whatever's managing the WiFi connection and application logic. If a project's architecture already has a Raspberry Pi or a WiFi-capable ESP32 doing the heavy lifting, adding an H2 purely for its 802.15.4 radio is often simpler than trying to run everything -- WiFi, Thread, and application code -- on one chip. This coprocessor pattern also shows up in commercial Matter hubs, where a WiFi/Ethernet-connected main SoC pairs with a small 802.15.4-only radio chip rather than a single do-everything part.
Power Pins
| Pin | Function | Notes |
|---|---|---|
| 5V / VIN | Power input | Via USB or an external 5V supply |
| 3V3 | Regulated 3.3V output | Powers the chip and any 3.3V peripherals |
| GND | Ground | Multiple ground pins on most devkits |
3.3V logic throughout, same as the rest of the ESP32 family. The H2's no-WiFi design means its active-radio current draw is noticeably lower than a WiFi-capable sibling's, which matters directly for coin-cell or small-battery Zigbee/Thread end-device designs.
How the H2 Compares to Its Siblings
| Chip | WiFi | Bluetooth | 802.15.4 | LP core | Best for |
|---|---|---|---|---|---|
| ESP32-C3 | WiFi 4 | BLE 5.0 | No | No | Cheapest general WiFi/BLE sensor node |
| ESP32-C6 | WiFi 6 | BLE 5.3 | Yes | Yes | Matter/Thread/Zigbee alongside WiFi on one chip |
| ESP32-H2 | None | BLE 5.3 | Yes | No | Dedicated, low-cost Thread/Zigbee radio, no WiFi needed |
The choice between the H2 and the C6 usually comes down to whether a single device needs to speak WiFi itself. If it does, the C6 covers everything in one chip. If the WiFi/internet connection is handled elsewhere in the system -- a separate gateway, a Raspberry Pi, an existing router -- the H2 does the Thread/Zigbee job for less money and less power.
Common Mistakes and How to Avoid Them
Buying an H2 for a WiFi project by mistake. It's an easy mix-up given how similar the board names and form factors look across the ESP32 lineup -- double-check the specific chip printed on the module before assuming WiFi support.
Wiring something to GPIO8 or GPIO9 without checking the strapping role first. Same boot-mode-sampling behavior as the C6 and C3, on the identical pin numbers.
Trying to make the H2 replace a WiFi-capable chip outright. Its whole design philosophy is doing Bluetooth and 802.15.4 well and cheaply as a companion radio, not being a general-purpose WiFi replacement.
Keeping the analog budget too ambitious in the design. With a limited number of ADC channels, this isn't the chip for a project reading several analog sensors at once.
Practical Pin Usage Tips
Pair it with a WiFi-capable chip rather than trying to replace one. This is the intended deployment pattern, not a workaround.
Lean into the lower power budget for battery designs. If a project genuinely only needs Zigbee, Thread, or BLE, the H2's power profile beats a C6 running the same radios alongside an idle WiFi stack.
Use a strong external pull-down on GPIO9 for any custom bootloader switch. Espressif's own hardware guidelines call this out specifically -- the internal pull-up can be too weak on some board layouts to guarantee reliable download-mode entry.
Don't expect analog-heavy sensor support. Route more than a couple of analog readings through an external ADC over I2C instead.
Summary: ESP32-H2 Pin Reference at a Glance
ESP32-H2 · Single-core RISC-V @ up to 96MHz · BLE 5.3 · 802.15.4 (Zigbee/Thread/Matter) · No WiFi radio · GPIO0-27 on the chip, ~18-19 usable on a typical devkit · Strapping pins: GPIO8, GPIO9 · Single ADC
Which Projects the H2 Actually Fits
A strong fit: a Zigbee end device (a sensor, a smart switch) reporting to an existing Zigbee coordinator; a Thread end device joining an existing Thread mesh anchored by a separate border router; the Thread/Zigbee radio half of a DIY Matter bridge, paired with a WiFi-capable host handling the internet-facing side; or any coin-cell or small-battery device where the H2's lower power draw versus a C6 running the same radios genuinely extends runtime.
A weaker fit: anything that needs to join a WiFi network directly (impossible on this chip), general-purpose GPIO-heavy projects with no radio requirement at all (a plain microcontroller without a WiFi-capable ESP32's flexibility is rarely the right trade), or analog-sensor-heavy designs given the chip's modest ADC budget.
It's worth being honest about how the H2 gets chosen in practice: rarely as a standalone "pick this chip first" decision, and far more often as the second chip in a design that already has a WiFi-capable part doing the internet-facing work. Treating it as a companion radio rather than a general-purpose microcontroller is the right mental model from the start.
Quick Answers to Common ESP32-H2 Pin Questions
Can the H2 connect to my home WiFi network? No -- it has no WiFi radio at all. It only does Bluetooth LE and 802.15.4 (Zigbee/Thread).
Why would I choose an H2 over a C6 if the C6 does everything the H2 does, plus WiFi? Cost and power. If a project genuinely never needs WiFi on that specific chip, the H2 is cheaper and more power-efficient for its actual job than a C6 running the same radios with an idle WiFi stack alongside them.
Is the H2 a good general-purpose microcontroller? Not really its strength -- it's a purpose-built radio chip. For general GPIO-heavy projects with no specific Zigbee/Thread need, a C3 or C6 is a more flexible pick.
Which exact pins control boot mode? GPIO8 and GPIO9, identical to the C6 and C3's strapping pin behavior -- GPIO9 low on reset forces download mode.
Does it have a low-power core like the C6? No -- one RISC-V core, no separate LP core. Its low overall power draw comes from the smaller radio set, not from an architectural low-power core.
Can I use 5V sensors directly? No -- 3.3V logic throughout, same as the rest of the ESP32 family.
Where to Go From Here
Once the WiFi-less design makes sense as a deliberate trade-off rather than a missing feature, pairing an H2 with an ESP32-C6 or a Raspberry Pi running Home Assistant is the natural next step for building an actual Matter/Thread border router. From there, the same 802.15.4 stack running on the H2 carries directly over to Zigbee-only projects that don't need Thread or Matter at all, if that's the simpler fit for a specific device.