Aktualizacje oprogramowania [bramka ZigBee]

[[email protected]]

@vajera czyli w sumie z czym był problem ? Bo mnie zaciekawiłeś i przejrzałem repozytorium i chyba jedyna istotna zmiana jaką zauważyłem to że zwiekszyles bufory we własnym forku espui

[Zibi_007]

@vajera czyli w sumie z czym był problem ? Bo mnie zaciekawiłeś i przejrzałem repozytorium i chyba jedyna istotna zmiana jaką zauważyłem to że zwiekszyles bufory we własnym forku espui

Też bym się z chęcią dowiedział, bo jeśli będzie stabilnie to bym sobie zrobił bramkę tylko do alarmu, kompatybilną z Suplą ale także z możliwością ustawiania i sterowania z GUI bramki.

[vajera]

@vajera czyli w sumie z czym był problem ? Bo mnie zaciekawiłeś i przejrzałem repozytorium i chyba jedyna istotna zmiana jaką zauważyłem to że zwiekszyles bufory we własnym forku espui

Po żmudnej analizie miliona logów wypluwanych przez ESPUI doszedłem do wniosku, że problem jednak tkwi w tej bibliotece a nie, tak jak sugerowali niektórzy, w kodzie AsyncWebServer/AsyncTCP.

W funcji MarshallControl(...) generowany jest string json, który zawiera kod uaktualniający poszczególne komponenty - zauważyłem, że tuż przed SF wartość remaining space jest zwykle bliska zeru, więc poszedłem tym tropem i, tak jak słusznie zauważyłeś, zacząłem od zwiększenia bufora do update z 2 na 8 kB.

Na pierwszy rzut oka wydawało się, że to rozwiązało problem, ale bardzo intensywne klikanie potrafiło jednak wygenerować ów nieszczęsny błąd

Dalsze zwiększanie bufora nie miało sensu, bo błąd w końcu by się pojawił - w planach jest przecież rozwój GUI.

Grzebiąc dalej w logach i kodzie ESPUI doszedłem w końcu do następujących wniosków:

1. Kod generujący string JSON został napisany w taki sposób, że gdy kończy się wolne miejsce w buforze, wysyła wygenerowane dane i generuje kolejny JSON - i to działa prawidłowo;
2. W pewnych okolicznościach (i tutaj przyznaje nie ogarniam jeszcze do końca tego algorytmu) kod dzieli dane o pojedynczej kontrolce na części (fragmented) - autor chciał zapewne zabezpieczyć scenariusz, w którym pojedyncza kontrolka przekracza rozmiar bufora?
3. Ten scenariusz ma jakiś defekt, który sprawia, że wykrzacza się stos AsyncTCP - mam pewne podejrzenia, ale jeszcze nie potwierdzone (zaraz wsiadam do samolotu, więc pomęczę ten kod offline ) - prawdopodobnie nieprawidłowy wskaźnik?
4. Rozwiązaniem, które wydaje się działać, jest ustawienie tego parametru maxchunknum na więcej niż 0 - wtedy problem się nie pojawia - tak przynajmniej pokazują testy.
5. Minusem tego rozwiązania jest fakt, że czasami nie ładują się wszystkie zakładki - trzeba chwilę poczekać albo odświeżyć stronę, ale nie wydaje się to zbyt irytujące?

[vajera]

Wersja 0.8.46-29/06/2025:

1. przycisk .manufacturer_name = "eWeLink", .model_name = "CK-TLSR8656-SS5-01(7000)";
2. w przypadku niepowodzenia procedury parowania (nieznane urządzenie) bramka przywraca obsługę komunikatów i włącza GUI;
3. drobne poprawki w GUI - bez większych zmian wizualnych, ale istotne pod kątem stabilności GUI - nie udało mi wygenerować tego niesławnego błędu, ale jak zawsze proszę o testy;
4. jeżeli wersja 0.8.46 okaże się stabilna będę mógł wznowić prace nad rozbudową GUI.

[LukiSpajder]

Wgrana ver. 0.8.46

Wygląda że działa prawidłowo , chociaż czujnik dymu sparował się za drugim razem . I po usunięciu termometru xaomi nie chciał się dodać do bramki ale to raczej jego wina niż bramki , od jakiegoś czasu mam z nimi taki problem że znika ikona baterii i pojawia się 0 wyskakuje w apce wykrzyknik ale jak złapie logi z tego to zjawiska to wrzucę innym wątku . Po usunięciu wszystkiego z bramki sparował się .
Inne urządzenia po usunięciu powtórnie się parowały bez problemu , nie udało się zawiesić bramki .
Ale będę ja testowa jeszcze

[vajera]

Wgrana ver. 0.8.46

Wygląda że działa prawidłowo , chociaż czujnik dymu sparował się za drugim razem . I po usunięciu termometru xaomi nie chciał się dodać do bramki ale to raczej jego wina niż bramki , od jakiegoś czasu mam z nimi taki problem że znika ikona baterii i pojawia się 0 wyskakuje w apce wykrzyknik ale jak złapie logi z tego to zjawiska to wrzucę innym wątku . Po usunięciu wszystkiego z bramki sparował się .
Inne urządzenia po usunięciu powtórnie się parowały bez problemu , nie udało się zawiesić bramki .
Ale będę ja testowa jeszcze

