BLE Client Characteristic Configuration descriptor (BLE2902) value is not resetting to default (00 00) on connection

[SuperTankMan]

Board

az-delivery-devkit-v4

Device Description

ESP32 with stepper motor and few basic level sensors.

Hardware Configuration

Not relevant

Version

v2.0.2

IDE Name

Arduino IDE and PlatformIO

Operating System

All.

Flash frequency

80-240Mhz

PSRAM enabled

no

Upload speed

115200

Description

Hi All, this is my first discussion post so please excuse my manners :p

Recently I have been working on ESP32 BLE where the server sets up a service in which the attributes are read, Write, Notify. hence a BLE2902 is added to the characteristics. Once the client registers for the notification and then after a few notifications being received the client disconnect from the server without disabling notifications.

I have noticed that when the client makes connection again (without being bonded) the notification is still enabled! however the Bluetooth specifications specifically state that it should be reset to default value of notifications and Indications i.e disabled when not bonded. Anyone can test this using nRF connect and a standard service or useing BLE_notify.ino from the examples which has characteristics with notification.

Test procedure:
1.0 Connect to the device.
2.0 Enable Notification on a characteristic.
3.0 Disconnect from the device but not reset.
4.0 Connect to the device without power cycle or rest.
5.0 Check the status of the notification by reading value of BLE2902 it should reset to 00 00 or notification and indication disabled (see ref below) but it does not.

Has anyone noticed this and if so is this how ESP32 BLE is supposed to behave? or is it a bug or an issue?

TankMan-

References:
BLUETOOTH SPECIFICATION Version 4.2 [Vol 0]

3.3.3.3 Client Characteristic Configuration

The Client Characteristic Configuration declaration is an optional characteristic
descriptor that defines how the characteristic may be configured by a specific
client. The Client Characteristic Configuration descriptor value shall be
persistent across connections for bonded devices. The Client Characteristic
Configuration descriptor value shall be set to the default value at each
connection with non-bonded devices. The characteristic descriptor value is a bit
field. When a bit is set, that action shall be enabled, otherwise it will not be
used. The Client Characteristic Configuration descriptor may occur in any
position within the characteristic definition after the Characteristic Value. Only
one Client Characteristic Configuration declaration shall exist in a
characteristic definition.

Extracted from further down the spec. near Table 3.11 in the specification
Configuration Value Description
Notification 0x0001 The Characteristic Value shall be notified. This value can only be set if the characteristic’s property has the notify bit set.
Indication 0x0002 The Characteristic Value shall be indicated. This value can only be set if the characteristic’s property has the indicate bit set.
Reserved for
Future Use
The following Client Characteristic Configuration bits are defined:
The default value for the Client Characteristic Configuration descriptor value
shall be 0x0000.

Sketch

Use the BLE_notify.ino example and follow the instructions above

Debug Message

None

Other Steps to Reproduce

Use nRF connect or similar to register for notification or read BLE2902 values.

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[SuGlider]

@SuperTankMan

You can always set it to zero when the BLE server finds out that the client has disconnected (in a callback).
This is up to your application to define how to behave.

For that you can do something like this:

    BLE2902 *ble2902 = new BLE2902();
    ....
    ble2902->setNotifications(false);  // or true to turn it on

Check some the BLE2902 API at https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLE2902.h

[SuperTankMan]

@SuGlider
Hi SuGlider I have already tried this:
ble2902->setNotifications(false); // or true to turn it on
and it too does not work although internally getNotifications(bool) does return the value I set using setNotifications(bool) however it does not get reflected to the Client! i.e. when you read BLE2902 it still contains 01 00 when it has been set using setNotifications(true). I need to raise an issue with this too!
Thanks for your advice though.

[SuGlider]

@SuperTankMan

Could you please provide minimum example code that demonstrates the issue, for both master and slave.

I'll test it and verify/fix this issue.

[SuperTankMan]

@SuGlider
Here is the code: save the code below as xxxxx.ino I don't know if there is any other way to send you the file.
Note this file can be used to test both issue... and you need a utility like nRF connect or BLE scanner.
Just found out how I can make the files easyer for you...

