Wprawdzie mamy już Home Assistant 2025.5.2, oraz ESPHome 2025.5, to ja chciałbym się wrócić gdzie do początku kwietnia, gdy pojawił się Home Assistant 2025.4 i ESPHome 2025.4, bo też i wtedy pojawił się dość poważny problem, przynajmniej w przypadku frameworka Arduino, który pomimo upływu już prawie 2 miesięcy i pojawienia się w międzyczasie kilku aktualizacji, nadal nie został naprawiony, a bardziej wygląda to jakby strony – drużyna Home Assistant i drużyna ESPHome – wzajemnie tego gorącego kartofla między sobą przerzucały.

Odtwarzacz mediów ESPHome I2S w Home Assistant i problematyczny komunikat TTS

W swojej konfiguracji „inteligentnego domu” korzystam z różnych sprzętów i różnego oprogramowania, ale niewątpliwie pewnego rodzaju sercem, a właściwie mózgiem tego układu jest Home Assistant działające na GMKtec Nucbox G3, który jest wspierany przez sporo urządzeń bazujących m.in. na ESP8266 i ESP32, obecnie głównie pod kontrolą ESPHome. Jest to wybór nieprzypadkowy, bo poprzedzony testami, po których dopiero nastąpiła migracja z mojego autorskiego rozwiązania, na powyższy zestaw oprogramowania.

I przez długi czas wszystko działało poprawnie, nie licząc od czasu do mniejszych lub większych zmian w konfiguracji niektórych komponentów. Od czasu do czasu pojawiają się też bardziej „upierdliwe” zmiany, jak np. niedawno wprowadzone „olewanie” przez Home Assistant identyfikatorów ustawionych w ESPHome, a zamiast tego tworzenie nowych – na bazie nazwy, do której – przy okazji – automatycznie teraz dodawana jest nazwa urządzenia. Mógłbym napisać, że w końcu, ale chyba jednak wolałem dotychczasowy system, gdzie to ja o tym mogłem decydować.

Ale uznajmy, że to wszystko drobiazgi, które co najwyżej dokładają pracy, ale da się to ogarnąć. Kwestia czasu i przeprogramowania urządzeń, co na szczęście można zazwyczaj zrobić zdalnie za pomocą aktualizacji OTA (Over-the-Air).

Zawieszony odtwarzacz mediów I2S

I tak dochodzimy do sedna artykułu, czyli odtwarzacza mediów (media player) bazującego np. na starym głośniku Bluetooth, podpiętego np. za pomocą układu MAX98357A do ESP32, na którym działa ESPHome z komponentem I2S Media Player (Inter-IC Sound), dzięki czemu mamy coś w stylu „inteligentnego głośnika”, z którego możemy korzystać np. do odtwarzania na nim komunikatów głosowych (TTS) z Home Assistant. Do puszczania muzyki też, ale nie o tym, nie o tym… I do kwietnia 2025 uznajmy, że działało to całkiem dobrze, bez większych problemów.

Aż ekipy odpowiedzialne za rozwój ESPHome i Home Assistant zaczęły kombinować z tym, by odtwarzacz mediów był jeszcze lepszy, posiadał jeszcze więcej możliwości, a chyba przede wszystkim, by był lepiej dopasowany pod asystentów głosowych.

I tak kombinowali, że od kwietnia odtwarzacz mediów dostarczany przez ESPHome (I2S) w Home Assistant po odtworzeniu komunikatu głosowego (TTS) nie potrafi się zamknąć. I to dosłownie – odtwarzacz pozostaje w trybie odtwarzania, a komunikat jest powtarzany co jakieś 2 minuty… Bez przerwy…

Problem występuje tylko w przypadku frameworku Arduino, na ESP-IDF działa. Znaczy o ile ESP32 ucięgnie, ale o tym za chwilę. Problem nie dotyczy też np. odtwarzacza mediów dostarczanych przez kamery, z których korzystam. Tylko ESPHome i framework Arduino.

