In first post we have seen that the WeDo 2.0 Hub offers a “Battery Service” Primary Service:
[A0:E6:F8:1E:58:57][LE]> primary ... attr handle: 0x0046, end grp handle: 0xffff uuid: 0000180f-0000-1000-8000-00805f9b34fb ...
‘180F’ is defined in the Bluetooth Standard as a ‘Battery Service‘. LEGO assigned all handles from 0x0046 to 0xFFFF to this service (not quite true: since there is no other Primary Service, gatttool assumes 0xFFFF as the last handle).
What handles and characteristics?
[A0:E6:F8:1E:58:57][LE]> characteristics 0x0046 0xffff handle: 0x0047, char properties: 0x12, char value handle: 0x0048, uuid: 00002a19-0000-1000-8000-00805f9b34fb
[A0:E6:F8:1E:58:57][LE]> char-desc 0x0046 0xffff handle: 0x0046, uuid: 00002800-0000-1000-8000-00805f9b34fb handle: 0x0047, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x0048, uuid: 00002a19-0000-1000-8000-00805f9b34fb handle: 0x0049, uuid: 00002902-0000-1000-8000-00805f9b34fb
So there is just one useful characterist, the one with UUID ‘00002a19-0000-1000-8000-00805f9b34fb’ or just ‘2a19’ assigned to handle 0x0048.
There are 3 other characteristics (‘2800’, ‘2803’ and ‘2902’) each one assigned to one handle (‘0x0046’, ‘0x0048’ and ‘0x49’). What’s their purpose?
The first characteristic (‘2800’) contains the UUID of the Primary Service (we already know that it is ‘180F’):
[A0:E6:F8:1E:58:57][LE]> char-read-hnd 0x046 Characteristic value/descriptor: 0f 18
The second characteristic (‘2803’) describes the Service – something we already know from the ‘characteristics’ command:
[A0:E6:F8:1E:58:57][LE]> char-read-hnd 0x047 Characteristic value/descriptor: 12 48 00 19 2a
The first byte is the ‘characteristic properties’. Each bit has a meaning:
Broadcast: 01h
Read: 02h
Write without response: 04h
Write: 08h
Notify:10h
Indicate: 20h
Authenticated Signed Writes:40h
Extended Properties: 80h
So ’12h’ means ‘notify’ + ‘read’ so we can read and the battery level and we can also ask for notifications.
The second and third bytes specify the handle associated to the battery level: ‘0048h’.
The fourth and fifth bytes specify the characteristic UUID of the battery level: ‘2a19’.
Now the last characteristic (‘2902’) is used for notification and indication control.
[A0:E6:F8:1E:58:57][LE]> char-read-hnd 0x049 Characteristic value/descriptor: 00 00
Since it’s value is ‘0’ it means ‘Notifications and indications disabled’
Now let’s read the battery level, at the third characteristic (UUID: ‘2a19’/ Handle: 0x0048)
[A0:E6:F8:1E:58:57][LE]> char-read-hnd 0x048 Characteristic value/descriptor: 64
64h = 100d so battery level is 100%
We can also use this other command:
[A0:E6:F8:1E:58:57][LE]> char-read-uuid 2a19 handle: 0x0048 value: 64
Now let’s check with Android nRF Connect App:
Seems ok once again.
Until now we just accessed information defined in the Bluetooth standard. Maybe in the future the Bluetooth SIG decide to include motors, lights and other devices in the standard but for now each vendor (like LEGO) decides how to communicate with its gadgets and if it doesn’t release that information to the public it’s almost impossible to develop third-party applications for it.
LEGO promised to release a SDK in the first half of 2016. That’s a good decision, everyone (including LEGO) will benefit if everyone can create it’s own application and even integrate it with other tools or systems. But we are already in the second half of 2016 and no SDK…
Luckily there are already a few pieces of information scattered around the Web…
Next post: the WeDo 2.0 Hub button.