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

[george1255]

Wersja oprogramowania
Z2S-1.5.57-30/05/26

Ostatnie połączenie
5.06.2026, 10:42 (21 godzin temu)

Czas pracy
5 dni, 21 godzin, 17 minut i 9 sekund

Czas połączenia
21 godzin, 57 minut i 46 sekund

Powód restartu połączenia
reset połączenia z serwerem

[vajera]

U mnie wersja 1.5.69 działa cała noc bez restartu po wrzuceniu ver.1.5.71 restart po 9 minutach znacznik czasu ok.[ 7.43]. czy coś tam jest przydatnego oceń :

Dzięki, ale to raczej coś przypadkowego, bo tutaj mamy zupełnie inny mechanizm błędu - robiłeś w tym czasie coś w GUI? Możesz ewentualnie spróbować powtórzyć ten błąd.

[lukasz06]

Co prawda nie biorę udziału w tych testach ze względu na brak czasu, ale jak już parę dni temu pisałem, wersja 1.5.42 działa stabilnie.

@lukasz06 a GUI masz włączone? Bo to też ważne.

Co prawda już teraz rzadziej tam zaglądam ale jest włączone, a na jednej nawet Full z AD

[vajera]

@vajera zrobiłem akcje żeby mi dawało PUSCH przy restarcie, właczyłem notification w aplikacji, jest co trzeba na cloudzie i nie działa.
Czy dobrze zrobiłem akcję?
Action#: 1 of 1
Action name: start (enabled)
Event: {ON SUPLA REGISTERED AND READY}
from source channel: [GATEWAY EVENTS]
Action: {SET}
on destination channel: [LOCAL VIRTUAL BINARY]
EDIT:
Zrobiłem powiadamianie z clouda. Ale pytanie dlaczego powiadomienia z bramki z VB nie działają aktualne.
EDIT:
Powiadomienia z VB działają, sprawdziłem inaczej. Nie działają z tej powyższej akcji.

Sprawdziłem tę akcję i faktycznie nie działa - wydaje się, że przyczyna jest poniżej:

Code: Select all

