Wireless Sensor Networks Explained for Makers and IoT Builders

ESP32 & IoTBy November 13, 2026Fact-checked by Hugo Lindgren
Wireless Sensor Networks Explained for Makers and IoT Builders

By Fact-checked by Hugo Lindgren Published

In 2002, a 32-node wireless sensor network on Great Duck Island, Maine, logged more than a million readings from seabird burrows. That project helped start a field that now covers 125 million LoRaWAN devices worldwide, plus most of the smart sensors in a typical home. A wireless sensor network (WSN) is a group of small battery-powered devices that measure something, such as temperature, moisture, vibration or light, and pass the readings by radio to a central point where you can store and use them.

BoardESP32-C6 (x4)
RadioESP-NOW, 2.4 GHz
DifficultyBeginner to intermediate
TimeAn afternoon
HubRaspberry Pi with MQTT

Key takeaways

  • A WSN has four parts: sensor nodes, relays, a gateway (sink) and a dashboard or cloud.
  • The radio, not the sensor, uses most of a node’s battery, so the protocol you pick sets your battery life.
  • Plain Wi-Fi is a poor fit for battery nodes. ESP-NOW, Zigbee, Thread and LoRaWAN are built for this job.
  • Dev boards can draw 5–15 mA while “asleep”. That alone can turn a battery life of years into one of days.
  • The standards moved in late 2025 and 2026: Zigbee 4.0 and Suzi, Matter 1.5 soil sensors, Matter 1.6, ESP-NOW v2.0 and the ESP32-H21.

Fact-checked

We checked these key facts against the sources named, on November 13, 2026:

  • In 2002 came the Great Duck Island deployment (source: home.cs.colorado.edu)
  • ESP-NOW v2.0’s 1,470-byte payload makes large batches practical (source: docs.espressif.com)
  • In 2003, Berkeley’s “Spec” mote put the radio and custom circuits on a single chip running TinyOS (source: newsarchive.berkeley.edu)
  • Meanwhile, IEEE 802.15.4 (2003) gave the field a standard low-power radio layer, with Zigbee, and later Thread, built on top (source: standards.ieee.org)
  • Most WSNs use WPAN or low-power wide-area protocols (source: radiocrafts.com)

What is a wireless sensor network?

A wireless sensor network is a set of spatially spread-out, self-powered sensor nodes that cooperate over radio to monitor a physical environment. Each node senses, does a little processing and transmits. The data hops toward a gateway, which bridges the network to the internet or a local server.

Here is the classic layout in words, from the field to your screen:

[Sensor node]  [Sensor node]  [Sensor node]      <- sense + transmit (battery)
      \             |             /
       \       [Router/relay]    /               <- forwards packets (mains or big battery)
        \           |           /
         +----[Gateway / sink]-+                 <- collects, translates protocols
                    |
          [Server / cloud / dashboard]           <- stores, graphs, alerts

The four parts of every WSN

Every working WSN has the same four roles, even when one device plays two of them.

  1. Sensor nodes measure the environment and transmit readings. They are usually battery-powered and asleep most of the time.
  2. Routers or relays pass packets along for nodes too far from the gateway. In Zigbee and Thread meshes, mains-powered devices such as smart plugs often take this job.
  3. The gateway or sink (academic papers also call it the base station) receives everything and translates it. For example, it might turn ESP-NOW packets into MQTT messages on your home network.
  4. The application layer, meaning a database, a dashboard or a cloud service, stores the data and acts on it.

A WSN you probably already have at home

Smart thermostats with remote room sensors, Zigbee door contacts and Thread leak detectors are all wireless sensor networks. In a maker’s house, a typical version is three ESP32 boards in different rooms, each reading a BME280 every five minutes. They send the readings over ESP-NOW to a fourth ESP32 that publishes them to Home Assistant on a Raspberry Pi. You will build exactly that later in this article.

Inside a sensor node

A sensor node has five building blocks: a sensor, a microcontroller, a radio transceiver, memory and a power source. On modern maker hardware, three of those (the MCU, radio and memory) sit on one chip.

Sensor, brain, radio, battery

Block Job Real maker part
Sensor Converts a physical quantity into data Bosch BME280 (temperature, humidity, pressure over I2C)
Microcontroller Reads the sensor, filters, packs data, controls sleep RISC-V core inside the Espressif ESP32-C6
Radio transceiver Sends and receives packets ESP32-C6 has Wi-Fi 6, Bluetooth LE and IEEE 802.15.4 on chip
Memory Stores firmware, buffers readings, keeps state across sleep On-chip flash plus RTC memory that survives deep sleep
Power source Keeps it all running for months or years LiFePO4 cell, 2–3 AA cells with a regulator, or solar plus storage

The sensor talks to the MCU over a bus such as I2C, SPI or plain analog and digital pins. If the pin side is new to you, it helps to understand general purpose input output first. Many pins can do several jobs, and which ones you pick affects both wiring and sleep current.

LiFePO4 is popular with ESP32 builders for a practical reason. Its nominal 3.2 V sits inside the ESP32’s 3.0–3.6 V supply range, so a node can run straight from the cell with no regulator wasting current.

Power check

ESP32 chips are 3.3 V parts. Never feed a fresh 4.2 V Li-ion cell straight to the 3V3 pin. Use LiFePO4 or a low-quiescent regulator, and protect any lithium cell against short circuits.

Why the radio eats your battery

The radio is where most of the energy goes. Sensors like the BME280 draw microamps while measuring. An ESP32 transmitting draws in the order of a hundred milliamps, with short peaks that builders often measure at 200–400 mA. That is about a thousand times more. So the most important rule in WSN design is to keep the radio off as much as you can.

This is also why the protocol matters so much. A protocol that sends a packet in a few milliseconds and goes back to sleep beats one that needs seconds of handshaking. Wi-Fi is the worst case. On every wake-up, a node has to associate with the router, get an IP address and open a connection, which takes 1–3 seconds at full radio power.

