Hi Ray.
 
You are right. It doesn’t wait until the values have changed. It sends a new notification with the new values every x number of seconds that you define in the code.
 
Again, you are right to be confused about the descriptors. I have to admit that the section of the descriptors is not well implemented. The example works as it is, but at the time I didn’t understand well the logic behind the descriptor values.
 
Basically, these are the steps to create a BLE device:
1. Create a BLE Server –> ours its called “dhtESP32”

2. Create a BLE Service –> we define the following UUID for the service. It was created using the UUID generator website:

#define SERVICE_UUID "91bad492-b950-4226-aa2b-4ede9fa42f59"

3. Create a BLE Characteristic on the Service –> we create three different characteristics. one for each value we want to advertise (these were generated using the UUID generator website):

BLECharacteristic dhtTemperatureCelsiusCharacteristics("cba1d466-344c-4be3-ab3f-189f80dd7518", BLECharacteristic::PROPERTY_NOTIFY);

BLECharacteristic dhtTemperatureFahrenheitCharacteristics("f78ebbff-c8b7-4107-93de-889a6a06d408", BLECharacteristic::PROPERTY_NOTIFY);

BLECharacteristic dhtHumidityCharacteristics("ca73b3ba-39f6-4ab3-91ae-186dc9577d99", BLECharacteristic::PROPERTY_NOTIFY);

4. Create a BLE Descriptor on the characteristic. –> this is not well implemented in our example. First, because we create the following BLEDescriptors and then, they are not actually used. They are overwritten by the following command addDescriptor(new BLE2902() that creates a default BLE descriptor for the client characteristic (this is what is used on the BLE examples provided by the library).

BLEDescriptor dhtTemperatureCelsiusDescriptor(BLEUUID((uint16_t)0x2902));

BLEDescriptor dhtTemperatureFahrenheitDescriptor(BLEUUID((uint16_t)0x2901));

BLEDescriptor dhtHumidityDescriptor(BLEUUID((uint16_t)0x2903));

Second, because those UUIDs are not well implemented. 
0x2901, 0x2902, and 0x2903 are default UUIDs implemented by the SIG for the following:

• 0x2901: Characteristic User Description
• 0x2902: Client Characteristic Description
• 0x2903: Server Characteristic Description

It doesn’t make sense to create different descriptors for each of the characteristics. In that example, they all should be set to 0x2902 using the default method addDescriptor(new BLE2902().
You can check them on the following PDF:

• https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf

5. Start the service. –> this is ok
6. Start advertising. –> this is ok
 
I hope this helps.
I think I have to restructure that whole section.
 
I’m sorry for the confusion.
 
Regards,
Sara
 
 
 
 

Excellent explanation. Question. When I view the mobile app, nRF, it connects and communicates the correct values once I select the correct units. My question, is why does the app state that the server is not “advertising?” thank you.

Hi.
I’m not sure… Can you be a little more specific about what is happening?
Regards,
Sara

Just that on the screen of the mobile app, at the top there is a section that states that the server is not advertising yet I receive data correctly from the server with the DHT11 sensor.
Everything works. Does it say not advertising because I’m already connected and receiving data?

Hi again.
Yes, I think it’s that.
I think it’s probably because it is already receiving data, so it doesn’t advertise to other clients.
Regards,
Sara