Fixes BLE remote address type when connecting

[rbaron]

What does this implement/fix?

ESPHome running on esp32-c3 fails to connect to some BLE devices. A simple example is the nrf_blinky running on an nRF52840. While the dev branch running on the usual esp32 connects without issues, the same code running on the esp32-c3 fails with the following error:

[20:53:30][I][ble_client:085]: Attempting BLE connection to f5:30:30:a4:51:fc
...
[20:54:00][D][esp-idf:000]: W (31108) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x100
[20:54:00][W][ble_client:118]: connect to f5:30:30:a4:51:fc failed, status=133

After comparing the ESPHome BLE connection procedure with the BLE_Client.cpp from arduino-esp32 (which does work and connect while running on the esp32-c3), one of the differences is that we always use BLE_ADDR_TYPE_PUBLIC as the address type in the esp_ble_gattc_open call.

Updating it to use the actual scanned address type fixed the issue on the esp32-c3, while the esp32 kept working as before. My guess is that the BLE stack in the esp32-c3 is more strict about this argument.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Related issue or feature (if applicable): fixes

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#

Test Environment

• ESP32
• ESP32 IDF
• ESP32-C3 IDF
• ESP8266

Example entry for config.yaml:

For ESP32-C3:

esphome:
  name: ble-client-test
  platformio_options:
    board_build.flash_mode: dio

esp32:
   board: esp32-c3-devkitm-1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y

esp32_ble_tracker:

ble_client:
  - id: test_ble_client
    mac_address: F5:30:30:A4:51:FC

For ESP32:

esphome:
  name: ble-client-test

esp32:
  board: esp32dev
  framework:
    type: esp-idf

esp32_ble_tracker:

ble_client:
  - id: test_ble_client
    mac_address: F5:30:30:A4:51:FC

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[probot-esphome]

Hey there @buxtronix, mind taking a look at this pull request as it has been labeled with an integration (ble_client) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[janchrillesen]

I see a similar issue on ESP32 (non C3 version) after upgrade to the latest ESPhome

[10:13:35][D][esp32_ble_tracker:217]: Starting scan...
[10:13:37][D][ble_client:047]: Found device at MAC address [58:93:D8:8C:4D:D2]
[10:13:37][I][ble_client:085]: Attempting BLE connection to 58:93:d8:8c:4d:d2
[...]
[10:14:07][W][ble_sensor:037]: [Radon] Disconnected!
[10:14:07][D][sensor:125]: 'Radon': Sending state nan Bq/m³ with 0 decimals of accuracy
[10:14:07][W][ble_sensor:037]: [Radon long term] Disconnected!
[10:14:07][D][sensor:125]: 'Radon long term': Sending state nan Bq/m³ with 0 decimals of accuracy
[10:14:07][W][ble_client:118]: connect to 58:93:d8:8c:4d:d2 failed, status=133

This is the relevant config

  - platform: ble_client
    ble_client_id: airthings_radon
    update_interval: 5min 
    name: "Radon"
    icon: 'mdi:radioactive'
    service_uuid: 'B42E4A8E-ADE7-11E4-89D3-123B93F75CBA'
    characteristic_uuid: 'b42e4dcc-ade7-11e4-89d3-123b93f75cba'
    unit_of_measurement: "Bq/m³"
    lambda: |-
      uint16_t radon = x[4];
      radon += (x[5] << 8);
      return (float)radon;

  - platform: ble_client
    ble_client_id: airthings_radon
    update_interval: 5min 
    name: "Radon long term"
    icon: 'mdi:radioactive'
    service_uuid: 'B42E4A8E-ADE7-11E4-89D3-123B93F75CBA'
    characteristic_uuid: 'b42e4dcc-ade7-11e4-89d3-123b93f75cba'
    unit_of_measurement: "Bq/m³"
    lambda: |-
      uint16_t radon_lt = x[6];
      radon_lt += (x[7] << 8);
      return (float)radon_lt;      

[jesserockz]

LGTM