ESP32C3 czy ESP32S3 do Bluetooth Proxy na ESP Home

Mam w domu Bluetooth Proxy na ESP Home na esp-idf. Całość uruchomiana na XIAO ESP32C3.

Niestety nie łapie zasięgu we wszystkich pokojach, dlatego planuję dodać kolejne proxy.

Szukając po stronie Seed studio znalazłem ESP32S3

Różnica w cenie praktycznie żadna, jednak wg opisu ma BLE 5.0 dual-mode (cokolwiek to znaczy). I tu rodzą się moje pytania:

  • który układ lepiej użyć i dlaczego?
  • czy do płytek warto dokupić dodatkową antenę?

Czy wersja S3 ma jakieś zalety pod kątem bt proxy? Czy antena da znaczący uzysk? Być może lepiej byłoby dać 3 proxy zamiast jednego z większą anteną?
Będę wdzięczny za podzielenie się doświadczeniami.

Planuję dodać kilka termometrów Xiaomi LYWSD03MMC (wiem, że jest soft z Zigbee, ale jakoś nie polubiliśmy się z zegbee przy próbie wykorzystania przycisków z IKEA, wiec wolę na razie zostać przy BT)

Obawiam się, że jest dużo pytań a będzie mało odpowiedzi, nawet nie wiedziałem, że EBP działa już na C3.

Pewnie zdajesz sobie sprawę, że mimo zbliżonej nazwy modelu
ESP32, ESP32-C3 i ESP32-S3 konstrukcyjnie nie mają ze sobą wiele wspólnego (można powiedzieć, że więcej je różni niż łączy…).

Z doświadczeń wyłącznie ze zwykłymi ESP32 - największy sens ma użycie konstrukcji z kablowym Ethernetem, gdzie moduł WiFi wcale nie jest używany (on ma wspólną antenę z BT) dopiero wtedy moduł BT jest w stanie pracować w idealnym środowisku radiowym.

na XIAO ESP32C3 mam wg takiej konfiguracji: ESPHome Bluetooth Proxy ESP32-C3 YAML | digiblurDIY i działa to całkiem dobrze.
Zastanawiałem się nam modułami z ethernetem, jednak nie wszędzie mam/dam radę skrętkę pociągnąć. Zawsze łatwiej gdzieś wpiąć starą ładowarkę i maleńki moduł.

Musisz poeksperymentować, tak wiem jakie są ograniczenia w realnym życiu, sam obecnie mam konstrukcję na bazie modułu z Ethernetem podpiętą przez WiFi (plany były ambitne, ale życie jest za krótkie na realizację), więc widziałem różnicę na gorsze przy zmianie konfiguracji z kabla na WiFi.

Nie wiem co bym zrobił na twoim miejscu, C3 są bajerancko tanie (ta wersja nie ma jednak anteny zewnętrznej tak jak XIAO C3), nie wiem czy znajdziesz S3 w podobnej cenie, link przykładowy ale to chyba jeden z tańszych sklepów

PS
Popatrz co jest na oficjalnej stronie projektu EBP :smiley:

Turn any ESP32 into a Bluetooth proxy for Home Assistant. This option only works for “plain” ESP32 and not for ESP32-C3 or other variants.

te z XIAO są tylko kilka złotych droższe i mają connector.
Bardziej zastanawia się nad różnicami pomiędzy C3 a S3 oraz anteną dołączoną do zestawu:
image

a dedykowaną anteną:
image

całość można wrzucić w taką obudowę:

Najprościej będzie zamówić po sztuce i zrobić testy, ew opcja z ethernetem.

Xiao muszą mieć antenę zewnętrzną, bo skutkiem miniaturyzacji jest brak miejsca na typową antenę PCB, ta z zestawu flex-PCB

jest jakąś próbą przybliżenia anteny izotropowej (podobnie jak standardowe anteny PCB), więc z pewnością zwykłą antena dookólna pod warunkiem pionowego montażu ma szansę być lepszym rozwiązaniem.
Nie zmieni to jednak w żadnym stopniu samego faktu, że 2 moduły RF pracują na tej samej antenie.

Bluetooth proxy dla Home Assistant. Działa tylko dla „zwykłego” ESP32, a nie dla ESP32-C3 lub innych wariantów.

Comparison table for ESP8266/ESP32/ESP32-S2/ESP32-S3/ESP32-C3/ESP32-C6 (github.com)

Już od dawna w ESPHome jest eksperymentalne wsparcie BT/BLE dla C3 i S3, oficjalnie w projekcie EBP nie ma wsparcia, ale to nie znaczy, że to nie działa.

Jakkolwiek na digiblur nie jest opublikowany gotowiec YAMLa dla S3, więc to jest pewne ryzyko, bo sprzętowo to konstrukcja drastycznie inna od C3.

