Skip to content

BLE Appearance Characteristic only supports an incomplete hard-coded list of icons (IDFGH-14569) #15327

Open
@qwertymodo

Description

@qwertymodo

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

idf-release_v5.3-cfea4f7c-v1

Espressif SoC revision.

ESP32

Operating System used.

Windows

How did you build your project?

Other (please specify in More Information)

If you are using Windows, please specify command line type.

None

Development Kit.

ESP32-DevKitC

Power Supply used.

USB

What is the expected behavior?

When I call esp_ble_gap_config_local_icon() with a valid Appearance value, I expect that value to be accepted and the Appearance to be updated accordingly.

What is the actual behavior?

esp_ble_gap_config_local_icon() seems to have a hard-coded list of Appearance values here that it will accept, and any other values are rejected with an ESP_ERR_INVALID_ARG error. Unfortunately, this hard-coded list is both woefully incomplete and also unmaintained, as the git blame seems to indicate only a single value has been added to the list since it was originally created 7 years ago, so many completely valid Appearance values are rejected.

Steps to reproduce.

Attempt to call esp_ble_gap_config_local_icon with any Appearance value not explicitly defined in the switch case found at https://github.com/espressif/esp-idf/blob/master/components/bt/host/bluedroid/api/esp_gap_ble_api.c#L304

e.g.:
0x03CA (Presentation Remote)
0x04C1 (Switch)
0x0540 (Generic Sensor)
etc.

Check the return value, which will be 0x102 ESP_ERR_INVALID_ARG and the Appearance will remain 0x0000 Unknown when connecting to the device.

Debug Logs.


More Information.

I recommend simply removing the switch statement entirely. It would be one thing if the list was actively maintained and up-to-date with all current valid Appearance definitions, but as that is clearly not the case, the "validation" is not itself valid and is instead rejecting perfectly valid inputs for no reason.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions