ESPHOME problem z połączeniem TERMOMETR-ów XIAOMI

Straciłem połączenie z termometrami XIOAMI.
Pewnie po aktualizacji HA bo nic innego nie zmieniałem
Mam takie wpisy w logach:

2025-02-17 22:23:10.250 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration smartthinq_sensors which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

2025-02-17 22:23:10.255 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration hacs which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

2025-02-17 22:23:10.257 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration ble_monitor which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant

2025-02-17 22:23:12.821 ERROR (MainThread) [homeassistant.helpers.config_validation] The api integration does not support any configuration parameters, got [{'port': 6053}]. Please remove the configuration parameters from your configuration.

2025-02-17 22:23:23.053 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for esp32-bluetooth-proxy-68f948 @ 192.168.100.235: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192.168.100.235', port=6053))]: [Errno 113] Connect call failed ('192.168.100.235', 6053) (SocketAPIError)


Jak wyłącze API z konfiguracji to nie rozwiązuje to problemu

Tak przedstawionego problemu nie da się rozwiązać, brak jakichkolwiek użytecznych informacji dla diagnostyki czegokolwiek. W szczególności YAMLa z ESPHome.

Log pokazuje, że wywaliłeś API, więc nie jest prawdą, że nic nie zmieniałeś…

Wyjaśnij tok rozumowania - w jakim celu to zrobiłeś i co by to miało dać.
Jeśli odcinasz urządzeniu ESP możliwość porozumienia się z HA (i nawzajem) to jakim cudem cokolwiek by miało nadal działać?

O jaką Integrację w ESPHome w ogóle chodzi?

dobra, tu fartem zostawiłeś domyślną nazwę hosta ESP

esp32-bluetooth-proxy-68f948

Przez moment myślałem, że łączysz się po MQTT skoro pozwoliłeś sobie wywalić API, ale EBP musi mieć połączenie bezpośrednie.

Jaka integracja w HA, jakie firmware w tych Xiaomi (chodzi o BLE jak rozumiem, ale może jakieś modele albo co?)

To może chociaż informacja jaką wersję miałeś przed aktualizacją i jaką masz po?

Nie umiesz cofnąć wersji HA core? Skoro podejrzewasz, że to jest powodem jeśli chcesz się cofnąć do ostatniej styczniowej
ha core update --version 2025.1.4

Naprawdę po użytkowniku z dłuższym doświadczeniem na forum nie spodziewałem się wątku gdzie wypada przekierować tam
“Coś mi stuka w kole…”

Właściwie jako podsumowanie -
U mnie działa, a mam w tym momencie HA core 2025.2.4 i termohigrometry (Mija/Xiaomi) na firmware BTHome.

Ghost in the Shell… (damn, the Polish translation is really not what it meant to be “Mobilna uzbrojona jednostka porządkowa”)

Have you tried to reboot the whole HA machine?

Termometry LYWSD03MMC połączone przez BLE MONITOR od dawna nagle jednego dnia przestały się komunikować. Nie grzebie w plikach konfiguracyjnych jeśli nie mam takiej potrzeby więc obstawiam, że aktualizacja. Ale czy HA czy innej aplikacji używanej tego nie wiem. Jak to sprawdzić co się zadziało tego dnia ? jest to gdzieś w logach ?
WERSJA HA 2025.2.4

Są 3 punkty w których mogły być zmiany związane z aktualizacją czegoś.

  1. HA - tu załatwiasz to najprościej jak się da - cofasz wersję HA core poleceniem, takim jak wyżej (tylko ewentualnie dostosowanym by wrócić do takiej wersji, kiedy ostatnio U CIEBIE działało dobrze, założyłem że aktualizujesz HA chociaż raz na miesiąc i jakaś lutowa aktualizacja HA core zaszkodziła, bo napisałeś wątek teraz, a nie np. miesiąc temu). Nie używam integracji Xiaomi BLE w powiązaniu z tymi czujnikami nie jestem w stanie sprawdzić mam za to inne “xiaomi” (czytaj: xiaomi tego nie produkuje jest tylko marką handlową, realni producenci są różni), zintegrowane przez Xiaomi BLE i to takie dla których nie istnieje alternatywne firmware i one mi działąją bez zmian, czyli dobrze.
    Czytujesz notatki do wydania systematycznie? (tj. najlepiej przed każdym kliknięciem w aktualizuj, by wiedzieć czy nie grzebano w jakimś komponencie, który akurat używasz)
    2025.2: Iterating on backups - Home Assistant

  2. ESPHome i lub dedykowana integracja proxy BLE (projekt EBP) u mnie działa dobrze. Jeśli nie aktualizowałeś to się nie zmieniło, usunięcie API z konfiguracji podsumowując w 3 słowach było głupie (jeśli nie przechowujesz danego bina, którego używałeś wcześniej, to już raczej nie wrócisz do identycznego firmware jak miałeś wcześniej) pozostaje naprawić YAMLa, skompilować ponownie i przeflaszować ESP

  3. Same czujniki - jeśli używasz je z fabryczną aplikacją to, mogłeś zmienić im fabryczne firmware… (tu nie umiem przewidzieć co się stać mogło), a jeśli usunąłeś je w apce i dodałeś ponownie, to się zmieniły im tokeny.
    Zawsze możesz je odzyskać z chmury
    GitHub - PiotrMachowski/Xiaomi-cloud-tokens-extractor: This tool/script retrieves tokens for all devices connected to Xiaomi cloud and encryption keys for BLE devices.

