ble2902->setNotifications(false); does not get reflected to the Client

[SuperTankMan]

Board

az-delivery-devkit-v4

Device Description

n/a

Hardware Configuration

N/A

Version

v2.0.3

IDE Name

Arduino IDE and PlatformIO

Operating System

All

Flash frequency

80-240Mhz

PSRAM enabled

no

Upload speed

115200

Description

The code:
ble2902->setNotifications(false);
in the server side BLE does not get reflected to the client even when they read the notification and indication status.

Sketch

Standard BLE_Notify.ino with added ble2902->setNotifications(false); when the client registers for notifications

Debug Message

N/A

Other Steps to Reproduce

using modified code in the server side with ble2902->setNotifications(false); after the Client has registered for Notifications and the Server has processed ble2902->setNotifications(false); when you read the BLE2902 values they are still 01 00.

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 - Could you please provide both Sketches (BLE Central and Peripheral) that demonstrate the issue and that would be used to also demonstrate a fix? Thanks!

The example you suggested has no BLE2902 object (ble2902->xxx) in the code. I want to check how exactly you have tested it and where in the code it has been used. This example is the just BLE peripheral (server).

What did you use as BLE central (client) to test it and see the issue?

[SuperTankMan]

See code and details in issue #6863

[VojtechBartoska]

@SuperTankMan can we close this issue and continue only in #6863?

[SuperTankMan]

@VojtechBartoska (Sorry but No) - Frankly I think this issue although related is different the other is about default values not being set when disconnected and in this one is the new values of BLL2902 are not reflected to the client via reading BLE2902 it is possible the bug fix solution will cure both issues but I do think we should keep it until they are both resolved.

[SuGlider]

Issue confirmed.

There are actually two issues:
ESP32 BLE Server doesn't send back Descriptor when read is requested by BLE Client.
ESP32 BLE Client can't read Descriptor when it is sent from BLE Server.

These functionalities need to be implemented in BLE Library:
https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLEDescriptor.cpp#L185-L194
https://github.com/espressif/arduino-esp32/blob/master/libraries/BLE/src/BLERemoteDescriptor.cpp#L54-L58

[SuperTankMan]

Hi @SuGlider

I am not so sure if issue: L185-L194(ESP32 BLE Server doesn't send back Descriptor when read is requested by BLE Client.) is completely true.

I have done this experiment where I use one client to connect then register for notifications then I read the value of the BLE2902 descriptor and it reads value correctly as expected. I have also tried another experiment where a client connects then registers for notifications and then disconnects. I then use another client device to connect and read the BLE2902 descriptor and then too again is read correctly. What is not happening is that when I internally setNotifications(true or false) and then read the BLE2902 then it does not read correctly! hence not sure of your description of the issue. Also there is the issue that when server is disconnected from an unbonded/unpaired device the BLE2902 is not reset to its default value of 0x0000.

I am also not sure about L54-L58(ESP32 BLE Client doesn't receive Descriptor data when it is sent from BLE Server) I have not done this experiment with ESP32 being the Client so do not know.

Please clarify to me if I am missing something and also that the implanted cure will resolve both my issues?
i.e. 1) BLE2902 descriptor not resetting to default(0x0000) on disconnect and 2) BLE2902 not reflecting the internally set value(via setNotifications(bool)) when a read request is received from the client?

Thank you for your assistance and sorry if I have not understood your cure to be implemented.

[SuGlider]

@SuperTankMan - I guess you are using nRF Connect APP or BLE Scanner APP as client to run your exepriments.
I've run the ESP32 Server you proposed and added descriptor 0x2901 with value "this is a test!", which can be seen in both client APPs.
In order to see all the details, I turned the Core Debug Level to Verbose and analyzed all the message and events.
Let me explain what I see:

What is not happening is that when I internally setNotifications(true or false) and then read the BLE2902 then it does not read correctly!

None APPs, nRF Connect nor BLE Scanner, really reads Descriptors. Both write to them, but do not read.
There is an internal parameter in the BLE message (protocol) called response_needed which is used by the client to tell the Server if a response is needed.
It is funny that the Client request a READ of a Desciptor (I can see that in the logs), but doesn't request it to reply back.
I tried a number of Clients and none of them request response_needed as 1.
ESP32 BLE Client API BLERemoteDesciptor::readValue() also sends a BLE package with response_needed = 0 and also doesn't care about the Server response and doesn't even process the answer, when I force the software to send it.
The same for Google Chrome Web Bluetooth when reading descriptors (https://googlechrome.github.io/samples/web-bluetooth/read-descriptors.html?service=0x1700&characteristic=0x1a00)

I also added the necessary code in the place I mentioned to send a Message back with the data to the Client and it just ignores it.

By other hand, when the Client requests to read a Characteristic, it turns response_neededto 1 and effectively receives and treats the BLE package received back from the Server.

After all these tests, I concluded that BLE may define that when reading a Descriptor, the client doesn't get any response from this request and just get the data from its cache, created in the discovery process.

Therefore, as I said in my first message, the Client doesn't matter reading Descriptors, only matter reading Characteristics.
You can see that by using nRF Connect, because as soon as you press the 3 arrows down icon (Notify on/off), the value of the descriptor 0x2902 changes right away and I'm sure that ESP32 doesn't send back any response.

Thus, your Client APP will never read and doesn't want to read Descriptors.

setNotifications(true or false) will only be visible in the ESP32 Server, nothing else.

Also there is the issue that when server is disconnected from an unbonded/unpaired device the BLE2902 is not reset to its default value of 0x0000

This is something that if your ESP32 Server Sketch can do, as already said, by setNotifications(false) on the Service disconnect callback.
Doing so, in next time that other Client connects to the same ESP32 Server, it will be off by default.

After analyzing the Logs, I really think that there may be nothing to fix here...