Is there a standard/spec for the UUID used for provisionee devices?
I don't see anything in the mesh examples that indicates a standard UUID format is used.
It allows the first half to be user generated, then just pulls the rest from FICR->DEVICEID.
In our BLE system, we used the MAC address to identify devices.
Can we generate our own UUID format to include the MAC address, company id, device type, etc?
According to the Mesh Profile Specification, section 3.10.3 "Device UUID", the UUID must follow the format of rfc4122 and a generation procedure that ensures the uniqueness of each UUID.
The Device UUID is set in nrf_mesh_init(), which is invoked indirectly from the mesh application using mesh_stack_init().
Default value is made up of DEVICEID and DEVICEADDR, both of which are random (yet unique) values written to Factory information configuration registers (FICR) during production of the SoC. The reason for using those values for the default is that they are suited for the purpose.
You can override the default Device UUID by providing your own UUID value through the mesh_stack_init_params_t structure sent to mesh_stack_init(). E.g. create your own uint8_t[NRF_MESH_UUID_SIZE] containing the UUID and point init_params.core.p_uuid to it before the call to mesh_stack_init(&init_params, ...).
it would seem that the UUID's generated in the mesh examples do not follow the format of rfc4122?The version field is zero, which is not defined by rfc4122.
if we constructed UUIDs for our devices like:
where yyyy was our bluetooth mfg ID
where zzzzzzzzzzzz, was devices' unique BLE MAC address,
would that be a "problem"?
I have asked our mesh team to have a look into your questions, and will get back to you as soon as I have any answers.
I can confirm that the way the UUID is currently generated in the examples is not conformant to rfc4122.
Back to your use case, I got the suggestion from the team that you can use a name based UUID variant (see 4.3. Altorithm for Creating a Name-Based UUID in the rfc.) You should also consider other options, like the URI parameter in nrf_mesh_prov_listen() which is the way unprovisioned devices should be tied to their OOB identification.