The relevant section of the BT specification you should check is Service Discovery Protocol for an explanation on how UUIDs are used and defined in Bluetooth. They are used to describe particular services and their characteristics - in very basic terms think about it a little bit like port numbers on a PC network, with which you might be more familiar.
UUIDs are 128 bit numbers used to look up attributes but they can be shortened to 32 or 16 bit forms.
Services defined by the Bluetooth standards have UUIDs assigned to them, but you can add your own.
For example, if you want to define a new service, you can allocate your own UUID to represent it. There is a mechanism to minimise the chance of a clash of UUIDs. You can generate a random number for now if you're just testing - you should check the BT standards how to build the correct UUID for an existing service.
Thank you christophergregga_76. This is very clear and comprehensible.
However, I do not think the UUID I am referring to is a Service UUID. I have created my own service, which contains 3 characteristics. I have used IEEE to generate four 128-bit UUIDs - one for the service and three for the characteristics. I can clearly see these, along with the standard services of Device Information and Battery Service I am also using (these have their own, shorter, standard UUIDs). I have included these in my code in just the same way as is clearly shown in Wiced Example projects.
The UUID I am referring to is called a Peripheral ID by LightBlue, and seems to relate to the device, rather than any particular Service offered by the device. The UUID value is not one that I have specified anywhere in my code. This is why I suspect it is put in by Atmosphere Programmer when I use that to initialise my hardware.
Because my app uses the Service UUID to recognise that this is the correct peripheral, it doesn't seem to matter what this Peripheral ID is, but I am not entirely happy that I am generating and communicating a UUID code over which I have no apparent control. If I'm worrying about nothing, that's fine - I'd just like to understand.
1 of 1 people found this helpful
I think I've finally got the answer I need on this. The only UUIDs you need to be concerned with are the Service and Characteristic UUIDs described by christophergregga_76 above. The Project UUIDs I mention are not relevant to anyone developing with Wiced SDK. They relate only to projects generated by some other tools.
What is important is understanding the Device/Peripheral UUID displayed in LightBlue, as I do not recognise it, even on my own products. The reason is that it's generated by iOS. Instead of displaying the Bluetooth MAC address for a particular device, it assigns this UUID to that device, and hides the MAC address. I believe that Android does not do that.
It's some relief to learn this, as I was quite perturbed by a code being displayed and not having any idea where it came from. As I use the facility in 'Make Target' to enter different MAC addresses for every device in the 'Target Name' field, I will continue to get different UUIDs for every device from iOS.