No ESP_GATTC_NOTIFY_EVT received

[bilogic]

Hi,

1. I have a blood pressure device https://www.beurer.com/web/gb/products/medical/blood-presure/upper-arm-blood-pressure-monitors/bm-85.php that operates offline and stores measurements in its memory
2. The measurements can be retrieved by registering for indications from characteristics 0x2A35 and writing 0x0002 to it's 0x2902 descriptor
3. On another piece of BLE ESP32 code, after doing .2, I immediately get a series of callback via ESP_GATTC_NOTIFY_EVT with all stored measurements. This tells me the ESP32 and BP are good.
4. However, in esp32-ble2mqtt, after doing .2, there are no ESP_GATTC_NOTIFY_EVT received
5. Further however, esp32-ble2mqtt does receive ESP_GATTC_NOTIFY_EVT when connected to another device, i.e. mi_scale

Any idea where I can start?

[shmuelzon]

Hey,

I was looking at few things in preparation for this reply and noticed that on one of my devices, one of the characteristic’s notifications aren’t received (while others work as expected). This is a characteristic I hardly expect to change so I haven’t noticed it thus far but it still doesn’t work as expected. Right now I’m suspecting my recent upgrade to ESP-IDF 3.2 so tomorrow I hope to try and sniff the BLE traffic to understand what might be the problem and also try to revert the ESP-IDF upgrade and try again. I’ll let you know if that helps at all.

The code you mentioned works, is that also based on PlatformIO? Do you know which ESP-IDF version is used there?

Good day

[bilogic]

Hi,

Yes, it is PlatformIO but using the Espressif 32 platform 1.7.0 (aka arduino framework) which says IDF 3.1.3 in its changelog.

[bilogic]

I just upgraded Espressif 32 to 1.8.0 which uses IDF 3.2.0, the code remains working with the BP monitor.

[bilogic]

I have shared my code here https://github.com/bilogic/esp32-ble See if it works on your device. You need to replace serviceUUID and charUUID in main.cpp

[shmuelzon]

Hey,

I've ran a few tests and it wasn't the ESP IDF version but rather my commit for supporting indications. I had made a mistake that always tries to enable indications instead of notifications as well. I fixed it and pushed my changes. What was weird was the facts that (a) I did receive notifications even though I enabled indications (this might be because the fact the notifications were enabled are cached on the peripheral) and (b) only some of the characteristics worked (2 out of 4). Maybe there's a limit to the number of multiple indications the ESP can handle? Can you try the latest version again an see if anything changes?

I have shared my code here https://github.com/bilogic/esp32-ble

Thanks for that, I'll take a look later on

Good day

[bilogic]

Hi,

I have trouble compiling your latest code. I have followed https://github.com/shmuelzon/esp32-ble2mqtt/issues/31 and place the 2 files in /main

It continues to show this:

...
Traceback (most recent call last):
  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 174, in <module>
    main()
  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 165, in main
    get_list(SERVICES_URL, parse_services)
  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 76, in get_list
    data = opener.open(url).read().decode('utf-8')
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 435, in open
    response = meth(req, response)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 473, in error
    return self._call_chain(*args)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 556, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 403: Forbidden
Traceback (most recent call last):
  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 174, in <module>
    main()
make[1]: *** [/e/projectx/site/iot/esp32-ble2mqtt/main/component.mk:17: /e/projectx/site/iot/esp32-ble2mqtt/main/gatt.h] Error 1  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 165, in main

make[1]: *** Waiting for unfinished jobs....
    get_list(SERVICES_URL, parse_services)
  File "E:/projectx/site/iot/esp32-ble2mqtt/get_gatt_assigned_numbers.py", line 76, in get_list
    data = opener.open(url).read().decode('utf-8')
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 435, in open
    response = meth(req, response)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 473, in error
