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

[myxhir]

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?

ja mam 1.5.4-12/04/26 i u mnie restartów nie było, na tej mam czujkę PIR i 1 czujnik bateryjny ale T/H. Widocznie byłem w bezpiecznym gronie.
Bardzo natomiast dziękuję za Twoja ogromną pracę i w sumie robotę niczym Sherlock Holmes Doktorów Watsonów miałeś tutaj bardzo dużo

[lukasz06]

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?

Czyli termostaty zaliczają się do tego grona?
Jak tak to mam ich kilka, ale restartów nie było.

[vajera]

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?

Czyli termostaty zaliczają się do tego grona?
Jak tak to mam ich kilka, ale restartów nie było.

Zaliczają się, ale to musi być termostat bateryjny i komunikat o stanie baterii musiał się zbiec z innym komunikatem, np. o temperaturze. Ogólnie rzecz biorąc, ten błąd był wysoce złośliwy, w mojej bramce z 4x TRVZB potrafił się pojawić po 14h, więc niewykluczone, że dlatego Ciebie ominęło.

[vajera]

Podsumowując ten temat - zalecam aktualizację bramek do 1.5.72-08/06/26 (pierwsza wersja oparta o Arduino Core 3.3.10), zwłaszcza jeżeli posiadacie bateryjne urządzenia z kanałem samego termometru (przypominam, że błąd był obecny począwszy od wersji 0.9.38-20/09/2025).

@Zibi_007 - jeszcze raz dziękuję za wsparcie w zakresie public relations.

[Zibi_007]

Podsumowując ten temat - zalecam aktualizację bramek do 1.5.72-08/06/26 (pierwsza wersja oparta o Arduino Core 3.3.10), zwłaszcza jeżeli posiadacie bateryjne urządzenia z kanałem samego termometru (przypominam, że błąd był obecny począwszy od wersji 0.9.38-20/09/2025).

@Zibi_007 - jeszcze raz dziękuję za wsparcie w zakresie public relations.

No co Ty. Nie ma za co. To minimum, które mogłem zrobić. Jak na złość, nie miałem dostępu do żadnej bramki (z urządzeniami), aby pomóc w diagnozowaniu problemu I źle się z tym czułem, tym gorzej, jak mijały kolejne dni testowania. Całe szczęście Klub Promila nie zawiódł i udało się dojść do sedna problemu. Ja dziękuję wszystkim, którzy uczestniczyli w tym procesie, także tym, którzy wysyłali PW nie chcąc śmiecić w tym temacie. Oczywiście chylę czoła przed Tobą @vajera. Nie wiem, czy sam wykazałbym się taką determinacją w szukaniu przyczyny...
Też mam taką jedną historię sprzed wielu lat (dobrą do opowiedzenia przy butelce whisky ). Teraz w skrócie. Był sobie sof, który potrafił chodzić stabilnie nawet kilkadziesiąt godzin (2-3 dni) bez przerwy. Zazwyczaj chodził tylko kilka godzin dziennie, więc problem był niezauważalny. Natomiast uruchomiony na dłużej (powyżej 4-5 dni) wysypywał się i psuł bazę danych. Po dwóch tygodniach pracy zespołu poddaliśmy się, terminy goniły, soft poszedł do użytkowników (zrobiłem protezę, która po 48h od uruchomienia softu informowała o konieczności zapisu danych i uruchomienia programu ponownie). Nie wiem, czy ktokolwiek, kiedykolwiek zobaczył ten komunikat, bo feedbacku nie było, ale może i na tym Forum są dinozaury, które tego oprogramowania używały i nawet o tym błędzie nie wiedzą W każdym razie nie dawało mi to spokoju przez kolejne lata i po jakiś 10 usiadłem do tego ponownie Dla własnej wiedzy (satysfakcji). I... znalazłem ten błąd już w 9 linii kodu
To były inne czasy. O logach można było tylko pomarzyć. PC XT/AT, DOS, Turbo Pascal i 640 KB, które powinno wystarczyć każdemu

Jeszcze raz gratuluję rozwiązania problemu!!!

[lukasz06]

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?

Czyli termostaty zaliczają się do tego grona?
Jak tak to mam ich kilka, ale restartów nie było.

Zaliczają się, ale to musi być termostat bateryjny i komunikat o stanie baterii musiał się zbiec z innym komunikatem, np. o temperaturze. Ogólnie rzecz biorąc, ten błąd był wysoce złośliwy, w mojej bramce z 4x TRVZB potrafił się pojawić po 14h, więc niewykluczone, że dlatego Ciebie ominęło.

Też mam na 1 bramce 2 szt Sonoff TrvZb, a na drugiej 3 szt . Nie doświadczyłem tego przypadku, albo go przeoczyłem. W każdym razie cieszę się, że problem został rozwiązany i gratuluję. Twoja cierpliwość wytrwałość jest godna podziwu
Jakie masz teraz plany?

[vajera]

Też mam na 1 bramce 2 szt Sonoff TrvZb, a na drugiej 3 szt . Nie doświadczyłem tego przypadku, albo go przeoczyłem. W każdym razie cieszę się, że problem został rozwiązany i gratuluję. Twoja cierpliwość wytrwałość jest godna podziwu
Jakie masz teraz plany?

• Audyt kodu
• Rozbudowa funkcji zaworu SONOFF SWV - dodatkowe programy, odliczanie czasu z zaworu.
• Zakończenie przebudowy RGB CCT.
• Pilot IR, kostka Aqara.
• Nowe urządzenia.

[LukiSpajder]

Też mam na 1 bramce 2 szt Sonoff TrvZb, a na drugiej 3 szt . Nie doświadczyłem tego przypadku, albo go przeoczyłem. W każdym razie cieszę się, że problem został rozwiązany i gratuluję. Twoja cierpliwość wytrwałość jest godna podziwu
Jakie masz teraz plany?

• Audyt kodu
• Rozbudowa funkcji zaworu SONOFF SWV - dodatkowe programy, odliczanie czasu z zaworu.
• Zakończenie przebudowy RGB CCT.
• Pilot IR, kostka Aqara.
• Nowe urządzenia.

Kostka Aqara - czeka cierpliwie w mojej szafie . Choć trochę się pobawiłem nią na bramce aqara .

[Robinson74]

• Audyt kodu
• Rozbudowa funkcji zaworu SONOFF SWV - dodatkowe programy, odliczanie czasu z zaworu.
• Zakończenie przebudowy RGB CCT.
• Pilot IR, kostka Aqara.
• Nowe urządzenia.

A czy ten temat też uwzględniasz?
viewtopic.php?t=18459

Czy jest szansa weryfikacji działania funkcji nwk-scan SHORT ADDRESS?

[vajera]

A czy ten temat też uwzględniasz?
viewtopic.php?t=18459

Tak, ale póki co czekam na wsparcie nowej biblioteki w Arduino Core (razem ze wsparciem dla Espressif IDF 6.x).

Czy jest szansa weryfikacji działania funkcji nwk-scan SHORT ADDRESS?

Te tematy są ze sobą powiązane, bo nowa biblioteka korzysta z własnego stosu a nie z ZBOSS.