advertisedDevice.getName() always null

[Ingineerix]

First off: Thanks for your Awesome work Neil!

I never get names returned, I'm running in Arduino IDE, and have tried to make my own app as well as tried several published examples using your library, and none return canonical device names. When I scan using the nRF Android app, it pulls the names every time.

I even tried running a modified version of your sample at: https://pastebin.com/gGXrvg6z:
`#include "BLEUtils.h"
#include "BLEScan.h"
#include

#include "BLEDevice.h"
#include "BLEAdvertisedDevice.h"

class MyAdvertisedDeviceCallbacks: public BLEAdvertisedDeviceCallbacks {
void onResult(BLEAdvertisedDevice advertisedDevice) {
Serial.println(advertisedDevice.toString().c_str());
}
};

void setup()
{
Serial.begin(115200);
Serial.println("Scanning sample starting");
BLEDevice::init("");
BLEScan* pBLEScan = BLEDevice::getScan();
pBLEScan->setAdvertisedDeviceCallbacks(new MyAdvertisedDeviceCallbacks());
pBLEScan->setInterval(0x120);
pBLEScan->setWindow(0x60);
pBLEScan->setActiveScan(true);

BLEScanResults scanResults = pBLEScan->start(10);
Serial.print("Found devices: ");
Serial.println(scanResults.getCount());
scanResults.dump();
Serial.println("Scanning sample ended");
}

void loop()
{
}
`

Here's the output:
st:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:952 load:0x40078000,len:6084 load:0x40080000,len:7936 entry 0x40080310 Scanning sample starting Name: , Address: 78:94:82:4c:21:aa, manufacturer data: e000017cca712c0e, serviceUUID: 0000fe9f-0000-1000-8000-00805f9b34fb Name: , Address: 6b:b6:f8:eb:75:97, manufacturer data: e00001b6ca808237, serviceUUID: 0000fe9f-0000-1000-8000-00805f9b34fb Name: , Address: 4e:9b:11:3a:af:ae, manufacturer data: e00001a7ca8078bd, serviceUUID: 0000fe9f-0000-1000-8000-00805f9b34fb Found devices: 3 Scanning sample ended

[chegewara]

This is my output log:

