nrf52840 mesh 3.1 UUID structure

RE: nrf52840 mesh 3.1 UUID structure

Bjørn Kvaale — Mon, 25 Feb 2019 09:17:35 GMT

The uuid_generic_format_t struct is a part of the mesh spec (see link 8 in the mesh profile spec: "RFC4122 - A Universally Uniquie Identifier (UUID) URN Namespace). Therefore, it seems you are required to use all of the variables inside this structure to remain mesh compliant. Also take a look at section 3.10.3 Device UUID in the mesh profile spec for more info:

RE: nrf52840 mesh 3.1 UUID structure

melt — Thu, 21 Feb 2019 11:35:08 GMT

Thanks Bjorn, I understand. But im not to worried about the old UUID parameters.I just wanted to know if the Node[6] ID is good enough for identification when sending messages on the mesh. I just want to see where the message originated.

RE: nrf52840 mesh 3.1 UUID structure

Bjørn Kvaale — Wed, 20 Feb 2019 09:36:03 GMT

I would recommend taking a look at the migration guide in the mesh sdk v3.1.0 folder if you have not already, along with the release notes. In the migration guide, this is written:

### Example UUIDs updated @anchor migration_310_uuid_update

- Removed `mesh_app_uuid_gen()` API to prevent use of non RFC4122 compliant UUIDs.
- Updated `nrf_mesh_configure_device_uuid_reset()` API to make generated UUID compliant with
UUID version 4 as per RFC4122.

#### Required actions
- If your systems rely on the old UUIDs, specify the old UUID in the @ref mesh_stack_init_params_t structure
during stack initialization before updating the firmware of such devices.
- Use @ref mesh_app_uuid_print() API to print the UUIDs in a standard format. When printed as array of bytes,
the UUID may not be understandable by systems that use the string representation of the UUID for parsing.