Bluetooth Thermometers

A BLE thermometer

A few years ago, I bought the XIAOMI Mijia LYWSDCGQ which was nice but not really cheap. Its fun characteristic was its ability to broadcast the data (temperature, humidity, battery) as well as having a connected/polled mode.


And another one

Then XIAOMI released a smaller & cheaper version (LYWSD03MMC) running on 3V lithium batteries. Trouble was, they also introduced a "bindkey". Apparently the idea behind was two-fold: To force people to use the official app only and to avoid broadcasting unencrypted data. Well.... whatever...


It wasn't long before someone found a way to intercept the key. The method was awkward at the begining but the process rapidly became easier.

Alternative firmware

Then, the masterstroke came from Aaron Christophel (aka atc1441) who astonished people by releasing an alternative firmware (removing the need of a key) for these device and providing a way to flash them directly from a Chrome browser on a mobile!

Security aspects aside, this is absolutely awesome!!!

ESPHome and OpenMQTTGateway

So I decided to try them and started using ESPHome. Even if the technology is Bluetooth Low Energy, the reaching distance is quite impressive.

ESPHome ecosystem is not bad (far from it) but one needs to define all bluetooth addresses and push a new configuration to the gateway everytime a new thermometer is added (or switched from one protocol to another). I quickly grew tired of it and started to use OpenMQTTGateway instead.

The documentation and the different websites/blog/repositories/libraries make it a little bit messy but the product works quite well and the basic idea is simple:

One board (predominantly ESP8266/ESP32 based) is acting as a gateway between a type of device (RF or BLE mainly -- others are also available) and a MQTT broker.

I'll come back to the RF gateway another time but right now, we are taking about an ESP32 devkit listening to BLE broadcasts and forwarding them as MQTT messages.

The result is something along the lines of:

OpenMQTTGateway_ESP32_BLE/BTtoMQTT/A4C138123456 {"id":"A4:C1:38:12:34:56","name":"ATC_123456","rssi":-30,"model":"LYWSD03MMC_ATC","tempc":21.4,"tempf":70.52,"hum":66,"batt":76,"volt":2.894}

There is nothing to change on the gateway to add new sensors or if you switch from ATC to Xiaomi native protocol (or vice-versa). You only have to select the MQTT messages you want to keep (although there is a white-list feature, should the local laws require filtering).

From an Android Mobile

Aside from the gateway, there is (on Google Play) a handy application called MijiaTemp which is useful to debug and/or check what the sensors are doing.

For information, an new paying one Theengs BLE as appeared recently. I haven't tested it, so I am only mentioning it.

Ecosystem as a diagram

The ecosystem is now:


    Reverse Engineering of a BLE Bulb

    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.

    Concordia Bulb

    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.

    After a bit of research, I found that the light was basically a TINT B730 by Shenzhen LEDE Technology. And that the API seems totally proprietary.

    Android to the Rescue

    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:

    Example of BLE command with wireshark

    For example here:


    By matching the actions on the app to the BLE commands, I came up with a (incomplete but sufficient) list of commands.



    The header seems totally static and always



    The trailer seems totally static and always







    White Reset


    White Mode - Brightness


    Where VV = Brightness between 02 and 0b

    White Mode - Colour Temperature


    Where VV = Colour between 02 and 0b

    RGB Reset




    Where RR, GG, BB are between 00 and FF

    Preset/Memory mode


    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)


    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:

    CS = (0B+01+01+88 + 1C) & FF = B1

    And for White Reset with a random value of 0x05:

    CS = (0D+06+02+80+80+80+80+80+05 + 1C) & FF = 2B6 & FF = B6

    Testing from the command line

    Using a Bluetooth 4.0 USB Dongle, it is now possible to control the light directly from the computer...

    • Starting Bluetooth (assuming HCI0)

    hciconfig hci0 up

    • Looking for the bulb:

    hcitool lescan should return something like:

    D0:39:72:BE:12:34 (unknown)
    D0:39:72:BE:12:34 B730
    D0:39:72:BE:12:34 (unknown)
    D0:39:72:BE:12:34 B730
    • Connecting to the bulb:

    hcitool lecc D0:39:72:BE:12:34

    • Switching the light on:

    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.

    Software can be found on github:


    Other models of bulbs

    It seems that reverse engineering of bulb is a popular sport these days. I found the following instruction for other models of lights:


    This page is for informational purposes only... You assume total responsibility and use at your own risk!

    New Bluetooth Low Energy modules

    After the upgrade disaster of the "frimware" of a HM-10, I decided to retry with 2 new modules, this time from a european based reseller.

    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...

    Bluetooth BLE Link Bee

    The first module is a Bluetooth BLE Link Bee from DFRobot.

    BLE-LINK Bee

    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.

    BLE Bee - Based on HM-11 Module

    The second one is a BLE Bee - Based on HM-11 Module from Seeedstudio.

    BLE Bee - HM-11

    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!


    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...

    Bluetooth Low Energy : HM-.... dead!

    Following my adventures with the HM-12 unconventional module, I carried my experimentations with the HM-10 module this time.

    If the majority of the functions were working, some of them like the iBeacon related ones were giving me... nothing!


    So I decided to re-flash the "frimware" (as it is called on the website), carefully following instructions up to a great Windows telling me:

    Download completed successfully


    So far, so good... but the, the module started giving me only continous


    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!


    New (different) modules are on their way. TBC...

    Page 1 / 2 »