👷 0.110 Beta

Ten calendar w wersji 0.110 to tyklo nowy wygląd kalendarza, czyli jeżeli mamy włączoną/skonfigurowaną integracje calendar (np. Google, CalDAV czy Todoist:

To od wersji 0.110 kalendarz w aplikacji będzie miał ładniejszy wygląd (to się stanie samo - nic nie trzeba doinstalowywać).

PS
Tak to zrozumieliśmy z opisu HA, nie mamy żadnego kalendarza włączonego domyślnie i nie testowaliśmy tego.

F5 w przeglądarce albo poczekanie aż się odświeży aplikacja webowa powinno pomóc

Wszystko zrobione jak wyżej, nadal problemy zigbee, takie coś w logach:


Czy HACS został usunięty z integracji w nowym HA ? Coś w nowej wersji nie chce się uruchomić. Wcześniej już miałem nową wersję tą kafelkową.

Przy okazji dla używających custom components jako moduły konfiguracja została przeniesiona do configuration.yaml (zamiast ui-lovelace.yaml). Niestety teraz żeby cokolwiek zmienić trzeba restartować HA :-(((((( wcześniej wystarczyła edycja ui-lovelace.yaml.
Zmieniła się też ścieżka: /local/community/
Tak teraz wygląda konfiguracja np. kalendarza czy simple-thermostat card

lovelace:
  mode: yaml
  resources:
    - url: /local/community/simple-thermostat/simple-thermostat.js
      type: module
    - url: /local/community/lovelace-card-tools/card-tools.js
      type: js
    - url: /local/community/calendar-card/calendar-card.js
      type: js

Fizycznie komponenty są instalowane w : /data/data/pl.sviete.dom/files/home/AIS/www/community

Custom components tutaj czyli sonoffy i inne
/data/data/pl.sviete.dom/files/home/AIS/custom_components

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 :slight_smile: Zobaczymy @Iron czy przejdzie test dzieci :wink:

chyba widzimy co się dzieje… jakiś proces blokuje /dev/ttyACM0 - port na którym działa zigbee2mqtt
być może jest to inna instancja zigbee

sprawdz proszę w konsoli coś takiego

pm2 status

i wyślij nam co tam jest?

jeżeli masz 2 razy serwis zigbee - tak jak poniżej:

to usuń ręcznie jeden serwis, tak:

pm2 delete 7

gdzie 7 to id serwisu, a potem zapisz ustawienia serwisów:

pm2 save

i zobacz czy to pomaga?

Oczywiście sprawdzamy jak to możliwe, że proces się powielił… ale udało nam się to też wywołać.

1 polubienie

Z tego co widze to mam aż 3, już biorę się za usuwanie, rozumiem że dwa ostatnie?

Proponuje 11 i 13 czyli te które mają restarty.

1 polubienie

Tak też zrobiłem, po usunięciu sytuacja prezentuje się następująco:


dzięki za info :slight_smile:

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.

Oczywiście próbujemy to odtworzyć i poprawić.

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… :bug:

Pracujemy nad poprawką w kolejnej wersji, a na teraz zalecamy większy zen :pray: :wink: 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 :wink: Może pełen reboot bramki po aktualizacji był by też zasadny bo uzdrawiał by audio :slight_smile: 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ł.

0110.3b2 wydana

zmiany:

  • HA w wersji 0.110.3
  • AIS dom serwer w wersji 2.0.6 (poprawki na blokowanie mikrofonu na pilocie)
  • kilka innych drobnych poprawek (zależności pomiędzy pakietami)

:warning: : 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ń: https://docs.python.org/3/library/asyncio.html
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.

:information_source: 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).

0.110.4b2 wydana na BETA

2 zmiany:

  • HA w wersji 0.110.4
  • nowy I/O scheduler

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 :slight_smile:
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.

0.110.4b4 wydana na beta

Zmiany:

  • zigbee2mqtt 1.13.1
    image
  • nowy sposób uruchamiania serwisów zigbee i tunel
  • poprawione odświeżanie mapy urządzeń zigbee oraz odtwarzacza
  • ustawiamy tryb zarządzania częstotliwością procesora interactive (to jest kolejna poprawka mająca za zadanie ustabilizować działanie systemu)

0.110.5 wydana na beta

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ę.

Jutro wydamy 0.110.5 na kanale stabilnym :wave: