Najlepszy serwer proxy Bluetooth - Bramka Blutooth LE GL.iNet GL-S10

Bramka ESPHome Bluetooth Proxies (w skrócie EBP) niezależnie od sprzętu na jakim jest zainstalowana nie dekoduje, ani nie obrabia w żaden sposób pakietów Bluetooth, ona je po prostu odsyła “jakie są” (czyli jako dane surowe - RAW) do obróbki przez HA, a tym samym z punktu widzenia użytkownika zachowuje się jak zwykły dongle BT (z obsługą BLE), tyle, że podpięty do HA po sieci, a nie po USB.

W dużym uproszczeniu wygląda to tak:

Czujnik BLE ~/~/~(protokół BLE)~/~/~> bramka BLE =+=(dane RAW)=+=> HA (tu następuje “odkopanie” protokołu BLE z danych RAW dekodowanie i dalsza obróbka)

~/~/~ to warstwa transportowa, którą jest eter (połączenie BT BLE “przez powietrze”, aby było ściślej to nie musi być w pełnym sensie aktywne połączenie - może być to przechwycony metodą nasłuchu pakiet rozgłaszany w trybie beaconu, czyli nasłuch pasywny)
=+= to warstwa transportowa Ethernet (obojętnie czy po kabelku czy przez WiFi, oczywiście lepiej gdy się to odbędzie po kabelku)

Więc podsumowując to wszystko - nie da się nic wymusić, bo to HA, a nie EBP obrabia dane.

Więc odpowiedni kod musi się znajdować w samym HA (czyli w sofcie bramki AIS), jak sprawdziłem w HA obsługę EBP wprowadzono w core 2022.9.0 (ale możliwe, że były też jakieś późniejsze zmiany, bo tryb aktywny w EBP jeśli dobrze pamiętam pojawił się z pewnym opóźnieniem względem wrześniowej premiery, jak ktoś ma czas na kopanie w commitach, to w sumie jest wszystko do sprawdzenia, ale na to jestem za leniwy…)


Ze względu na specyfikę komunikacji w EBP bramka BLE może być zintegrowana tylko z jedną instalacją HA.
(jakkolwiek należy przyjąć, że to ograniczenie dotyczy ogólnie każdego urządzenia ESPHome - może być ono podłączone wyłącznie do jednego HA po API albo do jednego brokera MQTT)
Więc jeśli masz ją zintegrowaną w innym HA to musisz ją wywalić z Integracji oraz Ignorować po ewentualnym kolejnym wykryciu (lub wyłączyć Integrację, jakkolwiek u siebie mając więcej niż 1 HA po prostu ignoruję).

Odnośnie współpracy EBP z bramkami AIS to chyba najlepiej by się ktoś z AIS wypowiedział @administratorzy @moderatorzy.


PS Na PW się umawialiśmy, że wrzucisz (odpowiednio sformatowany - przypominam o linijkach z odwrotnymi apostrofami!, edit: widzę po logu, że jesteś jednym z niewielu dbających o formatowanie :+1:) YAML z IDE (dashboardu) ESPHome, który uzyskałeś w momencie Adopcji do dashboardu ESPHome, bo bez jego zawartości trudno dalej ujechać.
My nie mamy w ręce twojego sprzętu, więc jeśli nie dostarczasz danych to ich nie mamy.
Jaki YAML jest TERAZ na repo to wiadomo - wystarczy tam zajrzeć, ale jaki nagłówek masz wkompilowany w obecny firmware na urządzeniu to nikt nie ma pojęcia.
(a od niego zależy czy uwalisz sobie sprzęt aktualizacją, czy nie)


Blakkader w sumie się też nie przyłożył, bo stamtąd
https://blakadder.github.io/bluetooth-proxies/
linkuje do głównej gałęzi projektu EBP na githubie (a tam mamy wersję dla HW 2.x bazującej na IP101) zamiast do swojego forka (gdzie kluczowy YAML dla HW 1.x jest INNY)…
ale na jego repo jest obecnie “jedyny słuszny” dla GL.iNet GL-S10 o wersji HW 1.x (wszystkich na LAN8720):

czyli


PS Obecna wersja softu EBP na konkretnie ten sprzęt ma obsługę odpowiednio oznaczonej kontrolki LED i to jest wskaźnik że coś bramka odbiera (nie mam jednak możliwości zabrania bramki na “bluetoothową pustynię” by zweryfikować, że istotnie ten LED będzie ciemny jak noc przy braku BLE w okolicy).

Nie wiem czy tak było zawsze (a nie mam weny na kopanie po historii commitów), na początku istnienia tego projektu interesowałem się wersją dla “generic ESP32”, bo takie mam w szufladach (i tam EBP “fabrycznie” nie ma wsparcia dla kontrolki LED BT “prosto z pudełka”, bo typowe płytki deweloperskie takich nie posiadają)

2 polubienia