CXX build/wear_levelling/WL_Flash.o
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "E:/portable/esp32/msys2/mingw32/lib/python2.7/urllib2.py", line 556, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 403: Forbidden
CXX build/wear_levelling/wear_levelling.o
make[1]: *** [/e/projectx/site/iot/esp32-ble2mqtt/main/component.mk:17: /e/projectx/site/iot/esp32-ble2mqtt/main/gatt.inc] Error 1
make: *** [E:/portable/esp32/esp-idf/make/project.mk:552: component-main-build] Error 2
make: *** Waiting for unfinished jobs....
...

[bilogic]

~I also looked through your last commit. I could not see anything that might have fixed the "No ESP_GATTC_NOTIFY_EVT received" issue. What's changed? Thank you.~

Just saw it. Thanks.

[bilogic]

Hi,

I don't think this commit https://github.com/shmuelzon/esp32-ble2mqtt/commit/6d307b3b65dfe2d3294a3ea9a325c0557ca9ebae?diff=unified solves the problem. My ble_characteristic_notify_register() has a variant of your fix but still facing the issue. I also do not see any difference whether htole16 is used or not.

int ble_characteristic_notify_register(mac_addr_t mac, ble_uuid_t service_uuid,
                                       ble_uuid_t characteristic_uuid)
{
    uint16_t notify_en = 1;
    ble_device_t *device;
    ble_service_t *service;
    ble_characteristic_t *characteristic;

    if (!(device = ble_device_find_by_mac(devices_list, mac)))
        return -1;

    if (!(service = ble_device_service_find(device, service_uuid)))
        return -1;

    if (!(characteristic = ble_device_characteristic_find_by_uuid(service,
                                                                  characteristic_uuid)))
    {
        return -1;
    }

    if (!(characteristic->properties & (CHAR_PROP_NOTIFY | CHAR_PROP_INDICATE)))
        return -1;

    if (characteristic->client_config_handle == 0)
        return -1;

    if (esp_ble_gattc_register_for_notify(g_gattc_if, device->mac,
                                          characteristic->handle))
    {
        return -1;
    }

    if (characteristic->properties & CHAR_PROP_INDICATE)
    {
        ESP_LOGI(TAG, "Indication registered: %s", uuidtoa(characteristic_uuid));
        notify_en = 2;
    }
    else
    {
        ESP_LOGI(TAG, "Notification registered: %s", uuidtoa(characteristic_uuid));
    }

    ble_operation_enqueue(&operation_queue, BLE_OPERATION_TYPE_WRITE_CHAR,
                          device, characteristic, sizeof(notify_en), (uint8_t *)&notify_en);

    return 0;
}

[bilogic]

In terms of logs, the one difference I see is the numerous ESP_GAP_BLE_SCAN_RESULT_EVT from esp32-ble2mqtt in contrast to my working code.

I'm unsure if the code under case ESP_GAP_BLE_SCAN_RESULT_EVT: might be interrupting ESP_GATTC_NOTIFY_EVT from happening.

[shmuelzon]

htole16() would not make a difference on the ESP32 since it's little-endian anyways. It's just to make the code more portable.

ESP_GAP_BLE_SCAN_RESULT_EVT is there pretty much all the time when devices publish themselves. I usually add an

if (event != ESP_GAP_BLE_SCAN_RESULT_EVT)

before the debug message.

Why do you think that the code for ESP_GAP_BLE_SCAN_RESULT_EVT would interfere with the ESP_GATTC_NOTIFY_EVT? Since I cannot reproduce your issue here, could you try to change the BT stack log levels for L2CAP, GAP and GATT in make menuconfig -> Component Config -> Bluetooth -> Bluedroid Enable -> BT_DEBUG_LOG_LEVEL? Maybe we'll see something there? Or at least compare it to the code that works.

[shmuelzon]

BTW - With your code, does it still work if you register on all the characteristics that support notifications/indications as I do?

[bilogic]

BTW - With your code, does it still work if you register on all the characteristics that support notifications/indications as I do?

