add bluetooth proxy as option

Did you try to add this line in the override yaml? bluetooth_proxy:

@govido that will do the trick right? :)

Will try! These screens are the perfect candidates to base room presence tracking om.

Just tried it, but I can't get it to work. After flashing it seems it rolls back the OTA. I see this in the ESPHome logs:

[10:13:29.383][W][safe_mode:094]: OTA rollback detected! Rolled back from partition 'app1'
[10:13:29.383][W][safe_mode:094]:  The device reset before the boot was marked successful

This is the config I used in the override yaml to setup bluetooth proxy:

esp32_ble_tracker:
  scan_parameters:
    # We currently use the defaults to ensure Bluetooth
    # can co-exist with WiFi In the future we may be able to
    # enable the built-in coexistence logic in ESP-IDF
    active: true

bluetooth_proxy:
  active: true

Just did a serial flash using the above override config and that worked. But now I get a crash.

Crash log

ESP32-S3 crashes immediately after setup() completes:

[10:34:39] ESP-ROM:esp32s3-20210327
[10:34:39] Build:Mar 27 2021
[10:34:39] rst:0x1 (POWERON),boot:0x18 (SPI_FAST_FLASH_BOOT)
[10:34:39] SPIWP:0xee
[10:34:39] mode:DIO, clock div:1
[10:34:39] load:0x3fce2820,len:0x1140
[10:34:39] load:0x403c8700,len:0xcf0
[10:34:39] load:0x403cb700,len:0x2e90
[10:34:39] entry 0x403c8910
[10:34:39] I (24) boot: ESP-IDF v5.5.5 2nd stage bootloader
[10:34:39] I (25) boot: Multicore bootloader
[10:34:39] I (25) boot: chip revision: v0.2
[10:34:39] I (25) boot: efuse block revision: v1.3
[10:34:39] I (27) boot.esp32s3: Boot SPI Speed : 80MHz
[10:34:39] I (31) boot.esp32s3: SPI Mode       : DIO
[10:34:39] I (35) boot.esp32s3: SPI Flash Size : 16MB
[10:34:39] I (39) boot: Enabling RNG early entropy source...
[10:34:39] I (43) boot: Partition Table:
[10:34:39] I (46) boot: ## Label            Usage          Type ST Offset   Length
[10:34:39] I (52) boot:  0 otadata          OTA data         01 00 00009000 00002000
[10:34:39] I (59) boot:  1 phy_init         RF data          01 01 0000b000 00001000
[10:34:39] I (65) boot:  2 app0             OTA app          00 10 00010000 007c0000
[10:34:39] I (72) boot:  3 app1             OTA app          00 11 007d0000 007c0000
[10:34:39] I (78) boot:  4 nvs              WiFi data         01 02 00f90000 00070000
[10:34:39] I (85) boot: End of partition table

[10:34:39] I (88) esp_image: segment 0: paddr=00010020 vaddr=3c190020 size=d1910h (858384) map
[10:34:40] I (255) esp_image: segment 1: paddr=000e1938 vaddr=3fc9b600 size=062e8h (25320) load
[10:34:40] I (260) esp_image: segment 2: paddr=000e7c28 vaddr=40374000 size=083f0h (33776) load
[10:34:40] I (268) esp_image: segment 3: paddr=000f0020 vaddr=42000020 size=18e524h (1631524) map
[10:34:40] I (571) esp_image: segment 4: paddr=0027e54c vaddr=4037c3f0 size=0f12ch (61740) load
[10:34:40] I (586) esp_image: segment 5: paddr=0028d680 vaddr=50000000 size=00020h (32) load

[10:34:40] I (596) boot: Loaded app from partition at offset 0x10000
[10:34:40] I (596) boot: Disabling RNG early entropy source...

[10:34:41] [I][logger:127]: Log initialized
[10:34:41] [I][app:060]: Running through setup()
[10:34:41] [I][i2c:205]: Performing bus recovery
[10:34:41] [W][component:290]: api set Warning flag: waiting for client connection
[10:34:41] [I][app:117]: setup() finished successfully!
[10:34:41] [W][component:290]: wifi set Warning flag: scanning for networks

assert failed: 0x420a8a66

