I will limit myself to the ESP32, because the libraries for other boards \u2014 such as ArduinoBLE<\/a> for BLE-enabled Arduino boards (Arduino Nano 33 IoT\/BLE, Arduino UNO R4 WiFi, etc.) \u2014 differ significantly. Covering everything in a single post would have made it too confusing and too long. <\/p>\n This is what you can expect in this article:<\/p>\n <\/p>\n\n First, I need to introduce a few basic BLE-related concepts that might confuse you at first (I felt the same way!). Hopefully, the example sketches will clear things up. <\/p>\n\n Bluetooth\u00ae Low Energy (BLE) was introduced with Bluetooth 4.0 and is designed for applications with low power consumption and low data rates. This allows battery-powered devices, such as sensors or Bluetooth trackers, to often operate for months or even years on a single button cell battery. <\/p>\n In BLE, there are two roles: peripheral and central. The peripheral device (hereinafter referred to as the peripheral) provides information, while the central device (hereinafter referred to as the central) retrieves this information, establishes a connection, and reads or modifies it. You can think of the peripheral as a server and the central as a client. Typical peripherals are sensors or microcontrollers, while smartphones or PCs often take on the role of the central. <\/p>\n\n The data provided by the peripheral is organized into services. Each service contains one or more characteristics in which the actual data is stored. Each characteristic and each service has a unique identifier (UUID = Universally Unique Identifier). Characteristics can have different properties. For example, they can be read-only, writable, or enabled for automatic notifications (notify or indicate). <\/p>\n Notify is particularly useful: If the peripheral changes the value of a characteristic, it can notify the central unit. This means the central unit does not have to repeatedly query the data. This simplifies the code and is ideal for measured values such as temperature, acceleration, or heart rate. <\/p>\n In order for a central device to locate a peripheral device at all, the peripheral regularly transmits short advertising packets. These packets contain, among other things, the device name and the services it offers. Only after the peripheral has been located is a connection established and the desired data exchanged. <\/p>\n\n Many BLE devices have similar features, such as a rechargeable battery. The Bluetooth SIG (Special Interest Group) has standardized services and characteristics for such features. 16-bit UUIDs have been defined for these standardized services, for example: <\/p>\n How you define and organize your own services and characteristics is up to you. You define the corresponding UUIDs yourself. Since you typically assign 128-bit UUIDs for this purpose, the risk of collisions \u2014 that is, identical UUIDs \u2014 is extremely low. Let us consider two buttons on a microcontroller board that serves as a peripheral. The button states (pressed\/released) are transmitted via BLE. The UUIDs could then look like this: <\/p>\n The position of the hyphens is fixed, as is the length of the UUIDs, which is 32 hexadecimal digits. <\/p>\n\n Using the General Advertising Profile (GAP), BLE devices regularly send small advertising packets. These include, among other things, the device name and the UUIDs of the services being offered. This allows other devices to discover the peripheral and decide whether they want to connect to it. <\/p>\n Since advertising packets offer only a limited amount of storage space, typically only a single 128-bit service UUID can be transmitted. Although additional services may be present, they are not recognized until after the connection is established. <\/p>\n\n The Generic Attribute Profile (GATT) defines how data is organized and exchanged in the form of services and characteristics. Using GATT, characteristic values can be read, written, or transmitted via Notify or Indicate. <\/p>\n In most applications, the peripheral is the GATT server, since it provides the services and characteristics. The central, accordingly, is the GATT client that accesses this data. However, the terms \u201cserver\u201d and \u201cclient\u201d are independent of the roles of peripheral and central. In specific applications, a device can also take on both roles simultaneously. <\/p>\n\n The following sketch turns the ESP32 into a peripheral that offers one service and one characteristic. A suitable program on a smartphone or PC serves as the central device, which is authorized to read and modify the value of the characteristic. <\/p>\n Before you upload the sketch, check whether your ESP32 supports Bluetooth. Most do, but not all. The ESP32S2 is one of the models that does not support Bluetooth. <\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n\n First, you need to include BLEDevice.h. This library file should include all other files required by the sketch. <\/p>\n Our sketch has only one service and one characteristic. The UUIDs can be chosen freely. <\/p>\n With Use You can then add a characteristic to the service using Finally, the service still needs to be started.<\/p>\n With In <\/p>\n\n To get started with the peripheral you just created, you will need a central device. A smartphone or a PC works well for this. I will focus on smartphones here, but in the appendix<\/a> I will also introduce some (Windows) PC apps for BLE. <\/p>\n There are various BLE apps available for smartphones; I have tried LightBlue\u00ae<\/a> and nRF Connect<\/a> on my Android smartphone. Both apps are also available for Apple smartphones. For this post, I am primarily using LightBlue, as I find its interface a bit more user-friendly. In the appendix,<\/a> I will briefly discuss nRF Connect. <\/p>\n Open LightBlue, select the “ESP32 BLE Minimal” peripheral, and connect. Then go to the characteristic. In the upper-right corner of the screen, you will likely see \u201cHEX.\u201d Tap it, select \u201cUTF-8 String,\u201d and tap \u201cSave.\u201d Use \u201cRead\u201d to view the characteristic\u2019s value and \u201cWrite\u201d to change it. <\/p>\n\n If you write something like “Hi ESP32!” as the new value, you will see that both the output from the next “Read” and the output on the serial monitor change accordingly:<\/p>\n\n The first example was meant to illustrate the concept, but it has only limited practical value. That is why we are now going to switch an LED on the peripheral via the central unit. It is actually a simple task: when the characteristic has a certain value, turn the LED on; when it has another specific value, turn it off. <\/p>\n It would be much more convenient if we didn’t have to keep querying the value of the characteristic, but instead if writing to the characteristic would automatically trigger the associated actions. And that is exactly what callbacks are for. Let us take a look at an example: <\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n Connect an LED to pin 17. Then take your BLE Central device, connect to the “ESP32 BLE LED” peripheral, and select its only characteristic. If you type \u201cON,\u201d the LED will light up; if you type \u201cOFF,\u201d it will turn off again. If you type anything else, such as \u201cBlabla,\u201d nothing will happen. In the serial monitor, it looks like this: <\/p>\n\n The only truly new feature here is the callback. For readers with limited experience in C++, things are about to get a little challenging. “BLECharacteristicCallbacks” is a class with the member function Virtual functions are defined when they are to be overridden in derived classes. And that is precisely what we are doing here. Using Using And then you might have come across the following line:<\/p>\n It is important to note that a BLE advertising packet is tiny (a maximum of 31 bytes for standard advertising). If these 31 bytes are not enough, a second packet can be used \u2014 the scan response. In other words, the line means: \u201cIf a scanner requests it, send an additional scan response packet.\u201d This way, you will be on the safe side. <\/p>\n\n In the example sketch, we set up a callback for a characteristic and defined the You can find the callback class and function definitions in the BLE library files of the Arduino ESP32 board package (here)<\/a>. There is also some additional information in the example sketches in the BLE library, which you can find under File \u2192 Examples \u2192 Examples for your board<\/em> \u2192 BLE. <\/p>\n To illustrate this, I extended the BLECharacteristicCallbacks class from the previous example with a \u00a0<\/p>\n<\/div>\n \n And while I was at it, I also added the function You might be wondering how to handle this when setting up callbacks for multiple characteristics, where different actions are to be performed for each characteristic. Do I then have to create a separate callback class and callback object for each characteristic? No, not necessarily. <\/p>\n In the line To make this work, assign the same callback object to both characteristics:<\/p>\n<\/p>\n \n If the tasks to be performed by the callback are very different, it might be clearer to create separate callback classes.<\/p>\n\n In the examples so far, the action always originated from the central device: it set the value of a characteristic, which the peripheral then evaluated and reacted to accordingly.<\/p>\n In the next example, we will reverse this principle. The action will now be initiated on the peripheral side, and the central device reacts. To do this, we will connect two pushbuttons to the ESP32 and want to see immediately on the smartphone when one of the buttons is pressed or released. <\/p>\n In principle, this could already be achieved using the techniques described so far. For each button, we create a separate characteristic and change its value according to the button\u2019s state. The central could then read this value at regular intervals. However, this constant polling is cumbersome and also carries the risk that a brief button press between two read operations might go unnoticed. <\/p>\n It is more elegant to have the central automatically notified as soon as the value of a characteristic changes. That is precisely what the notify property is for. <\/p>\n However, simply setting the notify property is not enough. The characteristic must also be enabled for notifications. This is done using the Client<\/strong> Characteristic<\/strong> Configuration<\/strong> Descriptor<\/strong>(CCCD). This standardized descriptor has the UUID 0x2902 and allows the Central to subscribe to notifications (or indications) for a characteristic. <\/p>\n Since we are already using descriptors, we might as well use them to solve a second problem. Because our example uses two characteristics, we would have to distinguish between them on the central side based on their UUIDs \u2014 which is not very convenient. The Characteristic User Description descriptor (UUID 0x2901), on the other hand, allows us to assign a freely chosen name to a characteristic. This makes it much easier to distinguish between the two characteristics. <\/p>\n\n To prepare, connect two pushbuttons to the appropriate pins on the ESP32. Connect the other ends of the two pushbuttons to GND. <\/p>\n Here is the sketch:<\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n\n As before, open your favorite BLE app, select the BLE peripheral (in this case: “ESP32 Two Button Server”), and then choose one of the two characteristics: “Button 1 state” or “Button 2 state.”<\/p>\n Then you will need to subscribe to the notification. There is a “Subscribe” button for that. <\/p>\n If you press either of the two buttons now, you will receive the corresponding message in your app.<\/p>\n You can see what that looks like in LightBlue in the image on the right. <\/p>\n<\/div>\n\n\n\n To use these two descriptors, you must include the corresponding header files, BLE2901.h and BLE2902.h.<\/p>\n This time, we will create two characteristics. I think the procedure is self-explanatory. The notify property is set with Next, we will handle the “Characteristic User Description” descriptor for the characteristic of the first button. For this, we will create a new BLE2901 object using Next, we assign the desired name to the descriptor using The descriptor is assigned to the characteristic using Assigning the CCCD is easier: In loop(), we continuously check the status of the buttons. If a status changes, we update the value of the characteristic using This sketch is for illustrative purposes only and has not been optimized. To ensure that button presses in rapid succession are not lost, I would use interrupts. We could also get by with just one characteristic covering buttons 1 and 2. However, I wanted to show how to set up two characteristics. <\/p>\n\n For didactic reasons, the client side has so far been a smartphone, PC, or laptop. Now we are taking the next step by having two ESP32s communicate via BLE. A message entered in the serial monitor of the server ESP32 (peripheral) should be displayed on the serial monitor of the client ESP32, and vice versa. <\/p>\n\n On the server side, there is not really anything new regarding BLE. However, we are combining some elements from previous examples into a single sketch. When the message is sent to the client (more specifically, when we change the value of the characteristic), we use notify so that the client does not have to constantly check for the value in We also use the server callback functions We use two characteristics for the messages we send and receive. RX_UUID is the UUID for receiving (R = receive), and TX_UUID is the UUID for sending (T = transmit). <\/p>\n Here is the server sketch:<\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n If input is entered via the serial monitor and the server is connected to the client ( The client side is new and includes a whole range of new features. Until now, the software (like LightBlue) has handled scanning for available BLE devices. We had then selected the device from the list and established the connection. Now we need to teach the central ESP32 how to do all of this. Since that involves quite a few things at once, I have added an intermediate step: a central sketch that initially just scans and searches for the desired service. <\/p>\n\n So here is the scanner sketch:<\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n\n
\n
\n
\n
A Brief Overview of BLE<\/h2>\n
Peripheral and Central<\/h4>\n
Services and Characteristics<\/h4>\n\n
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/07\/ble_scheme-1024x334.png\")
<\/a>Standardized vs. Non-Standardized Services and Characteristics<\/h4>\n
\n
\n
\n
\n
\n
\n
\n
Advertising and General Advertising Profile (GAP)<\/h4>\n
Generic Attribute Profile (GATT)<\/h4>\n
A First Minimal Sketch<\/h2>\n
#include <BLEDevice.h>\n\/\/#include <BLEServer.h> \/\/ should be included automatically\n\/\/#include <BLEUtils.h> \/\/ should be included automatically\n\n#define SERVICE_UUID \"12345678-1234-1234-1234-1234567890ab\"\n#define CHARACTERISTIC_UUID \"abcd1234-1234-1234-1234-abcdef123456\"\n\nBLECharacteristic *pCharacteristic;\n\nvoid setup() {\n Serial.begin(115200);\n\n BLEDevice::init(\"ESP32 BLE Minimal\");\n\n BLEServer *pServer = BLEDevice::createServer();\n BLEService *pService = pServer->createService(SERVICE_UUID);\n pServer->advertiseOnDisconnect(true);\n\n pCharacteristic = pService->createCharacteristic(\n CHARACTERISTIC_UUID,\n BLECharacteristic::PROPERTY_READ |\n BLECharacteristic::PROPERTY_WRITE\n \/* NR = no response, needed for Bluetooth LE Lab *\/\n \/\/ | BLECharacteristic::PROPERTY_WRITE_NR \n );\n\n pCharacteristic->setValue(\"Hello Smartphone!\");\n\n pService->start();\n\n BLEAdvertising *pAdvertising = BLEDevice::getAdvertising();\n pAdvertising->addServiceUUID(SERVICE_UUID);\n pAdvertising->start();\n\n Serial.println(\"BLE Server started\");\n}\n\nvoid loop() {\n String value = pCharacteristic->getValue();\n\n if (value.length() > 0) {\n Serial.println(value);\n delay(2000);\n }\n}<\/pre>\nExplanations<\/h4>\n
BLECharacteristic *pCharacteristic;<\/code>, you define a pointer to a characteristic object. The “p” is there to remind you that this is a p<\/strong>ointer. The object itself is created later. Since we will also need the characteristic later in loop()<\/code>, it is defined globally. <\/p>\nBLEDevice::init();<\/code> initializes the BLE device and sets its name. A lot happens in the background to accomplish this, such as initializing the ESP32’s Bluetooth hardware. BLEDevice is not a class that you create an object from; rather, it contains a set of functions. That is why you call the init function using the scope operator \u201c::\u201d (class::function()) and not, as you are probably more used to, using the dot operator (object.function()). <\/p>\nBLEServer *pServer = BLEDevice::createServer();<\/code> to create a GATT server or a pointer to it. The server is assigned a service with the UUID defined at the beginning using BLEService *pService = pServer->createService(SERVICE_UUID);<\/code>. Since “pServer” is a pointer, you use the arrow operator instead of the dot operator to access createService()<\/code>. Using advertiseOnDisconnect(true)<\/code> ensures that you can reconnect immediately after a disconnect. Otherwise, you would have to restart the ESP32. <\/p>\ncreateCharacteristic()<\/code>. To do this, you pass the UUID and the properties. In this example, the value of the characteristic can be both read and written. <\/p>\nsetValue()<\/code> accepts either an Arduino-String<\/code> or a pointer to a byte array (uint8_t<\/code>) with the data length specified (setValue(const uint8_t *pData, size_t length)<\/code>). This allows both text and any binary data to be transmitted. <\/p>\ngetAdvertising()<\/code>, you get a pointer to the advertising object (there is only one). Only with addServiceUUID()<\/code> does the service become visible during the scanning process. Without this specification, a client can still discover the service via the GATT server after establishing a connection. <\/p>\nloop()<\/code>, the value of the characteristic is regularly queried using getValue()<\/code> and displayed.<\/p>\nBut what am I supposed to do with this now?<\/h4>\n
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/07\/screen_light_blue_start-473x1024.jpg\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/07\/screen_light_blue_peripheral-473x1024.webp\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/07\/screen_light_blue_characteristic-473x1024.webp\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_minimal_example.png\")
Callbacks<\/h2>\n\n
Characteristic Callbacks<\/h3>\n
#include <BLEDevice.h>\n#include <BLEServer.h>\n#include <BLEUtils.h>\n\n#define SERVICE_UUID \"11111111-1111-1111-1111-111111111111\"\n#define CHARACTERISTIC_UUID \"11111112-1111-1111-1111-111111111111\"\n\nconst int ledPin = 17;\n\n\/\/ Callback-Class\nclass MyCallbacks : public BLECharacteristicCallbacks {\n\n void onWrite(BLECharacteristic *pCharacteristic) override{\n\n String value = pCharacteristic->getValue();\/\/.c_str(); \/\/uncomment if necessary\n\n Serial.print(\"Received: \");\n Serial.println(value);\n\n if (value == \"ON\") {\n digitalWrite(ledPin, HIGH);\n Serial.println(\"LED ON\");\n }\n else if (value == \"OFF\") {\n digitalWrite(ledPin, LOW);\n Serial.println(\"LED OFF\");\n }\n }\n};\n\nvoid setup() {\n\n Serial.begin(115200);\n\n pinMode(ledPin, OUTPUT);\n digitalWrite(ledPin, LOW);\n\n BLEDevice::init(\"ESP32 BLE LED\");\n\n BLEServer *pServer = BLEDevice::createServer();\n\n BLEService *pService =\n pServer->createService(SERVICE_UUID);\n pServer->advertiseOnDisconnect(true);\n\n BLECharacteristic *pCharacteristic =\n pService->createCharacteristic(\n CHARACTERISTIC_UUID,\n BLECharacteristic::PROPERTY_READ |\n BLECharacteristic::PROPERTY_WRITE\n );\n\n pCharacteristic->setValue(\"OFF\");\n pCharacteristic->setCallbacks(new MyCallbacks());\n\n pService->start();\n\n BLEAdvertising *pAdvertising =\n BLEDevice::getAdvertising();\n\n pAdvertising->addServiceUUID(SERVICE_UUID);\n pAdvertising->setScanResponse(true);\n pAdvertising->start();\n\n Serial.println(\"BLE Server started\");\n}\n\nvoid loop() {\n \/\/ nothing to do\n}<\/pre>\n![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/07\/output_switch_led_and_call_back.png\")
<\/a>Explanation of the Sketch <\/h4>\n
onWrite()<\/code>, which is called in the event of a write operation. Since the library\u2019s developers couldn\u2019t know exactly what should happen when onWrite()<\/code> is called, they defined the function as “virtual.” <\/p>\nclass MyCallbacks : public BLECharacteristicCallbacks {....<\/code>, we derive the class MyCallbacks from the predefined class BLECharacteristicCallbacks and define our own onWrite()<\/code> function. The body of the function can be modified, but its parameter cannot. It expects a pointer to a BLECharacteristic object. <\/p>\nsetCallbacks(new MyCallbacks())<\/code>, we create an object of the MyCallbacks class, which we assign to pCharacteristics. <\/p>\npAdvertising->setScanResponse(true);<\/code><\/p>\nAdditional Callback Classes and Callback Functions<\/h4>\n
onWrite()<\/code> function. In addition to onWrite()<\/code>, there are other functions such as onRead()<\/code>, onNotify()<\/code>, and onStatus()<\/code>. Furthermore, there are other callback functions with their own functions. Here is an (incomplete!) list of some callback classes with selected callback functions: <\/p>\n\n
onConnect()<\/code>) or disconnects (onDisconnect()<\/code>)<\/li>\nonConnect()<\/code>, onDisconnect()<\/code>)<\/li>\nonRead()<\/code>, onWrite()<\/code>).<\/li>\nonRead()<\/code>, onWrite()<\/code>)<\/li>\nonAuthenticationComplete()<\/code>, onAuthorizationRequest()<\/code>) <\/li>\n<\/ul>\nonRead()<\/code> function (more precisely, I redefined the function). I also defined a BLEServerCallbacks class that uses onConnect()<\/code> and onDisconnect()<\/code> to indicate whether a client has connected or disconnected: <\/p>\n<\/p>\n#include <BLEDevice.h>\n#include <BLEServer.h>\n#include <BLEUtils.h>\n\n#define SERVICE_UUID \"11111111-1111-1111-1111-111111111111\"\n#define CHARACTERISTIC_UUID \"11111112-1111-1111-1111-111111111111\"\n\nconst int ledPin = 17;\n\n\/\/ Callback-Class\nclass MyCharacteristicsCBs : public BLECharacteristicCallbacks {\n\n void onWrite(BLECharacteristic *pCharacteristic) override{\n\n String value = pCharacteristic->getValue();\/\/.c_str(); \/\/uncomment if necessary\n\n Serial.print(\"Received: \");\n Serial.println(value);\n\n if (value == \"ON\") {\n digitalWrite(ledPin, HIGH);\n Serial.println(\"LED ON\");\n }\n else if (value == \"OFF\") {\n digitalWrite(ledPin, LOW);\n Serial.println(\"LED OFF\");\n }\n }\n\n void onRead(BLECharacteristic *pCharacteristic) override{\n\n Serial.print(\"Characteristic \");\n Serial.print(pCharacteristic->getUUID().toString());\n Serial.print(\" was read\");\n }\n};\n\nclass MyServerCBs : public BLEServerCallbacks {\n void onConnect(BLEServer *pServer) override {\n Serial.println(\"Client is connected\");\n }\n\n void onDisconnect(BLEServer *pServer) override {\n Serial.println(\"Client is disconnected\");\n }\n};\n\n\n\nvoid setup() {\n\n Serial.begin(115200);\n\n pinMode(ledPin, OUTPUT);\n digitalWrite(ledPin, LOW);\n\n BLEDevice::init(\"ESP32 BLE LED\");\n\n BLEServer *pServer = BLEDevice::createServer();\n\n BLEService *pService =\n pServer->createService(SERVICE_UUID);\n pServer->advertiseOnDisconnect(true);\n pServer->setCallbacks(new MyServerCBs());\n\n BLECharacteristic *pCharacteristic =\n pService->createCharacteristic(\n CHARACTERISTIC_UUID,\n BLECharacteristic::PROPERTY_READ |\n BLECharacteristic::PROPERTY_WRITE\n );\n\n pCharacteristic->setValue(\"OFF\");\n pCharacteristic->setCallbacks(new MyCharacteristicsCBs());\n\n pService->start();\n\n BLEAdvertising *pAdvertising =\n BLEDevice::getAdvertising();\n\n pAdvertising->addServiceUUID(SERVICE_UUID);\n pAdvertising->setScanResponse(true);\n pAdvertising->start();\n\n Serial.println(\"BLE Server started\");\n}\n\nvoid loop() {\n \/\/ nothing to do\n}<\/pre>\ngetUUID()<\/code>, which returns the UUID of a characteristic. With toString()<\/code>, you can convert it into a string that you can display on the serial monitor. <\/p>\n\nMultiple Characteristic Callbacks<\/h4>\n
void<\/span> onWrite<\/span>(BLECharacteristic<\/span> *pCharacteristic<\/span>)<\/code>, the function receives as a parameter a pointer to the exact characteristic that was just written to. If you have created the characteristics pChar1 and pChar2, you can check within the function which characteristic was just written to, for example, if(pCharacteristic == pChar1) {.....}<\/code>. <\/p>\nclass MyCallbacks : public BLECharacteristicCallbacks {....};\n....\nBLECharacteristic *pChar1;\nBLECharacteristic *pChar2;\n....\nMyCallbacks *callbacks = new MyCallbacks();\n....\npChar1->setCallbacks(callbacks);\npChar2->setCallbacks(callbacks);<\/pre>\nNotify and Descriptors<\/h2>\n\n
What is this for?<\/h4>\n
Example Sketch for Notify and Descriptors<\/h4>\n
#include <BLEDevice.h>\n#include <BLEServer.h>\n#include <BLEUtils.h>\n#include <BLE2901.h>\n#include <BLE2902.h>\n\n#define SERVICE_UUID \"7a3e0001-9b52-4b24-91c9-123456789abc\"\n#define BUTTON1_UUID \"7a3e0002-9b52-4b24-91c9-123456789abc\"\n#define BUTTON2_UUID \"7a3e0003-9b52-4b24-91c9-123456789abc\"\n\nconst int button1Pin = 18;\nconst int button2Pin = 19;\n\nBLECharacteristic *button1Char;\nBLECharacteristic *button2Char;\n\nbool lastButton1 = HIGH;\nbool lastButton2 = HIGH;\n\nvoid setup() {\n Serial.begin(115200);\n\n pinMode(button1Pin, INPUT_PULLUP);\n pinMode(button2Pin, INPUT_PULLUP);\n\n BLEDevice::init(\"ESP32 Two Button Server\"); \/\/new name\n\n BLEServer *pServer = BLEDevice::createServer();\n pServer->advertiseOnDisconnect(true);\n BLEService *pService = pServer->createService(SERVICE_UUID);\n\n button1Char = pService->createCharacteristic(\n BUTTON1_UUID,\n BLECharacteristic::PROPERTY_READ |\n BLECharacteristic::PROPERTY_NOTIFY\n );\n\n button2Char = pService->createCharacteristic(\n BUTTON2_UUID,\n BLECharacteristic::PROPERTY_READ |\n BLECharacteristic::PROPERTY_NOTIFY\n );\n\n BLE2901 *desc1 = new BLE2901();\n desc1->setDescription(\"Button 1 state\");\n button1Char->addDescriptor(desc1);\n button1Char->addDescriptor(new BLE2901());\n button1Char->addDescriptor(new BLE2902());\n button1Char->setValue(\"Button 1 not pressed\");\n\n BLE2901 *desc2 = new BLE2901();\n desc2->setDescription(\"Button 2 state\");\n button2Char->addDescriptor(desc2);\n button2Char->addDescriptor(new BLE2902());\n button2Char->setValue(\"Button 2 not pressed\");\n\n pService->start();\n\n BLEAdvertising *pAdvertising = BLEDevice::getAdvertising();\n pAdvertising->addServiceUUID(SERVICE_UUID);\n pAdvertising->setScanResponse(true);\n pAdvertising->start();\n\n Serial.println(\"BLE Server started\");\n}\n\nvoid loop() {\n bool button1 = digitalRead(button1Pin);\n bool button2 = digitalRead(button2Pin);\n\n if (lastButton1 == HIGH && button1 == LOW) {\n button1Char->setValue(\"Button 1 pressed\");\n button1Char->notify();\n\n Serial.println(\"Button 1 pressed\");\n delay(200);\n }\n else if(lastButton1 == LOW && button1 == HIGH) {\n button1Char->setValue(\"Button 1 released\");\n button1Char->notify();\n\n Serial.println(\"Button 1 released\");\n delay(200);\n }\n if (lastButton2 == HIGH && button2 == LOW) {\n button2Char->setValue(\"Button 2 pressed\");\n button2Char->notify();\n\n Serial.println(\"Button 2 pressed\");\n delay(200);\n }\n else if (lastButton2 == LOW && button2 == HIGH) {\n button2Char->setValue(\"Button 2 released\");\n button2Char->notify();\n\n Serial.println(\"Button 2 released\");\n delay(200);\n }\n\n lastButton1 = button1;\n lastButton2 = button2;\n}<\/pre>\nOutput<\/h4>\n\n
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/screen_lightblue_notify_example.png\")
<\/a><\/figure>\n<\/div>\n<\/div>\n\nExplanations<\/h4>\n
BLECharacteristic::PROPERTY_NOTIFY<\/code>. <\/p>\nBLE2901 *desc1 = new BLE2901();<\/code> and store its address in the pointer desc1<\/code>. <\/p>\ndesc1->setDescription(\"Button 1 state\");<\/code>.<\/p>\nbutton1Char->addDescriptor(desc1);<\/code>. We will do the same for the second button below. <\/p>\nbutton1Char->addDescriptor(new BLE2902());<\/code>.<\/p>\nbuttonxChar->setValue(\"Button x .....\");<\/code>. <\/p>\nbuttonxChar->notify();<\/code>.<\/div>\n\nA few more comments on the sketch<\/h4>\n
Connecting Two ESP32s via BLE<\/h2>\n
The Server (Peripheral)<\/h3>\n
loop()<\/code>. To be notified of a message arrival (= write event) on the client side without having to constantly check “manually,” we use the characteristic callback function onWrite()<\/code>. <\/p>\nonConnect()<\/code> and onDisconnect()<\/code> to keep track of the connection status. <\/p>\n#include <BLEDevice.h>\n#include <BLEServer.h>\n#include <BLEUtils.h>\n#include <BLE2902.h>\n\n#define SERVICE_UUID \"11111111-1111-1111-1111-111111111111\"\n#define RX_UUID \"22222222-2222-2222-2222-222222222222\" \/\/ Client -> Server\n#define TX_UUID \"33333333-3333-3333-3333-333333333333\" \/\/ Server -> Client\n\nBLECharacteristic *txCharacteristic;\nbool deviceConnected = false;\n\nclass ServerCallbacks : public BLEServerCallbacks {\n void onConnect(BLEServer *pServer) {\n deviceConnected = true;\n Serial.println(\"Client connected\");\n }\n\n void onDisconnect(BLEServer *pServer) {\n deviceConnected = false;\n Serial.println(\"Client diconnected\");\n pServer->startAdvertising();\n }\n};\n\nclass RxCallbacks : public BLECharacteristicCallbacks {\n void onWrite(BLECharacteristic *pCharacteristic) {\n String value = pCharacteristic->getValue();\n\n if (value.length() > 0) {\n Serial.print(\"Received: \");\n Serial.println(value);\n }\n }\n};\n\nvoid setup() {\n Serial.begin(115200);\n\n BLEDevice::init(\"ESP32 BLE Server\");\n\n BLEServer *pServer = BLEDevice::createServer();\n pServer->setCallbacks(new ServerCallbacks());\n\n BLEService *pService = pServer->createService(SERVICE_UUID);\n\n BLECharacteristic *rxCharacteristic = pService->createCharacteristic(\n RX_UUID,\n BLECharacteristic::PROPERTY_WRITE\n );\n rxCharacteristic->setCallbacks(new RxCallbacks());\n\n txCharacteristic = pService->createCharacteristic(\n TX_UUID,\n BLECharacteristic::PROPERTY_NOTIFY\n );\n txCharacteristic->addDescriptor(new BLE2902());\n\n pService->start();\n\n BLEAdvertising *advertising = BLEDevice::getAdvertising();\n advertising->addServiceUUID(SERVICE_UUID);\n advertising->setScanResponse(true);\n advertising->start();\n\n Serial.println(\"Server started\");\n}\n\nvoid loop() {\n if (deviceConnected && Serial.available()) {\n String text = Serial.readStringUntil('\\n');\n\n if (text.length() > 0) {\n txCharacteristic->setValue(text);\n txCharacteristic->notify();\n\n Serial.print(\"Sent: \");\n Serial.println(text);\n }\n }\n}<\/pre>\nif (deviceConnected && Serial.available())<\/code>), the input is set as the new value, and the client is notified via notify()<\/code>.<\/p>\n\nThe Client (Central)<\/h3>\n
Intermediate Step: The Client scans<\/h4>\n
#include <BLEDevice.h>\n#include <BLEUtils.h>\n\n#define SERVICE_UUID \"11111111-1111-1111-1111-111111111111\"\n\nvoid scanForDevices() {\n Serial.println(\"Searching server...\");\n\n BLEScan *pScan = BLEDevice::getScan();\n pScan->setActiveScan(true);\n\n BLEScanResults *pResults = pScan->start(5);\n\n for (int i = 0; i < pResults->getCount(); i++) {\n BLEAdvertisedDevice device = pResults->getDevice(i);\n\n Serial.println(device.toString());\n\n if (device.haveServiceUUID() &&\n device.isAdvertisingService(BLEUUID(SERVICE_UUID))) {\n Serial.println(\"Matching server found!\");\n }\n\n Serial.println();\n }\n}\n\nvoid setup() {\n Serial.begin(115200);\n BLEDevice::init(\"ESP32 BLE Client\");\n\n scanForDevices();\n}\n\nvoid loop() {\n}<\/pre>\n
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_two_esp32_client_scanner.png\")
<\/a>