How data moves: WSN topologies

WSNs use three practical topologies: star, cluster-tree and mesh. Star is simplest and most power-efficient for end nodes. Mesh gives you range and self-healing at the cost of always-on routers. Cluster-tree sits between the two.

Some textbook lists include “bus” and “ring” topologies. Those come from wired networking and make little sense for radios, where every transmission is a broadcast into the air. Ignore them for WSN design.

Star

Every node talks directly to one hub. ESP-NOW sensor setups, Bluetooth LE sensors reporting to a phone or hub, and Wi-Fi devices on a single access point are all stars.

  • Pros: simple, lowest latency, end nodes can sleep deeply, and one failed node affects nobody else.
  • Cons: range is limited to one radio hop, and if the hub fails, everything is offline.

Cluster-tree

Nodes report to a local cluster head, and cluster heads forward to the gateway. LoRaWAN uses a related “star-of-stars” model. End devices transmit to every gateway in earshot, and the gateways forward over IP to a network server that removes duplicate packets.

A maker version of this is a hybrid network. Short-range ESP-NOW clusters (a greenhouse, a barn) report to an ESP32 cluster head that also carries a LoRa radio. The cluster head combines the readings and sends one compact LoRa packet over a kilometre or more to the farmhouse. That answers a common question about pairing ESP-NOW clusters with a LoRa backbone: let the cluster head do the batching, because LoRa airtime is scarce. In Europe, the 868 MHz band also carries duty-cycle limits.

Mesh and self-healing

In a mesh, routers relay for each other, and the network finds a new path when one router drops out. Zigbee and Thread are both mesh protocols built on IEEE 802.15.4. Battery devices join as “sleepy end devices” that never relay, while mains-powered devices form the routing backbone.

  • Pros: coverage grows with every router, there is no single point of failure in the path, and it handles large buildings well.
  • Cons: routers must stay powered, you need a coordinator or border router, and every extra hop adds latency.

Single-hop vs multi-hop

Single-hop means a node reaches the sink directly. Multi-hop means packets pass through relays. The trade-off is energy against range. Multi-hop lets low-power radios cover big areas, but relay nodes burn more energy. The relays nearest the sink burn the most, because all traffic funnels through them. Researchers call this the “hotspot” or “energy hole” problem, and it is why relays should be on mains power whenever possible.

WSN protocols compared (2026)

For battery sensors around a house, use ESP-NOW if every node is an ESP32 and you want full control. Use Zigbee or Thread if you want off-the-shelf devices and a self-healing mesh. Use LoRaWAN when the distances are measured in kilometres. Wi-Fi only makes sense for nodes on mains power.

WSN protocol chooser for makers (2026)

Protocol Band Topology Payload / data rate Typical range (rough) Hub needed? Maker hardware Best for
ESP-NOW 2.4 GHz Star (mesh possible in your own code) 250 B (v1.0) or 1,470 B (v2.0) per packet; 1 Mbps default PHY Tens of metres indoors, more in the open Any ESP32 as receiver ESP32, ESP32-C3, ESP32-C6, ESP32-S3 All-ESP32 home and garden sensors
Zigbee 4.0 2.4 GHz; Suzi adds 800/900 MHz Mesh 802.15.4 frames up to 127 B; 250 kbps at 2.4 GHz One room to a house per hop, extended by routers Coordinator ESP32-C6, ESP32-H2, ESP32-H21, USB coordinator dongles Off-the-shelf smart-home sensors
Thread (with Matter) 2.4 GHz Mesh, IPv6 802.15.4 frames; 250 kbps Similar to Zigbee Border router to reach your network ESP32-C6, ESP32-H2, ESP32-H21 Cross-brand Matter devices
Bluetooth LE 2.4 GHz Star (mesh exists) Up to 2 Mbps PHY on BLE 5 Room scale Phone, hub or ESP32 proxy Nearly every ESP32, nRF boards Wearables, beacons, phone-read sensors
Wi-Fi 2.4 / 5 / 6 GHz Star via access point Megabits and up Your Wi-Fi coverage Router Any ESP32, Raspberry Pi Pico W Mains-powered nodes, cameras
LoRaWAN Sub-GHz (US915, EU868) Star-of-stars Roughly 0.3–22 kbps, small payloads Kilometres LoRaWAN gateway plus network server SX1262/SX1276 boards, RAK WisBlock Farms, cities, utility metering

The ranges are deliberately rough. Antenna, walls, height and interference can easily change real range by a factor of five, so test on your own site before you commit.

ESP-NOW

ESP-NOW is Espressif’s connectionless protocol. It sends small frames directly between ESP32 chips using Wi-Fi radio hardware, with no router, no IP stack and no association. A node can wake up, send and go back to sleep in a fraction of a second.

According to Espressif’s ESP-NOW FAQ, version 1.0 carries up to 250 bytes per packet. ESP-NOW v2.0, supported from ESP-IDF v5.4, raises this to 1,470 bytes. Espressif’s own component leaves 1,450 bytes after its 20-byte header. A v1.0 device only accepts v2.0 packets of 250 bytes or less, and longer ones are cut short or dropped.

The default PHY rate is 1 Mbps. Espressif measured one-to-one throughput at about 214 Kbps in an open environment and about 555 Kbps in a shielding box. You can change the rate per peer with esp_now_set_peer_rate_config(). For sensor readings of a few dozen bytes, throughput hardly matters. Airtime does, and ESP-NOW keeps it tiny.

Did you know?

According to Espressif’s ESP-NOW FAQ, the old 250-byte limit existed because the payload sits inside a single IEEE 802.11 vendor-specific element whose length field is one byte. Version 2.0 lifts that ceiling to 1,470 bytes.

Zigbee 4.0 and Suzi