https://github.com/SuperTankMan/Issue-code

Issue #6863 - As it is just compile and see that fit the LED does not flash. Then use somethign like nRF connect or BLE Scanner mobile app to connect, select service 0x1700 and register the notification. Once the counter starts updating in the characteristics values and LED starts flashing disconnect without deregistering notifications. Then connect again and you'll see that the counter will continue counting and LED flashing without reregistering for the notifications(if the notifications and indications were set to default 0x0000 then this would not happen) also you can read the BLE2902 values using nRF or BLE scanner.
Issue #6868 - Uncomment the line in code as below and do the test again youll see that after a disconnect even though the code setNotification(false) the update to the nRF or BLE connect does not happen on reconnect of device however the getNotification works as setNotification(false) seasm to work internally only but does not update the BLE2902 to the client.

---

//((BLE2902*)myBLE2902)->setNotifications(false);
//**** Uncomment above line to test if setNotifications(false) updates the Client ****/

//code file starts here...
`
#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

#define LED_BUILTIN 26

/* Define Service */
//Custome service UUID
#define serviceID BLEUUID((uint16_t)0x1700)

BLEDescriptor *myBLE2902 = new BLE2902();
bool deviceConnected = false;

uint8_t counter = 1;
unsigned long previousMillis = 0; // will store last time LED was updated
const long interval = 1000; // interval at which to blink (milliseconds)

BLECharacteristic counterCharacteristic
{
BLEUUID((uint16_t)0x1A00),
BLECharacteristic::PROPERTY_READ |
BLECharacteristic::PROPERTY_NOTIFY
};

class MyServerCallbacks : public BLEServerCallbacks
{
void onConnect(BLEServer* MyServer)
{
deviceConnected = true;
}
void onDisconnect(BLEServer* MyServer)
{
deviceConnected = false;
MyServer->getAdvertising()->start();
}
};

void setup()
{
pinMode(LED_BUILTIN, OUTPUT);

// Serial.begin(115200);

//Create and name the BLE device
BLEDevice::init("ESP32BLETest");

/* Create the BLE server */
BLEServer *MyServer = BLEDevice::createServer();
MyServer->setCallbacks(new MyServerCallbacks()); // Set the function that handles Server Callbacks

/* Create service on the server */
//BLEService *MyService = MyServer->createService(BLEUUID((uint16_t)0x1700)); // A random ID has been selected
BLEService *MyService = MyServer->createService(serviceID); // A random ID has been selected

/* Add characteristic to the service */
MyService->addCharacteristic(&counterCharacteristic);
counterCharacteristic.addDescriptor(myBLE2902);
counterCharacteristic.setValue(&counter, 2);

/* Configure advertising with the service to advertise */
MyServer->getAdvertising()->addServiceUUID(serviceID);

// Start the service
MyService->start();

// Start the Server/Advertising
MyServer->getAdvertising()->start();

Serial.println("Waiting for a Client to connect...");
}

void loop()
{
digitalWrite(LED_BUILTIN, HIGH);

if (!deviceConnected)
{
//Not connected so reset Notifications
//((BLE2902*)myBLE2902)->setNotifications(false);
//**** Uncomment above line to test if setNotifications(false) updates the Client ***/
}
else
{
//if registered for Notification then flash LED and send counter value to Client by notification
if (((BLE2902)myBLE2902)->getNotifications())
{
//loop to blink without delay
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval)
{
// save the last time you blinked the LED
previousMillis = currentMillis;
digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
counter++;
counterCharacteristic.setValue(&counter, 1);
counterCharacteristic.notify();
}
}
}
}
`

[SuGlider]

@SuperTankMan

Issue #6863 - As it is just compile and see that fit the LED does not flash. Then use somethign like nRF connect or BLE Scanner mobile app to connect, select service 0x1700 and register the notification. Once the counter starts updating in the characteristics values and LED starts flashing disconnect without deregistering notifications. Then connect again and you'll see that the counter will continue counting and LED flashing without reregistering for the notifications(if the notifications and indications were set to default 0x0000 then this would not happen) also you can read the BLE2902 values using nRF or BLE scanner.
Issue #6868 - Uncomment the line in code as below and do the test again youll see that after a disconnect even though the code setNotification(false) the update to the nRF or BLE connect does not happen on reconnect of device however the getNotification works as setNotification(false) seasm to work internally only but does not update the BLE2902 to the client.

onDisconnect(BLEServer* MyServer) is actually never called when the Disconnect button is pressed in the BLE Client APP.
Thus, deviceConnected is never false, except when it runs by first time before any connection is started.
In order to really disconnect you must shut off the Bluetooth radio of the smartphone or go out of range.
When uncommenting that code line, I see that it works as expected, when reconnected.

The counter also stops and starts whenever pressing the Notify button in the BLE Client APP.
Therefore the client is capable of controlling the CCCD in the server.

Changing CCCD in the server doesn't affect the client because in BLE the client is who should control CCCD.
I think that the client BLE APP really doesn't care and does not actually read the descriptor.

Therefore calling BLE2902::setNotifications(bool) only changes its bit internally to the server, nothing else.
But calling BLE2902::setNotifications(bool) before starting advertising the server will work as default setup for CCCD in the pairing or bonding, allowing the server to persist CCCD state across connections for bonded devices, for example. For such case, the server sketch shall save CCCD state in the NVS using "Preferences.h" or some other method, in order to make it persist and then restore its state when the ESP32 is reset, powered on or gets into range again.

I think that the explanation above may cover all the issues you have reported.

[SuperTankMan]

onDisconnect(BLEServer* MyServer) is actually never called when the Disconnect button is pressed in the BLE Client APP.
Thus, deviceConnected is never false, except when it runs by first time before any connection is started.
In order to really disconnect you must shut off the Bluetooth radio of the smartphone or go out of range.
When uncommenting that code line, I see that it works as expected, when reconnected.

I am not convinced about this the device stops advertising as soon as its connected and when callback onDisconnect(BLEServer* MyServer) is called the advertising starts again when disconnected hence it is calling onDisconnect(BLEServer* MyServer). Also the fact that when the line below

//((BLE2902*)myBLE2902)->setNotifications(false);
//**** Uncomment above line to test if setNotifications(false) updates the Client ***/

is uncommented then the Server stops sending notifications it means working I have also moved this line to the onDisconnect(BLEServer* MyServer) and that too works.

The counter also stops and starts whenever pressing the Notify button in the BLE Client APP.
Therefore the client is capable of controlling the CCCD in the server.

Sure it is able to stop however it takes two registration of notification from the client to enable notification in stead of the one and when the Client reads the status of the BLE2902 i.e. registation and notification status it does not read the correct value.

Changing CCCD in the server doesn't affect the client because in BLE the client is who should control CCCD.
I think that the client BLE APP really doesn't care and does not actually read the descriptor.

Sure Client can control but its getting wrong information when reading in the case when setNotification(false) is called() and this not acceptable in the sense that the Bluetooth specification clearly states the behaviour to set its self to default as detailed and reference in the issue.

Therefore calling BLE2902::setNotifications(bool) only changes its bit internally to the server, nothing else.

Sure and it look like that is the case however its not helpful to the Client when he needs to know(by reading BLE2902) the status of the registration of notification as he gets false information.

But calling BLE2902::setNotifications(bool) before starting advertising the server will work as default setup for CCCD in the..
pairing or bonding, allowing the server to persist CCCD state across connections for bonded devices, for example. For such case, the server sketch shall save CCCD state in the NVS using "Preferences.h" or some other method, in order to make it persist and then restore its state when the ESP32 is reset, powered on or gets into range again.

Sure persistence can be achieved as you stated however that is not the issue, the issue is that it's not adhering to the Bluetooth spec. and not updating the BLE2902 when setNotification(fbool) is called

I think that the explanation above may cover all the issues you have reported.

While I appreciate your assistance and help I do not think this issue is resolved I do think its a bug and does not adhere to the specification and hence both the issue still stands.