I won’t go over the basic BLE concepts\u2014such as “service,” “characteristic,” “peripheral,” and “central”\u2014again here. If you need more information, check here<\/a>. <\/p>\n\n What to expect in this article:<\/p>\n\n To follow along with the examples in this post, you will first need two BLE-capable boards that are supported by the ArduinoBLE library. As of today, and to the best of my knowledge, these are the following Arduino boards: <\/p>\n\n BLE communication also works between different boards. So you do not need two identical models. But of course, I have not tested all the models and combinations myself. <\/p>\n For some boards, you may need to update the NINA-W102 firmware. You can identify the problem by the corresponding error messages that appear during compilation. But the update is no big deal: select the correct board and port in the Arduino IDE. Then go to Tools \u2192 Firmware Updater \u2192 Select Board \u2192 Check for Updates \u2192 Select Version (>3.0.0) \u2192 Install. <\/p>\n\n Then you will need the ArduinoBLE library, which you can easily install using the Arduino IDE’s library manager. <\/p>\n\n And finally, you will need a smartphone with a compatible BLE app, such as LightBlue<\/a> or nRF Connect (for Android<\/a> \/ for Apple<\/a>). Alternatively, you can use a PC or laptop with a Bluetooth adapter. In that case, you will also need suitable apps, such as Bluetooth LE Explorer. I discussed some smartphone and PC apps in more detail in my last post. <\/p>\n\n We will start off simple and turn our Arduino into a peripheral, assigning it a service and a characteristic. The characteristic should be writable by the client. We will use a suitable app on a PC or smartphone as the client. Here’s the sketch: <\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n Upload the sketch, open your BLE app (such as LightBlue), and search for the “BLE Minimal” peripheral. Connect to it, then go to the corresponding characteristic. If you tap or click \u201cRead,\u201d you should see the value of the characteristic, which is \u201cHello Smartphone.\u201d If you only see numbers, you will need to change the format to UTF-8. In nRF Connect, you will need to tap the service before the characteristic, and the down arrow corresponds to \u201cread.\u201d <\/p>\n Then click “Write New Value” (nRF Connect: up arrow) and enter a new value, such as “Hello Arduino.” If necessary, you may also need to change the format to UTF-8 here. You will see the new value immediately in the serial monitor, and on the client (central), you will see the value the next time it reads. <\/p>\n This is what the output looked like on my smartphone using LightBlue (before changing the characteristic):<\/p>\n\n And this was the output on the serial monitor after writing the characteristic and the peripheral logging out of the central unit:<\/p>\n\n After including the ArduinoBLE library, use An object of the BLEStringCharacteristic <\/strong>class expects a string as its value. There is a separate class for all major data types, such as BLEFloatCharacteristic <\/strong>or BLEBooleanCharacteristic<\/strong>. You can find these classes (except for the String class) in the ArduinoBLE file BLETypedCharacteristics.h<\/a>. <\/p>\n In addition to the UUID, you pass your characteristics object its properties (permissions). The most important ones are: <\/p>\n You can find a list of all properties in the “BLEproperty” enum in BLEProperty.h<\/a>. <\/p>\n Use You can set the name used for advertising with In the next example, we will use the write function to switch the Arduino board’s LED on and off. It is actually a simple task: a specific value of the characteristic means \u201cturn the LED on,\u201d while another means \u201cturn the LED off.\u201d However, constantly checking the value to see if it has changed is a bit impractical. It would be more elegant if these actions were performed automatically. And that is exactly what the event handler functions in the ArduinoBLE library are for. In principle, they correspond to the callback functions I introduced in my last post about BLE with the ESP32. <\/p>\n And since we are on the topic of event handler functions, let us use them to be notified when a central connects to our Arduino or when the connection is lost.<\/p>\n Here is the sketch:<\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n If you connect your Arduino board to the central, set the characteristic to 1 (hexadecimal format) once, then to 0, and then disconnect, you should see output like the one shown below on the serial monitor. On the board, you will see the board LED turn on and then off again. <\/p>\n\n Much of the sketch is already familiar. To control the LED, we define the service We define the event handlers using the function The following events are defined for the characteristics:<\/p>\n The following events are defined for the BLE object:<\/p>\n The connected central is passed to the BLE event handlers. The event handler for the characteristic receives not only the central but also the triggering characteristic. Nevertheless, in the event handler function, we use You could also omit the expressions So it seems the callbacks do not run quite as automatically as I had promised; otherwise, we would not have to poll. And anyone who has read my last post about BLE with the ESP32 might wonder why there was no need to use a counterpart to The next question is: What happens if the Arduino is busy with other time-consuming tasks in In my tests, switching commands sent in quick succession (period = < delay time) were not lost but were processed individually at intervals of DelayInSeconds. So it is best to keep In the previous example, the central changed the characteristic value, and we used a callback function on the peripheral to be automatically notified of this change. In the following example, we will reverse the process. The peripheral changes the characteristic, and we want to be automatically notified of this on the central device. To achieve this, we use the “notify” characteristic property. <\/p>\n The event that triggers the update (write process) of the characteristic is pressing or releasing a button. And to make things a little more interesting, we are using two buttons. We will set up a characteristic for each button\u2014not because we have to or because it is practical, but simply to try working with two characteristics. <\/p>\n Since it is a bit inconvenient to pick the characteristics on the central device by their UUID, we will give them names: “Button 1 state” and “Button 2 state.” To set up these names, we use a descriptor. Just as there are characteristics predefined by the Bluetooth SIG, there are also predefined descriptors. The descriptor for naming characteristics is called \u201cCharacteristic User Description\u201d and has the UUID 0x2901. <\/p>\n To try out the following sketch, connect two pushbuttons with one side each to pins 6 and 7 on your Arduino board. Connect the other sides of both pushbuttons to GND. <\/p>\n Here is the sketch:<\/p>\n<\/p>\n \u00a0<\/p>\n<\/div>\n \n If you open LightBlue or a similar app, you will see that the characteristics now have names (middle image below). Select one of the characteristics and change the format from HEX to UTF-8. Then tap “Subscribe”. When you press the corresponding button now, you will see an output like the one shown in the lower right. This means you no longer need to tap \u201cRead\u201d. <\/p>\n\n\n
\n
\n
Preparation<\/h2>\n\n
\n
ArduinoBLE Minimal Sketch<\/h2>\n
#include <ArduinoBLE.h>\n\nBLEService myService(\"19B10000-E8F2-537E-4F6C-D104768A1214\"); \nBLEStringCharacteristic myCharacteristic(\"19B10001-E8F2-537E-4F6C-D104768A1214\", BLERead | BLEWrite, 40);\n\nvoid setup() {\n Serial.begin(115200);\n while (!Serial);\n\n if (!BLE.begin()) {\n Serial.println(\"Starting BLE module failed!\");\n while (1);\n }\n\n BLE.setLocalName(\"BLE Minimal\"); \/\/ \"Advertising Name\"\n \/\/ BLE.setDeviceName(\"BLE Minimal\"); \/\/ Device Name\n BLE.setAdvertisedService(myService);\n\n myService.addCharacteristic(myCharacteristic);\n BLE.addService(myService);\n\n myCharacteristic.writeValue(\"Hello Smartphone!\");\n\n BLE.advertise();\n\n Serial.println(\"BLE Minimal Sketch\");\n}\n\nvoid loop() {\n BLEDevice central = BLE.central();\n\n if(central) {\n Serial.print(\"Connected to central: \");\n Serial.println(central.address());\n\n while (central.connected()) {\n if (myCharacteristic.written()) {\n if (myCharacteristic.value()) { \n Serial.println(myCharacteristic.value());\n }\n }\n }\n \n Serial.println(\"Disconnected from central.\");\n }\n}<\/pre>\n![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/screen_lightblue_start-473x1024.webp\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/screen_lightblue_peripheral-473x1024.webp\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/screen_lightblue_characteristic-473x1024.webp\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_arduinoble_minimal.png\")
<\/a>Explanations of the sketch<\/h3>\n
BLEService myService(uuid);<\/code> to create the “myService” object and pass in the UUID (which you can choose freely). BLEStringCharacteristic myCharacteristic(uuid, permissions);<\/code> creates the “myCharacteristic” characteristic object. Its UUID can also be chosen freely (provided it has not already been assigned elsewhere). <\/p>\n\n
BLE.begin()<\/code> to initialize your Arduino’s BLE functions. <\/p>\nsetLocalName()<\/code>; in other words, you will see this name in the list of available peripherals. It is worth noting that after disconnecting from the client, your peripheral may appear in the list under a different name. In my case, it was “Arduino.” “Arduino” was the default device name. If you want to change this behavior, change the device name using setDeviceName()<\/code>. <\/p>\n\nFurther explanations in short:<\/h5>\n
\n
BLE.setAdvertisedService(myService);<\/code>, the UUID from myService<\/code> is included in the advertising data.<\/li>\nmyService.addCharacteristic(myCharacteristic);<\/code>, we add the characteristic myCharacteristic<\/code> to the service myService<\/code>.<\/li>\nBLE.addService(myService);<\/code> adds the service to the local GATT server.<\/li>\nmyCharacteristic.writeValue()<\/code> updates the value of the characteristic.<\/li>\nBLEDevice central = BLE.central();<\/code> creates a BLEDevice object named “central.” If a central is connected, this object represents the connected central. Otherwise, when queried with if (central)<\/code>, it evaluates to false. <\/li>\ncentral.address();<\/code> returns the MAC address of the central. <\/li>\ncentral.connected()<\/code> checks whether the central is still connected. If not, we exit the while loop. Because central<\/code> is recreated, the check if (central)<\/code> returns “false” until a new connection is established. <\/li>\nmyCharacteristic.written();<\/code>, we check whether the central has assigned a new value to the characteristic.<\/li>\n<\/ul>\n\nEvent Handlers (Callbacks)<\/h2>\n
#include <ArduinoBLE.h>\n\nBLEService ledService(\"19B10000-E8F2-537E-4F6C-D104768A1214\");\nBLEByteCharacteristic switchCharacteristic(\"19B10001-E8F2-537E-4F6C-D104768A1214\", BLERead | BLEWrite);\n\nconst int ledPin = LED_BUILTIN;\n\nvoid setup() {\n Serial.begin(115200);\n while (!Serial);\n\n pinMode(ledPin, OUTPUT);\n\n if (!BLE.begin()) {\n Serial.println(\"Starting BLE module failed!\");\n\n while (1);\n }\n\n BLE.setLocalName(\"LED_Switch\");\n BLE.setDeviceName(\"LED_Switch\");\n BLE.setAdvertisedService(ledService);\n\n ledService.addCharacteristic(switchCharacteristic);\n\n BLE.addService(ledService);\n\n BLE.setEventHandler(BLEConnected, blePeripheralConnectHandler);\n BLE.setEventHandler(BLEDisconnected, blePeripheralDisconnectHandler);\n\n switchCharacteristic.setEventHandler(BLEWritten, switchCharacteristicWritten);\n\n switchCharacteristic.setValue(0);\n\n BLE.advertise();\n\n Serial.println((\"BLE device active, waiting for connections...\"));\n}\n\nvoid loop() {\n BLE.poll();\n}\n\nvoid blePeripheralConnectHandler(BLEDevice central) {\n Serial.print(\"Connected event, central: \");\n Serial.println(central.address());\n}\n\nvoid blePeripheralDisconnectHandler(BLEDevice central) {\n Serial.print(\"Disconnected event, central: \");\n Serial.println(central.address());\n}\n\nvoid switchCharacteristicWritten(BLEDevice central, BLECharacteristic characteristic) {\n \/\/ unused parameters\n (void)central;\n (void)characteristic;\n\n Serial.print(\"Characteristic event, written: \");\n\n if (switchCharacteristic.value()) {\n Serial.println(\"LED on\");\n digitalWrite(ledPin, HIGH);\n } else {\n Serial.println(\"LED off\");\n digitalWrite(ledPin, LOW);\n }\n}\n<\/pre>\n![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_arduinoble_led_switch.png\")
<\/a>Explanations to the sketch<\/h3>\n
ledService<\/code> with the characteristic switchCharacteristic<\/code>. What is new is that we are using the data type byte<\/code> for the characteristic (BLEByteCharacteristic<\/code>). <\/p>\nsetEventHandler()<\/code>. There is one version for the BLE object (BLE.setEventHandler()<\/code>) and one for the characteristics (switchCharacteristic.setEventHandler()<\/code>). You pass the event and the freely chosen name of the event handler function to the function. You are already familiar with this principle from interrupts. <\/p>\n\n
\n
switchCharacteristic<\/code> and not the passed parameter characteristic<\/code>. This is because the data type of the passed parameter is the BLECharacteristic base class and not BLEByteCharacteristic<\/strong>. The function value()<\/code> of the base class (i.e., BLECharacteristic::value()<\/code>) is defined as const uint8_t* value() const;<\/code>. Its return value is therefore a pointer, which would complicate matters (at least for C++ beginners). On the central side, we will have to address this challenge later. <\/p>\n(void)characteristics;<\/code> and (void)central;<\/code>. However, you might see a warning about “unused parameters.” Here, we are performing what is known as a “cast to void,” which essentially tells the compiler: I am intentionally not using these parameters. <\/p>\nBLE.poll()<\/code> checks and processes pending BLE events and, if necessary, calls the registered event handlers for them.<\/p>\n\nWhy do I have to poll here, but not with the ESP32?<\/h4>\n
BLE.poll()<\/code> there. The answer is: the ESP32 also \u201cpolls,\u201d but it does so automatically in the background using FreeRTOS. <\/p>\nloop()<\/code> meanwhile? Does it miss something because of a delayed BLE.poll()<\/code>? To test this, I inserted various delays into loop(). As a result, establishing the connection in LightBlue took approximately 14 times the delay time. It appears that there are multiple rounds negotiation, and each negotiation step is delayed by the delay time. Toggling the LED had a delay of up to a maximum of one delay time. <\/p>\nloop()<\/code> as lean as possible. <\/p>\n\nNotify and Descriptors<\/h2>\n
#include <ArduinoBLE.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 = 6;\nconst int button2Pin = 7;\n\nBLEService buttonService(SERVICE_UUID);\n\nBLEStringCharacteristic button1Char(\n BUTTON1_UUID, BLERead | BLENotify, 25);\n\nBLEStringCharacteristic button2Char(\n BUTTON2_UUID, BLERead | BLENotify, 25);\n\nBLEDescriptor button1Desc(\"2901\", \"Button 1 state\");\nBLEDescriptor button2Desc(\"2901\", \"Button 2 state\");\n\nbool lastButton1 = HIGH;\nbool lastButton2 = HIGH;\n\nvoid setup() {\n Serial.begin(115200);\n while (!Serial);\n\n pinMode(button1Pin, INPUT_PULLUP);\n pinMode(button2Pin, INPUT_PULLUP);\n\n if (!BLE.begin()) {\n Serial.println(\"Starting BLE module failed!\");\n while (1);\n }\n\n BLE.setLocalName(\"Arduino Two Buttons\");\n BLE.setDeviceName(\"Arduino Two Buttons\");\n\n BLE.setAdvertisedService(buttonService);\n\n buttonService.addCharacteristic(button1Char);\n buttonService.addCharacteristic(button2Char);\n\n button1Char.addDescriptor(button1Desc);\n button2Char.addDescriptor(button2Desc);\n\n BLE.addService(buttonService);\n\n button1Char.writeValue(\"Button 1 not yet pressed\");\n button2Char.writeValue(\"Button 2 not yet pressed\");\n\n BLE.advertise();\n\n Serial.println(\"BLE device active, waiting for connections...\");\n}\n\nvoid loop() {\n BLE.poll();\n\n bool button1 = digitalRead(button1Pin);\n bool button2 = digitalRead(button2Pin);\n\n if (lastButton1 == HIGH && button1 == LOW) {\n button1Char.writeValue(\"Button 1 pressed\");\n\n Serial.println(\"Button 1 pressed\");\n delay(200); \/\/ debouncing\n }\n else if (lastButton1 == LOW && button1 == HIGH) {\n button1Char.writeValue(\"Button 1 released\");\n\n Serial.println(\"Button 1 released\");\n delay(200);\n }\n\n if (lastButton2 == HIGH && button2 == LOW) {\n button2Char.writeValue(\"Button 2 pressed\");\n\n Serial.println(\"Button 2 pressed\");\n delay(200);\n }\n else if (lastButton2 == LOW && button2 == HIGH) {\n button2Char.writeValue(\"Button 2 released\");\n\n Serial.println(\"Button 2 released\");\n delay(200);\n }\n\n lastButton1 = button1;\n lastButton2 = button2;\n}<\/pre>\n![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_ble_two_buttons.png\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/ble_two_buttons_light_blue_I-1024x558.png\")
<\/a>
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/ble_two_buttons_light_blue_II-1024x768.png\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_arduino_ble_scan.png\")
<\/a>![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_two_arduinos_peripheral.png\")
![\"\"](\"https:\/\/wolles-elektronikkiste.de\/wp-content\/uploads\/2026\/08\/output_two_arduinos_central.png\")