Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| en:iot-open:practical:hardware:sut:esp32:iot_8 [2024/04/15 18:15] – ktokarz | en:iot-open:practical:hardware:sut:esp32:iot_8 [2025/04/12 08:37] (current) – [IoT8: BLE Communication with characteristics] ktokarz | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | ====== |
| - | This scenario presents how to create the Bluetooth Low Energy server device and corresponding client device. The server can be the sensor device which responds to the client with the results of the measurements. This can also be the output device, which we can control writing the data to. The client connects to a server and reads the data. This scenario presents the use of the concept of services and characteristics. | + | This scenario presents how to create the Bluetooth Low Energy server device and the corresponding client device. The server can be the sensor device which responds to the client with the results of the measurements. This can also be the output device, which we can control |
| ===== Prerequisites ===== | ===== Prerequisites ===== | ||
| - | It is necessary to understand the principles of the Bluetooth Low Energy protocol with concepts of services, characteristics and descriptors. We will use in this scenario the knowledge of the advertising process so making the IoT_7 exercise is recommended. | + | It is necessary to understand the principles of the Bluetooth Low Energy protocol with concepts of services, characteristics and descriptors. We will use in this scenario the knowledge of the advertising process so making the [[en: |
| ===== Suggested Readings and Knowledge Resources ===== | ===== Suggested Readings and Knowledge Resources ===== | ||
| Line 20: | Line 20: | ||
| ==== Start ==== | ==== Start ==== | ||
| - | You can use the beacon and simple client programs from IoT_7 as the starting point. | + | You can use the beacon and simple client programs from [[en: |
| ==== Steps ==== | ==== Steps ==== | ||
| Line 139: | Line 139: | ||
| === Step 2 === | === Step 2 === | ||
| In this step, we will analyse the behaviour of the client. The client software is much more complex than the server. It is because the server, called also the central device, in many circumstances is a more powerful device than the peripheral. Some parts of the software are implemented as callback functions because they handle reactions on the data coming asynchronously from the server. The diagram presents the algorithm of the client and data coming from the server. | In this step, we will analyse the behaviour of the client. The client software is much more complex than the server. It is because the server, called also the central device, in many circumstances is a more powerful device than the peripheral. Some parts of the software are implemented as callback functions because they handle reactions on the data coming asynchronously from the server. The diagram presents the algorithm of the client and data coming from the server. | ||
| - | {{ en: | + | {{ en: |
| === Step 3 === | === Step 3 === | ||
| Line 256: | Line 256: | ||
| </ | </ | ||
| - | In the loop function, we wait for the information that the server with the service UUID we were interested in was found. It is signalled with the use of " | + | In the loop() function, we wait for the information that the server with the service UUID we were interested in was found. It is signalled with the use of " |
| - | In a loop() function we will read the characteristic value every 1 second. It is a good practice to check if the characteristic is properly retrieved and readable before reading the value. | + | \\ |
| - | < | + | In a loop() function we will periodically |
| + | < | ||
| void loop() { | void loop() { | ||
| if (doConnect == true) { | if (doConnect == true) { | ||
| Line 317: | Line 318: | ||
| </ | </ | ||
| - | === Step 4 === | ||
| - | BLE peripheral device stops advertising after establishing a connection. While the connection is closed or lost it should restart advertising to be able to accept further connections. Doing it is possible with the use of callback functions, executed in selected events occurrence. We need to add the callback functions called on the connection and disconnection events. We will use two global boolean variables, one to store the state of the device, and another to control the single advertising start. | ||
| - | <code c> | ||
| - | bool deviceConnected = false; | ||
| - | bool advStarted = true; //first advertise starts automatically | ||
| - | |||
| - | class MyServerCallbacks: | ||
| - | void onConnect(BLEServer* pServer) { | ||
| - | deviceConnected = true; | ||
| - | }; | ||
| - | |||
| - | void onDisconnect(BLEServer* pServer) { | ||
| - | deviceConnected = false; | ||
| - | } | ||
| - | }; | ||
| - | </ | ||
| - | In the setup() function, just after the creation of the server we set up the callbacks. | ||
| - | < | ||
| - | pServer-> | ||
| - | </ | ||
| - | In the loop() function we have to program the starting of the advertising while the connection is ended. The startAdvertising() function should be called just once so the advStarted boolean variable helps us to control this process. | ||
| - | < | ||
| - | void loop(){ | ||
| - | if (!deviceConnected && !advStarted) { | ||
| - | pServer-> | ||
| - | advStarted = true; | ||
| - | } | ||
| - | |||
| - | if (deviceConnected){ | ||
| - | advStarted = false; | ||
| - | } | ||
| - | } | ||
| - | delay(500); | ||
| - | }; | ||
| - | </ | ||
| ==== Result validation ==== | ==== Result validation ==== | ||
| - | You should be able to find the device in the BLE neighbourhood. It should allow us to establish | + | You should be able to observe messages describing |
| ===== FAQ ===== | ===== FAQ ===== | ||