Jakkolwiek ja sugeruję olać fabryczne firmware i używać znacznie lepsze z tego projektu

tylko jeśli zaktualizowałeś sobie firmware fabryczne do aktualnego (lub fabrycznie miałeś zbyt nowe na zmianę softu) to musisz użyć specjalnej innej ścieżki zmiany firmware

(albo cofanie wersji po kabelku)


A w ogóle to prawdopodobne rozwiązanie masz powyżej - zrestartować system.

Tylko hmm przytoczone issue jest sprzed 1.5 roku, więc bardzo interesujący jest cykl twoich aktualizacji - opisz co jak często aktualizujesz, może to cokolwiek nam wyjaśni.

Problem był z połączeniem WIFI które było skonfigurowane w pliku YAML ESP HOME. Temat zamykamy

Jakim cudem możesz nas oświecić?
Z zasady nie zamykamy tematów, bo z poziomu użytkownika nie da się ich otworzyć.

2 polubienia

mam tak w konfuguracji zrobione:

# Your Wi-Fi SSID and password
# wifi_ssid: "HOME_EXT"
# wifi_password: "156990....."
wifi:
  networks:
  - ssid: !secret HOME_EXT
    password: !secret 156990......
    priority: 0.0
  - ssid: !secret HOME
    password: !secret 156990......
    priority: 5.0
  power_save_mode: none
  output_power: 17
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${friendly_name} brak sieci!"
    password: !secret wifi_rcvr

w momencie jak wyłaczyłem sieć HOME pojawiły się problemy.
Nie wiem czemu nie połaczył się z HOME_EXT

To normalne - przełączenie na inną sieć wymaga rebootu, skoro nie wrzucasz całego YAMLa tylko jakieś wyrywki nie da się ocenić czy i ewentualnie czemu ESP się nie zrebootowało.

W ogóle to nawet ten wyrywek YAMLa wygląda co najmniej dziwacznie.
Zgaduję że kropeczkami zakryłeś coś co już na dzień dobry nie eksponuje niczego, bo jest odnośnikiem do haseł ukrytych w secrets.yaml (no chyba, że to masz też spartolone).
Po to właśnie stosuje się sekrety, by móc “publikować żywcem” YAMLa nie ujawniając niczego, więc chyba masz sporo do poprawy…

Nie zrozumiałem co chcesz przekazać, ale nadal mam wrażenie, że nie wiesz o co to jest !secret ani jak to używać.

Opisałbym to, ale wydaje mi się, że to będzie tylko “krew w piach”, więc całkowicie straciłem motywację…


A co to za przeroszeniem ma wspólnego z tematem tego wątku?

Od dawna z tym walczymy → jeden problem = jeden wątek.

Aby uniknąć dyskusji totalnie nie na temat wyjątkowo zamykam ten wątek…
Jeśli będziesz zdecydowany czegoś się nauczyć odnośnie tematów związanych z EBP/ESPHome z tego wątku to daj znać na PW, to go znów otworzę,
ale INNY problem ma się znaleźć w INNYM wątku.

OK wracam do tematu, skoro obiecałem.

Ograniczę się tylko do takiego wyrywka, ale sekrety można stosować w wielu innych miejscach, gdzie są jakiekolwiek tokeny czy hasła które niekoniecznie chcemy gdziekolwiek udostępniać publicznie

# Your Wi-Fi SSID and password
# wifi_ssid: "HOME_EXT"
# wifi_password: "156990....."
wifi:
  networks:
  - ssid: !secret HOME_EXT
    password: !secret 156990......

Co mi w konfiguracji wyżej nie pasuje? - no wygląda jakby ktoś obcy Ci to zrobił, ale nie wykorzystałeś tego jak należy (bo w komentarzach są jakieś wartości które później pojawiają się jako nazwa sekretu… no to dość dziwne).

