I’ve been reading a little to try to understand BLE better.
The “Notify” mechanism is provided so a sensor server can alert anyone who is interested, that a change has occurred in the thing being ‘sensed’ by the server.
In looking at the code for the Part 1 of 2 (DHT server), it seems the idea is NOT to wait until the DHT device’s output has changed, from some previous value that was sensed, but rather the server is simply doing an arbitrary “Notify” every ‘n’ units of time (where ‘n’ is 10 and ‘units’ are seconds)?
I’m saying all this just to see if I understand the BLE concepts involved in this tutorial.
One of the things I don’t yet understand is where do the numbers come from for the Descriptors?
Why are the numbers 0x2901, 0x2902, 0x2903?
And, could they be anything I choose, and must they be sequential?
If anyone at RNT can recommend a good book for understanding the programming of BLE devices, please do so.
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 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:
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.
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.
I’m not sure… Can you be a little more specific about what is happening?
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?