D (1179) BLEUtils: Received a GAP event: ESP_GAP_BLE_SCAN_RESULT_EVT
D (1179) BLEUtils: search_evt: ESP_GAP_SEARCH_INQ_RES_EVT, bda: 74:91:ae:6f:ee:99, dev_type: ESP_BT_DEVICE_TYPE_BLE, ble_addr_type: BLE_ADDR_TYPE_RANDOM, ble_evt_type: ESP_BLE_EVT_CONN_ADV, rssi: -66, ble_adv: ??, flag: 26 ([LE General Discoverable Mode] [Simultaneous LE and BR/EDR to Same Device Capable (Controller)] [Simultaneous LE and BR/EDR to Same Device Capable (Host)] ), num_resps: 1, adv_data_len: 28, scan_rsp_len: 7
D (1212) BLEAdvertisedDevice: - setRSSI(): rssi: -66
D (1218) BLEAdvertisedDevice: Type: 0x01 (ESP_BLE_AD_TYPE_FLAG), length: 1, data: 1a
D (1225) BLEAdvertisedDevice: Type: 0x0a (ESP_BLE_AD_TYPE_TX_PWR), length: 1, data: f9
D (1233) BLEAdvertisedDevice: - txPower: -7
D (1238) BLEAdvertisedDevice: Type: 0x03 (ESP_BLE_AD_TYPE_16SRV_CMPL), length: 2, data: f018
D (1246) BLEAdvertisedDevice: - addServiceUUID(): serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb
D (1255) BLEAdvertisedDevice: Type: 0x07 (ESP_BLE_AD_TYPE_128SRV_CMPL), length: 16, data: f2c3f0aea9fa158c9d49ae73710a81e7
D (1266) BLEAdvertisedDevice: - addServiceUUID(): serviceUUID: e7810a71-73ae-499d-8c15-faa9aef0c3f2
D (1275) BLEAdvertisedDevice: Type: 0x09 (ESP_BLE_AD_TYPE_NAME_CMPL), length: 5, data: 4368656765
D (1284) BLEAdvertisedDevice: - setName(): name: Chege
D (1289) SampleScan: Advertised Device: Name: Chege, Address: 74:91:ae:6f:ee:99, serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb, txPower: -7
D (1303) BLEUtils: Received a GAP event: ESP_GAP_BLE_SCAN_RESULT_EVT
D (1309) BLEUtils: search_evt: ESP_GAP_SEARCH_INQ_RES_EVT, bda: 21:f9:d9:20:cf:6c, dev_type: ESP_BT_DEVICE_TYPE_BLE, ble_addr_type: BLE_ADDR_TYPE_RANDOM, ble_evt_type: ESP_BLE_EVT_NON_CONN_ADV, rssi: -44, ble_adv: ??, flag: 0 (), num_resps: 1, adv_data_len: 31, scan_rsp_len: 0
D (1334) BLEAdvertisedDevice: - setRSSI(): rssi: -44
D (1339) BLEAdvertisedDevice: Type: 0xff (ESP_BLE_AD_MANUFACTURER_SPECIFIC_TYPE), length: 29, data: 060001092002eb5c5fcff53c9a3877885f933fe159a9e2b6af1273d1b3
D (1353) BLEAdvertisedDevice: - manufacturer data: 060001092002eb5c5fcff53c9a3877885f933fe159a9e2b6af1273d1b3
D (1363) SampleScan: Advertised Device: Name: , Address: 21:f9:d9:20:cf:6c, manufacturer data: 060001092002eb5c5fcff53c9a3877885f933fe159a9e2b6af1273d1b3
D (1377) BLEUtils: Received a GAP event: ESP_GAP_BLE_SCAN_RESULT_EVT
D (1383) BLEUtils: search_evt: ESP_GAP_SEARCH_INQ_RES_EVT, bda: 49:c1:61:82:05:36, dev_type: ESP_BT_DEVICE_TYPE_BLE, ble_addr_type: BLE_ADDR_TYPE_RANDOM, ble_evt_type: ESP_BLE_EVT_CONN_ADV, rssi: -47, ble_adv: ??, flag: 26 ([LE General Discoverable Mode] [Simultaneous LE and BR/EDR to Same Device Capable (Controller)] [Simultaneous LE and BR/EDR to Same Device Capable (Host)] ), num_resps: 1, adv_data_len: 28, scan_rsp_len: 11
D (1421) BLEAdvertisedDevice: - setRSSI(): rssi: -47
D (1426) BLEAdvertisedDevice: Type: 0x01 (ESP_BLE_AD_TYPE_FLAG), length: 1, data: 1a
D (1433) BLEAdvertisedDevice: Type: 0x0a (ESP_BLE_AD_TYPE_TX_PWR), length: 1, data: f9
D (1441) BLEAdvertisedDevice: - txPower: -7
D (1446) BLEAdvertisedDevice: Type: 0x03 (ESP_BLE_AD_TYPE_16SRV_CMPL), length: 2, data: f018
D (1454) BLEAdvertisedDevice: - addServiceUUID(): serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb
D (1463) BLEAdvertisedDevice: Type: 0x07 (ESP_BLE_AD_TYPE_128SRV_CMPL), length: 16, data: f2c3f0aea9fa158c9d49ae73710a81e7
D (1474) BLEAdvertisedDevice: - addServiceUUID(): serviceUUID: e7810a71-73ae-499d-8c15-faa9aef0c3f2
D (1484) BLEAdvertisedDevice: Type: 0x09 (ESP_BLE_AD_TYPE_NAME_CMPL), length: 9, data: 47616c617879205335
D (1493) BLEAdvertisedDevice: - setName(): name: Galaxy S5
D (1499) SampleScan: Advertised Device: Name: Galaxy S5, Address: 49:c1:61:82:05:36, serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb, txPower: -7
D (1512) BLEUtils: Received a GAP event: ESP_GAP_BLE_SCAN_RESULT_EVT

D (3631) SampleScan: We found 3 devices
D (3635) BLEScan: >> Dump scan results:
D (3639) BLEScan: - Name: Chege, Address: 74:91:ae:6f:ee:99, serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb, txPower: -7
D (3650) BLEScan: - Name: , Address: 21:f9:d9:20:cf:6c, manufacturer data: 060001092002eb5c5fcff53c9a3877885f933fe159a9e2b6af1273d1b3
D (3662) BLEScan: - Name: Galaxy S5, Address: 49:c1:61:82:05:36, serviceUUID: 000018f0-0000-1000-8000-00805f9b34fb, txPower: -7
D (3674) SampleScan: Scanning sample ended

As you can see 2 devices has given name, the third is my laptop and is not advertising name at all.
My esp-idf is master commit.

[philteta]

As Ingineerix says "First off: Thanks for your Awesome work Neil!"
I love BLE beacon device and your work is very usefull for me.

I have exactly the same issue as Ingineerix, I have to get the "name" of some ble beacon for my project but it always return null... I have made a test with an android application, and it s works (I get a name).

BTW, do you now a way to get the complete BLE frame (in hex) ?

thank again and best regards

[philteta]

dear all,

I have try to use getPayload() to check if my device name is in the payload or not,

I have had this on the toString method on the BLEAdvertisedDevice.h file

	if (haveRSSI()) {
		ss << ", Rssi: " << (int)getRSSI();
	}

	ss << "\nPayload:!!\n"<< getPayload();
	ss << "!!\n";

And the only stuff on the serial monitor is

Name: , Address: c2:00:a4:00:01:80, txPower: -16, Rssi: -66
Payload:!!
����⸮L!!

I m not familar with java but I have see TX power, name, and other stuff are parsed on BLEAdvertisedDevice::parseAdvertisement.

In my case my device name is 17 char long.

Is someone have an idea ?

For information, I use 1.8.10 arduino
regards

[dlat58]

Hi,

I am also seeing a very similar issue, I am surrounded by BLE devices and the scan using ESP32 and the nkolban library is regularly returning 15+ addresses, but very few (maybe 1 or 2) have a name.

