Aktualizacje oprogramowania [bramka ZigBee]

[endrju_88]

Cześć Wam. Wgrałem wersję 0.8.45 i z początku szło topornie tzn.nie mogłem dodać ani jednego urządzenia , za każdym razem rgb na czerwono. Ale wyczyściłem bramkę ,wgrałem od nowa wsad i urządzenia zaczęły się dodawać. W GUI również nie zauważyłem jakichś problemów. Włącza się bez zająknięcia ,nie resetuje. Usunąłem urządzenie poprzez Remove device with channels , po czym chciałem dodać i ta sama sytuacja co u kolegi @Zibiego , urządzenie ponownie dodało się ale za drugim razem. Zauważyłem nowe okienko Clusters&Attributes , SUPER!!!. Będę testował ten 0.8.45 , jak coś będzie nie halo to wrócę z informacją.

[Zibi_007]

Wersja 0.8.45-27/06/2025 to wersja stricte testowa, wyłącznie dla chętnych alfa-testerów
Przywróciłem nowe GUI, prawdopodobnie zlokalizowałem przyczynę restartów i prawdopodobnie ją naprawiłem.
Bramka chodzi już jakiś czas bez jednego restartu, w tym czasie klikam co się da w szybkim tempie, jednocześnie z komputera i komórki.
Niemniej doświadczenie już nie jeden raz pokazało, że to co działa u mnie nie musi działać u innych.

W uzupełnieniu do poprzedniego info. Całą noc się bramka chodziła. Wszystko działa, a robiłem różne rzeczy. Ani razu bramka nie zaliczyła nieprzewidzianego resetu ani zawieszenia.

[LukiSpajder]

Wgrana ver. 0.8.45

Działa bardzo szybko reakcja na naciśniecie np. parowania natychmiast dioda zapala się na zielono.
Sparowałem kilka urządzeń głowica , czujnik otwarcia okna , termometr , czujka ruchu . Dodały się bez problemu . GUI robi wrażenie mnogość funkcji informacji na wyciągniecie ręki .
Po sparowaniu czujnika otwarcia okna ostatniego z dodanych do bramka jakby nie miała połączenia z Supla, wszystkie urządzenia połączyły się po zigbee . W cludzie był nie dostępny logi mam częściowe z tego momentu co się nie łączył z serwerem . Może to pojedyncza anomalia

Logi ver.0.8.45 brak poł. supla .rar

A nie mogę dodać do bramki urządzeń po wgraniu pliku Z2S_Gateway.ino.merged.4MB.no_OTA.no_logs.bin
przy parowaniu zapala się niebieska dioda i zaraz czerwona. Nie dodaje się żadne urządzenie - Może ktoś sprawdzić u Siebie

[Zibi_007]

Wersja 0.8.44-27.06.2025 zawiera wszystkie dotychczas dodane urządzenia, ale przywróciłem oryginalny WebInterface, przynajmniej do czasu rozwiązania problemów z restartami bramki. Nie używajcie póki co wersji z nowym GUI, gdyż takie ciągłe restarty mogą też uszkodzić plik z danymi bramki, co będzie prowadzić do konfliktu kanałów i braku części urządzeń.

Kolejny update. Jednak udało mi się doprowadzić bramkę do zapętlenia z ciągłym przechodzeniem w tryb offline. Zaczęło się od dodawania kolejnych urządzeń. Jak bramka trafiła na takie, którego nie zna (eWeLink::CK-TLSR8656-SS5-01(7000)) - wrzucę później w odpowiedni dział), to bardzo długo (ponad 2 minuty dioda świeciła na czerwono). Od tego momentu bramka co pewien czas robi wszystkie kanały off, a później znowu się prawidłowo loguje do Supli. Logi w załączniku. A było już tak pięknie... Podejrzane jest to, że podczas tych pętli bramka bardzo często odwołuje się do głowicy termostatycznej.

[vajera]

Kolejny update. Jednak udało mi się doprowadzić bramkę do zapętlenia z ciągłym przechodzeniem w tryb offline. Zaczęło się od dodawania kolejnych urządzeń. Jak bramka trafiła na takie, którego nie zna (eWeLink::CK-TLSR8656-SS5-01(7000)) - wrzucę później w odpowiedni dział), to bardzo długo (ponad 2 minuty dioda świeciła na czerwono). Od tego momentu bramka co pewien czas robi wszystkie kanały off, a później znowu się prawidłowo loguje do Supli. Logi w załączniku. A było już tak pięknie... Podejrzane jest to, że podczas tych pętli bramka bardzo często odwołuje się do głowicy termostatycznej.