Device registered (activity timeout 120 s, server version: 28, server min version: 1)
LAST STATE ADDED: Registered and ready (13)
[ 13605][I][Z2S_Gateway.ino:174] supla_callback_bridge(): event(0x23), action(0x4010)
[ 13606][I][Z2S_Gateway.ino:208] supla_callback_bridge(): Supla device status changed to 17
[ 13606][I][Z2S_local_action_handlers.cpp:292] handleAction(): &&&&&&&&&&&&&&&&&&&&&&&&&&event 16400, action 0
Notification: can't send - srpc not set
- Telnet: [ 13607][V][NetworkServer.h:41] NetworkServer(): NetworkServer::NetworkServer(port=23, ...)
Telnet running
[ 13612][I][Z2S_local_action_handlers.cpp:292] handleAction(): &&&&&&&&&&&&&&&&&&&&&&&&&&event 35, action 24576
Current status: [17] Registered and ready
Changing activity timeout to 30 s
Send: [53 55 50 4C 41 1C 02 00 00 00 D2 00 00 00 01 00 00 00 1E ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 0
Send: [53 55 50 4C 41 1C 03 00 00 00 4C 04 00 00 0B 00 00 00 05 00 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 7
Send: [53 55 50 4C 41 1C 04 00 00 00 4C 04 00 00 0B 00 00 00 05 07 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 14
Send: [53 55 50 4C 41 1C 05 00 00 00 4C 04 00 00 0B 00 00 00 05 0E 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 24
Send: [53 55 50 4C 41 1C 06 00 00 00 4C 04 00 00 0B 00 00 00 05 18 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 25
Send: [53 55 50 4C 41 1C 07 00 00 00 4C 04 00 00 0B 00 00 00 05 19 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 33
Send: [53 55 50 4C 41 1C 08 00 00 00 4C 04 00 00 0B 00 00 00 05 21 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 35
Send: [53 55 50 4C 41 1C 09 00 00 00 4C 04 00 00 0B 00 00 00 05 23 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Notification: sending registration for context 43
Send: [53 55 50 4C 41 1C 0A 00 00 00 4C 04 00 00 0B 00 00 00 05 2B 00 00 00 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]
Send: [53 55 50 4C 41 1C 0B 00 00 00 E0 01 00 00 00 00 00 00 ]
Send: [53 55 50 4C 41 ]

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?

[vajera]

W temacie zasadniczym - wydaję się, że udało mi się zlokalizować źródło błędu i usunąć je, jednocześnie zachowując kod dodany w wersjach > 1.5.41 - wersja 1.5.70-06/06/26 powinna pracować stabilnie (moja bramka pracuje już ponad 22h, ale najważniejsza bramka w tych testach przeżyła noc bez ponownego uruchomienia ).

Chcę gorąco podziękować wszystkim, którzy wsparli mnie w rozwiązywaniu tego problemu, zarówno biorąc aktywny udział w testach (@bokk, @LukiSpajder), jak i zgłaszając bezawaryjną pracę bramki (@Robert Błaszczak , @lukasz06 , @endrju_88 , @george1255), a także zapewniając wsparcie merytoryczne (@klew , @[email protected]) i z zakresu public relations (@Zibi_007 - bardzo dziękuję!).

Szczególne podziękowania należą się koledze @zzrr, bo bez Jego zaangażowania, zebranych logów i zaklętej czujki, wciąż jeszcze szukałbym przyczyny. Robert - dziękuję bardzo!

Wkrótce opiszę szczegóły techniczne tego błędu, oczywiście jego usunięcie nie oznacza, że bramka jest oporna na wszystkie zakłócenia, więc zawsze może się zdarzyć okazjonalny restart, niemniej wydaje się, że zasadniczy problem został usunięty i mogę wrócić do dalszego rozwijania kodu bramki.

[vajera]

Kontynuując poprzedni wątek - wiem, że dwa dni temu nieco pospiesznie ogłosiłem sukces, więc tym razem czekałem cierpliwie nie tylko na swoje bramki, ale przede wszystkim na bramkę Roberta (@zzrr), bo to ona restartowała się z zegarmistrzowską precyzją co 27 minut, niezależnie od zmian w kodzie. Tym razem rzeczona bramka przepracowała całą noc, moja bramka właśnie przekroczyła granicę 23h, co nie udało się wcześniej z żadną z wersji > 1.5.41, więc mam nadzieję, że to nie falstart.

Krótkie podsumowanie:

• Błąd nie dotyczył GUI, gdyż naznaczone bramki potrafiły restartować się zarówno w wersji z GUI, jak i bez.
• Błąd miał losowy charakter, zarówno w kwestii bramek, które dotykał, jak i czasu wystąpienia.
• Pojawił się pierwszy raz w wersji 1.5.42, pomimo że ta wersja wprowadziła niewiele zmian w kodzie - głównie dotyczyły one kodu T/H.

Najbardziej prawdopodobną przyczyną tych losowych restartów bramki był jeden z elementów mechanizmu monitorowania aktywności urządzeń ZigBee (last_seen_ms), który powodował albo nadpisanie sterty/stosu albo tzw. race condition (stos ZigBee pracuje w oddzielnym wątku) - to będę musiał jeszcze zweryfikować.
Ten błąd aktywował się głównie tam, gdzie jedno urządzenie ZigBee miało kilka kanałów często raportujących swój stan, np. głowica TRV (T/H + HVAC), dlatego czujka Roberta była tak wybitnie podatna (4x VirtualBinary, 1x T/H), a z drugiej strony wielu użytkowników nie doświadczyło tego problemu wcale.

[LukiSpajder]

Super że się udało namierzyć problem
U mnie ta wersja testowa 1.5.71 się nie zresetowała jedynie telnet coś nie chciał działać. Ale przy wersji oficjalnej 1.5.70 wszystko dział

Pytanie :
Czy powróci info o sile radia w apce Supli ?

[vajera]

Super że się udało namierzyć problem
U mnie ta wersja testowa 1.5.71 się nie zresetowała jedynie telnet coś nie chciał działać. Ale przy wersji oficjalnej 1.5.70 wszystko dział

Pytanie :
Czy powróci info o sile radia w apce Supli ?

Wkrótce powróci.
ps. Moja bramka pracuje 1 dzień 8h bez przerwy.

[LukiSpajder]

Super że się udało namierzyć problem
U mnie ta wersja testowa 1.5.71 się nie zresetowała jedynie telnet coś nie chciał działać. Ale przy wersji oficjalnej 1.5.70 wszystko dział

Pytanie :
Czy powróci info o sile radia w apce Supli ?

Wkrótce powróci.
ps. Moja bramka pracuje 1 dzień 8h bez przerwy.

U mnie z przerwami bo się coś logi zawieszały i wyłączyłem bramkę , przed aktualizacja 8 godzin 20 minut . Choć ta w garażu wyłączone było GUI ponad 1 dzień .

Teraz wszystkie 4 bramki zaktualizowane i se działają full GUI odpalone

[bokk]

U mnie 3 bramki od 11 godzin GUI Minimal bez restartu