How Do You Use ESP-NOW for Peer-to-Peer Wireless Communication on the ESP32?

Detailed Explanation

ESP-NOW is Espressif's own connectionless communication protocol that runs on top of the ESP32's Wi-Fi radio hardware but bypasses the standard Wi-Fi stack entirely — there is no access point, no association handshake, no DHCP, and no IP address involved. It operates as a link-layer protocol, encapsulating short data payloads inside vendor-specific 802.11 action frames sent directly between devices identified only by their Wi-Fi MAC address. This is fundamentally different from ESP32 Wi-Fi Station mode, which joins an infrastructure network and communicates over IP, and from ESP32 BLE, which uses an entirely separate radio protocol with its own pairing and GATT data model.

How Peers Work

Before two devices can exchange ESP-NOW packets, each side must register the other's MAC address as a peer using esp_now_add_peer(), supplying the peer's address, the Wi-Fi channel to use, and optionally a per-peer encryption key. Once registered, esp_now_send() delivers a payload of up to 250 bytes (the per-packet limit documented in the ESP-IDF API reference) to that peer with no further setup — there is no multi-step connection process to wait through, which is why ESP-NOW's round-trip latency is typically measured in single-digit milliseconds rather than the tens to hundreds of milliseconds a fresh BLE connection or Wi-Fi association can take.

A device can also register the broadcast address FF:FF:FF:FF:FF:FF as a peer. A packet sent to the broadcast peer is received by every ESP-NOW-listening device within range on the same channel, without each recipient needing to be individually registered — useful for one-to-many sensor broadcasts or discovery beacons where the sender doesn't know its recipients' addresses in advance.

Coexistence With Wi-Fi

Because ESP-NOW shares the same radio and low-level driver as ordinary Wi-Fi, a device can run both simultaneously: staying associated to an access point (for example, to relay data to the cloud) while also exchanging ESP-NOW packets with nearby peers. The constraint is that ESP-NOW communication happens on whatever channel the radio is currently tuned to — if the device is connected to an AP in Station mode, its ESP-NOW traffic is locked to that AP's channel, so all ESP-NOW peers must either operate on the same channel or the gateway device must handle channel changes carefully. A device not associated to any AP can set its ESP-NOW channel freely with esp_wifi_set_channel().

Encryption

ESP-NOW supports optional per-peer encryption (CCMP, the same authenticated-encryption mode used by WPA2) so that a subset of peers can exchange encrypted payloads while others remain unencrypted. The ESP-IDF API reference documents a maximum of 6 simultaneously encrypted peers per device — a smaller ceiling than the roughly 20 total peers a device can otherwise track — which matters for designs planning a larger mesh where confidentiality is required on every link; always confirm the current limits against the ESP-IDF version targeted, since Espressif has adjusted these figures across SDK releases.

Practical Examples

A common use case is a battery-powered sensor mesh — several ESP32 or ESP32-C3 nodes reporting temperature, door state, or button presses — where no Wi-Fi infrastructure exists on site, or where joining a full Wi-Fi network would cost too much energy per transmission for a coin-cell or small-battery design. Each sensor wakes from deep sleep, sends a single ESP-NOW packet to a fixed gateway MAC address, and returns to sleep, without ever incurring a Wi-Fi association's DHCP and TCP/TLS handshake overhead.

A second common pattern is a low-latency remote control or game controller link between two ESP32 boards, where BLE's connection-interval-driven latency (typically tens of milliseconds at best, longer at low-power connection intervals) is too slow, but a full Wi-Fi/UDP link is unnecessary complexity for a small, fixed set of control bytes.

A third pattern uses the broadcast peer address to implement device discovery: new nodes broadcast an announcement packet on power-up, and a gateway listening for ESP-NOW broadcasts learns each node's MAC address dynamically rather than requiring it to be hard-coded or provisioned in advance.

Design Considerations

• Channel agreement is the most common cause of "ESP-NOW just doesn't work." All peers that need to communicate must be on the same Wi-Fi channel. A device connected to an AP in Station mode has no direct control over which channel that puts it on, so a gateway device bridging Wi-Fi and ESP-NOW needs to either fix the AP to a known channel or detect and propagate the current channel to its ESP-NOW peers.
• Treat the 250-byte payload limit as a hard per-packet ceiling, not something to fragment around manually without a reason — if application data genuinely exceeds this consistently, ESP-NOW may be the wrong protocol for that link and a full Wi-Fi/TCP or UDP connection may fit better.
• Reliability is the application's responsibility. The send callback reports whether the over-the-air delivery succeeded, but there is no built-in retry, sequence numbering, or ordering guarantee beyond that single acknowledgement — for anything beyond a fire-and-forget sensor reading, add application-level sequence numbers and a retry/timeout scheme.
• RF layout and antenna design rules for the module's Wi-Fi radio apply equally to ESP-NOW — see RF PCB layout guidelines — since ESP-NOW uses the same physical radio and antenna path as standard Wi-Fi.

For ESP32 products that need a router-free sensor mesh, remote-control link, or mixed Wi-Fi/ESP-NOW gateway architecture, Zeus Design's firmware team develops production ESP32 firmware, including protocol selection between ESP-NOW, BLE, and Wi-Fi for the specific latency, power, and range requirements of a product.

Common Mistakes

• Assuming ESP-NOW behaves like a normal IP socket. It has no IP address, no routing, and no built-in retry beyond a single delivery acknowledgement — code that assumes TCP-like reliability without adding it explicitly will silently drop packets under interference.
• Registering a peer without first confirming both devices are on the same channel, especially when one device is also connected to an access point in Station mode and the other is standalone — this is the single most common ESP-NOW bring-up failure.
• Leaving carrier-level encryption enabled on more peers than the platform supports, then discovering that peers beyond the documented encrypted-peer limit either fail to register or fall back to unencrypted — check the current SDK's limit rather than assuming it matches an older tutorial's figure.
• Choosing ESP-NOW for a link that actually needs internet connectivity or interoperability with non-Espressif devices. ESP-NOW is a proprietary, Espressif-specific protocol; it does not interoperate with standard Wi-Fi clients, BLE devices, or non-Espressif hardware, unlike Wi-Fi or open protocols compared in Bluetooth vs Wi-Fi vs LoRa vs Zigbee.