Obtaining UUID of a primary service

RE: Obtaining UUID of a primary service

bluetoothmdw — Mon, 23 Feb 2026 11:28:03 GMT

Thanks, I wasn't aware of the GATT discovery manager. That sounds promising. I'll give it a try.

RE: Obtaining UUID of a primary service

Einar Thorsrud — Mon, 23 Feb 2026 11:24:47 GMT

Hi,

I have not attempted to reproduce from scratch, but these APIs are used by the GATT Discovery Manager module, and I am not aware of any bugs there (that does not mean that non can exist).

Perhaps it will be better to use the discovery manager instead? This is a module in the nRF Connect sDK exists precisely to make service discovery simpler than it is with only the Zephyr APIs. It is demonstrated in Peripheral GATT Discovery Manager (this is a peripheral sample, but the discovery part is the same regardless of GAP role). This sample performs a service discovery and prints all services and characteristics (including the service UUID).

RE: Obtaining UUID of a primary service

bluetoothmdw — Mon, 23 Feb 2026 10:37:20 GMT

Additional:

The big difference between my attempt and the solution in the referenced post is that I attempted to discover using:

discover_params.type = BT_GATT_DISCOVER_ATTRIBUTE

which the documentation describes as

// Discover Attributes of any type.

whereas the other post performs discovery in several stages following the usual GATT hierarchy:

discover_params.type = BT_GATT_DISCOVER_PRIMARY

discover_params.type = BT_GATT_DISCOVER_CHARACTERISTIC and

discover_params.type = BT_GATT_DISCOVER_DESCRIPTOR

Using the staged approach produces different values of BT_UUID_16(svc_attr->uuid)->val from primary service declarations. e.g. the working code produces output such as:

attr is a primary service. UUID type is 0, val = 1801

whereas I always get

attr is a primary service. UUID type is 13, val = e246

Is it possible that when discover_params.type = BT_GATT_DISCOVER_ATTRIBUTE is used, there's a bug?

Einar Thorsrud could you please try to recreate this situation using discover_params.type = BT_GATT_DISCOVER_ATTRIBUTE and see what you think of the results?

Thank you

RE: Obtaining UUID of a primary service

bluetoothmdw — Mon, 23 Feb 2026 09:46:42 GMT

Thank you, Einar. I hadn't spotted that post.

But whilst the author of the other post does "solve" their problem, they do also say "Per the table, user_data is a bt_gatt_service_val, and the uuid member of user_data is a 16-bit UUID with value 0x1801, or BT_UUID_GATT. This is true, but unhelpful. I was expecting the UUID of the service. This seems wrong".

I will try to use the information in that post to arrive at the result that I want but there are still open questions that this leaves.

1. Is the documentation incorrect regarding user_data?

https://docs.zephyrproject.org/latest/doxygen/html/group__bt__gatt__client.html#:~:text=bt_gatt_discover_func_t,-typedef%20uint8_t(*&text=Discover%20attribute%20callback%20function.,-conn&text=Connection%20object.&text=Attribute%20found%2C%20or%20NULL%20if%20not%20found.&text=Discovery%20parameters%20given.,order%20to%20cache%20its%20information.&text=bt_gatt_attr%20is%20given%20as%20an,See%20below.

2. If it is correct then is the behaviour encountered a bug?

3. Is the solution presented in the other post a solution or is it in fact a workaround?

A thorough sample for discovery would be a useful addition to the Zephyr or nrf samples along with improvements to the documentation.

Thanks for the pointer, hopefully I can get this working regardless of the answer to these questions :-)

RE: Obtaining UUID of a primary service

Einar Thorsrud — Mon, 23 Feb 2026 08:01:50 GMT

Hi,

Please see this post.