UUIDs and TinyB

Hi,
I've recently purchased some Puck.js units to experiment with.
I'm using them from a Raspberry PI 3, C++ with wiringPI, bluez + the Intel tinyB library for BLE.

TinyD always seems to return UUIDs as the full 128bit string representation, what is odd is if I declare a UUID on the Puck js code using a short, the 128bit UUID that is returned has garbage in it.. for example
UUID = 'BCDE' on the Puck, then from tinyD it reads back

0000bcde-0000-0000-0100-0008000000fe .. If I declare the full 128bit string in the JS then it comes back as expected. I'm just curious if it is safe to convert the string back to an array (I'm assuming the BCDE portion is in the correct lower 2 bytes due to endianess) and use the short as is or if there is an issue on the Puck side that the rest of the UUID data is perhaps corrupted?

I imagine it's a TinyB issue - Puck.js will be reporting back 16 bit UUIDs over BLE - it's not even sending the bytes for 128 bit UUIDs. If you use something like nRF connect you should see them fine.

You could always try TinyB on some other type of BLE device to make sure but I imagine you'd find the same.

There's some info on 16 bit UUIDs here: https://stackoverflow.com/questions/3621­2020/how-can-i-convert-a-bluetooth-16-bi­t-service-uuid-into-a-128-bit-uuid

Basically a 16 bit UUID should be represented as 0000xxxx-0000-1000-8000-00805F9B34FB - so you'd actually expect there to be some 'garbage' (see my response to your other post - sending 00000 instead of the extra data definitely won't make a 16 bit UUID).

However if the UUID being reported back isn't the very specific form above, something seems wrong.

Hi, I think you are correct in that it's a limitation of tinyB. The format you mention is exactly what I'm seeing with the xxxx's replaced with the 16bit UUID value.
Thanks for that link, that's exactly what I wanted so at least I know there is no fudging happening when I try to identify the correct service and characteristic.