Zigbee is a mesh protocol on top of IEEE 802.15.4, and it is maintained by the Connectivity Standards Alliance (CSA). On November 18, 2025, the CSA announced Zigbee 4.0. It brings security updates aligned with international standards, better interoperability and batch commissioning for setting up many devices at once. Coverage by The Verge also reported direct smartphone setup.

The same announcement introduced Suzi, the new brand for Zigbee’s sub-GHz feature. According to the CSA and CNX Software, Suzi runs in the 800 MHz band in Europe and the 900 MHz band in North America. Its aim is long-range, low-power mesh for larger homes, commercial sites and industrial buildings. Sub-GHz signals pass through walls and travel further than 2.4 GHz. That puts Zigbee closer to LoRa territory while keeping the mesh.

Do you need a hub? Yes. A Zigbee network needs a coordinator that forms the network and manages joins. In Home Assistant, that is usually a USB Zigbee coordinator running ZHA or Zigbee2MQTT. An ESP32-C6 or ESP32-H2 can also act as a coordinator with Espressif’s Zigbee SDK.

Thread and Matter 1.5

Thread is an IPv6 mesh on IEEE 802.15.4, so every node has a real IP address. Matter is the application layer that runs on top of Thread, Wi-Fi or Ethernet. Matter defines what a “temperature sensor” or “soil sensor” is, so devices from different brands work in Apple Home, Google Home, Amazon Alexa, SmartThings and Home Assistant.

Matter 1.5, released by the CSA in November 2025, matters most to WSN builders because it added an official soil-sensor device type. The type reports soil moisture and, optionally, temperature, and it can pair with Matter water valves for automatic irrigation. The same release added cameras (WebRTC streaming with Matter as the signalling layer), closures such as garage doors and gates, energy tariff and grid carbon-intensity data, and TCP transport. Matter 1.5.1 followed in March 2026 as a maintenance release.

The current major version is Matter 1.6, announced in June 2026. It adds NFC-based commissioning and Thermostat Suggestions and improves management across ecosystems. A 1.6.1 point release followed in September 2026.

Thread devices mesh happily without a border router. However, you need one, such as a recent smart speaker, a hub or Home Assistant with an OpenThread border router, for your phone or server to reach them.

Did you know?

Matter 1.5 (November 2025) added an official soil-sensor device type, according to the Connectivity Standards Alliance, so a garden moisture node can now be a standard smart-home device instead of a custom gadget.

LoRa and LoRaWAN

LoRa is a long-range sub-GHz radio modulation. LoRaWAN is the network protocol on top of it, standardised by the LoRa Alliance. It trades data rate for range: you get a few bytes every few minutes over kilometres, on a battery that can last years.

The LoRa Alliance reported 125 million LoRaWAN end devices deployed globally on December 10, 2025, with 25% compound annual growth. It repeated the figure in its February 17, 2026 report “LoRaWAN Enters Its Next Growth Phase as Massive IoT Scales Globally”. The count is self-reported by an industry body and may not fully cover China.

The largest operators named include ZENNER (about 10 million devices), Actility (4.6 million) and The Things Industries (3.8 million). The Alliance had 360 members after adding 57 in 2025.

For makers, the usual route is an SX1262-based board plus a community network such as The Things Network, or your own gateway. If you are asking about ESP-NOW vs LoRa range across a garden or farm: ESP-NOW covers a typical yard. LoRa is the tool once distances reach hundreds of metres with buildings or trees in the way.

Bluetooth LE and Wi-Fi: when they make sense

Bluetooth Low Energy is the right choice when a phone is the gateway. Wearables, fitness sensors and beacons all fit here. BLE advertising also lets a sensor broadcast readings without pairing, and Home Assistant can pick those up through ESP32 Bluetooth proxies.

Wi-Fi makes sense for mains-powered nodes and anything heavy on data, such as cameras. For battery sensors, the 1–3 second association on every wake-up is the problem. That is why an ESP32 that checks in over Wi-Fi every five minutes drains its battery many times faster than the same board using ESP-NOW.

Maker tip

Don’t use plain Wi-Fi for battery nodes. Each wake-up costs 1–3 seconds of full-power radio time to reconnect. ESP-NOW, Zigbee or Thread get the same reading out in milliseconds.

Which one should you choose?

  • All your nodes are ESP32 and you want full control: ESP-NOW with one ESP32 gateway.
  • You want store-bought sensors to work with yours: Zigbee or Thread/Matter on an ESP32-C6 or ESP32-H2.
  • Distances are over a few hundred metres, or you’re crossing fields: LoRa or LoRaWAN.
  • A phone or watch is the receiver: Bluetooth LE.
  • The node has mains power and moves lots of data: Wi-Fi.

What about ESPHome deep sleep compared with a custom ESP-NOW setup? ESPHome is far quicker to configure and fits neatly into Home Assistant. But a deep-sleep ESPHome node reconnects to Wi-Fi on each wake, so it pays the association cost every time. A custom ESP-NOW node takes more code and lasts much longer on the same cell. Pick ESPHome for nodes that can be charged or that report rarely. Pick ESP-NOW when battery life is the priority.

Types of wireless sensor networks

Researchers group WSNs by where they are deployed and what they carry. The five standard types are terrestrial, underground, underwater, multimedia and mobile. Each one exists because the medium or the data changes the engineering problem.

Types of WSN at a glance

Type Medium Main challenge Example use
Terrestrial Air, at ground level Battery life, coverage Home climate, crop fields, data-center racks
Underground Soil and rock Radio waves absorbed by soil Soil moisture, tunnels, landslide monitoring
Underwater Water Radio barely works, acoustic waves are slow Ocean monitoring, pipelines, aquaculture
Multimedia Air Bandwidth and energy for images, audio and video Security cameras, traffic monitoring
Mobile Air, nodes moving Changing topology, routing Robots, drones, vehicles, animal tags

Terrestrial