I did not do this as I was able to make both codes the "same" by having a whitelist in ble2mqtt. In that test, my code worked, but ble2mqtt did not.

[bilogic]

Why do you think that the code for ESP_GAP_BLE_SCAN_RESULT_EVT would interfere with the ESP_GATTC_NOTIFY_EVT?

It is just pure speculation on my part based on the log differences and due to not fully understanding the scanning code.

Since I cannot reproduce your issue here, could you try to change the BT stack log levels for L2CAP, GAP and GATT in make menuconfig -> Component Config -> Bluetooth -> Bluedroid Enable -> BT_DEBUG_LOG_LEVEL? Maybe we'll see something there? Or at least compare it to the code that works.

Ok, which IDF should I be using?

[shmuelzon]

3.2 is good enough, I guess...

[shmuelzon]

Hey,

I looked over the code you shared above and the only 'real' difference I see is that all the write requests are done without a response. Could you try applying the following on your setup?

diff --git a/main/ble.c b/main/ble.c
index dca8143..60a8f91 100644
--- a/main/ble.c
+++ b/main/ble.c
@@ -147,7 +147,7 @@ static inline void ble_operation_perform(ble_operation_t *operation)
         esp_ble_gattc_write_char_descr(g_gattc_if, operation->device->conn_id,
             operation->characteristic->client_config_handle, operation->len,
             operation->value,
-            ESP_GATT_WRITE_TYPE_RSP, ESP_GATT_AUTH_REQ_NONE);
+            ESP_GATT_WRITE_TYPE_NO_RSP, ESP_GATT_AUTH_REQ_NONE);
         break;
     }

Thankfully, I still get the ESP_GATTC_WRITE_DESCR_EVT event so the queue continues to work as expected. It might also eliminate the issue you had with the Mi Scale that hanged after attempting to enable indications.

Let me know...

[bilogic]

I tried ESP_GATT_WRITE_TYPE_NO_RSP previously and the logs showed a new error, ESP_GATTC_NOTIFY_EVT was still not received, so I stopped pursuing.

I still have trouble compiling your latest code, something about the python scripts. Any idea?

[bilogic]

ESP_GATT_WRITE_TYPE_NO_RSP creates this error

W (14813) BT_GATT: ATT - Ignore wrong response. Receives (13)                                 Request(11) Ignored

[shmuelzon]

The compilation issues are detailed in #31. I have a fix for the scripts so they don’t fail but there are broken links on the bluetooth.org site that prevent building the full GATT services/characteristics database. If I were to push the fix now, basic characteristics like the device name would not be published correctly and you wouldn’t know why as there we no errors during build. I’ll give the Bluetooth SIG a couple of more days to fix it and if they won’t, I’ll sadly commit the auto-generated code. In the meantime, since you probably already have them created, you can just execute touch main/gatt.inc main/gatt.h so make won’t try to recreate them.

I’ll take a look at what that error means

[bilogic]

Ok, I'm able to compile your latest master with L2CAP, GAP and GATT set to DEBUG, however, it is generating a ton of logs and I already tried to minimize by whitelisting only indications for 0x2A35. I'm trying to think of a better strategy. :)

[bilogic]

I'm curious, does my code work for your problematic indication? Or was it resolved by this commit https://github.com/shmuelzon/esp32-ble2mqtt/commit/6d307b3b65dfe2d3294a3ea9a325c0557ca9ebae?

[shmuelzon]

No, that commit fixed it but, in my case, they were notifications, not indications. I’m going to try to flash a HR app on a BLE chip and see if it will work with this project. Maybe then I’ll be able to reproduce this issue and debug it.

[bilogic]

I actually emulated my BP device on another ESP32, but it worked fine with esp-ble2mqtt.

I just noticed both BP and mi_scale have 0x2a05, it would be interesting to know if both are getting stuck without the blacklist, see https://github.com/shmuelzon/esp32-ble2mqtt/issues/2#issuecomment-487357848.