Na szczęście, zanim postanowiłem wyrwać sobie resztę włosów z głowy, przeanalizowałem Twoje logi i doznałem oświecenia. Problem, o którym tutaj napisałeś, jest jak najbardziej realny, ale na nie ma nic wspólnego z przypadkiem nowego GUI (o czy za chwilę w oddzielnym poście).
Całkiem niedawno udało mi się rozwiązać problem z wolnym dodawaniem nowych urządzeń (zwłaszcza tych przycisków) - zrobiłem to wyłączając odbiór komunikatów Zigbee w trakcie parowania (dodając nowe GUI uzupełniłem to jeszcze o wyłączenie serwera Web w tracie parowania), tak żeby jak najmniej rzeczy przeszkadzało bramce w trakcie dodawania nowego urządzenia.
Podejrzewam, że już domyślasz się, co zepsułem Po dodaniu nowego urządzenia bramka robi restart i wszystko wraca do normy...chyba, że urządzenia nie ma w bazie, bo wtedy bramka nie zrobi restartu a ja zapomniałem dodać kod reaktywujący odbiór komunikatów i włączenie GUI, więc z punktu widzenia użytkownika bramka robi się głucha i ślepa, aż do momentu restartu.

[lukasz06]

A tak z ciekawości zapytam, czy musi być ten restart zarówno żeby sparować . jak i po sparowaniu, bo w komercyjnych raczej tego nie ma

[vajera]

@Zibi_007, @endrju_88, @LukiSpajder - bardzo dziękuję za Wasze zaangażowanie, moja bramka też chodziła całą noc bez jednego restartu, pomimo że regularnie ją "dręczyłem" klikaniem w różne opcje.

W nagrodę wujek Łukasz opowie Wam historię

Szukając jakiegoś rozwiązania na GUI dla bramki natknąłem się na bibliotekę ESPUI - stabilny projekt z imponującą ilością forków, bardzo dużo komponentów i całkiem przejrzysty sposób tworzenia kodu. Dodałem ją do projektu i zacząłem budowę nowego GUI, najpierw z wizją, że udostępnię je, gdy osiągnie odpowiednią stabilność. Zamieszanie z modyfikacją kodu SuplaDevice spowodowało, że udostępniłem nowe GIU wcześniej, niż pierwotnie zamierzałem. Wersja 0.8.41-22/06/2025 zyskała pozytywny odbiór i działa stabilnie, więc jeszcze tego samego dnia ujrzała światło dzienne wersja 0.8.42-22/06/2025, w której między innymi dołożyłem formatowanie tekstów w HTMLu (bold, italic itd.)...i zaczęło się...
Regularne restarty bramki z powodu naruszenia stosu w kodzie AsyncTCP...czego ja nie przetestowałem...za długi bufor?...przeniesienie kodu z callbacka do pętli?...testy kilku różnych wersji AsyncTCP i AsyncWebServer...kopanie sieci...wtedy znalazłem to w issues ESPUI:

https://github.com/s00500/ESPUI/issues/321

Problem identyczny z moim, zgłoszony w grudniu 2024 i...nierozwiązany do dzisiaj...na tym etapie byłem już właściwie gotowy zamknąć ten rozdział i rozpocząć od nowa z czymś innym, bo skoro ani autor biblioteki ani aktywni użytkownicy (rozwijający nawet swoje forki) nie znaleźli rozwiązania, to jakie są szanse, że ja je znajdę w gąszczu obcego kodu...ale stwierdziłem, że dam sobie jeszcze jeden dzień...

Odkomentowałem wszystkie Serial.println(...) i próbowałem ogarnąć, jak działa ten kod i gdzie może być źródło stack fault.

Ostatnia noc i nasze testy pokazały, że chyba zlokalizowałem przyczynę i prawdopodobnie znalazłem działający workaround, chociaż to właśnie bardziej objazd niż pełne rozwiązanie.

[vajera]

A tak z ciekawości zapytam, czy musi być ten restart zarówno żeby sparować . jak i po sparowaniu, bo w komercyjnych raczej tego nie ma

Do sparowania nie jest potrzebny restart - naciskasz przycisk BOOT albo odpalasz polecenie z konsoli/GUI - bramka wchodzi w tryb parowania i od tego momentu urządzenie Zigbee zaczyna wysyłać dane, więc z punktu widzenia sieci Zigbee restart również nie jest konieczny (podobnie jak ma to miejsce w komercyjnych bramkach).

Restart bramki po dodaniu nowego urządzenia związany jest z działaniem Supla - o ile w teorii możliwe jest dodanie nowych kanałów w trakcie pracy SuplaDevice to od samego początku przyjąłem bezpieczniejszy model - bramka dopisuje nowe kanały do tabeli i po restarcie buduje kanały Supla jeden po drugim.

[Zibi_007]