These are the common case: nodes on or above ground, talking through the air. Your ESP-NOW house network, a vineyard LoRaWAN deployment and a Zigbee office are all terrestrial. The design problems are coverage and keeping batteries alive.

Underground

Soil, especially wet soil, absorbs radio signals quickly. Underground networks therefore bury the sensors and keep the radio near the surface, use low frequencies, or use magnetic induction (MI), which couples coils through the soil instead of sending a radiating wave. Research groups, including a geomechanics team at UC Berkeley, have explored MI-based underground sensing for monitoring infrastructure and the ground.

Underwater

Radio frequencies fade within metres in seawater, so underwater WSNs mostly use acoustic modems. Sound travels at around 1,500 m/s in water, which is fast for sound but very slow next to radio. The results are high latency, low bandwidth and tricky timing. Surface buoys often act as gateways to satellite or cellular links.

Multimedia

Multimedia WSNs carry images, audio and video in addition to scalar readings. That breaks the usual “few bytes, rarely” pattern, so these nodes need more bandwidth and more power. Matter 1.5’s camera support, which uses WebRTC for streaming, is a mainstream example of multimedia sensing moving into consumer networks.

Mobile

In a mobile WSN, nodes move. Examples include robots, drones, tagged animals and vehicles. Routes change constantly, so protocols must handle neighbours appearing and disappearing. A good small-scale example is student ESP32 prototype cars that warn each other of hazards over radio. That is a vehicle-to-vehicle mobile network built on the same chips as this article’s build. If your nodes ride on robots, the power budget has to share space with the motors and servos, which usually dominate.

Real-world applications and examples

WSNs are used wherever measuring something by hand is too slow, too dangerous or too expensive. The biggest groups are homes, agriculture, industry and data centers, utilities, healthcare and environmental science.

Home and garden

Room-by-room climate sensing, leak detection, door and window contacts, and garden soil moisture make up the maker’s core list. Soil sensing just became a standard category. A Matter 1.5 soil sensor can trigger a Matter water valve with no custom integration. An ESP32-C6 running Thread is well suited to building one.

Industry and data centers

Factories use WSNs for vibration-based predictive maintenance, tank levels and temperature. Wireless helps most on rotating or retrofitted equipment, where running cable costs more than the sensor.

Data centers are a mature commercial case. Vertiv’s Wireless Sensor Network product supports hundreds of sensors per gateway for rack temperature, humidity and similar readings. It integrates with building systems through Vertiv’s RDU120 monitoring unit or Modbus TCP, which is typical of how commercial WSNs connect to existing management software.

Cities and utilities

Utility metering is where LoRaWAN scale shows up. Two of the LoRa Alliance’s largest named operators, ZENNER and Birdz, are metering companies. Cities also use WSNs for parking occupancy, air quality, waste-bin fill levels and street lighting. Sub-GHz protocols dominate here because range per gateway decides the cost.

Healthcare is the other big field: wearable sensors form body-area networks, usually over Bluetooth LE, that report to a phone or bedside hub.

Science and the environment

Wildlife and climate research is where WSNs started. On Great Duck Island in 2002, Intel Research and UC Berkeley researchers worked with the College of the Atlantic to deploy 32 motes in Leach’s storm-petrel burrows and the surrounding habitat. The network logged over a million readings by late November, and a 56-node second generation followed in 2003. The project showed scientists could monitor sensitive habitat without disturbing it.

Geotechnical monitoring (slopes, dams, tunnels and bridges) uses the same principles with tougher enclosures and longer deployments.

Build one: a 3-node ESP32 sensor network with ESP-NOW

This build gives you a working WSN: three battery nodes that wake, read a BME280, send over ESP-NOW and sleep. An always-on ESP32 gateway forwards each reading to an MQTT broker, and Home Assistant on a Raspberry Pi graphs it. The code targets the Arduino-ESP32 core 3.x.

Build steps

  1. Flash the gateway and note its MAC address and Wi-Fi channel.
  2. Wire a BME280 to each ESP32-C6 node.
  3. Put the gateway MAC, channel and a unique node ID into each node sketch, then flash it.
  4. Install Mosquitto and add the MQTT sensors to Home Assistant.
  5. Walk the nodes around your home and garden, and log RSSI and lost packets.

What you need

Part Qty Notes
ESP32-C6 board 3 Sensor nodes. A board with a low-quiescent regulator and no always-on LED gives the best sleep current
Any ESP32 board 1 Gateway on USB power. An ESP32-C6 also works
BME280 breakout (3.3 V) 3 I2C address 0x76 or 0x77 depending on the board
LiFePO4 cell and holder 3 3.2 V nominal, runs the ESP32 directly
100–470 µF capacitor 3 Across 3V3 and GND to smooth the transmit current spikes
Raspberry Pi 4 or 5 1 Home Assistant OS, or Raspberry Pi OS with Mosquitto
Jumper wires, breadboard 1 set

Software: the Arduino IDE with the Espressif ESP32 core 3.x, the Adafruit BME280 Library (which installs Adafruit Unified Sensor) and PubSubClient by Nick O’Leary.

Wiring (each node)

From pin To pin Wire purpose
BME280 VIN / VCC ESP32-C6 3V3 3.3 V power
BME280 GND ESP32-C6 GND Ground
BME280 SDA ESP32-C6 GPIO23 I2C data
BME280 SCL ESP32-C6 GPIO22 I2C clock
Capacitor + ESP32-C6 3V3 Supply buffer for transmit peaks
Capacitor − ESP32-C6 GND Ground

GPIO23 and GPIO22 match the Arduino core’s default I2C pins for the ESP32-C6. Any free GPIO works if you change the defines. Most BME280 breakouts already carry I2C pull-up resistors.

Node code: sense, send, sleep

The node does everything in setup() and never reaches loop(). Deep sleep restarts the chip, and a counter in RTC memory survives between wakes so the gateway can spot missing packets.