Załóżmy, że prawdziwe wyglądają tak: SSID tej sieci WiFi to HOME_EXT a hasło do niej to 156990supertajnehasloktoregoniechceujawniac

Więc sekcję WiFi można skonfigurować na parę różnych sposobów

Przy publikacji ujawniamy wszelkie dane (oczywiście publikując można zamalować, czy “zaiksować”, ale po takim ukryciu źle się z tego korzysta, źle wygląda, kod nie jest przenośny dla innych użytkowników itd.)

wifi:
  networks:
  - ssid: HOME_EXT
    password: 156990supertajnehasloktoregoniechceujawniac

Jak wyżej tylko cudzysłowy (lub apostrofy zwyczajne) dają pewność, że ciąg jest typu string
te akurat są, ale załóżmy, że ktoś sobie wymyśli hasło 0xdeadbeef a to po prostu liczba szesnastkowa… wtedy może zostać nieprawidłowo zinterpretowana (nie jak string tylko jako hex i nici z logowania do sieci… najnowsze wersje ESPHome wprawdzie zwykle radzą sobie nawet w takich wypadkach (w zamian za to kod jest interpretera YAML bardziej skomplikowany…) ale jednak lepiej dmuchać na zimne, niech string pozostanie na zawsze stringiem

wifi:
  networks:
  - ssid: "HOME_EXT"
    password: "156990supertajnehasloktoregoniechceujawniac"
  1. A teraz zróbmy to tak by nie trzeba było niczego zamalowywać, zakropkowywać itd. = wymyślamy samodzielnie jakieś nazwy sekretów, które potencjalnemu czytelnikowi powiedzą co tam jest ukryte (a mimo tego nie ujawniają żadnych potencjalnie wrażliwych danych)

Najpierw to co jest wtedy w pliku secrets.yaml (tym należącym do ESPHome, bo takich plików w HA bywa więcej!) jak sama nazwa wskazuje tej zawartości nie ujawniamy.

moje_ukryte_ssid: "HOME_EXT"
moje_ukryte_haslo_wifi: "156990supertajnehasloktoregoniechceujawniac"

i nasz YAML urządzenia używający tych sekretów - można go publikować śmiało w całym internecie

wifi:
  networks:
  - ssid: !secret moje_ukryte_ssid
    password: !secret moje_ukryte_haslo_wifi
  1. zasadniczo zawsze i wszędzie można używać rozwiązania z punktu 3. ALE…
    ESPHome compiler (builder/IDE, czy jakkolwiek sobie go nie nazwiemy) wyposażono w kreator nowych urządzeń… i on korzysta z pewnych predefiniowanych nazw sekretów (więc nie warto z tym walczyć lepiej je po prostu wykorzystać) akurat właściwie predefiniowane są tylko 2 nazwy dotyczące ssid i klucza zazwyczaj jedynej sieci WiFi (w konfiguracji wszystkich urządzeń jednego zwykłego użytkownika)

typowa zawartość secrets.yaml po jednorazowym użyciu kreatora urządzenia (o ile wtedy wprowadzimy te hasła co poprzednio)

# Your Wi-Fi SSID and password
wifi_ssid: "HOME_EXT"
wifi_password: "156990supertajnehasloktoregoniechceujawniac"

wtedy oczywiście YAML urządzenia ma wyglądać tak

wifi:
  networks:
  - ssid: !secret wifi_ssid
    password: !secret wifi_password
  1. a teraz już idziemy po całości do secrets.yaml można sobie dopisać wszystko co się może przydać w każdym tyowym urządzeniu
# aby nie walczyć niepotrezbnie z kreatorem te 2 linijki niech sobie zostaną
wifi_ssid: "HOME_EXT"
wifi_password: "156990supertajnehasloktoregoniechceujawniac"

# można zduplikować te same tajne sekrety od innymi nazwami, to nie rzeszkadza
moje_ukryte_ssid: "HOME_EXT"
moje_ukryte_haslo_wifi: "156990supertajnehasloktoregoniechceujawniac"

# można dodać wiele więcej
wifi_ssid_secondary: "HOME_INT"
wifi_password_secondary: "supertajnehaslo156990ktoregoniechceujawniac"
# i zdublować pod krótszym aliasem
wifi_ssid_2: "HOME_INT"
wifi_password_2: "supertajnehaslo156990ktoregoniechceujawniac"

wifi_ssid_tertiarary: "HOME_MID"
wifi_password_tertiarary: "supertajnehaslo156990ktorego156990nie156990chceujawniac"
wifi_ssid_3: "HOME_MID"
wifi_password_3: "supertajnehaslo156990ktorego156990nie156990chceujawniac"

# chyba łątwo zgadnąć do czego będą służyły sekrety o takich nazwach
wifi_rcvr: "zgadnijmnie"
api_key: "KDA+68+xhvgirM17wuoL8KtIU7zR44GEnXzmdahiB3I="
ota_pass: "3ffe73763da8903e2b4fed36cd062cc7"
# dla przykładu apostrofy zwyczajne niżej
web_username: 'esphome'
web_password: 'esphome'

i na koniec taka

UWAGA

nigdy nie należy kopiować cudzych haseł gdzieś wygrzebanych w sieci razem z cudzą konfiguracją, którą zastosujemy u siebie, jeśli nie mamy pomysłu istnieją nawet generatory haseł czy tokenów, oczywiście czasem konfiguracja wymaga haseł gdzie nie są realnie potrzebne silne hasła, ale to już zupełnie inna kwestia jak sobie zapewniacie bezpieczeństwo…

po wyłączeniu sieci HOME widać w logach, że nie łaczy się z HOME_EXT

2025-02-22 23:17:39.306 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for esp32-bluetooth-proxy-68f948 @ 192.168.100.235: Error connecting to [AddrInfo(family=<AddressFamily.AF_INET: 2>, type=<SocketKind.SOCK_STREAM: 1>, proto=6, sockaddr=IPv4Sockaddr(address='192.168.100.235', port=6053))]: [Errno 113] Connect call failed ('192.168.100.235', 6053) (SocketAPIError)

jak to skonfigurować aby działało ?

Nie wiem, u mnie działa… podejrzewam, że masz źle skonfigurowaną sieć LAN.

Kluczowa jest kwestia by oba AP były w tym samym fizycznym segmencie sieci co HA.
A jeśli nie są, to musi być routing multicastu (musi działać mDNS).

Jeśli nie działa mDNS to nie ma innego wyjścia niż statyczna konfiguracja IP (oczywiście kompletna a nie samo IP).

1 polubienie

jak odpiąłem i wywaliłem z konfiguracji sieć HOME to za cholery nie chce się połączyć nawet po restarcie

Przepraszam, ale nie mam siły na dalszą walkę.


Moim zdaniem wynika z tego, że ta twoja druga sieć HOME_EXT nie jest w tym samym segmencie fizycznym sieci co HA (w przeciwieństwie do sieci pierwszej - HOME), może jest za firewallem, może nie ma routingu multicast, może router Mikrotik? albo milion innych przyczyn (ale zakładam, że jeśli konfigurujesz sobie sieć w jakiś bardziej zaawansowany sposób, to chyba robisz to świadomie).

W ogóle zastanawia mnie twój tok rozumowania - z drugą siecią nigdy nie uzyskałeś działającego połączenia, ale mimo to wywalasz pierwszą z konfiguracji (zamiast zamienić im priorytety, wtedy miałbyś jakiś działający backup połączenia).
Teraz to już tylko flaszowanie po kabelku.

Dawkujesz nam szczątkowe informacje i mimo najszczerszych chęci nic się z tego nie ulepi.

Może zwrócę uwagę na to, że ani razu nie wkleiłeś kompletnego YAMLa swojego sprzętu na ESPHome (więc nie wiem skąd wiem, że używasz ESPHome Bluetooth Proxy, bo tego chyba też nigdzie jasno nie napisałeś, a może to było w innym wątku, skasowanych postach, czy kij wie gdzie? - znalazłem - domniemanie było z nazwy hosta… ale jakoś nie zwykłeś potwierdzać ani zaprzeczać rzeczy których się tylko domyślam, bo nie podajesz wystarczająco kompletnych informacji, a zamiast tego produkujesz zagadki w rodzaju “znajdź 20 szczegółów którymi się różnią te 2 obrazki”…).


Powrót do tematu z tytułu.

Przy okazji twojego wątku (tego tutaj właśnie), przeszukałem szuflady i znalazłem jedną sztukę LYWSD03MMC na fabrycznym firmware…
Dzięki czemu postanowiłem zrobić eksperyment ile wytrzyma ogniwo zasilające na fabrycznym sofcie Xiaomi w porównaniu do BTHome od @pvvx

I wiesz co… no kurczę paka, kurza twarz… u mnie działa…
(sensor dodany do chmury Xiaomi z aplikacji, token wyciągnięty narzędziem które chyba linkowałem wyżej) oczywiście dodanie do chmury tylko w celu uzyskania tokenu szyfrowania, bo połączenie z HA za pomocą BLE


i dla porównania sensor odniesienia na alternatywnym sofcie…


Ostatni rzut na taśmę…

Co to jest BLE MONITOR? bo nic mi się tu nie układa w sensowną całość.
Może czas na jakiś link albo co?

Ile lat nie aktualizowałeś HA?

1 polubienie

tak na szybko to wygląda to tak u mnie w tej chwili.