Reverse engineering the control protocol

Start by reverse engineering the control protocol for the bulb, as demonstrated in this guide. Note: If you’re using a peripheral that implements a standard service, the following process will not be necessary. The salient points are as follows:

  1. Download the ChiChinLighting Smart Light app (also available on iOS). If you’re using a different peripheral (and it doesn’t use a standard service) a similar app will be available.
  2. Set up the bluefruit sniffer and wireshark to intercept packets between the bulb. Note: the sniffer will often fail to capture packets once the devices are connected. This is because the bulb advertises on all three advertising channels, while the sniffer only listens on one. When the bulb connects to your device, it issues the connection request on only one of the advertising channels – if the sniffer is listening to a different channel, it won’t catch the pairing request and switch channels to follow it. I couldn’t find a way to fix this problem aside from disconnecting from and reconnecting to the bulb repeatedly until the channels happened to match.
  3. Control the bulb using the smartphone app. Inspect the packets for patterns based on which parameters you change. Test your hypotheses using BlueZ and gatttool (more on those in the next post).

I followed the above process, and this is what I discovered:

Command Value Notes
on cc2333
off cc2433
colour rrggbb 56(rrggbb)00f0aa rrggbb is a 6-digit hex value
warmth xx 56000000(xx)0faa xx is a 2-digit hex value
pattern pa sp bb(pa)(sp)44 pa is a pattern (0x25-0x38 inclusive), sp is the speed (0x01-0xff inclusive, larger values are slower)

To control the bulb, write to handle 0x0043. Additionally, writing ef0177 causes the bulb to send a handle value notification of 0x0050 indicating the state of the bulb. This has the form 6615(on)(st)20(sp)(rrggbb)(ww)0599, where