Backtrace:
0x403809c9:0x3fcf3d50
0x40380991:0x3fcf3d70
0x40384f52:0x3fcf3d90
0x420a8a66:0x3fcf3dd0
0x420a8c52:0x3fcf3df0
0x420a1ef9:0x3fcf3e10
0x420a1f6f:0x3fcf3e30
0x42095ee3:0x3fcf3e50
0x420962b5:0x3fcf3e70
0x42095ef7:0x3fcf3e90
0x42095f8f:0x3fcf3eb0
0x4208d4a4:0x3fcf3ee0
0x420896db:0x3fcf3f00
0x420a7431:0x3fcf3f20
0x420a8f61:0x3fcf3f40

Decoded stack trace:

WARNING: Decoded against a local build that no longer matches the firmware running on the device, so these frames may name the wrong lines.

WARNING: Found stack trace! Trying to decode it

0x403809c9: panic_abort at /COMPONENT_ESP_SYSTEM_DIR/panic.c:477
0x40380991: esp_system_abort at /COMPONENT_ESP_SYSTEM_DIR/port/esp_system_chip.c:87
0x40384f52: __assert_func at /COMPONENT_NEWLIB_DIR/src/assert.c:40

0x420a8a66: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  at /TOOLCHAIN/xtensa-esp-elf/include/c++/14.2.0/bits/basic_string.h:809
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420a8c52: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420a1ef9: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420a1f6f: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x42095ee3: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420962b5: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x42095ef7: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x42095f8f: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x4208d4a4: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420896db: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420a7431: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

0x420a8f61: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
  (inlined by) runtime_tiles::control_event(_lv_event_t*)
  at /IDF_BUILD/../src/esphome/components/smart_display/runtime_tiles.h:4971

ELF file SHA256: 73135eac0

Running with only esp32_ble_tracker: it starts but still hangs on connecting to the wifi.

I guess this is a memory issue. I see this for the memory:

free_heap=4800
min_free=2744
largest_block=2560
psram_free=5228428

Is there anything we can do to free up some memory to enable it running bluetooth_proxy on the side?

Thanks for trying this and for posting the numbers, that makes the cause clear.

Those figures are the key: with only esp32_ble_tracker added, the chip is down to 4.8 KB of free internal memory with a largest block of 2.5 KB. The 5 MB of PSRAM does not help here, because the Bluetooth stack, Wi-Fi and the network stack all need the memory inside the chip itself. On these RGB screens that memory is already fully spoken for: Wi-Fi cannot move to PSRAM without breaking the picture, and cutting its buffers made the connection to Home Assistant stall. So this is not a matter of trimming a few kilobytes, the gap is far larger than what can be freed.

There is also the radio. Wi-Fi and Bluetooth share one antenna, and an active proxy spends a good part of its time scanning. That time comes out of the Wi-Fi link the screen depends on for layouts, pictures and staying connected, so even with enough memory the screen would get noticeably worse.

For that reason I am not going to add Bluetooth proxy as an option. For Bermuda I would recommend a separate plain ESP32 as a proxy: it costs a few euros, runs the stock ESPHome Bluetooth proxy firmware, and you can place it where reception is best for presence tracking, which matters more for Bermuda than the screen's location.

The override YAML stays yours to experiment with, of course, but I can't support this combination.

Got a screen running? Tell others which board you have and what works on the Tessera website. It helps everyone pick a screen that works.

Like my work? Consider buying me a coffee, much appreciated!

Also requested in GitHub issue #129

What would you like to add

Is possible to add bluetooth proxy? Thanks

How this relates to Home Assistant

Device tracker

Pictures, mockups, or examples

No response

Before submitting

• I searched the existing issues and this has not already been requested

This was already tested and in the issues, and for multiple reasons, this is not an option, sorry! You can dig throug the discussion if you want to know why.

Actually, it is possible on the P4 boards.

I got it working on my large Guition display using this config:

Esp32_ble_tracker:
  Scan_parameters:
    interval: 1100ms
    window: 1100ms
    active: true

bluetooth_proxy:
  active: true
  connection_slots: 3

# Example configuration entry for HTTP mode
http_request:

update:
  - platform: esp32_hosted
    type: http
    source: https://esphome.github.io/esp-hosted-firmware/manifest/esp32c6.json
    update_interval: 6h
    name: esp32_cohost_update

@MaxGramser I think it would be a good idea to add the last part for updating the ESP32C6 co-host to the default ESP32P4 firmware as it improves general WiFi and Bluetooth performance of the boards that use this co-hosted setup.

Made PR for the co-host update code: https://github.com/MaxGramser/homeassistant_espscreen/pull/140