ESP32-C6 support possible?

[xawill]

Hi @fsaris, thank you very much for this component! I've since the beginning wanted to have a more reliable solution than the Home Assistant integration.

I have an esp32-c6-devkitc-1 board and wanted to try it out. Unfortunately it fails at installation with a type error (see attached full log file):

src/esphome/components/awox_mesh/mesh_connection.cpp:119:19: error: format '%d' expects argument of type 'int', but argument 6 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
119 |     ESP_LOGI(TAG, "%d queued commands (debounce timer: %d, next command %02X, for dest: %d)",

I am aware that you are probably not supporting the ESP32 C6 variant at the moment, but I was wondering if this is an error from your component that could be relatively easy to fix.

I would be very happy to help testing for the C6 variant, so don't hesitate to ask in case this is an issue you want to give a quick look at.

Thanks a lot in advance!

PS: I also attached my full yaml config.

logs_entrance_compile.txt
entrance.yaml.txt

[fsaris]

Looks that my latest changes need some attention to not break the compile process.
Will give it a look.

Not sure if this component works on a C6. Does the Bluetooth proxy work on it?

[fsaris]

ok, looks that the esp32-c6 is stricter with types. Will push some updates later today, but not sure if I will be able to identify all issues.

[xawill]

Yes, bluetooth proxy works with some special config (see my yaml repro file) and the ´dev’ branch of esphome.

Thanks a lot for checking the types! It indeed looks like this issue at least is only types-related.

[fsaris]

@xawill I updated some of the logging. And tried to build you yaml config. But it failed for me on a line from esp32_ble but I'm not on dev so maybe this is resolved in ESPHome already.

reference: 87d94d9

[xawill]

Thank you @fsaris for the quick fix! Yes, the dev branch fixes a compilation issue.

I have been testing it for a while and unfortunately it seems like the connection with the mesh cannot complete (even though it is recognized) with my C6 version. I have a BT_APPL: gattc_conn_cb error.

I therefore tried in VERY_VERBOSE logging mode to get more info about the underlying issue and encountered more type issues that could be linked with that issue:

In file included from src/esphome/components/awox_mesh/mesh_connection.h:8,
                 from src/esphome/components/awox_mesh/mesh_connection.cpp:5:
src/esphome/components/awox_mesh/mesh_connection.cpp: In member function 'virtual void esphome::awox_mesh::MeshConnection::loop()':
src/esphome/components/awox_mesh/mesh_connection.cpp:106:19: error: format '%d' expects argument of type 'int', but argument 5 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
  106 |     ESP_LOGV(TAG, "Send command, time since last command: %d", esphome::millis() - this->last_send_command);
      |                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/esphome/core/log.h:72:36: note: in definition of macro 'ESPHOME_LOG_FORMAT'
   72 | #define ESPHOME_LOG_FORMAT(format) format
      |                                    ^~~~~~
src/esphome/core/log.h:154:28: note: in expansion of macro 'esph_log_v'
  154 | #define ESP_LOGV(tag, ...) esph_log_v(tag, __VA_ARGS__)
      |                            ^~~~~~~~~~
src/esphome/components/awox_mesh/mesh_connection.cpp:106:5: note: in expansion of macro 'ESP_LOGV'
  106 |     ESP_LOGV(TAG, "Send command, time since last command: %d", esphome::millis() - this->last_send_command);
      |     ^~~~~~~~
src/esphome/components/awox_mesh/mesh_connection.cpp:106:60: note: format string is defined here
  106 |     ESP_LOGV(TAG, "Send command, time since last command: %d", esphome::millis() - this->last_send_command);
      |                                                           ~^
      |                                                            |
      |                                                            int
      |                                                           %ld
In file included from src/esphome/components/awox_mesh/device.h:7,
                 from src/esphome/components/awox_mesh/mesh_connection.h:13:
src/esphome/components/awox_mesh/helpers.h: At global scope:
src/esphome/components/awox_mesh/helpers.h:17:20: warning: 'std::string esphome::awox_mesh::int_as_hex_string(unsigned char, unsigned char, unsigned char)' defined but not used [-Wunused-function]
   17 | static std::string int_as_hex_string(unsigned char hex1, unsigned char hex2, unsigned char hex3) {
      |                    ^~~~~~~~~~~~~~~~~
cc1plus: some warnings being treated as errors
*** [.pioenvs/entrance/src/esphome/components/awox_mesh/mesh_connection.cpp.o] Error 1
========================= [FAILED] Took 36.81 seconds =========================

By the way, I saw in your commit that you referenced issue 104 instead of this one.

[fsaris]

I have a BT_APPL: gattc_conn_cb error.

Those I get also sometimes. Be sure to clean the build files (the Clean build files option in the context menu) and upload the software using a wired connection.

I fixed the type issue.

[xawill]

Thank you very much, everything compiles perfectly!

Unfortunately I cannot manage to have a connection to the mesh. The very verbose logs didn't help. I am stuck with 1 device found, but 0 known and 0 fully recognized:

[15:53:09][D][awox.mesh:235]: Total devices: 1
[15:53:09][D][awox.mesh:237]: Available device A4:C1:38:D9:96:1B [0] => rssi: 4294957297
[15:53:09][D][awox.mesh:260]: Currently 0 mesh devices reachable through active connections (0 currently known and 0 fully recognized)
[15:53:09][D][awox.mesh:133]: No devices found to connect to

But you did everything you could. I guess this is a BLE incompatibility issue. You can close this issue if you want. Cheers!

[fsaris]

I see that the RSSI value is now not correctly shown in the logs, should be a negative value. Just pushed a fix for that.

Looks the the connection from you ESP to the BLE device is not reaching the minimal RSSI value. You can decrease this by changing the min_rssi https://github.com/fsaris/EspHome-AwoX-BLE-mesh-hub?tab=readme-ov-file#min_rssi-number---optional or change the position of the ESP

[xawill]

Oh, good catch! Yeah, I'll try min_rssi value. The ESP is already right next to the lamp for testing, so should be ok :)

[fsaris]

There is a lot of stuff that can interfere with the Bluetooth connection; power device, other wifi devices power cords etc.

[xawill]

From what I see in the docs, min_rssi=-90 by default. After your fix, I see my device at -56, but suddenly switches to -9999. I also still have a few BTU_TASK error during the connection process which eventually fails. 🤷🏼