A few weeks ago I stumbled on some posts for the Xiomi MI, band. Cheap thing $30, Amazon gets it to me in 2 days. I found websites that detailed how to communicate with it from a BLE Central device, so I thought cool, I'll get one. Impulse buy.
This was the perfect use for my BLE Nano. I already had some BLE Central code written that worked for communicating with the RFDuino. Of course, this wouldn't work...
After about 8 hours, it came down to a parameter change on the connect, ex.
ble.gap().connect(params->peerAddr, Gap::ADDR_TYPE_PUBLIC, NULL, NULL);
My original code had a random address type. This was quite maddening because I could connect with the MI from both Unix and my iPhone using "LightBlue".
It wasn't until I connected that I realized the communication protocol's for the MI had changed.
The current protocol is actually more standardized. All alerts (buzzing) are through a standard BLE endpoint for "Immediate Alert". LED control, not so much, I now realize LED control isn't exposed to an external device. My plan had been to use the 3 led's as a sort of traffic light, or:
- led 1 = >200mg/dl
- led 2 = >100mg/dl
- led 3 = blink out the 10's every minute or so.
- led 1 = >200mg/dl
- led 2 = >100mg/dl
- led 3 = blink out the 10's every minute or so.
Or something like that, coupled with buzzing to queue me in on what's going on.
If you look around for posts on the MI, you'll see the lights don't really work anyway. They're triggered by an accelerometer that only responds to some bizarre form of hand waving, I got them to light up once or twice, the motion required being way to ridiculous for public presentation.
That said, could be an excellent vibrating alert device that can go a month on a charge.
Some other notes from this experience:
1. The BLE Nano (with MBED) doesn't really work with Windows 10, unless you're comfortable restarting windows frequently. The Arduino version may be fine, I have one of each, but I have issues with BLE Central on the Arduino version. In the end, I moved my development over to the Mac. Additionally, opening and closing serial windows and dragging/dropping hex files is a PIA. I was able to automate this to some extent with the Mac, one of the reasons I purchased a Mac, nice to finally put that to use. See my github for a basic script. In a nutshell, it's a ksh that watches the download folder for a hex file, moves it to the Nano, and launches a serial window.
2. I don't think BLE sniffing is all it's cracked up to be. I have an Ubertooth and a Nordic device and can hook them up to Wireshark. With an RFduino I can see all the "Magic" packets (ATT etc). With more proprietary devices like the MI or the Pebble, once these things pair, I don't see anything. If you want to hack a BLE device, decompile the Android APK if one is available.
On to the Pebble watch. Still going strong. Found out from Pebble support that the aplite versions of the pebble support "Pin" pairing via bluetooth. The new models only support ssp (simple secure protocol). They also pointed out the mfg'r note for nRF51, which indicates that while ssp is in the command set, it doesn't actually work. Allegedly there's a beta that will support ssp, and will pair with the Pebble Time. Wait and see.
