In this laboratory you will learn how to build a Bluetooth Low Energy (BLE) environmental service on your ESP32 Sparrow boards and to expose the measured sensor data to a Web application.

Bluetooth Smart, also known as Bluetooth Low Energy, abbreviated as BLE, is an energy-efficient iteration of Bluetooth designed to conserve power. Its main use involves transmitting small amounts of data over short distances with low bandwidth.

Unlike the constant activity of regular Bluetooth, BLE typically stays in sleep mode, only activating when a connection is established.

This results in significantly lower power consumption, approximately 100 times less than traditional Bluetooth, depending on the specific application. To explore the key distinctions between Bluetooth and Bluetooth Low Energy, refer to the detailed comparison here.

Within Bluetooth Low Energy, there exist two device types: the server (referred to as peripheral) and the client. The ESP32 is versatile, capable of functioning as either a client or a server.

The server actively broadcasts its presence, making it discoverable by other devices, and it holds data that the client can access. Meanwhile, the client conducts scans of nearby devices. Upon locating the desired server, it initiates a connection and awaits incoming data. This mode of communication is termed point-to-point, and it is the communication mode we will employ with the ESP32 Sparrow.

GATT, which stands for Generic Attributes, establishes a hierarchical data structure accessible to connected BLE devices. In essence, GATT outlines the protocol governing the exchange of standard messages between two BLE devices. Grasping this hierarchical arrangement is crucial as it facilitates a clearer comprehension of how to effectively employ BLE with the ESP32.

• Profile: standard collection of services for a specific use case;
• Service: collection of related information, like sensor readings, battery level, heart rate, etc. ;
• Characteristic: it is where the actual data is saved on the hierarchy (value);
• Descriptor: metadata about the data;
• Properties: describes how the characteristic value can be interacted with. For example: read, write, notify, broadcast, indicate, etc.

At the highest level of the hierarchy is a profile, consisting of one or more services. Typically, a BLE device encompasses multiple services.

Each service comprises at least one characteristic, and it may also reference other services. Essentially, a service serves as a repository of information, such as sensor readings.

The Bluetooth Special Interest Group (SIG) has established predefined services for various data types, including Battery Level, Blood Pressure, Heart Rate, Weight Scale, etc. Additional defined services can be explored here.

A characteristic is invariably associated with a service, serving as the location within the hierarchy where the actual data resides (value). It consistently consists of two attributes: the characteristic declaration, offering metadata about the data, and the characteristic value.

Furthermore, the characteristic value may be accompanied by descriptors, providing additional details about the metadata specified in the characteristic declaration.

The properties delineate the ways in which interaction with the characteristic value can occur. Essentially, these properties encompass the operations and procedures applicable to the characteristic:

• Broadcast
• Read
• Write without response
• Write
• Notify
• Indicate
• Authenticated Signed Writes
• Extended Properties

Every service, characteristic, and descriptor possesses a Universally Unique Identifier (UUID), which is a distinct 128-bit (16 bytes) number, for instance: 55072829-bc9e-4c53-938a-74a6d4c78776

Shortened UUIDs are available for all types, services, and profiles outlined in the Bluetooth Special Interest Group (SIG) specifications.

Should your application require a custom UUID, you can generate one using a UUID generator website, but for this lab assignment we will use the default UUID for an Environmental Sensing Service.

In essence, the UUID serves the purpose of uniquely identifying information. For example, it can distinguish a specific service provided by a Bluetooth device.

In our project, we will establish an Environmental Sensing Service featuring three distinct characteristics: one for temperature, another for humidity, and a third for pressure.

The specific temperature, humidity, and pressure readings are stored within the values assigned to their respective characteristics. Each characteristic is configured with the notify property, ensuring that the client receives notifications whenever these values undergo a change.

We will adhere to the default UUIDs designated for the Environmental Sensing Profile and its associated characteristics.

To access the default assigned UUID numbers, visit this page and refer to the Assigned Numbers Document (PDF). By searching for the Environmental Sensing Service within the document, you can explore all the authorized characteristics applicable to this service. It's evident that the Environmental Sensing Service supports temperature, humidity, and pressure readings.