ESPHome Bluetooth Proxy doesn't work correctly

ESPHome
1

I’ve installed HA 2022.10.4 also with newest ESPHome.
I wish to use new Active Bluetooth Proxy, but it doesn’t seem to work stable and correct.

I’ve got 1 ESP32 on ground floor and 1 ESP32 on 1st floor.
On ground floor I’ve only one Switchbot Curtain and on 1st floor I’ve got 2 of them works in group.

HA discovered switchbot devices, but integration does work very poor - it’s doesn’t work for most time.

image
image3006×254 38.5 KB

This long available devices are after HA restart. But even devices are available usually grouped curtains doesn’t work together - only one of them are moving.

Today morning one side of curtain was opened and after that I tried to open second side. But I’ve seen an error. I suppose sometime my 1st floor switchbot devices are connected to ground ESP where signal might be very poor. Like on below screen esp32_kociol_ble is device from ground floor.

image
image2198×404 101 KB

image
image2572×204 63.6 KB

Is it possible maybe to force selected ESP connect with specific switchbot (via MAC address)?
Why integrations is so unreliable?

1 Like
2

Yesterday I add Status sensor for ESPs.
As you can see devices have a ON status, but switchbots are unavailable from this morning

2990×400 85 KB

bluetooth_proxy works really unreliable

3

To use an active Bluetooth Proxy you need this in your code.

esp32_ble_tracker:
  scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true
4

I know and I use it like that.

Problem is esp which are disconnect from SwitchBot s

5

If you are still having trouble with the switchbots and the proxies:

If you flashed your ESPHome proxy before 7:00AM UTC on Tuesday, December 13, 2022, please flash again as it should improve the connection times.

Please use the web flash tool below or ESPHome addon 2022.12.0b5 or later as the main line ESPHome addon does not yet have the connection time improvements or aarch64 flashing fix:
https://esphome.github.io/bluetooth-proxies/

If you use the ESPHome addon you MUST connect the device via serial to flash it or you will not see the performance improvements with active connections.

6

After reflashing my M5 Atom, when I click install in the ESPHome Addon, is it normal to see this?:

Processing atom-bluetooth-proxy-d66750 (board: m5stack-atom; framework: espidf; platform: platformio/espressif32 @ 5.2.0)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.40402.0 (4.4.2) 
 - tool-cmake @ 3.16.9 
 - tool-ninja @ 1.10.2 
 - toolchain-esp32ulp @ 2.35.0-20220830 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch3
Reading CMake configuration...
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc
-- Check for working C compiler: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -- broken
-- Configuring incomplete, errors occurred!
See also "/data/atom-bluetooth-proxy-d66750/.pioenvs/atom-bluetooth-proxy-d66750/CMakeFiles/CMakeOutput.log".
See also "/data/atom-bluetooth-proxy-d66750/.pioenvs/atom-bluetooth-proxy-d66750/CMakeFiles/CMakeError.log".

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/tool-cmake/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /data/atom-bluetooth-proxy-d66750/.pioenvs/atom-bluetooth-proxy-d66750/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/data/cache/platformio/packages/tool-ninja/ninja cmTC_d791c && [1/2] Building C object CMakeFiles/cmTC_d791c.dir/testCCompiler.c.obj
    [2/2] Linking C executable cmTC_d791c
    FAILED: cmTC_d791c 
    : && /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -mlongcalls -Wno-frame-address   CMakeFiles/cmTC_d791c.dir/testCCompiler.c.obj  -o cmTC_d791c   && :
    /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: error loading plugin: /data/cache/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:296 (__project)
  CMakeLists.txt:3 (project)



========================== [FAILED] Took 8.69 seconds ==========================
7

That might be fixed in Support non-multiarch toolchains on 32-bit ARM by agners · Pull Request #4191 · esphome/esphome · GitHub which is in 2022.12.1

1 Like