ESP32 (35) – BLE, scan response

In the previous posts I explained how to receive and send advertising packets based on the Bluetooth LE standard.

The payload (that is the amount of “useful” data) of those packets is at most 31 bytes. It isn’t much: if – for example – you want to include the device name, little place remains for other data.

The BLE standard allows peripherals to send additional data using the scan request – scan response process.

When a device receives an advertising packet, it can contact the transmitter by sending a scan request packet to request further information. When receiving a scan request package, the peripheral can respond with a scan response packet:


Advertising and scan request packets have the same format; it’s therefore possible to transfer, using scan response, additional 31 bytes of data.


The esp framework offers two modes for configuring the content of a scan response packet: using the esp_ble_adv_data_t struct or creating a byte array (raw mode). These modes are similar to the ones used to configure advertising packets you learned in previous articles (struct and raw mode).

In the first case, you have to declare a second struct, in addition to the one related to the advertising packet, to define the content of the scan response packet:

static uint8_t manufacturer_data[6] = {0xE5,0x02,0x01,0x01,0x01,0x01};
static esp_ble_adv_data_t scan_rsp_data = {
  .set_scan_rsp = true,
  .manufacturer_len = 6,
  .p_manufacturer_data = manufacturer_data,

Very important is set to true the set_scan_rsp parameter. It’s indeed this parameter what tells the driver that this struct is related to the scan response packet.

You can then pass the new struct to the driver, with the same function used previously:


The driver will call the callback function twice: one to indicate the successful configuration of the advertising packet and one for the configuration of the scan response one. The two events are different:


You have to wait until both the events have triggered before starting the advertising process. In my example program (you can download the source code from my Github repository) I use two boolean variables:

bool adv_data_set = false;
bool scan_rsp_data_set = false;
  adv_data_set = true;
  if(scan_rsp_data_set) esp_ble_gap_start_advertising(&ble_adv_params); break;
  scan_rsp_data_set = true;
  if(adv_data_set) esp_ble_gap_start_advertising(&ble_adv_params); break;

If you want to use the raw mode instead, you have to declare a byte array and fill it with the content of the payload of the packet. Then you can use a specific function of the framework to pass the array to the driver:

static uint8_t scan_rsp_raw_data[8] = {0x07,0xFF,0xE5,0x02,0x01,0x01,0x01,0x01};
esp_ble_gap_config_scan_rsp_data_raw(scan_rsp_raw_data, 8);

did you notice that the content of the scan response packet is the same in the two examples?

The driver will confirm the configuration of the packet with a dedicated event. Also in this case you have to wait for the end of both configurations (advertising and scan response):

  scan_rsp_data_set = true;
  if(adv_data_set) esp_ble_gap_start_advertising(&ble_adv_params); break;
You can also mix the two modes in your program. For example you can configure the advertising packet using the struct and configure the scan response one using the raw mode.

Now with the nRF Connect app you can verify that your scan response packet is correctly received by your smartphone:


In the following video I explain how I built the payload of the packet and how the program works:

ESP32 (34) – BLE, raw advertising

In the previous post, you learned how to send BLE advertising packets with the esp32 chip.

To define the content of the packet, you used a struct, of the esp_ble_adv_data_t type:


The struct’s definition is included in the esp_gap_ble_api.h file:


Although there are many fields available, sometimes it is necessary to be able to define the content of the advertising packet arbitrarily. For this reason, the esp-idf framework provides a raw mode.

Instead of defining a struct, you create a byte array and fill it with the entire contents of the packet’s payload:

static uint8_t adv_raw_data[10] = 

then you can use the esp_ble_gap_config_scan_rsp_data_raw() function to pass the array to the driver. You have to specify both the array and its size as parameters:

esp_ble_gap_config_scan_rsp_data_raw(scan_rsp_raw_data, 8);

When using this new function, it also changes the event that the driver passes to your callback function when the configuration is complete. The new event is ESP_GAP_BLE_ADV_DATA_RAW_SET_COMPLETE_EVT. As in the previous example, when this event is triggered you can start the advertising process:


Raw data

For the advertising process to work, the data contained in the array must correspond to a valid payload.

In the blog post about the iBeacons, I’ve already shown you its structure. Let’s briefly review it:


The payload contains one or more AD (advertising data) structures. Each structure is made by 3 fields:

  • an initial byte that represents the length (in bytes) of the structure, excluding itself
  • a byte that represents the type of the data contained in the structure
  • a variable number of bytes which are the actual data

The codes that can be used to define the type of data can be found in the Bluetooth specifications. Depending on the type of data, it is then necessary to apply a particular format to the data that follows. The necessary information is found in the Core Specification Supplement document (available on the website).

Let’s see a simple example: the ADType 0x09 represents the complete local name, which is the name of the device. This name must be specified in AD data with simply a sequence of the ASCII codes that correspond to the different letters.

You can use a website to do the conversion:


The payload to transmit this name is therefore:

adv_raw_data[7] = {0x06,0x09,0x4d,0x79,0x42,0x4c,0x45};

The first byte has value 0x06 that is the sum of the name length (5 bytes) and 1 byte for the data type (0x09).


In the following video you can see how I use the raw advertising feature to simulate the advertising packet of my iBeacon and therefore I’m able to activate the relay as in the previous example.

The source code of the program is available in my Github repository.

Alexa (Echo) with ESP32 and ESP8266 – Voice controlled relay


Rui Santos writes, “In this project, you’re going to learn how to control the ESP8266 or the ESP32 with voice commands using Alexa (Amazon Echo Dot). As an example, we’ll control two 12V lamps connected to a relay module. We’ll also add two 433 MHz RF wall panel switches to physically control the lamps.”

More info at

Check out the video after the break.

ESP32 (33) – BLE, advertising

In the previous posts you learned how to use the esp32 chip to receive and parse the advertising packets transmitted by BLE peripherals. As a practical example, I developed a program to detect the presence of a particular iBeacon and activate an output accordingly.

In today’s tutorial, you’ll learn how to transmit advertising packets instead.

Advertising process

You’ve already discovered that the Bluetooth driver included in the esp-idf stack is executed in a dedicated thread. Whenever the driver needs to send a notification to your program, it calls a callback function indicating which event has triggered.

The advertising process is very simple:

  • the program configures the data to be transmitted with esp_ble_gap_config_adv_data()
  • the driver reports that it has finished the configuration with the event ESP_GAP_BLE_ADV_DATA_SET_COMPLETE_EVT
  • the program can now start the advertising process with esp_ble_gap_start_advertising()
  • the driver reports that the process has started with the event ESP_GAP_BLE_ADV_START_COMPLETE_EVT


Advertising DATA

It’s possible to tell the driver which data to include in the advertising packet with the following command:

esp_err_t esp_ble_gap_config_adv_data(esp_ble_adv_data_t *adv_data);

The command accepts as parameter a pointer to an esp_ble_adv_data_t struct:


The meaning of the different fields is explained in the Supplement to the Bluetooth Core Specification document.

First let’s find out how to transmit the device name. You have to use the esp_ble_gap_set_device_name() function to pass the name to the driver and set the field include_name to true in the struct:

static esp_ble_adv_data_t adv_data = {
  .include_name = true,

Using the flags, you can publish some features of your device. The available constants are:


you can combine them with the OR operator. If, for example, you want to tell the world that your device is limited discoverable (i.e. it sends the advertising packets only for a limited time, usually 30 seconds) and that it doesn’t support classic Bluetooth (BR/EDR, Basic Rate/Enhanced Data Rate) you’ll write:

static esp_ble_adv_data_t adv_data = {

Advertising PARAMETERS

After configuring the content of the advertising packet, you have also to tell the driver how to send the packet.

The command:

esp_err_t esp_ble_gap_start_advertising(esp_ble_adv_params_t *adv_params);

accepts as parameter an esp_ble_adv_params_t struct:


You can configure the minimum and maximum transmission interval of the packet. The two parameters can assume a value from 0x20 to 0x4000. To calculate the interval in milliseconds, the value specified must be multiplied for 0.625. This means that the minimum value (0x20) corresponds to an interval of 12.5ms.

The esp_gap_ble_api.h file lists the constants that can be used for the other parameters (esp_ble_adv_type_t, esp_ble_addr_type_t …).

For example, let’s configure the advertising process as it follows:

  • minimum transmission interval: 0x20, maximum: 0x40
  • non connectable device (it doesn’t accept incoming connections and only sends data in broadcast)
  • public MAC address
  • transmission on all the 3 channels dedicated to advertising packets
  • no filter on devices who can perform a scan or connect
static esp_ble_adv_params_t ble_adv_params = {
  .adv_int_min = 0x20,
  .adv_int_max = 0x40,
  .adv_type = ADV_TYPE_NONCONN_IND,
  .own_addr_type  = BLE_ADDR_TYPE_PUBLIC,
  .channel_map = ADV_CHNL_ALL,
  .adv_filter_policy  = ADV_FILTER_ALLOW_SCAN_ANY_CON_ANY,


I prepared a program that includes what explained above. The source code is available in my Github repository.

Here’s how it works:

ESP32 (32) – BLE, iBeacon

In my previous article I explained the Bluetooth Low Energy technology and the advertising process.

You learned that a BLE device can leverage the advertising packets to send data; in this case the device is called broadcaster and the devices which receive data are called observers.

The payload of an advertising packet has the following structure:


ADV ADDR is the device MAC address (this is the address displayed by the program developed in the previous article) and ADV DATA is a field, with a max length of 31 bytes, that contains one or more structures, each with 3 elements:

  • AD length is the total length (in bytes) of each data structure
  • AD type is the type of data contained in the structure
  • AD data is the real data

The official website of the Bluetooth Special Interest Group lists all the available AD types.

A device, for example, can transmit its local name using the AD type 0x09:


In scan mode, the Bluetooth driver returns to the program the received data (ADV DATA) in the scan_result->scan_rst.ble_adv array. This array contains uint8_t values and it’s size is scan_result->scan_rst.adv_data_len.

The Bluedroid library contains a method, esp_ble_resolve_adv_data(), which allows to get the value for a specific AD type passing the raw data. The header file esp_gap_ble_api.h contains definitions for the most common AD types:


In my Github repository you can find an updated version of the scan program. Thanks to what explained above, now the program can also display – if available – the name of the device:



A particular family of broadcaster devices are the iBeacons. These devices have been designed by Apple to allow interaction with IOS devices (iPhone …) based on location awareness. Let’s make an example: an iPhone can “notice” that it is close to a particular iBeacon, associated with a room in a museum, and therefore offer the user a brief guide to the exhibited works.


iBeacon specifications are available on Apple’s developer portal. iBeacons work transmitting advertising packets with  specific payload (ADV DATA):


The first structure has AD type = flags (0x01). Each bit has a different meaning, usually iBeacons use 0x0A value for AD data.

The second structure has type = 0xFF, that is Manufacturer Specific Data. The Bluetooth standard allows the different manufacturers to use this ID to transmit custom data. The total data length is 25 bytes (0x1A – 0x01 that is the length of the AD type field).

Apple specifications further subdivide the AD data field in several elements:


The first field is the manufacturer/company; iBeacons normally use the code 0x004C, assigned to Apple Inc. The next two fields define the iBeacon type and have a fixed value (0x02 e 0x15). The UUID field, together with the Major and Minor ones (optional, they can have a value of 0) uniquely identifies each iBeacon.  (insieme con i campi Major e Minor (facoltativi, possono essere impostati a 0) identificano univocamente il singolo iBeacon. Finally, the TX power field contains a measurement, one meter away from the iBeacon, of the received power and is useful for  precisely estimate the distance between the phone and the iBeacon itself.


I developed a program for the esp32 chip which turns a relay on if it detects a specific iBeacon. Via menuconfig you can configure the UUID of the iBeacon which triggers the led, the pin the led is connected to and the timeout – in seconds – after which the program turns the led off if the iBeacon is not detected anymore. You can moreover set a power threshold to control the distance at which the iBeacon is detected.

To parse the received packet and get the UUID value, in my program I used the method described in this article (parsing using a struct).

The program verifies if the received packet (event ESP_GAP_SEARCH_INQ_RES_EVT) was sent by an iBeacon checking that the packet length is 30 bytes and that its header contains the values listed above:

// iBeacon fixed header
ibeacon_header_t ibeacon_fixed_header = {
  .flags = {0x02, 0x01, 0x06},
  .length = 0x1A,
  .type = 0xFF,
  .company_id = 0x004C,
  .beacon_type = 0x1502

It compares the fixed header with the received one using memcmp, function that compares two blocks in memory:

if(memcmp(adv_data, ibeacon_fixed_header, sizeof(ibeacon_fixed_header)))
  result = true;

The source program is available in my Github repository, here’s a video that shows how it works:

Game audio for the ESP32


ESP32 game audio at Buildlog.Net blog:

I have been working on some games for the ESP32 and needed some decent quality audio with a minimum number of additional components.  I was bouncing between using the DAC and using the I2S bus. The DAC requires less external parts, so I went that way. I ended up creating a very simple library for use in he Arduino IDE. (Note: This only works with ESP32)

Check out the video after the break.

ESP32 (31) – BLE, GAP

In my previous tutorials you learned how to use the wifi interface of the esp32 chip. Starting from this post, I’m going to explain you the second wireless technology the esp32 chip supports: bluetooth.

In particular, my tutorial will be about Bluetooth Low Energy (BLE), sometimes called also Bluetooth 4.0 or Bluetooth Smart:


Bluetooth Low Energy

BLE is a technology to build personal wireless area networks (WPAN); that is it allows to put in communication different devices (computers, smartphones, smartwatches…) “close” to each other (a theoretical maximum distance of 100m). As the name suggests, version 4.0 of the Bluetooth standard was designed to reduce the power consumption of the devices connected to the network.

Devices are divided into two families:

  • central
  • peripheral

the first ones (central) are devices like PCs, tablets or smartphones with good processing power and memory. The second ones (peripheral) are instead sensors, tags… with less hardware resources and power. A central device can be connected to more peripheral devices at the same time, while it’s not true the opposite:


BLE devices periodically report their presence by transmitting advertising packets. The advertising packet can contain up to 31 bytes of data and the transmission frequency can be chosen by the single device: reducing this frequency can indeed reduce energy consumption.

If a BLE device, after having received an avertising package, wants to obtain more information from the device that transmitted it, it can request a second packet of information (always for a maximum of 31 bytes), the scan response packet. The transmission of this second data package is optional:


A BLE device can take advantage of advertising packages to send data in broadcast mode. In this case, this device is called a broadcaster, while the devices that receive the data are called observers.

What explained above is defined within a BLE specification called Generic Access Profile (GAP).


In this first tutorial you’ll learn how to develop a program that will periodically scan the air looking for BLE devices, that is a program which receives advertising packets and displays the data received in the serial console.

Before compiling a program which uses the Bluetooth controller, make sure (using menuconfig) that the controller is enabled (Component config -> Bluetooth):


Start your program with the required header files:

#include "esp_bt.h"
#include "esp_bt_main.h"
#include "esp_gap_ble_api.h"

You also need to initialize the NVS partition, used by the Bluetooth driver:


the Bluetooth controller of the esp32 chip supports both the classic and the low energy mode. If one of this two modes is not required in your program, you can release the memory the framework normally allocates to manage it using the esp_bt_controller_mem_release() command. In this example you’re not going to use the classic mode, so:


Now you can configure (using the default settings) the controller in BLE mode:

esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT();

The esp-idf framework esp-idf includes the Bluedroid bluetooth stack. This library was developed by Broadcom and used by Android since version 4.2 Bluedroid is initialized and enabled with the following commands:


Now you’re ready to start scanning…

GAP, events

In a similar way to what you learned about the wifi driver, the bluetooth driver also runs in a thread separate from our program and communicates with it via events. In order to receive such events, you have to implement a callback function. Whenever the bluetooth driver has to notify an event, it will call that function.

The prototype of the callback function is:

static void esp_gap_cb(esp_gap_ble_cb_event_t event, esp_ble_gap_cb_param_t *param);

You tell the driver which callback function has to use with the esp_ble_gap_register_callback() method:


The Bluetooth driver handles several events, there are the ones related to the scan process:


Before being able to start the scan process, you have to configure the scan parameters. The configuration is performed using the esp_ble_scan_params_t struct. It’s very important that the variable with the scan parameters is available during all the scan process; it’s therefore necessary to define it globally:

static esp_ble_scan_params_t ble_scan_params = {
  .scan_type              = BLE_SCAN_TYPE_ACTIVE,
  .own_addr_type          = BLE_ADDR_TYPE_PUBLIC,
  .scan_filter_policy     = BLE_SCAN_FILTER_ALLOW_ALL,
  .scan_interval          = 0x50,
  .scan_window            = 0x30

With the esp_ble_gap_set_scan_params() method you configure the scan process passing the struct defined above to the driver:


When the driver has finished the configuration, it calls the callback function with the event ESP_GAP_BLE_SCAN_PARAM_SET_COMPLETE_EVT. Depending on the event raised, the callback function also receives some parameters. The framework’s Programming Guide explains – for each event – the related parameters. For this event, it’s available the variable scan_param_cmpl that contains only the status parameter.

In the callback function you can use the switch statement to identify each event:

switch (event) {

and check if the configuration was successful with:

if(param->scan_param_cmpl.status == ESP_BT_STATUS_SUCCESS)

If so, you can start the scan process:


The parameter is the scan duration (in seconds).

Once the scan process has started, the driver raises the ESP_GAP_BLE_SCAN_START_COMPLETE_EVT event. For this event too it’s possible to verify the correct execution by reading the status parameter (pay attention: the name of the variable which contains the parameter changes!):

  if(param->scan_start_cmpl.status == ESP_BT_STATUS_SUCCESS)
    printf("Scan started\n\n");
    printf("Unable to start scan process");

GAP, scan process

During the scan process, for each advertising packet the chip receives the event ESP_GAP_BLE_SCAN_RESULT_EVT is raised.

This event contains some subevents. You can identify which subevent was raised reading the scan_rst.search_evt parameters. Two subevents are in particular interesting:


the first tells you that a device was detected, while the second one that the scan process completed.

For each detected device, various information is available. For now let’s print its address in the console:

  if(param->scan_rst.search_evt == ESP_GAP_SEARCH_INQ_RES_EVT) {
    printf("Device found: ADDR=");
    for(int i = 0; i < ESP_BD_ADDR_LEN; i++) {
      printf("%02X", param->scan_rst.bda[i]);
      if(i != ESP_BD_ADDR_LEN -1) printf(":");

The address is an uint8_t array, whose size is defined by the ESP_BD_ADDR_LEN constant. The address is normally displayed in hex form, with the bytes separated by :


Device list management

As explained above, the ESP_GAP_BLE_SCAN_RESULT_EVT event is raised everytime a device sends an advertising packet. This means that a single device will be detected multiple times during the scan process.

It’s therefore necessary to maintain a list of the known devices. In my Github repository you can find a test program that scans the network and prints all the detected devices.

You can verify if it works correctly comparing what the program detects with the BLE devices listed by a smartphone… for Android for example you can use the very good nRF Connect application by Nordic.

Here’s what my program detected:


and here’s the nRF Connect’s screenshot:



ESP32 (30) – HTTP server in SoftAP mode

One of the most frequent questions I receive from my website’s contact form or from my Facebook page is whether it’s possible to publish an HTTP server when the esp32 chip is working in SoftAP mode, that is when it publishes its own wifi network.

In previous tutorials (18 – Access Point and 20 – Webserver) I’ve already blogged about the two subjects separately, today I’ll explain how to combine them.

Access Point

Let’s start defining the parameters of the TCP/IP network will be published by the esp32 chip. You have to choose an addressing plan, that is which IP addresses will belong to the network. You can use some of the IP addresses IANA assigned to private networks (RFC1918):


The numbers /8/12/16 are, in short form, the network mask. For example/8 means that the network contains all the addresses from to, a total of 16.777.216 different addresses. Thanks to the subnetting you can slice a network in smaller subnetworks.

In this example I’m going to use the network with netmask (/24), that is a network with 254 usable addresses ( – You have to statically assign to the esp32 chip an address that belongs to that network; to make things easy I chose the first one (

tcpip_adapter_ip_info_t info;
memset(&info, 0, sizeof(info));
IP4_ADDR(&info.ip, 192, 168, 1, 1);
IP4_ADDR(&, 192, 168, 1, 1);
IP4_ADDR(&info.netmask, 255, 255, 255, 0);
ESP_ERROR_CHECK(tcpip_adapter_set_ip_info(TCPIP_ADAPTER_IF_AP, &info));

The other devices which will connect to the network will dynamically configure their IP address, thanks to the DHCP service. To use the DHCP server in your program, first you have to stop it before configuring the network settings and then start it:


After having configured the TCP/IP network and the related services, you can set up the wifi interface of the esp32 chip and activate the SoftAP mode:

wifi_init_config_t wifi_init_config = WIFI_INIT_CONFIG_DEFAULT();

You have to prepare a wifi_config_t struct that contains all the parameters for the wifi network (SSID, authentication…) and pass it to the method:

ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_AP, &ap_config));

You can hardcode the parameters in the program, or make them configurable via menuconfig (as in this example) or Possiamo decidere di inserire i parametri hardcoded nel programma, di renderli configurabili tramite menuconfig (come nell’esempio) or even read them from a config file or from NVS variables.

Finally start the wifi interface with:


HTTP server

Now you can use the Netconn API of the lwip library to bind your program to the TCP/80 port (it’s the standard port used by the HTTP protocol) and to listen for incoming connections:

struct netconn *conn;
conn = netconn_new(NETCONN_TCP);
netconn_bind(conn, NULL, 80);

The accept() method blocks the program until a new connection is accepted:

struct netconn *newconn;
netconn_accept(conn, &amp;newconn);

After having established the connection, your program must speak the same language (protocol) of the client; in this case the HTTP protocol used by web browsers.

To keep the example simple, it will publish a static website, whose content is stored in an SPIFFS partition (see the ESP32lights project for more information). Therefore, the program will answer requests in the form GET <resource> looking for the resource in the SPIFFS partition and, if found, sending its content using the netconn_write() method:


Bonus, mDNS

To be able to connect to the HTTP server published by the esp32 chip, a client must know the IP address ( assigned to the chip.

We can leverage the mDNS service (as explained here) to allow the client to connect using an alias (for example esp32web):

mdns_server_t* mDNS = NULL;
ESP_ERROR_CHECK(mdns_set_hostname(mDNS, "esp32web"));
ESP_ERROR_CHECK(mdns_set_instance(mDNS, "esp32 webserver"));

If the device you’re using supports the mDNS service, it will be possible to connect to the website using the address esp32web.local:



The complete program is available in my Github repository. After having loaded it on your devboard, a new wifi network will be available:


if you connect to that network, your device will be assigned an IP addess on the network:


and you’ll be able to point the browser to http://esp32web.local (or and display the website:


ESP32 (29) – Deep sleep

One of the major concerns for embedded devices is the power consumption. If the device you’re designing will be battery powered, it’s indeed important to reduce as much as possible its power consumption  to maximize the autonomy (= the working time before it’s necessary to replace or recharge the battery).

The esp32 chip offers 5 different power modes. The “normal” mode is named active mode; in this mode all the features of the chip are available. By starting to reduce the CPU speed and disabling some peripherals and cores, the chip switches to different power saving modes, as summarized in the following diagram:


In this first post about the esp32 power saving modes, I’ll explain the deep sleep mode.

Deep sleep

The esp-idf framework actually supports two power saving modes: light sleep and deep sleep. Between the two, the deep sleep mode is the one which offers greater energy savings. In this mode, are turned off:

  • both the CPUs
  • most of the RAM memory
  • all the peripherals

by default are instead kept active:

  • the RTC controller
  • the RTC peripherals, including the ULP coprocessor
  • the RTC memories (slowfast)

You can put the chip in deep sleep with the esp_deep_sleep_start() method, while it’s possible to wake up it via different events:


When the chip wakes up from deep sleep, a new boot sequence is performed. It’s therefore very important to understand that the execution of your program does not restart at the point where the esp_deep_sleep_start() method is called.

Let’s see how to configure and use two wake up events; in a future post I’ll write about touch pad and ULP.


The simplest wake up event is for sure the one which leverages a timer of the RTC controller. Thanks to the method:

esp_err_t esp_sleep_enable_timer_wakeup(uint64_t time_in_us)

you can wake up the esp32 chip after the specified number of milliseconds. The method must be called before entering the deep sleep mode:

// wakeup after 10 seconds

I/O triggers

In a previous post I’ve already blogged about the possibility to receive interrupts when a digital pin of the chip changes its status. We can leverage a similar functionality to wake up the chip from sleep.

With the method

esp_err_t esp_sleep_enable_ext0_wakeup(gpio_num_t gpio_num, int level)

you can enable the wake up if the specified pin (gpio_num) changes its status (level).

You can only use the pins with RTC function (0, 2, 4, 12-15, 25-27, 32-39) and the possible levels are 0 (= low) or 1 (high). If, for example, you want to wake up the chip from deep sleep if pin 4 has a low level, you’ll write:

esp_sleep_enable_ext0_wakeup(4, 0);

The framework also offers a method to monitor different pins:

esp_err_t esp_sleep_enable_ext1_wakeup(uint64_t mask, esp_sleep_ext1_wakeup_mode_t mode)

the pins (this method also accepts only the ones specified above) must be specified in a bitmask and  the wakeup modes are:

  • ESP_EXT1_WAKEUP_ALL_LOW = wakeup  when all the pins are low
  • ESP_EXT1_WAKEUP_ANY_HIGH = wakeup when at least one pin is high
When the chip wakes up from the sleep, the pins specified will be configured as RTC IO. To be able to use them again as normal digital pins, you have first to call the rtc_gpio_deinit(gpio_num) method. The ext0_wakeup method at the moment cannot be used together with touch pad or ULP events.

After the wake up…

If you configured more than one wake up event, you can know which specific event woke up the chip with:

esp_sleep_wakeup_cause_t esp_sleep_get_wakeup_cause()

The possible constants are:


For the ext1_wakeup event, a specific method is available to get the bitmask of the pins:

uint64_t esp_sleep_get_ext1_wakeup_status()


As explained above, in deep sleep mode the content of the RTC fast and RTC slow memories is preserved. You can therefore use those memory segments to store data that must be retained during the sleep.

To ask the compiler to store a variable in the RTC slow memory, you can use the RTC_DATA_ATTR attribute, or the RTC_RODATA_ATTR one if the variable is read only:

RTC_DATA_ATTR static time_t last;


I wrote a program (its source code is in my Github repository) to demonstrate the deep sleep mode and two different wake up events:



Luca Dentella published a new build:

Today’s project, ESP32lights, is a smart device based on the esp32 chip.
Thanks to ESP32lights you can turn a load on and off (I used it for my christmas lights)

  • manually
  • based on daily schedules
  • based on the light intensity

ESP32lights connects to your wifi network, can be configured and operated via a web browser and it’s optimized for mobile devices (responsive web interface based on jQuery Mobile).

Full description on his blog. More tutorials about the ESP32 chip here.

Check out the video after the break.