But I have spent way too much time on this already, will get back after I'm done with other stuff. Thank you.

[bilogic]

Both BP and mi_scale gets stuck after dequeuing 0x2A05, should we pursue this first? It might lead to understanding why 0x2a35 does not trigger ESP_GATTC_NOTIFY_EVT

[bilogic]

In my code, it does not sweep through all available properties, instead it gets the serviceUUID from ESP_BLE_AD_TYPE_xxx (some form of advertisement?) and only loads the characteristics inside, so for MI_SCALE, it goes for service 0x181D, thus avoiding characteristics 0x2A05 altogether likewise for the BP (BC85), it only goes for service 0x1810.

Characteristics 0x2A05 is found under service 0x1801 for both devices.

BLE Advertised Device found: Name: Amazfit Bip Watch, Address: f2:d7:58:34:22:40, manufacturer data: 570100433e17a05e5bdf93da35fa0f0a73739303f2d758342240, serviceUUID: 0000fee0-0000-1000-8000-00805f9b34fb
BLE Advertised Device found: Name: MI_SCALE, Address: c8:0f:10:c7:6f:e1, manufacturer data: 5701c80f10c76fe1, serviceUUID: 0000181d-0000-1000-8000-00805f9b34fb
BLE Advertised Device found: Name: BC85, Address: 28:fd:80:07:b5:25, manufacturer data: 42433835, serviceUUID: 00001810-0000-1000-8000-00805f9b34fb

[shmuelzon]

Well, the sample code you provided writes to the descriptor without expecting a response and also doesn't wait for an acknowledgement from the BT stack. If we follow that logic, we can apply the following patch:

diff --git a/main/ble.c b/main/ble.c
index dca8143..def82b4 100644
--- a/main/ble.c
+++ b/main/ble.c
@@ -147,13 +147,9 @@ static inline void ble_operation_perform(ble_operation_t *operation)
         esp_ble_gattc_write_char_descr(g_gattc_if, operation->device->conn_id,
             operation->characteristic->client_config_handle, operation->len,
             operation->value,
-            ESP_GATT_WRITE_TYPE_RSP, ESP_GATT_AUTH_REQ_NONE);
+            ESP_GATT_WRITE_TYPE_NO_RSP, ESP_GATT_AUTH_REQ_NONE);
         break;
     }
-
-    if (operation->len)
-        free(operation->value);
-    free(operation);
 }

 static void ble_operation_dequeue(ble_operation_t **queue)
@@ -170,6 +166,13 @@ static void ble_operation_dequeue(ble_operation_t **queue)
         UUID_PARAM(operation->characteristic->uuid), operation->len,
         operation->value);
     ble_operation_perform(operation);
+
+    if (operation->type == BLE_OPERATION_TYPE_WRITE_CHAR)
+        ble_operation_dequeue(queue);
+
+    if (operation->len)
+        free(operation->value);
+    free(operation);
 }

 static void ble_queue_timer_cb(TimerHandle_t xTimer)
@@ -750,7 +753,12 @@ static void esp_gattc_cb(esp_gattc_cb_event_t event, esp_gatt_if_t gattc_if,
         }
         break;
     case ESP_GATTC_WRITE_DESCR_EVT:
-        need_dequeue = 1;
+        if (param->write.status != ESP_GATT_OK)
+        {
+            ESP_LOGE(TAG,
+                "Failed writing characteristic descriptor, status = 0x%x",
+                param->write.status);
+        }
         break;
     case ESP_GATTC_REG_FOR_NOTIFY_EVT:
         if (param->reg_for_notify.status != ESP_GATT_OK)

You can try it now, but even if it works, I'm not sure it's the correct solution.

[bilogic]

Hi,

I applied the patch but no joy. There is also the usual error from ESP_GATT_WRITE_TYPE_NO_RSP, are you getting anything similar?

W (27593) BT_GATT: ATT - Ignore wrong response. Receives (0x13) Request(0xd1) Ignored

