Missing declaration: esp_gattc_service_elem_t

[rwel59]

I've looked through lots of header files searching for the definition/declaration of this element: esp_gattc_service_elem_t.

Can't find it and a number of BLE functions seem to use it, including some sample code I've got that doesn't compile because of this error.

Has it been superceded by something or could you provide some direction as to where I can find it please

[ESP_Sprite]

components/bt/bluedroid/api/include/esp_gatt_defs.h, around line 429

[rwel59]

looked through that header... mine ends at line line 395 so I guess the issue is an outdated version. was quite sure that I had the latest but apparently that is not the case.

I'm using PlatformIO with VS Code dev environment.

PlatformIO states that they update to the latest STABLE version which they seem to define as v2.1. Here is what one of their developers says on their forum..."We use an archive esp-idf-v2.1.zip from release page https://github.com/espressif/esp-idf/releases". However, after comparing esp_gatt_defs.h for 2.1 and what I have, they are obviously different files.

Is that the correct location for latest version? I will have to go back to PlatformIO to figure this out. thanks

[kolban]

Release of the ESP-IDF can be downloaded here:

https://github.com/espressif/esp-idf/releases

At the time of writing, the latest release is v2.1. These are what I would call "stable" releases meaning that the code that comprises the release will not change over time. What works in the release will continue to work over time in that release.

The source code for what will become the next release can be found here:

https://github.com/espressif/esp-idf

This is not stable. What works today may not work tomorrow. The benefit of using this pre-release master code is that you get early access to function that will be present in the next release, bug fixes to potential bugs that were present in the previous releases and the opportunity to be a great community member to test out the new functions and if/when things break, report them back through the issues page thus becoming a tester and validator of the new code base. The down-side is that you must be patient and be prepared to realize that this is not a release and hence may contain bugs large and small. I would suggest not basing production code on anything other than a release.

[rwel59]

Didn't really want to use pre-release stuff. Got into it by trying to study/compile your (Kolban) example code on BLE Notify with your c++ wrappers. So, if I want to try and follow your stuff, do you have any other suggestions?

I was assuming that the 2.1 release probably does not offer much in the way of BLE support which is why you are using pre-release?

[kolban]

There was indeed quite a bit of churn on the ESP32 BLE support around that time. However, the classes I am tinkering with were an on-going target. When ESP-IDF 3.0 comes out I'll create a branch/release tested for that and maintain it against 3.0 while at the same time make forward progress on new functions that may become present in a post ESP-IDF 3.0 world.