[Problem-rozwiązany] Samoistny restart bramki [bramka ZigBee]

[vajera]

U mnie 3 bramki od 11 godzin GUI Minimal bez restartu

Ja tam od razu poszedłem w FullGUI 1 dzień 10h 37 minut.

[klew]

SuplaDevice najpierw powiadamia, że jest REGISTERED_AND_READY a dopiero później zaczyna rejestrować lokalne powiadomienia na serwerze. Pytanie do @Krzysztofa, czy to jest by design?

Tak, ten registered and ready dotyczy głównej wiadomości rejestrującej.
Potem było dodane dużo rzeczy, które dzieją się po faktycznej rejestracji na serwerze, w tym rejestracja powiadomień.

[vajera]

SuplaDevice najpierw powiadamia, że jest REGISTERED_AND_READY a dopiero później zaczyna rejestrować lokalne powiadomienia na serwerze. Pytanie do @Krzysztofa, czy to jest by design?

Tak, ten registered and ready dotyczy głównej wiadomości rejestrującej.
Potem było dodane dużo rzeczy, które dzieją się po faktycznej rejestracji na serwerze, w tym rejestracja powiadomień.

OK, czyli nie da się wysłać lokalnego powiadomienia o tym zdarzeniu, chyba że zrobię jakieś opóźnienie czasowe?

[klew]

OK, czyli nie da się wysłać lokalnego powiadomienia o tym zdarzeniu, chyba że zrobię jakieś opóźnienie czasowe?

Powiadomienie o rejestracji?
W sumie to nie wiem .
Wydaje mi się że ta rejestracja pushy jest potrzebna na początku (pierwsza rejestracja i konfiguracja w cloud), a przy kolejnych stratach nie powinno to mieć większego znaczenia.
Ale pewności nie mam
Do czego takie powiadomieniem?

[vajera]

OK, czyli nie da się wysłać lokalnego powiadomienia o tym zdarzeniu, chyba że zrobię jakieś opóźnienie czasowe?

Powiadomienie o rejestracji?
W sumie to nie wiem .
Wydaje mi się że ta rejestracja pushy jest potrzebna na początku (pierwsza rejestracja i konfiguracja w cloud), a przy kolejnych stratach nie powinno to mieć większego znaczenia.
Ale pewności nie mam
Do czego takie powiadomieniem?

Robert (@zzrr ) próbował zrobić sobie powiadomienia o restarcie bramki

[vajera]

Każdy dobry kryminał ma przynajmniej dwa zakończenia, więc trzymając się tej zasady, mam dla Was jeszcze jedną historię - mam nadzieję, że już ostatnią w tym temacie

Wczoraj ogłosiłem sukces w rozwiązaniu problemu restartów i nic nie stało już na przeszkodzie, żeby wznowić pracę nad rozwojem kodu bramki...poza moim przeczuciem, że to nie jest koniec.

Problem rozwiązałem usuwając wszystkie wywołania funkcji Z2S_updateZbDeviceLastSeenMs - ona i tak była już zbyteczna, bo uaktualnianie last_seen_ms odbywa się w innym mechanizmie.

Pozostała natomiast zagadka - dlaczego ta funkcja nie sprawiała do tej pory problemów a nagle zaczęła resetować bramki i to w zupełnie losowy sposób.

Miałem na to dwie hipotezy, o których zresztą wcześniej pisałem - przepełnienie głównego stosu programu albo tzw. race condition (konflikt dwóch wątków).
Obstawiałem raczej pierwszą hipotezę, ale nie byłbym sobą, gdybym tego nie sprawdził.

@Robert znowu zaoferował pomoc, więc udostępniłem Mu kilka wersji testowych, które miały ustalić, która z tych dwóch hipotez jest prawdziwa (ewentualnie obie). Wynik...żadna nie okazała się słuszna

Nie ukrywam, że zmartwiło mnie to bardziej, niż te restarty, bo co z tego, że pozbyłem się ich, skoro nadal nie znam przyczyny - a to oznacza, że problem może w każdej chwili wrócić

Naśladując mojego ulubionego komisarza Marcina Zakrzewskiego, postanowiłem wrócić na miejsce zbrodni, czyli do logów z restartów tej zaklętej bramki, ale tym razem czytając je linijka po linijce, z nadzieją znalezienia jakiegokolwiek tropu.

Udało mi się wyłapać, że na sekundę przed restartem bramka dostaje kilka komunikatów z czujki, w tym dwa o stanie baterii (voltage i percentage), co na pierwszy rzut oka nie prowadziło do nikąd, bo zmian w tym kodzie nie było od dawna...ale postanowiłem mimo wszystko zajrzeć do funkcji updateSuplaBatteryLevel, bardziej dla formalności, niż z nadzieją na znalezienie tam rozwiązania.

Kiedy tak przeglądałem tę funkcję linijka po linijce, mój wzrok padł na ten kod:

Code: Select all

   case SUPLA_CHANNELTYPE_HUMIDITYANDTEMPSENSOR: {

            auto Supla_Z2S_VirtualThermHygroMeter = 
              reinterpret_cast<Supla::Sensor::Z2S_VirtualThermHygroMeter *>(element);

            Supla_Z2S_VirtualThermHygroMeter->Refresh();
          } break;


          case SUPLA_CHANNELTYPE_THERMOMETER:{

            auto Supla_Z2S_VirtualThermHygroMeter = 
              reinterpret_cast<Supla::Sensor::Z2S_VirtualThermHygroMeter *>(element);

            Supla_Z2S_VirtualThermHygroMeter->Refresh();
          } break;