Gdyby ktoś chciał sobie odpalić na ESP32-C3 to u mnie działa mniej więcej taka konfiguracja (wykroiłem z niej swoje rzeczy) konfiguracja jest pod płytkę Seeedstudio Xiao C3 dla innych należy zmienić definicję płytki na dedykowaną lub od biedy na board: esp32-c3-devkitm-1

substitutions:
  name: esp32-c3-xiao1
  friendly_name: ESP32-C3-xiao1

esphome:
  name: "esp32-c3-xiao1"
  friendly_name: ESP32-C3-xiao1
  platformio_options:
# bez DIO nie lata na frameworku IDF, w przypadku arduino nie jest konieczne
    board_build.flash_mode: dio

esp32:
  board: seeed_xiao_esp32c3
  framework:
    type: esp-idf
# opcje poniżej na bazie konfiguracji z digiblur-DIY 
    sdkconfig_options:
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"  
# edit: można wywalić całą tą powyższą sekcję na podstawie digiblur dla ESPHome >=  2023.11.6  tzn. może i zadziała na starszych wersjach

# Enable logging
logger:
#  level: DEBUG
# poniżej podniesiony poziom logowania, bo wolę w logach mieć podgląd czy działa skoro to wsparcie eksperymentalne
  level: VERBOSE

# Enable Home Assistant API
api:
  encryption:
    key: "klucz_szyfrowania_nieobowiazkowy"
ota:
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esphome-ESP32-C3-xiao1"
    password: "nieobowiazkowy_klucz_do_AP_ale_jakis_warto_miec"
captive_portal:

# web serwer zakomentowany z powodu ryzyka zużywania dużych zasobów, odważni mogą odkomentować
#web_server:
#  port: 80
#  auth:
#    username: !secret web_username
#    password: !secret web_password


esp32_ble_tracker:
  scan_parameters:
    active: true

bluetooth_proxy:
  active: true
 # active: false

button:
  - platform: safe_mode
    name: ${friendly_name} (Safe Mode)

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${friendly_name} IP Address"
    ssid:
      name: "${friendly_name} Connected SSID"
    bssid:
      name: "${friendly_name} Connected BSSID"
    mac_address:
      name: "${friendly_name} Mac Wifi Address"
    scan_results:
      name: "${friendly_name} Latest Scan Results"
      
binary_sensor:
  - platform: status
    name: "${friendly_name} Node Status"
    id: system_status

sensor:
  - platform: internal_temperature
    name: "${friendly_name} Internal Temperature"
    accuracy_decimals: 1

  - platform: wifi_signal
    name: "${friendly_name} sygnał WiFi"
    update_interval: 60s
      
  - platform: uptime
    name: "${friendly_name} Uptime"
    filters:
      - lambda: return x / 3600;
    unit_of_measurement: "h"
1 polubienie

Nie chcę zaczynać nowego tematu, a ostatni wpis kolegi @szopen bardzo pasuje do mojej sytuacji, więc zapytam tu.
Czy udało się komuś uruchomić na frameworku arduino taki moduł ?

Po wyborze

muszę ustawić frameworka na esp-idf
wywalić logowanie, żeby moduł się uruchomił i przeszedł do online.
Płytka jest sprawna na 100% , bo po wgraniu tasmoty śmiga, aż miło. Jak podałem za mało informacji, to proszę krzyczeć.
Dla uściślenia, chodzi mi tylko o pierwsze uruchomienie, taki podstawowy yaml, gdy zmienię frameworka, lub dodam logi moduł nie wstaje, więc przypuszczam , że wpada w pętlę rozruchową.

Dzięki za podesłanie configu, ja mam nieco inaczej, tzn:

esphome:
  name: esphome-web-25bf30
  friendly_name: BTProxy
  platformio_options:
    board_build.mcu: esp32c3
    board_build.variant: esp32c3  

esp32:
  board: esp32-c3-devkitm-1
  framework:
    type: esp-idf
    sdkconfig_options:
      CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
      CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"

nie wiedziałem, że jest board pod xiao esp32c3.
Nie musiałem dawać u siebie dio, nie wiem czym to jest spowodowane.
Czekam na płytki i popróbuję z wariantami.

Może z YAMLa wywal funkcje charakterystyczne dla IDF? (te linijki zapożyczone z digiblur), może trochę niejasne są te wstawione komentarze, ale na frameworku arduino bluetooth nie działa (i nie pamiętam czy czasem nie jest tak, że się kompiluje, ale firmware kończy na bootloopie).

Nie wiem, u mnie Xiao-C3 działało na frameworku arduino (bez bluetooth!) od momentu kiedy się go dorobiłem (raczej niedawno kilka miesięcy temu - odkupiłem 2 sztuki od kogoś z ogłoszenia na forum, podejrzewam maj/czerwiec?) i chyba już wtedy była gotowa ta definicja płytki.

