Adds a feature for BLEDescriptors so that they optionally reset their value on client disconnect

[chrbongardt]

This feature is necessary for the BLE2902 descriptor to work properly. Without this feature the notify and indication values on the BLE2902 are not set back to default and when a new client connects notifications and indications are sent despite the new client not having subscribed to those.

[chegewara]

You can reset descriptor value on disconnect. In some cases, like HID, it is required to keep notification enabled on reconnect. I dont recommend to merge this.

PS according to bluetooth specs peripheral should keep 0x2902 descriptor value for each connected central. but this library is simplified (its a bug) and has 1 value for all connected devices

[chrbongardt]

Thank you for your comments @chegewara. So the right way would be too keep a record of all the past connected clients and store their subscription settings? Don't they have to resubscribe after a reconnect? I was testing this with the nrfConnect app and as soon as I reconnect I was getting a SUCCESS_INDICATE on the characteristic callback, however the nrfConnect App was not receiving the indications since it wasn't subscribed to it. I don't think that is the expected behaviour.

[chegewara]

Yes, they have to resubscribe. For example in esp32 subscribe for notification is 2 steps process:

1. subscribe in esp32
2. change descriptor value in peripheral

Because esp32 bluetooth stack (old one) is based on bluedroid, which is used in android and other OSes i am assuming its common for all and probably it is also bluetooth specs (cant confirm that).

I was testing this with the nrfConnect app and as soon as I reconnect I was getting a SUCCESS_INDICATE on the characteristic callback, however the nrfConnect App was not receiving the indications since it wasn't subscribed to it. I don't think that is the expected behaviour.

Yes, its not expected behavior because nRF connect does not have implemented to resubscribe on reconnect. Its all depending on client app implementation.

So the right way would be too keep a record of all the past connected clients and store their subscription settings?

Yes, at least for few devices. For example esp32 bluedroid stack keeps stored pairing/bonding data for max 12 devices. You have to keep in mind, if you want to store descriptors value, that embedded devices have limited amount of storage (ram and/or flash) and peripheral can have teens descriptors, so storing value for all descriptors and all previously connected central devices is not possible, but it would be good to keep it for few at least.

Another thing is that peripheral should send notifications only to peers that subscribe to notifications, but this library is sending to all connected devices. Its not big issue, but with few connected central devices it may decrease performance.

[chrbongardt]

Yes, its not expected behavior because nRF connect does not have implemented to resubscribe on reconnect. It's all depending on client app implementation.

I understand that, but somehow it doesn't feel right to me. Although if that's how the standard is then nothing to do about it hahaha. For me it makes more sense if the client would resubscribe manually to the relevant characteristics after every sessions instead of assuming that all previously subscribed characteristics are important for the new session. In this case, why implement optional subscription mechanism at all?

Yes, at least for few devices. For example esp32 bluedroid stack keeps stored pairing/bonding data for max 12 devices. You have to keep in mind, if you want to store descriptors value, that embedded devices have limited amount of storage (ram and/or flash) and peripheral can have teens descriptors, so storing value for all descriptors and all previously connected central devices is not possible, but it would be good to keep it for few at least.

Yeah, I will check on that and see if I can implement it. My C/C++ experience is almost nil, just started this week tinkering with the ESP32 and Arduino.

Another thing is that peripheral should send notifications only to peers that subscribe to notifications, but this library is sending to all connected devices. Its not big issue, but with few connected central devices it may decrease performance.

I can't replicate this. I was able to connect a second client by reenabling advertising on the onConnect callback of the server. But even if I subscribed to the characteristic I only get the values on the first client that subscribed to it. The second one doesn't get the values even if subscribed.

[chegewara]

I can't replicate this. I was able to connect a second client by reenabling advertising on the onConnect callback of the server. But even if I subscribed to the characteristic I only get the values on the first client that subscribed to it. The second one doesn't get the values even if subscribed.

You need 2 devices. Even if you start 2 advertising it is still the same peripheral.
This way i was able to start 9 BLE UART apps on windows and connect with one esp32 even if esp32 can connect max 7 devices.

[chrbongardt]

I was trying with two different smartphones, but as I said, only the first one that subscribed was receiving the indications. Am I missing something else? Actually that is a feature that I’m interested in.

Btw, thank you for your comments and guidance respecting this. Is there any IRC or somewhere to ping you? I think I should close this PR.

[chegewara]

I was trying with two different smartphones, but as I said, only the first one that subscribed was receiving the indications. Am I missing something else? Actually that is a feature that I’m interested in.

This is true as long as second device wont subscribe, but esp32 will send notifications anyway, just client app will ignore it.
You can try to find me and few more helpful people on gitter:
https://gitter.im/espressif/arduino-esp32