Kolejny update. Jednak udało mi się doprowadzić bramkę do zapętlenia z ciągłym przechodzeniem w tryb offline. Zaczęło się od dodawania kolejnych urządzeń. Jak bramka trafiła na takie, którego nie zna (eWeLink::CK-TLSR8656-SS5-01(7000)) - wrzucę później w odpowiedni dział), to bardzo długo (ponad 2 minuty dioda świeciła na czerwono). Od tego momentu bramka co pewien czas robi wszystkie kanały off, a później znowu się prawidłowo loguje do Supli. Logi w załączniku. A było już tak pięknie... Podejrzane jest to, że podczas tych pętli bramka bardzo często odwołuje się do głowicy termostatycznej.

Na szczęście, zanim postanowiłem wyrwać sobie resztę włosów z głowy, przeanalizowałem Twoje logi i doznałem oświecenia. Problem, o którym tutaj napisałeś, jest jak najbardziej realny, ale na nie ma nic wspólnego z przypadkiem nowego GUI (o czy za chwilę w oddzielnym poście).
Całkiem niedawno udało mi się rozwiązać problem z wolnym dodawaniem nowych urządzeń (zwłaszcza tych przycisków) - zrobiłem to wyłączając odbiór komunikatów Zigbee w trakcie parowania (dodając nowe GUI uzupełniłem to jeszcze o wyłączenie serwera Web w tracie parowania), tak żeby jak najmniej rzeczy przeszkadzało bramce w trakcie dodawania nowego urządzenia.
Podejrzewam, że już domyślasz się, co zepsułem Po dodaniu nowego urządzenia bramka robi restart i wszystko wraca do normy...chyba, że urządzenia nie ma w bazie, bo wtedy bramka nie zrobi restartu a ja zapomniałem dodać kod reaktywujący odbiór komunikatów i włączenie GUI, więc z punktu widzenia użytkownika bramka robi się głucha i ślepa, aż do momentu restartu.

No tak, w trakcie czytania drugiego akapitu zacząłem się domyślać

[Zibi_007]

@Zibi_007, @endrju_88, @LukiSpajder - bardzo dziękuję za Wasze zaangażowanie, moja bramka też chodziła całą noc bez jednego restartu, pomimo że regularnie ją "dręczyłem" klikaniem w różne opcje.

W nagrodę wujek Łukasz opowie Wam historię

Szukając jakiegoś rozwiązania na GUI dla bramki natknąłem się na bibliotekę ESPUI - stabilny projekt z imponującą ilością forków, bardzo dużo komponentów i całkiem przejrzysty sposób tworzenia kodu. Dodałem ją do projektu i zacząłem budowę nowego GUI, najpierw z wizją, że udostępnię je, gdy osiągnie odpowiednią stabilność. Zamieszanie z modyfikacją kodu SuplaDevice spowodowało, że udostępniłem nowe GIU wcześniej, niż pierwotnie zamierzałem. Wersja 0.8.41-22/06/2025 zyskała pozytywny odbiór i działa stabilnie, więc jeszcze tego samego dnia ujrzała światło dzienne wersja 0.8.42-22/06/2025, w której między innymi dołożyłem formatowanie tekstów w HTMLu (bold, italic itd.)...i zaczęło się...
Regularne restarty bramki z powodu naruszenia stosu w kodzie AsyncTCP...czego ja nie przetestowałem...za długi bufor?...przeniesienie kodu z callbacka do pętli?...testy kilku różnych wersji AsyncTCP i AsyncWebServer...kopanie sieci...wtedy znalazłem to w issues ESPUI:

https://github.com/s00500/ESPUI/issues/321

Problem identyczny z moim, zgłoszony w grudniu 2024 i...nierozwiązany do dzisiaj...na tym etapie byłem już właściwie gotowy zamknąć ten rozdział i rozpocząć od nowa z czymś innym, bo skoro ani autor biblioteki ani aktywni użytkownicy (rozwijający nawet swoje forki) nie znaleźli rozwiązania, to jakie są szanse, że ja je znajdę w gąszczu obcego kodu...ale stwierdziłem, że dam sobie jeszcze jeden dzień...

Odkomentowałem wszystkie Serial.println(...) i próbowałem ogarnąć, jak działa ten kod i gdzie może być źródło stack fault.

Ostatnia noc i nasze testy pokazały, że chyba zlokalizowałem przyczynę i prawdopodobnie znalazłem działający workaround, chociaż to właśnie bardziej objazd niż pełne rozwiązanie.

I takie właśnie są problemy z czyimś kodem. Opisywałem wcześniej jedno takie "ulepszenie", które nie doprowadziło niemal firmy do ruiny. A mógłbym takich historii opowiedzieć wiele. Dla mnie to już w zasadzie zamierzchła historia, z całkiem innego etapu życia, ale jak sobie czasem przypomnę, to mi jeszcze puls skacze Miejmy nadzieję, że Twoje "obejście" problemu będzie działać