[bilogic]

Am I right to say that arduino framework does not rely on bluedroid while the IDF does? I'm beginning to think the issue is not in your code but in the BLE libraries.

[shmuelzon]

No, I don't see those with my devices... But they don't support indications, only notifications. Are you getting that error for all of the characteristics that support indications? What about notifications (if any), do those also show that error?

Well, I'm stumped... I'm writing to the CCCD just like your code. Maybe I'm writing to the wrong handle and don't parse the GATT tree correctly? We can verify by printing the specific handle that we're writing to in both implementation to verify.

Am I right to say that arduino framework does not rely on bluedroid while the IDF does?

Doesn't look that way. The BLE code in your project seems like just a wrapper around the ESP-IDF APIs. Same callbacks/events and everything.

[bilogic]

Are you getting that error for all of the characteristics that support indications? What about notifications (if any), do those also show that error?

I only get 1 line of that error each time, but that could be due to my whitelist, or because it is stuck at 0x2a05. I have to setup a very specific test to find out more. I just realized a watch of mine supports only notifications. More testing required.

Well, I'm stumped... I'm writing to the CCCD just like your code. Maybe I'm writing to the wrong handle and don't parse the GATT tree correctly? We can verify by printing the specific handle that we're writing to in both implementation to verify.

I did print the handles, they match. Only the gattc_if is different, but I don't think it should affect anything.

Doesn't look that way. The BLE code in your project seems like just a wrapper around the ESP-IDF APIs. Same callbacks/events and everything.

The reason I asked is because the error comes from gatt_client_handle_server_rsp() in esp-idf\components\bt\bluedroid\stack\gatt\gatt_cl.c and it does not show up in my code as it uses ESP_GATT_WRITE_TYPE_NO_RSP

I'm just as stumped... I'm considering porting your MQTT code over to mine.

[shmuelzon]

Hey,

I loaded a blood-pressure example from TI's BLE SDK on one of their SoC's and it seems to behave correctly:

I (7818) BLE2MQTT: Discovered BLE device: a0:e6:f8:c3:f8:85, connecting
I (8928) BLE2MQTT: Connected to device: a0:e6:f8:c3:f8:85, scanning
I (9698) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/GenericAccess/DeviceName = BloodPressure Sensor
I (9798) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/GenericAccess/Appearance = 0
I (9878) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/GenericAccess/PeripheralPreferredConnectionParameters = 80,160,0,1000
I (9968) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/BloodPressureFeature = 32
I (9998) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/SystemID = 0,0
I (10068) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/ModelNumberString = Model Number
I (10098) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/SerialNumberString = Serial Number
I (10158) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,22,63,0,4,0,0
I (10188) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/FirmwareRevisionString = Firmware Revision
I (10278) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/HardwareRevisionString = Hardware Revision
I (10308) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/SoftwareRevisionString = Software Revision
I (10368) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/ManufacturerNameString = Manufacturer Name
I (10398) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/IEEE11073-20601RegulatoryCertificationDataList = 254,0,101,120,112,101,114,105,109,101,110,116,97,108
I (10478) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/DeviceInformation/PnPID = 1,13,0,272
I (10668) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,23,63,0,4,0,0
I (11148) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,23,63,0,4,0,0
I (11658) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,24,63,0,4,0,0
I (12158) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,24,63,0,4,0,0
I (12648) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,25,63,0,4,0,0
I (13158) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,25,63,0,4,0,0
I (13658) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,26,63,0,4,0,0
I (14168) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/IntermediateCuffPressure = 30,123,0,255,7,255,7,7,219,0,0,0,6,26,63,0,4,0,0
I (14668) BLE2MQTT: Publishing: a0:e6:f8:c3:f8:85/BloodPressure/BloodPressureMeasurement = 30,123.000000,83.000000,93.000000,-1.273000,0.000000,1536.000000,-229000.000000,0,4,0
I (18408) BLE2MQTT: Discovered BLE device: 70:ed:40:4c:ae:0c, not connecting
W (20708) BT_APPL: bta_gattc_conn_cback() - cif=1 connected=0 conn_id=1 reason=0x0013
I (20708) BLE: Connection closed, reason = 0x13
I (20708) BLE2MQTT: Disconnected from device: a0:e6:f8:c3:f8:85