For info I see name for Tiles, Garmin devices, Bose headphones, Fitbits and other fitness trackers as people walk into range.
But I do not see name for any Apple devices (Watch, iPhone, iPad, AirPods) and I do not see name for any Android phones despite the fact that I have an iPhone on my desk and an Apple Watch on my wrist. I also have an iBeacon on my desk but I can't see the name for that.

I am using an active scan with the default interval and window values.

I even added this to BLEAdvertisedDevice::parseAdvertisement but it made no difference:
case ESP_BLE_AD_TYPE_NAME_SHORT: { // Adv Data Type: 0x08
if(!haveName()) {
setName(std::string(reinterpret_cast<char*>(payload), length)); }
break;
} // ESP_BLE_AD_TYPE_NAME_CMPL

If I scan using any BLE scanner on my iPhone I see names for many more devices (but certainly not all), so there must be some advertising data I am not seeing for some reason.

I have not completed my investigations yet, so maybe I will find my missing data but any help would be appreciated.

[chegewara]

Hi,
sorry for my incompetence. Finally ive found that bug. Please try to change 31 in this line to 62.
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEAdvertisedDevice.cpp#L355

[dlat58]

@chegewara , sorry if I’m being a bit thick, but is that value always 62? Or only 62 if parsing a scan response from an active scan?

[chegewara]

62 bytes max. 31 bytes for advertising and 31 bytes for scan response. Its quick fix now, i will fix it later by sending length value from parameters.

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/bluetooth/esp_gap_ble.html#_CPPv2N22esp_ble_gap_cb_param_t25ble_scan_result_evt_param12ble_evt_typeE

[Ingineerix]

@chegewara, Thanks for this! At least now I know I'm not going crazy. I'll try my project again.

[dlat58]

@chegewara I changed the value to 62 and now I get back the name of the iBeacon on my desk (but only when it is connectable for some reason) but the many phones (and my apple watch) in my vicinity still return no names, so I assume they do not advertise their names even in the extra active response data.

[chegewara]

You can check this with nRF connect on android or nRF beacon on android.

[dlat58]

@chegewara I think my investigations are pretty much complete.

My conclusion is that the library is awesome, I have been messing about with BLE for a while but this library makes it accessible to anyone with some common sense.

Your fix in BLEAdvertisedDevice.cpp ::parseAdvertisement sizeConsumed >=62 is definitely required to get the response data.

I found some devices (maybe Garmin?) include the null terminator in the device name, which messes up your toString method (as it stops when it reaches \0). In ::setName m_name = name.c_str() fixes this.

I found some beacons (Jaalee?) only advertise the short name so I added in ::parseAdvertisment
case ESP_BLE_AD_TYPE_NAME_SHORT: { // Adv Data Type: 0x08
if(!haveName()) {
setName(std::string(reinterpret_cast<char*>(payload), length));
}
break;
} // ESP_BLE_AD_TYPE_NAME_SHORT

I found many devices don't advertise any name at all or more annoyingly only advertise a single space 0x20 (???) but your amazing method BLEDevice::getValue(address, BLEUUID((uint16_t)0x1800), BLEUUID((uint16_t)0x2A00) ) will get something reasonable back. I am assuming that, if you can connect at all, the Generic Access service will be available but I do get a few hangs from time to time so maybe not! I might add a ::haveService method to your library, also is there a way to tell if a device is connectable before I try to connect?

I have found that if you don't get back what you expect (especially from an Apple device) maybe iPad rather than Name's iPad or iPhone rather than Name's iPhone then this is because it isn't being transmitted, I'm sure there is a way but I don't know it yet. Interestingly my household is totally devoid of Android devices which probably indicates that I am giving my kids too much pocket money.

On a final note, is there any way to set a timeout on BLEClient::connect as I have found this call can take an absolute age when failing to connect?

[chegewara]

Hi,
thanks for taking time to describe all your findings. I hope we all can learn something from that.

There is few things i can help you with. First of all, service 0x1800 is obligatory and evry single ble device that you can connect to will have it, also characteristic 0x2A00. But you have to know that value of this characteristic can be empty string or something not printable.
Next, there is few bugs in this library i am just discovering. To be honest i didnt look through code to search for any, but now i am working hard on improving this library. You are having difficulties to connect to some devices because of this line:
https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/BLEClient.cpp#L114
as you can see here we have hardcoded what kind address is using peer device you are trying to connect and most of peripherals, and all apple devices are using not public address. Its to keep privacy and do not allow to keep tracking device. It has been fixed in code i am working on now, but its not merged yet. Another thing is that esp-idf bt stack have bug with this parameter, all not public addresses are recognized as RANDOM.
If you wish you can prepare merge with addition to BLEAdvertising to parse short data also with fix to parsing response packet too.

If you are brave you can try my latest code:
https://github.com/chegewara/esp32-snippets-enchancements-test/tree/multi_connect_test

[chegewara]

parsing scan response fixed by a4e3d43.

I will add short name parse when i have time and dont forget about it.