I few months ago, I participated in the crowdfunding of a cheap Bluetooth Low Energy LED Bulb. Raised money was pitiful but project went ahead under a new name and I received my bulb anyway.
If you ask me, the name "Con Bulb" sounds odd both in English or in French (not for the same reasons) but this is not the point here so let's move on!
The website provides a link to apps (iOS and Android) but nothing else. These apps sort of work but since there is zero documentation, it's hard to guess what some functions/buttons are. And obviously, no info about the protocol used.
New versions of Android (>=4.4) have a nice feature called Bluetooth HCI snoop log. First, you need to activate the Developer Options by taping 7 times on Build number in your settings.
Then by activating the option "Bluetooth HCI snoop log", all the Bluetooth traffic will be recorded in a file (in /storage/emulated/0/Android/data/btsnoop_hci.log on my phone running Lollipop).
This file can then be read with Wireshark on a computer.
Decoding the data
All commands sent to the bulb follow a similar pattern:
For example here:
aa:0a:fc:3a:86:01:0b:01:08:5d:8d:0d
By matching the actions on the app to the BLE commands, I came up with a (incomplete but sufficient) list of commands.
API
Header
The header seems totally static and always
aa:0a:fc:3a:86:01
Trailer
The trailer seems totally static and always
0d
Commands
On
0a:01:01:00:28
Off
0a:01:00:01:28
White Reset
0d:06:02:80:80:80:80:80:RD:CS
White Mode - Brightness
0c:01:VV:RD:CS
Where VV = Brightness between 02 and 0b
White Mode - Colour Temperature
0e:01:VV:RD:CS
Where VV = Colour between 02 and 0b
RGB Reset
0d:06:01:80:80:80:80:80:RD:CS
RGB
0d:06:01:RR:GG:BB:80:80:RD:CS
Where RR, GG, BB are between 00 and FF
Preset/Memory mode
0b:01:MM:RD:CS
Where MM is a Preset mode:
MM=01: Red
MM=02: Green
MM=03: Blue
MM=04: Yellow
MM=05: Pink
MM=06: Cyan
MM=07: White
MM=08: Cycle of Primary Colours (Fast)
MM=09: Cycle of Primary + Secondary Colours
MM=0a: Cycle of Primary Colours (Slow)
Night Mode (Switches off after 20 minutes)
10:02:03:01:RD:CS
About RD & CS bytes
RD seems totally random
CS is apparently a checksum value equal to SUM(bytes composing the command including the random value + 0x1C) & 0xFF
For example, for preset #1 (Red) with a random value of 0x88:
gatttool -b D0:39:72:BE:12:34 --char-write-req -a 0x0021 -n aa0afc3a86010a010100280d
Python version
Using bluepy and a bit of Python, it is possible to control the light easily. Beware, the protocol is only partially implemented and communication is only unidirectional (computer to bulb) without waiting for any feedback. It might be a very bad idea to send commands at random (eg white temperature while in RGB mode) and/or too quickly.
And since I also supported the airboard project, I decided to buy them in XBee format (without really knowing it, see below).
Both are based on TI chips (CC2540 for the first one et CC2541 for the second). One day I'll have to have a serious look at Nordic Semiconductor's offering (specially their new nRF51822 SoC) but the boards based on nRF8001 were out of stock anyway...
This module is the one officialy supported by the airboard. It comes with a very handy micro-usb port and integrated voltage regulator & leds. The "AT" physical switch is no longer in use with recent firmware.
I haven't explored much but, so far, I am happily surprised.
This is basically a HM-11 module with a couple of capacitors in the XBee form factor. Nothing more! Not even a "system led".
Price (even directly in China) is basically 4 times the one of the HM-11 alone and twice the one of the module above (but with fewer bells and whistles). This sounds odd but at least the embedded HM-11 seems genuine and the upgrade to the very latest firmware went without a hitch!!
But before I reached this stage, I discovered what the "Xbee form factor" was:
As a frenchman, I am a strong Metric System Advocate as it is better on all counts. But having a module using a 2mm (instead of standard 2.54mm) spacing was annoying (that said the HM-1x modules themselves use 1.5mm) as I had to create a makeshift pin adapter to be able to connect to the module. At least, I'll know for next time!
iBeacon
Despite following all the instructions carefully, I was still unable to create a iBeacon with these modules.
Turned out that there is a bug with iOS 7.1.1 and iBeacons are not always detected. So maybe that was the signal to upgrade to iOS 8.
Using iOS 8.1.3, I was able to see the beacons... but with the HM-11 module, I had to more issues: It seems very unstable on a 3V battery (maybe a booster and/or a proper sleeping management is required) and I wasn't able to set-up the calibration value as AT+MEAS doesn't seem to work. Oh well...
One power cycle later, it got even worse because I know have only
www.jnhuama.cwww.jnhuama.cwww.jnhuama.cwww.jnhuama.c (note the missing final "n"!)
I used the correct file ("CC2540" chip and HM-10 firmware) and the upload wasn't interrupted... So what went wrong? Not a clue... I only guess that I managed to brick my $6.87 module. This time I am really starting to wonder if these HM modules were really genuine!
Not everything in The Project is wireless, the Gas and Electricity sensors are (at least for the moment) wired, the Internet connection and, last but not least, the power supply, are too.
This is where the WAF (i.e. Wife acceptance factor) enters. Wikipedia has an extensive explanation about the concept. (Actually, it could also have been called Valentine Acceptance Factor on this day!)
We are not talking about expensive stuff (it's build rather on the cheap, isn't it?) here but having to cope with bizarre (and wired) apparatus in the flat.
The best way I found, on top of having a very accepting and forgiving spouse, was to enlist her and use her newly acquired illumination skills to decorate the wooden box.