// WSN node: BME280 -> ESP-NOW -> deep sleep (Arduino-ESP32 core 3.x)
\#include <WiFi.h>
\#include <esp_now.h>
\#include <esp_wifi.h>
\#include <Wire.h>
\#include <Adafruit_BME280.h>

\#define NODE_ID        1        // unique per node: 1, 2, 3
\#define WIFI_CHANNEL   6        // must match the gateway's channel
\#define SLEEP_SECONDS  300      // 5 minutes
\#define SDA_PIN        23
\#define SCL_PIN        22
\#define BME_ADDR       0x76     // try 0x77 if begin() fails

uint8_t gatewayMac[6] = {0x24, 0x6F, 0x28, 0xAA, 0xBB, 0xCC}; // replace with your gateway's MAC

typedef struct __attribute__((packed)) {
  uint8_t  nodeId;
  uint32_t bootCount;
  float    temperature;
  float    humidity;
  float    pressure;
} SensorPacket;

RTC_DATA_ATTR uint32_t bootCount = 0;
Adafruit_BME280 bme;

void goToSleep() {
  esp_sleep_enable_timer_wakeup((uint64_t)SLEEP_SECONDS * 1000000ULL);
  esp_deep_sleep_start();
}

void setup() {
  bootCount++;

  Wire.begin(SDA_PIN, SCL_PIN);
  if (!bme.begin(BME_ADDR, &Wire)) {
    goToSleep();                       // no sensor: don't waste battery
  }
  // Forced mode: one measurement, then the BME280 sleeps by itself
  bme.setSampling(Adafruit_BME280::MODE_FORCED,
                  Adafruit_BME280::SAMPLING_X1,   // temperature
                  Adafruit_BME280::SAMPLING_X1,   // pressure
                  Adafruit_BME280::SAMPLING_X1,   // humidity
                  Adafruit_BME280::FILTER_OFF);
  bme.takeForcedMeasurement();

  SensorPacket pkt;
  pkt.nodeId      = NODE_ID;
  pkt.bootCount   = bootCount;
  pkt.temperature = bme.readTemperature();
  pkt.humidity    = bme.readHumidity();
  pkt.pressure    = bme.readPressure() / 100.0F;   // hPa

  WiFi.mode(WIFI_STA);
  esp_wifi_set_promiscuous(true);
  esp_wifi_set_channel(WIFI_CHANNEL, WIFI_SECOND_CHAN_NONE);
  esp_wifi_set_promiscuous(false);

  if (esp_now_init() != ESP_OK) {
    goToSleep();
  }

  esp_now_peer_info_t peer = {};
  memcpy(peer.peer_addr, gatewayMac, 6);
  peer.channel = WIFI_CHANNEL;
  peer.encrypt = false;
  esp_now_add_peer(&peer);

  esp_now_send(gatewayMac, (uint8_t *)&pkt, sizeof(pkt));
  delay(20);                           // let the frame and MAC-level ACK finish

  goToSleep();
}

void loop() {
  // never reached
}

The packet is 17 bytes, far below the 250-byte ESP-NOW v1.0 limit. Every node therefore works with every ESP-IDF version on the gateway.

Maker tip

Keep ESP-NOW payloads at 250 bytes or less if any device in your network runs an ESP-IDF version older than v5.4. v1.0 receivers cut short or drop larger v2.0 packets.

Gateway code: ESP-NOW to MQTT

Yes, ESP-NOW and Wi-Fi can run at the same time on the gateway, with one catch: they share a single radio, so ESP-NOW listens on whatever channel your router uses. The gateway connects to Wi-Fi first and prints its channel, and you set that same channel in every node.

The receive callback runs inside the Wi-Fi task, so it only copies each packet into a FreeRTOS queue. Publishing happens in loop().

// WSN gateway: ESP-NOW receiver -> MQTT publisher (Arduino-ESP32 core 3.x)
\#include <WiFi.h>
\#include <esp_now.h>
\#include <PubSubClient.h>

const char*    WIFI_SSID = "your-ssid";
const char*    WIFI_PASS = "your-password";
const char*    MQTT_HOST = "192.168.1.50";   // Raspberry Pi / Home Assistant IP
const uint16_t MQTT_PORT = 1883;
const char*    MQTT_USER = "mqtt-user";
const char*    MQTT_PASS = "mqtt-pass";

typedef struct __attribute__((packed)) {
  uint8_t  nodeId;
  uint32_t bootCount;
  float    temperature;
  float    humidity;
  float    pressure;
} SensorPacket;

typedef struct {
  SensorPacket pkt;
  int8_t       rssi;
} RxItem;

QueueHandle_t rxQueue;
WiFiClient    net;
PubSubClient  mqtt(net);

void onRecv(const esp_now_recv_info_t *info, const uint8_t *data, int len) {
  if (len != sizeof(SensorPacket)) return;
  RxItem item;
  memcpy(&item.pkt, data, sizeof(SensorPacket));
  item.rssi = info->rx_ctrl->rssi;
  xQueueSend(rxQueue, &item, 0);
}

void connectMqtt() {
  while (!mqtt.connected()) {
    if (!mqtt.connect("espnow-gateway", MQTT_USER, MQTT_PASS)) {
      delay(2000);
    }
  }
}

void setup() {
  Serial.begin(115200);
  rxQueue = xQueueCreate(16, sizeof(RxItem));

  WiFi.mode(WIFI_STA);
  WiFi.setSleep(false);                 // keep the radio listening for ESP-NOW
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) {
    delay(250);
  }
  Serial.printf("Gateway MAC: %s  Wi-Fi channel: %d\n",
                WiFi.macAddress().c_str(), WiFi.channel());

  if (esp_now_init() != ESP_OK) {
    Serial.println("ESP-NOW init failed");
    return;
  }
  esp_now_register_recv_cb(onRecv);

  mqtt.setServer(MQTT_HOST, MQTT_PORT);
}

