ciąg dalszy pochodzi z innego wątku
w dokumentacji w/w komponentu są nawet wskazówki jak zoptymalizować konfigurację YAML sprzętu EBP w ESPHome
A projekt owszem jest rozwojowy, ale czytaj dokumentację uważnie, bo generuje tysiące encji, więc trzeba wycinać od razu zapis w bazie danych (no mieszkam na 1 piętrze jakieś 10m od chodnika i 15m od ulicy)
No właśnie… chyba coś nie bardzo poszło. Skofigurowałem pierwszą płytkę ESP32, ale HA widzi ją tak:
esphome:
name: ble-proxy
friendly_name: BLE Proxy
esp32:
board: esp32dev
framework:
type: esp-idf
sdkconfig_options:
CONFIG_BT_BLE_42_FEATURES_SUPPORTED: y
CONFIG_BT_BLE_50_FEATURES_SUPPORTED: y
CONFIG_ESP_TASK_WDT_TIMEOUT_S: "10"
logger:
baud_rate: 0
api:
encryption:
key: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
ota:
- platform: esphome
password: !secret wifi_password
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ap:
ssid: "Ble-Proxy Fallback Hotspot"
password: !secret wifi_password
captive_portal:
esp32_ble_tracker:
scan_parameters:
continuous: False
active: True
interval: 320ms
window: 300ms
bluetooth_proxy:
active: true
sensor:
- platform: uptime
name: "Uptime Sensor"
update_interval: 60s
Jakakolwiek próba wyboru śledzonego urządzenia kończy się tak:
Najpierw 2 kluczowe informacje - jaką masz płytkę i co za urządzenia BLE oraz czy masz chociaż blade pojęcie o ESPHome (bo mam wrażenie że tego YAMLa to wkleiłeś na pałę nie pasującego do MCU)?
BO z tego co widać, to twoje proxy wcale nie działa (przypuszczam, że się zawiesza lub traci łączność WiFi)
Jeśli zacznie działać to przy wielu urządzeniach BLE zaspamujesz sobie bazę, wiec najpierw w HA sekcja dla rekordera coś w guście tej z dokumentacji
recorder:
exclude:
# to completely exclude all Bermuda data from logs,
# add this domain section. Not recommended,
# but might be good if you like *big* hammers.
# zakomentowane bo tak radykalne cięcia zwykle nie są konieczne
# domains:
# - bermuda
entity_globs:
# to filter specific sensors
- sensor.*_distance_to_aska*
- sensor.*_distance_to_back*
# ...etc
# or filter all the distance-to sensors
- sensor.*_distance_to_*
# The area sensors
- sensor.*_area
# The distance to closest area sensor
- sensor.*_distance
# to niżej to akurat moja propozycja na ilość gęstych danych w HA na granicy rozsądku
# standardowo tu jest 5 dni, ale dla analizy niektórych rzeczy było to dla mnie za mało, to nie powiązane z trakerem
# uwaga nawet z takim ograniczeniem baza może urosnąć do niezdrowych rozmiarów
purge_keep_days: 12
Kupiłem u Chińczyka kilka sztuk ESP32-WROOM-32U
no… trochę masz rację. Posłużyłem się gotowcem podebranym z podpowiedzianego przez Ciebie linku. Przedtem jednak zarejestrowałem pytkę w ESPHome. Dopiero potem dodałem do konfiguracji wpisy z tego linku i skompilowałem firmware.
… I tutaj znów możesz mieć rację, moje pojęcie o ESP jest bardzo bliskie blademu. Przy konfiguracjach urządzeń posługuję się wskazówkami i podpowiedziami innych.
Jestem tylko użytkownikiem, choć iks lat temu pisałem programy użytkowe - C, pascal, ada, lisp, clipper - takie tam starocie… 
Natomiast co do wyłączenia niektórych sensorów z zasięgu recordera, oczywiście jestem świadom takiej konieczności. Ale najpierw musiałbym znać nazwy tych, które mam wyłączyć. A na razie mam z tym problem bo… płytka chyba nie gada z otoczeniem…
Wyłącz hurtem choćby używając tego przykładowego YAMLa (on tylko usunie zapisywanie typowych generowanych sensorów przez tę integrację, a nie musisz znać ich historii, żadnych innych wpisów w bazie to nie zablokuje), wiem co mówię, bo uruchamiałem to na testowej instalacji i zostawiłem bez nadzoru na jedną dobę… i baza spuchła do nieprzyzwoitego rozmiaru (naprawdę cieszyłem się że nie uruchomiłem tego od razu na produkcyjnej).
Hmm to jakieś doświadczenie masz (raczej spooooooro większe od mojego), tylko pisanie programów dla embedded się nieco różni - musisz uwzględniać możliwości sprzętu, co jak rozumiem całkowicie olałeś (oczywiście można się przyczepić, że ESPHome, to żadne pisanie programów 
a raczej układanie klocków lego, ale obowiązek dopasowania rozwiązań do sprzętu pozostaje.
ESP32-WROOM-32U to jest "zwykłe stare dwurdzeniowe ESP32 na procku Xtensa), a tymczasem dołożyłeś tam ustawienia prawdopodobnie dla ESP32-S3 lub ESP32-C3, no coś jakby próba włożenia silnika z Ferrari do malucha 126p - mimo wysiłku wyrwało skrzynię biegów
Zacznij od początku (olej na razie optymalizowanie ustawień firmware) wywal z integracji, a z IDE (kompilera) kafelek z YAMLem, wgraj stamtąd soft proxy
a potem się pomyśli czy optymalizować
tak, tak… miałem laborkę z assemblerów na Z80 przez 2 semestry na II roku… Ale zarżnij mnie - nic nie pamiętam, poza wypychaniem zmiennych na stos…
Tymczasem biorę się za porządki w ESP…
Wywaliłem integrację Bermuda BLE, usunąłem konfigurację BLE Proxy z ESPHome.
Z Ready-Made Projects wybrałem opcję Bluetooth proxy i wskazałem urządzenie Generic ESP32, co utworzyło poniższą konfigurację:
substitutions:
name: esphome-web-655530
friendly_name: BLE Proxy
esphome:
name: ${name}
friendly_name: ${friendly_name}
min_version: 2024.6.0
name_add_mac_suffix: false
project:
name: esphome.web
version: dev
esp32:
board: esp32dev
framework:
type: esp-idf
# Enable logging
logger:
# Enable Home Assistant API
api:
# Allow Over-The-Air updates
ota:
- platform: esphome
# Allow provisioning Wi-Fi via serial
improv_serial:
wifi:
# Set up a wifi access point
ap: {}
# In combination with the `ap` this allows the user
# to provision wifi credentials to the device via WiFi AP.
captive_portal:
dashboard_import:
package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
import_full_config: true
# Sets up Bluetooth LE (Only on ESP32) to allow the user
# to provision wifi credentials to the device.
esp32_improv:
authorizer: none
# To have a "next url" for improv serial
web_server:
Następnie zainstalowałem na płytce skompilowany firmware:
Na razie logi z instalacji nie wróżą sukcesu…
logs_esphome-web-655530_run.zip (12,4 KB)
Spróbuj tak:
api:
encryption:
key: "9p2efbtoh/7izZ93LRVsgSXsL1JAoP07YQeoyATI7IE="
@Krzysztonek
NIE
wygląda na to, że nie posprzątałeś po poprzedniej nieudanej instalacji (błąd połączenia API) miało wylecieć wszystko = wpis z Integracji + kafelek z IDE (Compilera)
miałeś też zacząć od początku od GOTOWCA, a nie od zera
Cały proces powtórzyłem DOKŁADNIE wg powyższej instrukcji, słowo harcerza!
Wygenerowany tym razem konfig ESP jest znacznie krótszy od poprzedniego:
substitutions:
name: esp32-bluetooth-proxy-655530
friendly_name: Bluetooth Proxy 655530
packages:
esphome.bluetooth-proxy: github://esphome/bluetooth-proxies/esp32-generic/esp32-generic.yaml@main
esphome:
name: ${name}
name_add_mac_suffix: false
friendly_name: ${friendly_name}
api:
encryption:
key: QEay2PsBdv6HrvpQm0B7Mh2gROGAWTSf7WheflKfMvE=
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
Najważniejsze, że wreszcie ruszył skaner…:
Teraz muszę jakoś poidentyfikować wykryte urządzenia, bo ich adresy MAC niewiele mi mówią…
friendly_name…
W każdym razie wygląda na to, że jestem już na właściwej ścieżce 
I ten jest OK
w kolejnym kroku możesz się odciąć od repozytorium
substitutions:
name: esp32-bluetooth-proxy-655530
friendly_name: Bluetooth Proxy 655530
esphome:
name: ${name}
name_add_mac_suffix: false
friendly_name: ${friendly_name}
# powyżej nie ruszamy, bo mamy fajną nazwę unikalnie wygenerowaną z MAC-adresu
# oczywiście wszystko może podlegać edycji, więc jak sobie zapanujesz to możesz ustawić swoje nazwy
# sugeruję do tego używanie opcji dostępnych w kafelkach w IDE
# tu była sekcja projektu wiążąca YAMLa ze zdalnym repozytorium
# zamiast tego jest sekcja esp32: oraz to co sporo niżej
esp32:
board: esp32dev
framework:
type: esp-idf
api:
encryption:
key: QEay2PsBdv6HrvpQm0B7Mh2gROGAWTSf7WheflKfMvE=
# zauważ że powyższy klucz-token zostawiłem nienaruszony,
# jeśli będziesz dokładał kolejne proxy, bo jedno nie ma wielkiego sensu
# to za każdym razem sobie zachowaj takie jak było wygenerowane
# albo zapanuj nad nimi samodzielnie
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# od tej linijki do końca jest już ręcznie definiowana konfiguracja zamiast zdalnej
# de facto utrzymałem treść zgodną z aktualną wersją projektu
# czyli o identycznej funkcjonalności z tym króciutkim
# możesz dodać własne ustawienia, to jest tylko minimum
# linia poniżej należy jeszcze do sekcji wifi:
ap:
logger:
ota:
- platform: esphome
id: ota_esphome
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
button:
- platform: safe_mode
id: button_safe_mode
name: Safe Mode Boot
Po skompilowaniu wsad będzie zgodny z tym który masz w tej chwili, ale będziesz mógł stuningować radio
Wreszcie mam dokładnie to, o czym marzyłem: piękny config w ESPHome i śmigający skaner BT. Dziękuję Ci za nieocenioną pomoc, @szopen 
Mam jednak nieodparte wrażenie, że jeszcze w kilku kluczowych sprawach moje pojęcie ma nadal bladozielony kolor:
configured_devices, które wykryte urządzenia BT są moje, a które obce? Chcę trackować tylko kilka z nich, ale nie wiem jak się do tego zabrać, żeby nie podpiąć się np. pod jakieś urządzenie przechodnia z ulicy. Czy można ponadawać im jakieś friendly names? Jak to ogarniąc?ad 1. to masz opisane tam
https://github.com/agittins/bermuda/wiki/ESPHome-Configurations#ble-tracker-settings
ad 2.
nie da się uniknąć wykrywania obcego sprzętu
https://github.com/agittins/bermuda/wiki/How-to-get-the-IRK-(Identity-Resolving-Keys)-for-iOS,-Android-etc
ad 3 trackowanie działa z dokładnością rzędu kilkunastu -kilkudziesięciu centymetrów (zależy jak się uda skalibrować), to jest WIP, mapy nie działają i nie wiadomo czy i kiedy powstaną (są w trakcie rozwoju), więc strefa jest rozpoznawana na zasadzie bliżej/dalej a zatem optymalnie aby każdy odbiornik był w centrum swojego pomieszczenia, póki projekt jest aktywny rozwija się, ale ile czasu może zająć rozwój nie wiadomo - popatrz na samo HA od przystawki dla Philips Hue do systemu integrującego tysiące innych systemów IoT rozwój zajął wiele lat.
ad 4. nie przesadzasz, ale patrz ad 3. uruchomiłem to tylko w małym jednopoziomowym mieszkaniu więc nie mam praktyki jak to wygląda przy kilku kondygnacjach
ad 5. przeczytaj dokumentację aż wychwycisz wszystkie interesujące kruczki, zajrzyj w issues (również w zamknięte), u siebie uruchomiłem to jako ciekawostkę (bo sprzęt i tak miałem - dość intensywnie używam czujniki BLE), ale życie jest za krótkie by się totalnie głęboko wkręcać we wszystko co jest możliwe do uruchomienia
musisz mieć ultrastabilnie działające WIFI
od wczoraj myślę jak przebudować ten OFF TOPIC (który sam nieopatrznie rozpocząłem) w osobny sensowny wątek
To jest logicznie oczywiste.
Jeszcze podpytam: Jak odróżnić swój <=> obcy i czy jest możliwość nadawania własnych nazw swoim urządzeniom? Jak rozpoznać co to za urządzenie jeśli widoczny jest tylko jego MAC?
Z 2D (jedna płaszczyzna) rzeczywiście nie ma problemu.
Właśnie wpadł mi do głowy pomysł na logikę skanowania w 3D, ale jeszcze nie wiem jak i czym można byłoby to oprogramować… Pomysł byłby taki, żeby izolować miedzy sobą grupy skanerów umieszczonych na tym samym piętrze (czy da się grupować skanery?) i poprzez porówywanie odległości pionowych określać poziom położenia urządzenia.
Cała przestrzeń byłaby rozumiana jako macierz 3D, składajaca się z warst (izolowanych pięter) jak kostka Rubika…
…ale muszę to jeszcze przemyśleć, bo może coś bredzę…
Linkowałem wyżej - największy problem to zmienne MAC-adresy, więc trzeba użyć metodę IRK, nie zawsze się uda…
Ponadto zapewne sam musisz uruchomić beacony, nie na każdym urządzeniu jest to możliwe.
Jako beacony kontrolne świetne są termohigrometry LYWSD03MMC (używam je na firmware BTHome).
Pomysły fajne, pewne rzeczy wymagają diametralnych zmian w HA, więc póki co obserwuj rozwój projektu…
Identity Resolving Key (IRK) is a 128-bit key used to generate and resolve random addresses. Connection Signature Resolving Key (CSRK) is a 128-bit key used to sign data and verify signatures on the receiving device.
Drugą opcją mogłoby być np. zdefiniowanie wszystkich skanerów jako logicznie jedna grupa (np. group.skanery_ble (nie wiem czy można je grupować) i potraktowanie grupy jako JEDNO urządzenie skanujące wspólną przestrzeń. Wtedy każdy ze skanerów widziałby wybrane urządzenie ze swojej lokalizacji w innej odległości, co - przy znanych, stałych dystansach między pojedynczymi skanerami tworzącymi całą grupę - natychmiast aż się prosi właśnie o triangulację.
Fajnie, ale to raczej materiały na dyskusję z autorami, ja do nich nie należę.
Swoją drogą plany rozwoju są takie by wykorzystywać prawdziwą triangulację (i tu grupy raczej nie pomogą bo są zaprzeczeniem idei triangulacji, tylko stopień skomplikowania rośnie wykładniczo przy zwiększaniu ilości skanerów).
W wersji rozwojowej osiągnięto już taki stopień wizualizacji
Znalazłem integrację dla metody IRK, ale warunkiem jej implementacji jest znajomość klucza IRK.
Na razie nie wiem skąd i jak go odczytać… Na liście wykrytych urządzeń brak jest takich danych.
No cóż to jest właśnie idea IRK, by się nie dało go zgadnąć ;D
wróć do czytania dokumentacji, tyle razy aż znajdziesz wszystko co musisz wiedzieć
tu przykład takich istotnych informacji
Tak właśnie teraz zrobię. Widać sporo jeszcze przede mną do ogarnięcia.
Tymczasem jeszcze raz dziękuję za dotychczasowe cenne wsparcie. Spróbuję dalej większej samodzielności ale wróciłbym ew. z pytaniami, na które nie znajdę odpowiedzi.
No cóż nie jestem ekspertem, więc chyba za bardzo już nie pomogę, dla Androida konieczna jest aplikacja np. HA-companion (i zdefiniowanie w niej własnych UUID), a dla wypustów Apple metody opisane są świetnie w podobnym projekcie