Automatyzacja na ratunek

Tak więc mamy zapętlony komunikat, a przynajmniej do momentu, aż czymś nie przerwiemy tej pętli. Może to być restart ESP32 z komponentem „media player”. Może to być odtworzenie np. pliku mp3, nawet pustego. Może to być w końcu polecenie zatrzymania odtwarzania.

I właśnie z tego ostatniego sposobu skorzystałem, by jakoś jednak dalej móc korzystać z odtwarzacza mediów w Home Assistant.

Utworzyłem automatyzację, której wyzwalaczem jest rozpoczęcie odtwarzania na konkretnym odtwarzaczu mediów (ESP32 z ESPHome i I2S), która ma zostać wyzwolona po zdefiniowanym czasie – 5, 10, 20, 30 sekund… To zależy od tego, jak długie komunikaty są zazwyczaj odtwarzane, tak by nie przerwać w trakcie.

Po wyzwoleniu automatyzacji (i spełnieniu warunków) do odtwarzacza mediów idzie polecenie zakończenia odtwarzania, co powoduje, że jego stan z „zawieszonego odtwarzania” zmienia się na bezczynny.

Taka automatyzacja w najprostszej wersji może wyglądać tak:

Jest to najprostsza wersja, która w wielu przypadkach będzie jednak wystarczająca. A w razie konieczności – tak jak ja mam to zrobione u siebie – można ją rozbudować o dodatkowe warunki i reguły, by lepiej dostosować do potrzeb.

Możesz też dodać odtworzenie np. mp3 po komunikacie TTS

Jeśli masz mało automatyzacji i skryptów, w których używasz komunikatów głosowych TTS, to być może lepszym rozwiązaniem będzie dodanie odtworzenia krótkiego kawałka muzycznego np. z pliku mp3. Może to być nawet „dźwięk ciszy”.

Ja mam takich automatyzacji i skryptów dość sporo, więc lepszym rozwiązaniem dla mnie jest automatyzacja bazująca na mechanizmie przedstawionym powyżej. Choć przyznam, że gdy ją tworzyłem, to myślałem, że to będzie tymczasowe rozwiązanie, dosłownie na kilka dni, aż nie pojawi się aktualizacja, która naprawi problem. Jak widać bardzo, ale to bardzo się myliłem i przez te prawie już dwa miesiące (!) stała się ona dość ważnym elementem mojego systemu „inteligentnego domu”.

Brak szerszej perspektywy podczas testów?

Niestety w tym przypadku model open source zdaje się, że zawiódł… Znaczy fajnie, że kolejne osoby dorzucają od siebie kolejne rozwiązania do koszyczka, jakim w tym przypadku jest Home Assistant i ESPHome, ale chyba jest to też doskonała ilustracja dla powiedzenia „gdzie niezależnych (od siebie) programistów wielu kucharek sześć, tam nie ma co jeść”.

Bo zakładam, że to nie było celowe działania, czyli narzucony z góry (Nabu Casa) przykaz, że musimy sprawić, by Home Assistant Voice Preview Edition lepiej się sprzedawał, to potrzeba jakichś bajerów, nawet jeśli przy okazji uwalimy odtwarzacze mediów bazujące na ESPHome i I2S. Zakładam też, że kod jest weryfikowany, nie tylko pod względem jego poprawności, ale czy w ogóle działa, i czy działa prawidłowo.

Tylko tu być może właśnie zbytnie rozproszenie, że każdy sobie kod (rzepkę) skrobie, więc każdy testował swój mały wycinek, a zabrakło szerszego spojrzenia. Zabrakło być może też refleksji, że np. określenie „efekt motyla” nie wzięło się znikąd, i czasem mała zmiana w jednym miejscu, może wywołać duże turbulencje w innym.

No dobra, ale co z tą naprawą?

Oczywiście to nie jest tak, że tylko ja zauważyłem problem, bo właściwie od razu na stronach powiązanych z projektem (np. GitHub) zaczęły się pojawiać zgłoszenia. Zgłoszenia, które szybko zaczęły się zmieniać we wspomnianego gorącego kartofla, którego najpierw przerzucały między sobą ekipy od Home Assistant i ESPHome, a ostatecznie nawet już wzajemnie wewnątrz ekip, między konkretnymi „opiekunami”, bo „przecież to nie ja”.

No cóż, w tym przypadku open source okazał się niekoniecznie zaletą, bo wraz z „rozproszonym kodem”, pojawiła się rozproszona odpowiedzialność.

To mogła być kosztowna wpadka

Są osoby, które do aktualizacji podchodzą jak pies do jeża – w myśl zasady, że jeśli działa, nawet z problemami, to lepiej nie ruszać, bo może być gorzej. Na szczęście zazwyczaj nie mają racji i można śmiało ich wrzucać do worka z „płaskoziemcami”. Natomiast jak widać na powyższym przykładzie – czasem i ślepej kurze trafi się ziarno… ;-)

Ja raczej należę do tych, co aktualizacje robią. Nie tylko dlatego, że mogą pojawić się dodatkowe opcje/funkcje, ale często (zazwyczaj?) oznacza to naprawę błędów. Nawet takich, o których istnieniu mogłem nie wiedzieć, co nie oznacza, że nie były istotne.

Na początku kwietnia szykował mi się kilkudniowy wyjazd… Przed nim, standardowo – kopie zapasowe, aktualizacje, testy… I to ostatnie być może uratowało mój portfel. Choć w przypadku odtwarzacza mediów nie było to trudne, bo on zasadniczo dość często „do mnie gada”.

Wyobraźmy sobie jednak sytuację, że komunikaty głosowe to rzadkość, do tego między aktualizacją a wyjazdem system „nie miał mi nic do powiedzenia”, ale stojąc już w drzwiach, odpaliłem skrypt, który odtwarza mi najważniejsze informacje, m.in. pogodowe.

Taki komunikat to dość sporo znaków, a że jest dynamiczny, to nie jest keszowany, a więc każdorazowo leci zapytanie do usługi Google Cloud, która odpowiada u mnie za zmianę tekstu w mowę (TTS). Jak zapewne łatwo się domyślić, gdyby takie – jak wspomniałem dość długie – zlecenie leciało co 2 minuty przez te kilka, kilkanaście dni, to jest bardzo prawdopodobne, że odczułby to również mój portfel. A konkretnie karta kredytowa…

No to może ESP-IDF?

Problem występuje tylko, gdy korzystamy z framweworka Arduino. W przypadku ESP-IDf wszystko działa poprawnie. Co ma nawet sens, bo w ostatnim czasie kod YAML definiujący komponent odtwarzacza mediów (media player) w ESPHome dla ESP-IDF znacznie się zmienił, rozbudował o nowe opcje, a ten z Arduino jest taki, jaki był.

Ale by to sprawdzić musiałem zamówić nowy układ ESP32, a konkretnie ESP32-S3 N16R8, czyli układ z większą pamięcią. Nie tylko flash, ale i PSRAM, która zdaje się w tym przypadku mieć decydujące znaczenie, bo na większości ESP32, które mam, nowa wersja ESP-IDF sypie błędami pamięci RAM przy próbie odtwarzania.

Tak więc – jeśli posiadasz „słabsze” ESP32 to obecnie albo zmieniasz na „mocniejszą” wersję i przechodzisz na ESP-IDF, albo męczysz się z wadliwie działającym odtwarzaczem mediów na Arduino.

Być może alternatywnie można skorzystać ze starszej wersji ESP-IDF, ale nie chce mi się już tego sprawdzać. Zwłaszcza że kod YAML był wtedy bardzo podobny do tego dla Arduino, więc jest spora szansa, że też będzie wpadać w pętle (obecny kod, dla nowego ESP-IDF znacznie się różni).