Dzięki! Najbardziej zależy mi na testach nowego GUI - czyli klikamy co się da, im szybciej tym lepiej
Wchodzimy do GUI z kilku urządzeń jednocześnie (komputer, telefon, mikrofalówka) itd.

[LukiSpajder]

A wiec tak po usunięciu urządzenia w zakładce Zigbee devices przez przycisk Remove device! , nie pokazuje się urządzenie na liście ale działa normalnie można nim sterować i pokazuje się reakcja w apce. Tak zrobiłem z przyciskiem ikea , mimo że działa próbowałem go sparować jeszcze raz aby pojawiła się na liście. I tak zapaliła się niebieska potem czerwona od tego momentu w Supli bramka zrobiła sie offline ale połączenie z urządzeniami jest , z routerm też jest połaczona bo ZIGBEE <=> SUPLA CONTROL PANEL Connected - działa
Zebrałem logi ale nie wiem w którym dokładnie monecie to się stało przesyłam wycinek ( jeśli by tu nic nie było mam całość w razie w )
Bramka cały czas wis świeci zielona dioda .

co wciśniete .png

Logi ver 0.8.46 jest tak .rar

- Teraz są tam logi

[vajera]

Najważniejsza kwestia - w Twoich logach brak kiss of death - takim mianem ochrzciłem ten złośliwy błąd w bibliotece ESPUI.

Kolejna kwestia - trochę namieszałem tym GUI, więc kilka słów wytłumaczenia:

1. Na początku była tabela kanałów Supla, która w nazwie miała...devices...nie pytajcie dlaczego, bo nie znam odpowiedzi
2. Każdy pozycja w tej tabeli definiuje jeden kanał Supla, więc, jedno urządzenie Zigbee może generować kilka kanałów (nawet 12 -14);
3. dostęp do tej tabeli w GUI daje zakładka Zigbee channels - mamy tam podgląd każdego kanału, możliwość zmiany niektórych wartości (@Zibi_007 - jesteś pewny, że wartości Timings nie zapisują się u Ciebie???) oraz usunięcia danego kanału lub wszystkich kanałów, co oczywiście będzie wymagać ręcznego usunięcia tych kanałów z Cloud;
4. na którymś etapie rozwoju bramki dodałem nową tabelę przechowującą dane o urządzeniach Zigbee (manufacturer name, model id, itd.) - dostęp do niej w GUI daje zakładka Zigbee Devices;
5. i teraz najważniejsze - to są dwie niezależne tabele - usunięcie wpisu z tabeli Zigbee Devices NIE ma wpływu na tabelę channels - podobnie w drugą stronę;
6. zakładka Zigbee Devices ma 3 przyciski:
   1. Remove Device = usuwa rekord z tabeli Zigbee Devices, nie zmienia nic w tabeli channels, więc z punktu widzenia sieci Zigbee i systemu Supla wszystko pozostaje bez zmian;
   2. Remove All Devices = jak wyżej, z tym że czyści całą tabelę;
   3. Remove Device with All Channels = ta funkcja to combo - usuwa wszystkie kanały danego urządzenia (tabela kanałów) i sam wpis o nim (tabela urządzeń).

[vajera]

Kontynuując - muszę zrobić porządek z tymi dwiema tabelami, ale póki co proponuję następujące opcje:

1. najlepszym rozwiązaniem do usunięcia urządzenia Zigbee z Supla w sytuacji, gdy np. nie sparowały się wszystkie kanały, zmieniła się definicja urządzenia albo nie planujemy już używać go z bramką jest Remove Device with All Channels;
2. To polecenie spowoduje restart bramki i prawdopodobnie channel conflict w Cloud - bramka będzie offline do czasu ręcznego usunięcia kanałów z Cloud;
3. Samo urządzenie Zigbee nadal będzie zbindowane z bramką i będzie kontynuować wysyłkę komunikatów, aż do wystąpienia jednego z trzech poniższych zdarzeń:
   1. sparowania z inną bramką - w tym scenariuszu musimy pamiętać, że wpis w binding table Zigbee nie zostanie usunięty, co może w pewnym momencie doprowadzić do przepełnienia tej tablicy i braku możliwości parowania nowych urządzeń;
   2. przeprowadzenia prawidłowej procedury usunięcia urządzenia z sieci Zigbee - opis poniżej;
   3. zresetowania stosu Zigbee, co spowoduje usunięcie wszystkich bindingów urządzeń Zigbee powiązanych z bramką;

[vajera]

Podsumowując - jeżeli chcemy prawidłowo i trwale usunąć jedno urządzenie Zigbee z bramki, postępujemy według poniższego algorytmu:

1. usuwamy urządzenie z sieci Zigbee bramki:
   1. Bramka NIE może być w trybie parowania;
   2. wprowadzamy urządzenie Zigbee w tryb parowania;
   3. zgodnie ze standardem Zigbee opuści ono wtedy sieć bramki (i zostanie usunięte z tablicy bindingów);
   4. również zgodnie ze standardem Zigbee będzie chciało sparować się z nowym koordynatorem, dlatego właśnie bramka NIE może być w trybie parowania bo urządzenie do niej powróci;
   5. należy poczekać aż urządzenie sparuje się z nową bramką (jeżeli je przenosimy) - oczywiście ta nowa bramka musi być wtedy w trybie parowania lub aż zakończy próbę parowania (przestanie mrugać dioda/ikona);
2. dopiero wtedy usuwamy urządzenie z Supla przyciskiem Remove Device and All Channels i robimy porządek w Cloud.