BluetoothSerial Status && API discussion for passkey/PIN

[Jonas-Meyer97]

Hi,
i have a few question and topic for possible discussion.
My first question would be what the status on the Branch: bt-serial-overhaul is. Is it already merged? Should future commits/pull-request affecting the BluetoothSerial library be done on this branch?

On #1458 it was already ask for a way to use passkey/PIN with this library. How should a API look like for something like this in a arduino-ish style? Any suggestion?

Currently the BluetoothSerial library is limited to one device connected at a time. #2061
Is there any plan on allowing more devices to recieve serial data via bluetooth?

I would like to contribute by coding some part but need my questions answered before starting to spend time coding.

[mouridis]

Regarding your multiple connections question, actually, accepting multiple connections was actually the default behavior of the BluetoothSerial library before commit 0d564d7 which accepted the PR you mentioned and limited incoming connections to a maximum of 1.

You can revert the changes of that commit and you will disable the limit, but keep in mind:

1. ESP will receive messages from ALL connected devices and you will not have a way to distinguish which message comes from which device because all messages are on the same stream. (you can easily solve this by adding some kind of client IDs in the each of the messages that the clients sent)
2. When ESP sends messages, ONLY the last (chronologically) client connected receives the messages from the ESP. So, if you want to broadcast messages to all clients, or control the recipient for each message send from ESP, it's not possible with the solution I suggest, (and the library tweaking required to fix that is not that simple).

Also check #2055 to why the limit was placed.

[Jonas-Meyer97]

Yeah i was aware of these problems. My question was a bit unclear.
It should be more like this:
Is there any plan to make the library send serial data to all connected devices instead of only the last conected device? Is it even possbile? Im not really sure how the whole bluetooth stuff works in detail and how the underlying software (ESP-IDF) is handling it.

[mouridis]

Yes, generally speaking, of course it's possible.

Looking at the current BluetoothSerial code (which I suggest that you do - I'm a very novice C coder but I could understand the mechanics easily), I understand that the correct way to implement support for multiple individual and independent clients would not be an easy task. (it would require handling of multiple RX, TX buffers and many other things)

But if you need a dirty fix for just simultaneous broadcast to all connected clients, I think it could be implemented with not much effort.

The library essentially transmits data in this line:

arduino-esp32/libraries/BluetoothSerial/src/BluetoothSerial.cpp

Line 90 in 0d564d7

esp_err_t err = esp_spp_write(_spp_client, _spp_tx_buffer_len, _spp_tx_buffer);

That _spp_client parameter of esp_spp_write contains the handle of the recipient connected client.

The variable receives value when a client is connected here:

arduino-esp32/libraries/BluetoothSerial/src/BluetoothSerial.cpp

Lines 165 to 174 in 0d564d7

	case ESP_SPP_SRV_OPEN_EVT://Server connection open
	if (!_spp_client){
	_spp_client = param->open.handle;
	} else {
	secondConnectionAttempt = true;
	esp_spp_disconnect(param->open.handle);
	}
	xEventGroupSetBits(_spp_event_group, SPP_CONNECTED);
	log_i("ESP_SPP_SRV_OPEN_EVT");
	break;

Now, as you can see, currently, the library only stores the handle of the most recently connected client.

You could easily modify _spp_client to be a data structure as an array or a queue, and then modify this snippes so that this structure holds the handles of all connected devices and not just the most recent one.

Then, you should modify the first part so that you loop between all values of your connected clients handles and use esp_spp_write not just once, but once for each connected client.

Of course, you would need a couple more small changes here and there (i.e. handle the disconnect of a client and update your data structure) and it would still be a very dirty fix, but it should work.

[copercini]

My first question would be what the status on the Branch: bt-serial-overhaul is. Is it already merged?

yes, it fixes a packet loss problem and is already merged

Should future commits/pull-request affecting the BluetoothSerial library be done on this branch?

no, you can use master if you want

On #1458 it was already ask for a way to use passkey/PIN with this library. How should a API look like for something like this in a arduino-ish style? Any suggestion?

I planned to implement this, initially it would be a fixed PIN passing on begin, like SerialBT.begin("ESP32name", 123456);, but it's a legacy BT method, and hard to enable on current ESP32 BT stack, that currently uses Secure Simple Pairing (SSP), the discussion is here: espressif/esp-idf#2774

Currently the BluetoothSerial library is limited to one device connected at a time. #2061
Is there any plan on allowing more devices to recieve serial data via bluetooth?

It's possible, but will they be independent clients? or all the received data will be mixed? how to handle it?

I would like to contribute by coding some part but need my questions answered before starting to spend time coding.

Yes, please, any contributions are welcome !!!

[Jonas-Meyer97]

1. ESP will receive messages from ALL connected devices and you will not have a way to distinguish which message comes from which device because all messages are on the same stream. (you can easily solve this by adding some kind of client IDs in the each of the messages that the clients sent)

Can the handle in ESP_SPP_DATA_IND_EVT be used to differentiate between differant clients sending data to the esp? I also get the same handle on ESP_SPP_SRV_OPEN_EVT and ESP_SPP_CLOSE_EVT

[pacifickashyap]

@copercini Now we can turn SSP on/off so can you please try to implement it in BluetoothSerial

[pacifickashyap]

espressif/esp-idf#2774

[copercini]

@pacifickashyap this lead us to the 2nd problem:
SSP is already compiled as enabled in arduino core, here

And seems not possible to change it in runtime, maybe @me-no-dev can help us with this =)

[copercini]

The most significant change is this one:
https://github.com/espressif/esp-idf/blob/65142bc59edb9fbf97b98b7aa867c68c32e15cb1/components/bt/bluedroid/device/controller.c#L152-L160

but if we disable CONFIG_BT_SSP_ENABLED this will not work without a PIN for BT classic in all arduino core

[pacifickashyap]

@copercini can we disable it from sdkconfig.h. If yes how?

[copercini]

@pacifickashyap arduino core use a aldeady compiled IDF version by @me-no-dev , so we can't change sdkconfig, unless he update it in the next version

You can use arduino as an IDF component, then you will compile everything from zero, including the sdkconfig changes

[xiongyumail]

@Craftplorer
You can try this compiled library.
disable_ssp.zip

[pacifickashyap]

Thanks,
it works perfectly.

[xiongyumail]

@pacifickashyap
HI ,
You can try this PR.
#2765

[pacifickashyap]

Tried it is working fine. Need to give pin only when new device is paired.
But if we use IRemote.h for Infrared remote, it gives us a error(cache disable but cache memory accesed) while pin is verified.