void loop() {
  if (!mqtt.connected()) connectMqtt();
  mqtt.loop();

  RxItem item;
  while (xQueueReceive(rxQueue, &item, 0) == pdTRUE) {
    char topic[40];
    char payload[160];
    snprintf(topic, sizeof(topic), "wsn/node%u/state", item.pkt.nodeId);
    snprintf(payload, sizeof(payload),
             "{\"t\":%.2f,\"h\":%.1f,\"p\":%.1f,\"boot\":%lu,\"rssi\":%d}",
             item.pkt.temperature, item.pkt.humidity, item.pkt.pressure,
             (unsigned long)item.pkt.bootCount, item.rssi);
    mqtt.publish(topic, payload);
    Serial.printf("%s %s\n", topic, payload);
  }
}

Unencrypted ESP-NOW frames addressed to the gateway are accepted without registering each sender as a peer. The gateway therefore isn’t bound by ESP-NOW’s 20-peer table limit when it only receives.

Maker tip

Many routers change channel automatically. If your nodes suddenly go silent, check the channel the gateway prints at boot, or fix the router’s 2.4 GHz channel so the nodes and gateway always match.

Seeing the data on a Raspberry Pi or Home Assistant

You need an MQTT broker. On Home Assistant OS, install the Mosquitto broker add-on and the MQTT integration. On plain Raspberry Pi OS, run sudo apt install mosquitto mosquitto-clients. Mosquitto 2.x only listens locally by default, so add a listener 1883 line and a password file before the gateway can connect.

Check the data arriving:

mosquitto_sub -h localhost -u mqtt-user -P mqtt-pass -t 'wsn/#' -v

Then define the sensors in Home Assistant’s configuration.yaml. Repeat the block for node2 and node3:

mqtt:
  sensor:
    - name: "Node 1 temperature"
      state_topic: "wsn/node1/state"
      unit_of_measurement: "°C"
      device_class: temperature
      value_template: "{{ value_json.t }}"
      expire_after: 900
    - name: "Node 1 humidity"
      state_topic: "wsn/node1/state"
      unit_of_measurement: "%"
      device_class: humidity
      value_template: "{{ value_json.h }}"
      expire_after: 900
    - name: "Node 1 RSSI"
      state_topic: "wsn/node1/state"
      unit_of_measurement: "dBm"
      device_class: signal_strength
      value_template: "{{ value_json.rssi }}"

expire_after: 900 marks a sensor unavailable after three missed five-minute reports. That gives you a free dead-node alarm. If you want a readout without a screen nearby, the gateway can also drive a small character display. A 16×2 liquid crystal display (LCD) on I2C is the usual choice.

Testing range and packet loss

The bootCount field turns the gateway log into a packet-loss meter. If node 2 reports boot counts 41, 42 and then 44, packet 43 was lost. Use this method:

  1. Leave all three nodes next to the gateway for an hour and confirm zero gaps.
  2. Move one node to its final spot and watch the RSSI. Readings around −70 dBm or better are comfortable. Below about −85 dBm, expect losses.
  3. Log at least a day, because doors, people and neighbours’ Wi-Fi traffic change the results.
  4. For weak links, raise the node or turn its antenna, move the gateway to a central spot, or add a mains-powered relay ESP32 that re-sends packets.

ESP-NOW unicast already gets a MAC-level acknowledgement and retries. If a node still loses packets at its final spot, sending twice costs far less than a site survey.

Battery life math, and why your node dies in a week

Battery life depends on average current, and average current is set mostly by two numbers: the sleep current and the charge used per wake-up. On a well-built ESP-NOW node, that adds up to years. On a stock dev board, the sleep current alone can empty the cell in under a week.

The duty-cycle formula

Charge per cycle = (awake current × awake time) + (sleep current × sleep time). Divide your usable battery capacity by the charge per day.

Here is a worked example for one ESP-NOW node reporting every five minutes. The awake figures are a realistic assumed profile for an ESP32 waking from deep sleep. Measure your own board to replace them.

Battery-life worked example

State Current Time per cycle Charge per cycle
Boot and BME280 read 40 mA 0.12 s 4.8 mA·s (1.33 µAh)
ESP-NOW transmit (average, including peaks) 150 mA 0.03 s 4.5 mA·s (1.25 µAh)
Deep sleep, bare module plus sensor 20 µA 300 s 6.0 mA·s (1.67 µAh)
Total per 5-minute cycle 15.3 mA·s (4.25 µAh)

At 288 cycles a day, that comes to about 1.22 mAh per day. With a LiFePO4 cell rated around 1,500 mAh and roughly 1,200 mAh usable, that is about 980 days on paper. Real life, with cold weather, self-discharge and retries, will come in lower. Two years is a fair target.

Now swap ESP-NOW for Wi-Fi with a 2-second connection at over 350 mA. Each wake-up costs about 195 µAh. Daily use jumps to roughly 57 mAh, and the same cell lasts about 21 days.

Now keep ESP-NOW but leave the node on a dev board that draws 10 mA asleep. Sleep alone costs 833 µAh per cycle, or 240 mAh a day. The battery is flat in about five days. That answers the question of why a deep-sleep ESP32 sensor drains its battery in weeks instead of years: the code is usually fine, and the board is the problem.

A small LiFePO4 cell handles the 200–400 mA transmit spikes well, because those spikes last milliseconds. They barely move the energy total, but they can cause a brownout reset if the cell or wiring has high resistance. A 100–470 µF capacitor next to the module covers those peaks.

Dev board vs bare module

Chip / board Radios Deep-sleep current Source type
ESP32-H21 chip Bluetooth LE, IEEE 802.15.4 (Thread, Zigbee) 5 µA (9 µA light sleep) Espressif announcement, March 2026
ESP32-C6 chip Wi-Fi 6, Bluetooth LE, IEEE 802.15.4 7 µA Datasheet figure via distributor listing
Bare ESP32 module Wi-Fi, Bluetooth About 7–10 µA Independent 2026 board guide
Typical ESP32 dev board Same as module 5–15 mA Independent 2026 board guide

The gap between the last two rows is about a thousand to one. It comes from parts the chip doesn’t control: linear regulators with high quiescent current, USB-to-serial bridges, power LEDs and pull-up resistors. Espressif’s ESP32-H21 also adds an on-chip DC-DC converter. Espressif quotes RX current of about 8.2 mA with it enabled, which reduces the awake-time cost as well as the sleep floor.

Maker tip

Measure your actual board’s sleep current with a multimeter in series, or a power profiler, before you trust any battery estimate. Readings in milliamps mean a board part is leaking. Readings in microamps mean you’re close.

Five fixes that add months

  1. Remove or cut the power LED. A single LED can draw more than the whole chip asleep.
  2. Use a low-quiescent-current regulator, or none. LiFePO4 runs an ESP32 directly. If you need a regulator, choose one with microamp quiescent current.
  3. Batch readings. Store several readings in RTC memory and send them in one packet. ESP-NOW v2.0’s 1,470-byte payload makes large batches practical.
  4. Send on change. Skip the transmission when the temperature hasn’t moved by more than a set threshold, and send a heartbeat every hour or so.
  5. Skip Wi-Fi association completely. That is the whole point of ESP-NOW, Zigbee and Thread on battery nodes.

The big challenges in WSNs

The five problems that decide whether a WSN works are energy, security, interference, node failure and scaling. Energy is the hardest because every other fix (encryption, retries, mesh routing) costs more energy.