Jeśli masz coś czego nie zna ani platformio ani ESPHome, to powinieneś użyć definicji esp32-c3-devkitm-1 (ale jeśli płytka jest zbliżona konstrukcyjnie do czegoś co istnieje, to wybierz najbliższą konstrukcję)

Potem próbowałem dorzucić do konfigu obsługę bluetooth i zmieniłem frameworka na IDF co kończyło się bootloopem, więc odpuściłem i dalej miałem to odpalone na fw arduino.
Dopiero ten wątek uświadomił mi, że może warto zawalczyć, bo jest ktoś komu działa, no i okazało się, że esp-idf działa u mnie tylko pod warunkiem zdefiniowania DIO.
Jakby co to MCU rev 0.4 chociaż nie wiem skąd to wiem.
Flashowane na maszynie z ESPHome (port USB w Xiao to USB-JTAG, widać go u mnie jako ttyACMx, więc w przypadku flashowania z narzędzi Espressif’a trzeba mieć jakąś w miarę świeżą wersję).

Jeśli chcesz spróbować co twórcy przygotowali na dziś jako gotowiec, to spróbuj web-flashera
https://web.esphome.io/
i zrób Adopcję do dashboradu ESPHome

Jakkolwiek framework arduino musi działać, “puste”/“startowe” firmware dla ESP-web-tools jest kompilowane z takiego YAMLa

Edit: Na frameworku arduino działa mi też Płytka Aitexm Robot ESP32-C3 Dual USB taka jak jedna z opcji wyboru z oferty na Ali, którą linkowałem wyżej. Tam używam definicji esp32-c3-devkitm-1.
Ta płytka jest na bazie modułu ESP32-C3-MINI-1


Jest, wtedy nie trzeba ustawiać tego:

Kompilowałam wczoraj na aktualnej wersji ESPHome, więc to też jest u mnie zbędne (w ESP-IDF w wersji użytej w aktualnym ESPHome najwyraźniej te opcje są już włączone)

to też wywaliłem, ale działanie od wczoraj jeszcze nie oznacza pracy stabilnej

U mnie działa od kilkunastu dni, dokładnie na tym kodzie przytoczonym przez @szopen’a w tym poście:

Dodatkowo do tego web_server i bluetooth_proxy:.

1 polubienie

Ciekawe, u mnie ruszyło na takim kodzie

esphome:
  name: warsztat-garaz
  friendly_name: Warsztat garaż
  platformio_options:
    board_build.flash_mode: dio

esp32:
  board: esp32-c3-devkitm-1
  variant: esp32c3  
  framework:
    type: arduino

# Enable logging
logger:
  baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: "vnDvkvaaaaaaaaaaaaaaaaJHlT0pXUFU0="

ota:
  password: "63fa8f7a3d58bb18exxxxxxxxxcf"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Warsztat-Garaz"
    password: "BglAVpdaUm4n"
web_server:
  port: 80
  auth:
    username: !secret web_server_username
    password: !secret web_server_password
# Sync time with Home Assistant.
time:
  - platform: homeassistant
    id: homeassistant_time    

Nie twierdzę, że nie, próbę odpalenia BLE z użyciem frameworka arduino robiłem jakoś w maju, wtedy nie działało, esp-idf za to wtedy nie działał mi wcale (może kwestia dio), więc odpuściłem temat do zeszłego tygodnia, oczywiście próbując ponownie z esp-idf (nie bez powodu - z doświadczeń ze zwykłym ESP32 idf jest wydajniejszy, a w przypadku C3 mamy procek zaledwie jednordzeniowy)…

Taka jeszcze ciekawostka - bez uruchomionego BLE przeciętna temperatura MCU (framework arduino) była koło 35 stopni C, a po uruchomieniu proxy BLE (fw esp-idf) >= 50°C (sprzęt to Xiao C3).

Uruchomione BLE na ESP32-C3 (framework arduino) - przeciętna temperatura > 50°C.

Udało się komuś polączyć na ESP32-C3 jako proxy termometry LYWSD03MMC ustawione na BT5.0 Long Range?

Szczerze mówiąc nie próbowałem jak dotąd uruchomienia BT5LR… głównie ze strachu czy będę w stanie przywrócić działanie w BT4, gdyby to była porażka (jak znam życie wszystko się da, tylko czasem wymaga za dużo gimnastyki).

Na sofcie pvvx jak przedstawisz termometr na 5.0 LR to jak wyciągniesz baterię i włożysz to przełącza się z powrotem na 4.0 więc nie ma strachu.
Ja próbowałem i XIAO S3 nie widzi ich na 5.0. Smartfon Poco X3 Pro też ich nie widzi na 5.0 :frowning: