Open ammmze opened 2 years ago
Looks like getting it to compile with the esp-idf framework is relatively simple. Just had to replace the #ifdef ARDUINO_ARCH_ESP32
with #ifdef USE_ESP32
so it applies to all esp32. This should work in any of the 2.x+ release since we're just relying on the bluetooth stuff from esphome.
However, I'm not sure if this is something with the ESP32 C3, or something with the esp-idf framework, but I cannot connect to the device (and it's very different from the failing to pair that many other of the open issues refer to, which i've attempted to fix with a PR in esphome). I'm getting the following when it tries to connect...
[17:17:31][V][esp-idf:000]: W (31161) BT_APPL: gattc_conn_cb: if=3 st=0 id=3 rsn=0x100
[17:17:31][V][ble_client:147]: [e6:8a:37:a3:02:ea] ESP_GATTC_DISCONNECT_EVT, reason 256
[17:17:31][W][idasen_desk_controller:051]: [Office Desk] Disconnected!
[17:17:31][W][ble_sensor:039]: [Desk Height] Disconnected!
[17:17:31][V][sensor:074]: 'Desk Height': Received new state nan
[17:17:31][D][sensor:125]: 'Desk Height': Sending state nan cm with 1 decimals of accuracy
[17:17:31][W][ble_sensor:039]: [Desk Speed] Disconnected!
[17:17:31][V][sensor:074]: 'Desk Speed': Received new state nan
[17:17:31][D][sensor:125]: 'Desk Speed': Sending state nan cm/min with 0 decimals of accuracy
[17:17:31][V][ble_client:115]: [e6:8a:37:a3:02:ea] ESP_GATTC_OPEN_EVT
[17:17:31][W][ble_client:117]: connect to e6:8a:37:a3:02:ea failed, status=133
In this case, it's disconnecting well before the desk drops out of pair mode. And the disconnect reason is NOT a timeout. The disconnect reason here is:
ESP_GATT_CONN_CONN_CANCEL = 0x0100, /*!< L2CAP connection cancelled */ /* relate to BTA_GATT_CONN_CONN_CANCEL in bta/bta_gatt_api.h */
It doesn't even make enough of a connection to fetch the services and characteristics. I'll be experimenting more with it and will keep this issue updated.
The next thing I want to try is using the esp-idf framework with a regular ESP32 (instead of an ESP32-C3) and see if that makes a difference.
Looks like things are similar with a regular ESP32 with esp-idf framework where I'm still seeing the same disconnect. Though it appears to be able to retrieve the characteristics, but notifications don't work, so the state is not updated. I suspect this is ultimately more esphome issues rather than issues with this custom component. When I get a chance, I'll probably send a PR to fix it so it will at least compile correctly on esp-idf. That way, once we have working support in esphome, it should just work.
hrm...more wonky-ness. I tried to switch back to arduino framework and now notifications aren't working there now :( And now i'm getting 2 of these messages instead of 1.
[W][ble_client:177]: No descriptor found for notify of handle 0x1a
Previously, I would get 1 of them because for whatever reason unless I only had 1 sensor (in which case I didn't get the message at all).
Any idea what it would take to allow this to work with the esp-idf framework? I'm trying to run this on an M5 Stamp C3U (an ESP32-C3 variant), but only the esp-idf framework supports the esp32-c3 boards. When I attempt to compile with esp-idf framework, I get the following: