Raczej nikt go nie usuwał, tylko HA zmienia różne rzeczy z wersji na wersje i komponenty niestandardowe przestają działać. W repo HACS jest zgłoszone issue (i setki innych związanych z HACS na forum HA):
na końcu zgłoszenia jest jakieś opis obejścia - może pomoże…
Wg nas HACS będzie miał większy sens jak HA przestanie być beta, bo dodawanie niestandardowych rzeczy do czegoś co się zmienia z wersji na wersji ma właśnie taki efekt. Dlatego tego nie używamy i nie wspieramy.
W HA trwa “porzucenie konfiguracji w yaml-a” i przejście na JSON-a i edycję wszystkiego w aplikacji. HA opublikował na blogu wpis na ten temat → “The future of YAML”
Teraz każda nowa integracja lub poprawka w integracji musi mieć konfiguracje w aplikacji a YAML jest opcjonalny (dla geeków co lubią konsole). Oczywiście nie wszystkim się to podoba, my akurat uważamy, że to dobra droga (jedyna, jeśli HA ma być dla Kowalskiego).
Dobra wiadomość na koniec, chyba udało nam się poprawić blokowanie mikrofonu na pilocie, wydamy niebawem poprawkę na beta Zobaczymy @Iron czy przejdzie test dzieci
Wiesz jak to odtworzyć? jak zrobić żeby pojawiło się więcej niż jeden serwis zigbee?
W kodzie to teoretycznie nie jest to możliwe, bo przed każdym dodaniem nowego serwisu zigbee zatrzymujemy i usuwamy poprzedni.
już chyba wiadomo jak to się stało, źródło jest w tej zmianie
Czyli nie czekamy aż się serwis zatrzyma tylko asynchronicznie zatrzymujemy i uruchamiamy serwisy, więc jak ktoś szybko będzie wkładał i wyciągał dongla to może się tak zdarzyć, że 2 razy najpierw usuniemy a potem 2 razy dodamy…
Pracujemy nad poprawką w kolejnej wersji, a na teraz zalecamy większy zen przy wyciąganiu i wkładaniu dongla usb
Właśnie mi się udało to odtworzyć, myślałem co zrobiłem że pojawił się trzeci serwis zigbee, okazuje się że jak przełożę moduł zigbee w inne gniazo usb to się pojawia następny serwis zigbee.
Jak na załączonym obrazku :
dzięki za info - poszło do sprawdzenia, jeżeli zadziała OK z naszą poprawką z wczoraj to dzisiaj wydamy wersję 0.110.3b w której to będzie już poprawione
Super bo miałem znowu pisać w tej sprawie Może pełen reboot bramki po aktualizacji był by też zasadny bo uzdrawiał by audio robiłem ostatnio kilka aktualizacji, dzisiaj chciałem użyć mikrofonu w pilocie i zonk… wyjęcie i włożenie dongla rozwiązało problem ale po reboocie bramki efekt był by ten sam a użytkownik nawet by problemu nie zauważył.
kilka innych drobnych poprawek (zależności pomiędzy pakietami)
: Możliwość owielania serwisów zigbee (podczas szybkiego wkładania i wyciągania dongla bez czekania na komunikat systemu), jest to dość skomplikowany problem, który nie da się łatwo rozwiązać. Testujemy nowy sposób na dynamiczne dodawanie lub restartowanie serwisów (jeżeli już istnieją), ale to trochę potrwa.
To jak to działa teraz:
Wkładasz dongla USB Zigbee
Mechanizm Linux inotify informuje nas że dodano sprzęt USB
Jolka rozpoznaje urządzenie i informuje głosowo “Dodano urządzenie Zigbee” *
Jolka usuwa wszystkie serwisy Zigbee (żeby ich nie powielać) *
Jolka zleca uruchomienie nowego serwisu Zigbee *
Po uruchomieniu Jolka informuje, ze uruchomiono serwis Zigbee *
* dodając zadanie do wykonania do pętli zdarzeń
To wszystko dzieje się asynchronicznie, bez blokowania działania innych rzeczy na bramce.
Nasz system nie działa tak jak „tradycyjna” aplikacja oparta na wątkach, ale na jednym specjalnym logicznym wątku zwanym pętlą zdarzeń: asyncio — Asynchronous I/O — Python 3.12.0 documentation
Daje nam to sporo korzyści (jesteśmy pewni, że zadanie się wykona i że się wykona tylko raz, na jednym z 4 fizycznych rdzeni dostępnych na bramce). Biblioteka obsługująca pętle zdarzeń nie czeka na zakończenie wykonania zdarzenia tylko zleca wykonanie i “jedzie dalej” a potem wraca do zleconego zadania, żeby przekazać odpowiedz.
Jeżeli ktoś wkłada i wyciąga dongla USB kilka razy bez czekania na komunikat to zleca dodanie i usunięcie kilka razy sewisu Zigbee. Pętla zdarzeń wykona wszystkie te zlecenia ale usuwanie może wykonać szybciej niż dodawanie, w związku z czym serwisy się powielą…
Możemy łatwo się cofnąć do blokowania aplikacji do momentu skończenia zadania, tak jak to robiliśmy jeszcze w wersji 0.108, ale będziemy to próbować rozwiązać inaczej. Postaramy się zastąpić funkcje: start, stop, delete, save w PM2 jedną funkcją StartOrRestart.
Obejście problemu - nie wkładamy, nie przekładamy dongla USB Zigbee za szybko, czekamy aż Jolka poinformuje, że skończyła wykonywać zadanie po wyciągnięciu dongla zigbee (zatrzymała serwis zigbee) zanim włożymy ponownie dongla Zigbee (i zlecimy uruchomienie nowego serwisu zigbee).
Od kilku dni wykonujemy stress testy urządzenia, jak skończymy, to opublikujemy metodologię i wyniki w osobnym wpisie. Efektem tych testów jest zmiana trybu zarządznia wejściem i wyjściem na bramce (io scheduler w Linux).
Dotychczas mieliśmy I/O scheduler CFG który uchodzi za najbardziej zbalansowany I/O Scheduler (harmonogram wykonywanych zadań wejścia i wyjścia jest wyważony). Ma on jednak jedną wadę - pod stałym, dłgotrwałmy obciążeniem może wystąpić destabilizacja, ponieważ I/O próbuje jak najlepiej utworzyć harmonogram wykonywanych zadań. Stabilność jest dla nas ważniejsza niż wydajność dlatego w tej wersji (narazie testowo) zmieniamy I/O scheduler na NOOP, który jest bardzo prostym harmonogram, polegającym na wstawianiu wszystkich operazji wejścia i wyjścia do kolejki (nie stara się porządkować zapisywanych danych tak jak CFG). NOOP nie jest faworytem jeżeli chodzi o wydajność ale jest stabilny i prosty, więc go lubimy
Dla końcowego użytkownika zmiana nie powinna być zauważalna, od kilku dni nasze bramki mają NOOP i wszystko jest OK, gdyby jednak u kogoś nastąpiła jakaś “destabilizacja” po tej aktualizacji to dajcie znać na info@sviete.pl
Jeżeli nie będzie problemów, to harmonogram NOOP pojawi się w wersji stabilnej 0.110, którą wydamy 10 czerwca.
Zawieszała mi się bramka z kartą SD 64GB. Czy NOOP powinien pomóc? Zawieszanie w nocy, czyli chyba w momencie przejścia do zapisywania logów do kolejnego pliku.
Pewności na 100% nie ma czy to pomoże u Ciebie, być może w Twoim przypadku winna jest po prostu karta. Nie są to proste rzeczy na które da się odpowiedzieć tak / nie, za jakiś czas będziemy mieli więcej wniosków czy to pomaga czy nie.
Ostrzegamy, że pierwsze uruchomienie po aktualizacji może trwać nawet 20 minut (w zależności od tego jakie ktoś są dodane integracje i ile będzie trwało pobieranie i kompilowanie zależności).
Dodaliśmy też “przywracanie systemu” gdyby aktualizacja się nie powiodła.
Podczas uruchomienia bramki robimy sprawdzenie czy system jest poprawnie zainstalowany i jeżeli nie to informuje głosowo, że trwa przywracanie systemu i instalujemy najnowszą stabilną wersję.
Zobaczymy @Iron czy przejdzie test dzieci 
: Możliwość owielania serwisów zigbee (podczas szybkiego wkładania i wyciągania dongla bez czekania na komunikat systemu), jest to dość skomplikowany problem, który nie da się łatwo rozwiązać. Testujemy nowy sposób na dynamiczne dodawanie lub restartowanie serwisów (jeżeli już istnieją), ale to trochę potrwa.
Obejście problemu - nie wkładamy, nie przekładamy dongla USB Zigbee za szybko, czekamy aż Jolka poinformuje, że skończyła wykonywać zadanie po wyciągnięciu dongla zigbee (zatrzymała serwis zigbee) zanim włożymy ponownie dongla Zigbee (i zlecimy uruchomienie nowego serwisu zigbee).
