Ble_tracker and using unsupported devices

This is a quick post for future reference. I have been playing around w/ ble_tracker lately and learning how to read BT advertisements from clients that do not have sensor support in ESPHome.

I picked up a BT weight scale from the bargain bin yesterday and BT scanning apps show it as a Cheapsea device. A little googling indicated the OKOK protocol and different array indexes for the weight data. After trying all the indexes I could find online I was still SOL. Then I stumbled up on the format_hex_pretty() method that is part of the dev branch of the ESPHome Add-On. This let’s you capture data and watch the hex binary array change and it turns out that all the array indexes online were incorrect for the scale in my hands.

So if you find yourself in the same situation, this helped:

            ESP_LOGD("ble_adv", "  Advertised manufacturer data:");
            for (auto data : x.get_manufacturer_datas()) {
                ESP_LOGD("ble_adv", "    - %s: (length %i)", data.uuid.to_string().c_str(), data.data.size());
                ESP_LOGD("ble_adv", "    - %s:", format_hex_pretty(data.data).c_str());
            }
2 Likes

Wow thank you.

I thought this would be great for trying some bluetooth bbq temp gauges, they are designed to give two temps, the “oven” temp and the internal meat temp. However I am only getting this

[18:15:24][D][ble_adv:026]: New BLE device
[18:15:24][D][ble_adv:027]:   address: 2A:03:AD:1C:93:1F
[18:15:24][D][ble_adv:028]:   name: BBQ ProbeE 31039
[18:15:24][D][ble_adv:029]:   Advertised service UUIDs:
[18:15:24][D][ble_adv:031]:     - 0x180A
[18:15:24][D][ble_adv:031]:     - 0xFB00
[18:15:24][D][ble_adv:033]:   Advertised service data:
[18:15:24][D][ble_adv:038]:   Advertised manufacturer data:
[18:15:24][D][ble_adv:040]:     - 0x2A03: (length 6)
[18:15:24][D][ble_adv:041]:     - 1F.93.1C.AD.03.2A (6):

the only data seems to be the device’s own MAC address (backwards). Also I cannot find a reference to the Service UUID 0xFB00 in any docs.

Anything else to try? My relevant config is

esp32_ble_tracker:
  on_ble_advertise:
    - mac_address: 2A:03:AD:1C:93:1F
      then:
        - lambda: |-
            ESP_LOGD("ble_adv", "New BLE device");
            ESP_LOGD("ble_adv", "  address: %s", x.address_str().c_str());
            ESP_LOGD("ble_adv", "  name: %s", x.get_name().c_str());
            ESP_LOGD("ble_adv", "  Advertised service UUIDs:");
            for (auto uuid : x.get_service_uuids()) {
                ESP_LOGD("ble_adv", "    - %s", uuid.to_string().c_str());
            }
            ESP_LOGD("ble_adv", "  Advertised service data:");
            for (auto data : x.get_service_datas()) {
                ESP_LOGD("ble_adv", "    - %s: (length %i)", data.uuid.to_string().c_str(), data.data.size());
                ESP_LOGD("ble_adv", "HEXS    - %s:", format_hex_pretty(data.data).c_str());
            }
            ESP_LOGD("ble_adv", "  Advertised manufacturer data:");
            for (auto data : x.get_manufacturer_datas()) {
                ESP_LOGD("ble_adv", "    - %s: (length %i)", data.uuid.to_string().c_str(), data.data.size());
                ESP_LOGD("ble_adv", "HEXM    - %s:", format_hex_pretty(data.data).c_str());
            }

This approach will only read passively announced data. If you have more information about the bbq communication protocol it may help. But if it requires some form of hello/INIT then that’s beyond me.

Eg. The scale I have also provides resistance data, but only after being sent a request.

Understandable. Thanks. I’ll try and trace what the android app does.