The BloodPressure/BloodPressureFeature characteristic is read only, BloodPressure/IntermediateCuffPressure is notify only and BloodPressure/BloodPressureMeasurement is indicate only. My repository is based on the top of master branch with the patch from https://github.com/shmuelzon/esp32-ble2mqtt/issues/33#issuecomment-487861223 (haven't tried without it), but it seems to work as expected. I haven't looked at the spec to see if the values are parsed correctly or not, but at least indications and notifications are received.

[bilogic]

Hi,

Yes, I also did something similar, but still not reaching my goals. I'm using nRF as a reference in deciding if the devices aka BLE server are up to BLE specs, so far, it appears to be yes. Is having a sniffer able to find out what is going on?

[bilogic]

Not sure if you realized, the Queue timer always has to expire before the first dequeue goes out.

W (12377) BLE: Queue timer expired
W (12377) BLE: Dequeue: id: 1, type: 2, device: c8:0f:10:c7:6f:e1, char: 00002a9d-0000-1000-8000-00805f9b34fb, len: 2, val: 0x3ffd39a0
W (12377) BLE: Perform1: id: 1, type: 2, device: c8:0f:10:c7:6f:e1, char: 00002a9d-0000-1000-8000-00805f9b34fb, len: 2, val: 0x3ffd39a0
W (12387) BLE: Perform5: gattc_if: 0x1, conn_id: 0x0, client_config_handle: 0x20, length: 2
W (12397) BLE: Perform6: gattc_if: 0x1, conn_id: 0x0, UUID: 00002a9d-0000-1000-8000-00805f9b34fb, length: 2
I (12407) BLE: 02 00
D (12457) BT_GATT: gatt_get_ch_state: ch_state=4

[shmuelzon]

Yes, that’s what’s supposed to happen. When a new device is scanned, that will generate many BLE events almost simultaneously. As this takes a lot of CPU cycles (including MQTT subscriptions), the idea was to wait until I gathered all of them and only then start executing. The timer is reset after each operation is queued and only when it expires after the last one, we start dequeueing them.

[shmuelzon]

Is having a sniffer able to find out what is going on?

Sadly, I can’t guarantee that. I’m hoping it would give some insights as to what’s going on. Is the CCCD being written to correctly, is an error returned? Is an indication really sent?

[bilogic]

Ok, no problem. I will get one of it. Meanwhile I'm using your code to bridge the scale, a blacklist of 0x2a05 is needed for it to work.

And using my code to bridge the BP to http.

On 2 May 2019 17:39:39 GMT+08:00, Assaf Inbal notifications@github.com wrote:

Is having a sniffer able to find out what is going on?>

Sadly, I can’t guarantee that. I’m hoping it would give some insights as to what’s going on. Is the CCCD being written to correctly, is an error returned? Is an indication really sent?>

-- > You are receiving this because you authored the thread.> Reply to this email directly or view it on GitHub:> https://github.com/shmuelzon/esp32-ble2mqtt/issues/33#issuecomment-488611777

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[shmuelzon]

I’m sorry this has given you so much grief. But, at least you have something that works for now. If you are able to sniff the BLE traffic or have any more information that could help track down the root issue, please, let me know.

[bilogic]

No worries, I'm more than grateful for your help and promptness :) Will let you know once I make any progress. Thank you.

[shmuelzon]

@bilogic, I'm not sure if this is still relevant for you, but the new version of this project is built on a new ESP-IDF, perhaps something was fixed there.

[bilogic]

Yes it is still on my todo. Let me check it out once I find some time. Thank you.