W pierwszej chwili pomyślałem: OK, tutaj jest klasyczny błąd Ctrl-C/Ctrl-V, ale przecież on musi być w tym miejscu od dawna, więc jakie mógłby mieć znaczenie akurat teraz...?

Z ciekawości sprawdziłem - ten case SUPLA_CHANNELTYPE_THERMOMETER jest w kodzie począwszy od wersji 0.9.38-20/09/25, kiedy to dodałem do bramki termometr (wcześniej był tylko T/H).

Z pomocą AI zacząłem to analizować na poziomie reprezentacji tych klas w pamięci i co się okazało - otóż pomimo że funkcja Refresh zapisywała 32bitową wartość korzystając z nieprawidłowo zinterpretowanego wskaźnika, to, przez zupełny przypadek, ta zmienna była dokładnie w tym samym miejscu w pamięci w przypadku obu klas...więc wszystko działało jakby błędu nie było.

Wtedy wszystkie zapadki wskoczyły na właściwe miejsce - w wersji 1.5.42 zmieniłem definicję klasy Z2S_VirtualThermHygroMeter, dodając jej dziedziczenie po klasie Z2S_Core, co kompletnie zmieniło reprezentację tej klasy w pamięci.

W momencie, gdy nadchodził komunikat o stanie baterii dla obiektu typu termometr (nie T/H), wersja 1.5.42 i późniejsze nadpisywały losowy obszar pamięci naruszając integralność sterty, co przy najbliższej kontroli jej stanu generowało błąd krytyczny.

Do wyjaśnienia pozostaje sens tego pierwotnego "rozwiązania" problemu, które znalazłem wczoraj. Prawdopodobnie samo napisanie losowego obszaru nie musiało być wystarczające do wywołania błędu, ale w logach Roberta zauważyłem, że restart nastepował w kombinacji komunikatu o stanie baterii i prawie równoległym nadejściu komunikatu o natężeniu światła - oba komunikaty korzystały z tej funkcji Z2S_updateZbDeviceLastSeenMs, więc nie można wykluczyć, że to była ta przysłowiowa kropla przepełniająca puchar.

Reasumując, bo się trochę rozpisałem, błąd został zlokalizowany i poprawiony, logi trzeba czytać ((c) @klew ) a przy kilkudziesięciu tysiącach linii kodu każda zmiana musi być dobrze zaudytowana.

@Robert - jeszcze raz dziękuję za pomoc i zaangażowanie!

[zzrr]

Każdy dobry kryminał ma przynajmniej dwa zakończenia, więc trzymając się tej zasady, mam dla Was jeszcze jedną historię - mam nadzieję, że już ostatnią w tym temacie

....

Brawo Łukasz(@vajera). To normalnie było nie lada, wręcz matematyczne zadanie które jak zwykle rozwiązałeś.
Super wiadomości od wczoraj

[vajera]

Każdy dobry kryminał ma przynajmniej dwa zakończenia, więc trzymając się tej zasady, mam dla Was jeszcze jedną historię - mam nadzieję, że już ostatnią w tym temacie

....

Brawo Łukasz(@vajera). To normalnie było nie lada, wręcz matematyczne zadanie które jak zwykle rozwiązałeś.
Super wiadomości od wczoraj

Bez Twojej pomocy nie dałbym rady, bo ten błąd pojawiał się wyjątkowo losowo. Potrzebne było urządzenie bateryjne, które ma termometr (ale nie T/H) i jeszcze jakiś kanał raportujący dane, dlatego restartowały się głównie bramki, na których były termostaty bateryjne, tylko że tutaj potrzeba było zwykle przynajmniej kilka godzin, żeby komunikaty zgrały się w "pętlę śmierci". Twoja czujka okazała się idealna, bo komunikat o baterii szedł x2 i jednocześnie przychodziły dane z innych endpoint-ów.
Tak z ciekawości - pytanie do tych, którym bramki z wersjami > 1.5.41 działały prawidłowo - nie macie takich urządzeń w swoich bramkach?

[zzrr]

Każdy dobry kryminał ma przynajmniej dwa zakończenia, więc trzymając się tej zasady, mam dla Was jeszcze jedną historię - mam nadzieję, że już ostatnią w tym temacie

....

Brawo Łukasz(@vajera). To normalnie było nie lada, wręcz matematyczne zadanie które jak zwykle rozwiązałeś.
Super wiadomości od wczoraj

Bez Twojej pomocy nie dałbym rady, bo ten błąd pojawiał się wyjątkowo losowo. Potrzebne było urządzenie bateryjne, które ma termometr (ale nie T/H) i jeszcze jakiś kanał raportujący dane, dlatego restartowały się głównie bramki, na których były termostaty bateryjne, tylko że tutaj potrzeba było zwykle przynajmniej kilka godzin, żeby komunikaty zgrały się w "pętlę śmierci". Twoja czujka okazała się idealna, bo komunikat o baterii szedł x2 i jednocześnie przychodziły dane z innych endpoint-ów.
Tak z ciekawości - pytanie do tych, którym bramki z wersjami > 1.5.41 działały prawidłowo - nie macie takich urządzeń w swoich bramkach?

No nie ukrywam że się cieszę że mogłem coś i ja pomóc, a w sumie to mój PIR na bramce Bardzo dziękuję za miłe słowo. Ale tak naprawdę to przecież wiadomo i każdy to wie... Łukasz jesteś Gość i tyle i nie było takiego problemu który by został zgłoszony a którego byś nie rozwiązał czy to sam czy z naszą pomocą.

[endrju_88]

U mnie nie ma termostatów, ver.1.5.42. Mam dodane Kontaktrony, czujniki wykrywania wstrząsu, czujniki zalania, gniazda 230v , wyłączniki scen, czujniki T/H.