Energy (the #1 challenge)

Nodes can’t be recharged easily, so energy limits the lifetime of the whole network. The fixes are the ones above: deep sleep, short radio-on time, low-leakage hardware and fewer transmissions. Energy harvesting from small solar panels or vibration extends this further, but only if the node’s average draw already fits within the harvested power.

Security

Sensor packets can be sniffed, spoofed or replayed, and a fake temperature can trigger a real heater. ESP-NOW supports encrypted peers using a primary key (PMK) and per-peer local keys (LMK). Each encrypted peer must be registered, and the number of encrypted peers is limited, which matters at the gateway.

Zigbee 4.0’s security updates align the protocol with international standards. Thread and Matter add certificate-based commissioning, and Matter 1.6 improved certificate revocation list handling. Whatever protocol you use, control who can join and change default keys.

Interference and congestion

ESP-NOW, Wi-Fi, Bluetooth LE, Zigbee and Thread all share the crowded 2.4 GHz band. Microwave ovens add noise too. A busy apartment block can push packet loss up sharply. Fixes include picking quieter channels, choosing Zigbee and Wi-Fi channels that don’t overlap, adding random jitter to transmit times so nodes don’t collide, and moving long links to sub-GHz with LoRa or Suzi.

Node failure and scaling

Nodes die from flat batteries, water and wildlife. Design for it. Report a heartbeat, alarm on silence (the expire_after trick), and use mesh routing where a single dead relay would cut off a whole wing.

Scaling brings its own limits. Collisions grow with node count, and the routers nearest the sink carry everyone’s traffic. Cluster heads that combine data, staggered reporting schedules and multiple gateways (LoRaWAN’s star-of-stars) are the standard fixes. Commercial systems such as Vertiv’s handle hundreds of sensors per gateway by design.

WSN vs IoT: what’s the difference?

A wireless sensor network is the sensing and networking layer: nodes, radios and a sink. The Internet of Things is the wider system of connected devices, cloud services, apps and actuators that act on data. Most WSNs today are part of an IoT system, but a WSN can run entirely offline, and an IoT device doesn’t need to be a sensor at all.

Put concretely: your three ESP-NOW nodes and gateway are a WSN. Add Home Assistant automations that open a window vent when node 2 reads 28 °C, plus remote access from your phone, and the whole thing becomes an IoT system.

Short history: Smart Dust to Matter

WSN research is older than the everyday use of the term “IoT”. In the late 1990s, Kris Pister at UC Berkeley led the DARPA-funded Smart Dust project, which aimed to build sensing and communicating motes the size of a grain of sand. David Culler’s group built TinyOS, a tiny event-driven operating system for these motes. Berkeley’s Mica-family motes became the standard research platform.

In 2002 came the Great Duck Island deployment. In 2003, Berkeley’s “Spec” mote put the radio and custom circuits on a single chip running TinyOS. Pister co-founded Dust Networks to commercialise low-power mesh networking. Meanwhile, IEEE 802.15.4 (2003) gave the field a standard low-power radio layer, with Zigbee, and later Thread, built on top.

The thread from those motes runs straight to Zigbee 4.0, Matter 1.6 and the ESP32-C6 on your bench.

The four types of wireless networks (and where WSNs fit)

Wireless networks are grouped by range into four types: WPAN (personal area), WLAN (local area), WMAN (metropolitan area) and WWAN (wide area). WSN protocols sit mostly in WPAN and in low-power wide-area networks, which act as a WWAN for sensors.

Network type Typical reach Standards and protocols WSN role
WPAN A room to a house Bluetooth LE, IEEE 802.15.4 (Zigbee, Thread), ESP-NOW in practice Most home and building sensor networks
WLAN A building or campus Wi-Fi (IEEE 802.11) Gateways, mains-powered and camera nodes
WMAN A city district Historically WiMAX; city LoRaWAN networks fill this space for sensors Smart-city sensing
WWAN Regional to national Cellular (LTE-M, NB-IoT), LPWAN such as LoRaWAN Farms, utilities, remote assets

ESP-NOW technically runs on Wi-Fi radio hardware but behaves like a WPAN protocol: peer to peer, no access point, short range.

Learn more: books, simulators and virtual labs

Simulators are the cheapest way to study WSN routing, especially for networks of hundreds of nodes that you couldn’t afford to build. Use simulators for protocols and scale, and real hardware for energy and radio behaviour.

  • Contiki-NG with Cooja: Contiki-NG is an open-source OS for low-power IoT devices, with IPv6, 6LoWPAN and RPL routing over IEEE 802.15.4. Cooja is its network simulator, which can emulate real node firmware. It is the closest thing to a free WSN virtual lab.
  • ns-3: a discrete-event network simulator widely used in research, with models for IEEE 802.15.4 (LR-WPAN), Wi-Fi and LTE.
  • OMNeT++: another research simulator with many wireless frameworks built on it.
  • Reading: the original Great Duck Island paper and Berkeley’s TinyOS papers explain the core design trade-offs better than most textbooks. Any recent WSN textbook adds MAC protocols and routing.
  • Hands-on: build the network above, then move one node to Thread on an ESP32-C6 with Espressif’s ESP-IDF examples, and compare its battery drain with ESP-NOW.

When choosing a dev board for experiments, check which radios it has. The newer Espressif kits differ a lot. For example, the ESP-Mosaico dev kit pairs the ESP32-S31 with a touchscreen and plug-in modules, which suits a gateway or dashboard more than a sleepy node.

FAQ

What is a wireless sensor network?

A wireless sensor network is a group of small, usually battery-powered nodes that measure physical conditions and send the data by radio to a gateway. From there, it is stored, displayed or acted on. Typical nodes combine a sensor, a microcontroller, a radio and a battery.

What is a major challenge in wireless sensor networks?

Energy is the biggest challenge. Nodes run on batteries for months or years, and the radio uses far more power than anything else. Security, 2.4 GHz interference, node failure and scaling come next, and each of their fixes costs energy too.

What is the difference between a wireless sensor network and IoT?

A WSN is the sensing and radio networking layer. IoT is the broader system that adds internet connectivity, cloud or local servers, apps, automations and actuators. A WSN can work offline, and many IoT devices aren’t sensors.

What are the four types of wireless networks?

They are WPAN (personal area, such as Bluetooth LE and Zigbee), WLAN (local area, Wi-Fi), WMAN (metropolitan area) and WWAN (wide area, such as cellular and LoRaWAN). Most WSNs use WPAN or low-power wide-area protocols.

What are examples of wireless sensor networks?

Zigbee door and motion sensors in a smart home, LoRaWAN water meters across a city, rack temperature sensors in a data center such as Vertiv’s system, soil moisture networks on farms, and research networks like Great Duck Island’s seabird monitoring.

What protocols do wireless sensor networks use?

The common ones are IEEE 802.15.4 with Zigbee or Thread on top, Bluetooth Low Energy, Wi-Fi, LoRa and LoRaWAN, and, for ESP32 projects, ESP-NOW. Matter runs on top of Thread or Wi-Fi to make devices from different brands work together.

What are the components of a sensor node?

A sensor, a microcontroller, a radio transceiver, memory and a power source. On chips like the ESP32-C6, the microcontroller, radio and memory share one piece of silicon.

What topology is best for a wireless sensor network?

Star is best for small networks where every node can reach the gateway directly, because end nodes sleep longest. Mesh is best for large buildings or patchy coverage, as long as you have mains-powered routers. Star-of-stars (LoRaWAN) suits wide areas.

How long can a wireless sensor node run on batteries?

A well-designed node reporting every few minutes over ESP-NOW, Zigbee or Thread can run for one to several years on a single cell. The same node on Wi-Fi might last a few weeks, and on a dev board that leaks milliamps in sleep, under a week.

Can I build a wireless sensor network with ESP32 or Arduino?

Yes. ESP32 boards are the easiest route because ESP-NOW, Wi-Fi and Bluetooth LE are built in. The ESP32-C6, ESP32-H2 and ESP32-H21 also support Zigbee and Thread. Classic Arduino boards need an add-on radio module.

How do I get ESP-NOW sensor data into Home Assistant?

Use an always-on ESP32 gateway that receives ESP-NOW and publishes each reading to an MQTT broker, such as the Mosquitto add-on. Then define MQTT sensors in Home Assistant, as in the build above.

Do I need a hub or coordinator for Zigbee or Thread sensors?

Zigbee needs a coordinator, usually a USB dongle on Home Assistant or a commercial hub. Thread nodes form their mesh by themselves but need a border router to talk to your home network and to Matter controllers.

Your next step

Start with one node and the gateway, and measure that node’s sleep current before you build the other two. If the meter shows microamps, your network will run for years. If it shows milliamps, fix the board first. Once the numbers are right, adding nodes is just a change to NODE_ID.

Notes on this article

Written by

Samir covers Raspberry Pi, ESP32 and IoT projects, coding for microcontrollers and small robots. He likes projects that solve a real problem at home and writes them up so you can follow along with the same parts.

Covers: ESP32 & IoT, Raspberry Pi

  • Fact-checked by Hugo Lindgren against the sources listed below before publication.
  • Published

Fact-checking

  • Researched from 8 sources, listed below.
  • Every claim is checked by Hugo Lindgren; anything we cannot confirm is corrected, labelled or removed.
Sources (8)
  1. ESP-NOW FAQ, Espressif (docs.espressif.com)
  2. ESP-NOW API reference, ESP-IDF (docs.espressif.com)
  3. Matter 1.5 Introduces Cameras, Closures and Enhanced Energy Management Capabilities, CSA (csa-iot.org)
  4. Matter 1.5 brings support for cameras, soil sensors, and closures, Neowin (neowin.net)
  5. Matter 1.6 Announced With NFC Setup, MacRumors (macrumors.com)
  6. Matter 1.6.1 Arrives on the First Platforms (matter-smarthome.de)
  7. CSA announces Zigbee 4.0 and Suzi (csa-iot.org)
  8. Zigbee 4.0 introduces Suzi Sub-GHz connectivity, CNX Software (cnx-software.com)