Pomóżcie proszę początkującemu

[vajera]

No to ogólnie wygląda, że to w miarę sensownie działa
Zdarzało mi się, że gniazdko nie reagowało na polecenia (wtedy migała czasem czerwona dioda na gniazdku), ale po kilku minutach wrócił i działa dalej.

Natomiast bramka co kilka h się resetuje. Nie mam logów, bo te mi się zawieszają ;P. Teraz mam uptime 7 h, ale ogólnie nie dłuższego okresu uptime.

Na razie obserwuję dalej.

Taka propozycja - ustaw opóźnienie startu GUI np. na 120 sekund i zobacz, czy to wpłynie na uptime? Ewentualnie możesz wyłączyć automatyczne uruchamianie GUI przy starcie bramki.

[klew]

Taka propozycja - ustaw opóźnienie startu GUI np. na 120 sekund i zobacz, czy to wpłynie na uptime? Ewentualnie możesz wyłączyć automatyczne uruchamianie GUI przy starcie bramki.

Sprawdzę na razie to zasilanie, a potem wyłączę GUI.
Opóźniony start nie wiem czy coś zmieni, skoro reset jest po kilku godzinach pracy.

[vajera]

Zmień na próbę zasilanie bramki.

Zmienione i uptime spadł do 0!!!
Sprawdzamy

Przy okazji, po zmianie zasilania, parametry EM gniazdka były przez 1-2 min nieprawidłowe. Częstotliwość x4, napięcie x0.5. Tak jakby te mnożniki się za późno ustawiały.

Zgadza się, bo chciałem to zrobić "książkowo" i bramka próbuje odczytać mnożniki i dzielniki bezpośrednio z gniazdka. Może prościej będzie zapisać je na sztywno dla tego modelu, bo uaktualnienia firmware to on już raczej nie dostanie

Cieszę się, że działają - kluczem w ich przypadku okazał się wiek - po tym jak włączyłem w bramce Zigbee legacy mode przestały wypadać z sieci.
Ten sam sposób pomógł przy okazji rozwiązać problem z przyciskiem Philipsa (@Mario78) i przyciskami, z którymi walczył @Lector.

[vajera]

Taka propozycja - ustaw opóźnienie startu GUI np. na 120 sekund i zobacz, czy to wpłynie na uptime? Ewentualnie możesz wyłączyć automatyczne uruchamianie GUI przy starcie bramki.

Sprawdzę na razie to zasilanie, a potem wyłączę GUI.
Opóźniony start nie wiem czy coś zmieni, skoro reset jest po kilku godzinach pracy.

Mam taką obserwację, że jeżeli GUI wystartuje z opóźnieniem, to kolejne połączenia SSL mają zapas pamięci??? Jeżeli startuje od razu, to któraś z rzędu próba SSL handshake wywala błąd o braku pamięci.
Niestety Supla często robi reconnect, np. po większości zmian w Cloud - nawet jeżeli dotyczą innych urządzeń.

[klew]

Mam taką obserwację, że jeżeli GUI wystartuje z opóźnieniem, to kolejne połączenia SSL mają zapas pamięci??? Jeżeli startuje od razu, to któraś z rzędu próba SSL handshake wywala błąd o braku pamięci.
Niestety Supla często robi reconnect, np. po większości zmian w Cloud - nawet jeżeli dotyczą innych urządzeń.

Nawiązanie połączenia ssl z reguły około 20-30 kB RAM-u potrzebuje.
Nie rozumiem związku opóźnionego startu GUI z ogólnie dostępną ilością pamięci. Mierzyłeś to? Jakie są różnice?

[vajera]

Mam taką obserwację, że jeżeli GUI wystartuje z opóźnieniem, to kolejne połączenia SSL mają zapas pamięci??? Jeżeli startuje od razu, to któraś z rzędu próba SSL handshake wywala błąd o braku pamięci.
Niestety Supla często robi reconnect, np. po większości zmian w Cloud - nawet jeżeli dotyczą innych urządzeń.

Nawiązanie połączenia ssl z reguły około 20-30 kB RAM-u potrzebuje.
Nie rozumiem związku opóźnionego startu GUI z ogólnie dostępną ilością pamięci. Mierzyłeś to? Jakie są różnice?

Zrobię profesjonalny benchmark w wolnym czasie, ale teraz moje praktyczne doświadczenia

Kluczem jest bramka z dużą liczbą kanałów Supla (15-20). W takiej konfiguracji zaobserwowałem fakt, że pierwsze połączenie SSL przechodzi a kolejne wyrzucają błąd o braku wolnej pamięci.
Wydaje mi się, że ma to związek z pofragmentowaniem sterty? - to ESPUI używa intensywnie std::string i przy budowaniu kontrolek muszą się chyba robić dziury w stercie?
Niestety Arduino-core nie ma żadnych funkcji monitorowania alokacji i dealokacji sterty a ja nie mam czasu na samodzielną kompilację całego pakietu.

W wolnej chwili przejrzę jeszcze raz kod ESPUI i spróbuję go zoptymalizować, ale i tak jestem zadowolony, że udało mi się wtedy naprawić ten błąd z przesyłaniem dużej ilości danych.

I teraz moja prywatna hipoteza robocza - alokator RTOS przydziela bloki pamięci na stercie w średnio zoptymalizowany sposób - jeżeli GUI startuje zbyt wcześnie (???) to "szatkuje" stertę jak kapustę i SSL nie może później zaalokować tych 20-30k w sposób ciągły - zresztą widać to po tym parametrze MaxAllocHeap. Może kluczem jest to, że przy wczesnym starcie GUI nie są jeszcze zwolnione jakieś bloki po starcie Supla/Zigbee?

[vajera]

Tak dla porównania:

GUI uruchomione ręcznie (po kilku minutach pracy):

Code: Select all

Flash chip real size: 8388608 B | Free Sketch Space: 3407872 B
HeapSize: 358620 B | FreeHeap: 72360 B | MinimalFreeHeap: 61188 B | MaxAllocHeap: 51188 B
uxTaskGetStackHighWaterMark: 3224 B 
Total PSRAM: 0 B | Free PSRAM: 0 B

Local time: Wed Sep 24 12:44:06 2025
Supla uptime: 4920 s

GUI uruchomione podczas startu bramki:

Code: Select all

Flash chip real size: 8388608 B | Free Sketch Space: 3407872 B
HeapSize: 358620 B | FreeHeap: 75924 B | MinimalFreeHeap: 8280 B | MaxAllocHeap: 50164 B
uxTaskGetStackHighWaterMark: 3224 B 
Total PSRAM: 0 B | Free PSRAM: 0 B

Local time: Wed Sep 24 13:06:59 2025
Supla uptime: 1200 s

W tym porównaniu parametr MaxAllocHeap jest praktycznie identyczny - bramka ma tylko 8 kanałów. Natomiast widać ogromną różnicę w MinimalFreeHeap i tutaj upatruję potwierdzenia swojej hipotezy - brak opóźnienia powoduje, ze GUI zajmuje stertę, gdy są na niej jeszcze niezwolnione bloki pamięci po inicjalizacji Supla i/lub stosu Zigbee i w skrajnych przypadkach prowadzi to do nadmiernej fragmentacji sterty.
Ciekawostka - nawet przy braku opóźnienia i włączonym automatycznym uruchomieniu GUI zaczyna się budować dopiero gdy Supla ma status registered and ready a stos Zigbee wystartował. Prawdopodobnie RTOS mimo wszystko nie nadąża wtedy ze zwolnieniem pamięci na stercie.

[klew]

Bramka się zresetowała. Także teraz kolejny test z wyłączonym GUI

Przy okazji - gniazdko miałem włączone. Po resetach bramki, gniazdko pozostało włączone, ale w Supli było pokazane jako "wyłączone". EM raportował już dane poprawnie, więc jakaś komunikacja była.
Wydaje mi się, że wcześniej przy błędach komunikacji widziałem też taki stan, że w Supli gniazdko zmieniało stan po naciśnięciu przycisku w apce, ale fizycznie gniazdko się nie przełączało (bo nie było komunikacji z jakiegoś powodu).
Wg mnie stan gniadka powinien się aktualizować wyłącznie na podstawie stanu odczytanego z gniazdka, a nie pod wpływem poleceń z serwera. Jeśli tam jest VirtualRelay, to to by mogła być przyczyna tego, moim zdaniem, błędnego zachowania.

[Zibi_007]

Mam taką obserwację, że jeżeli GUI wystartuje z opóźnieniem, to kolejne połączenia SSL mają zapas pamięci??? Jeżeli startuje od razu, to któraś z rzędu próba SSL handshake wywala błąd o braku pamięci.
Niestety Supla często robi reconnect, np. po większości zmian w Cloud - nawet jeżeli dotyczą innych urządzeń.

Nawiązanie połączenia ssl z reguły około 20-30 kB RAM-u potrzebuje.
Nie rozumiem związku opóźnionego startu GUI z ogólnie dostępną ilością pamięci. Mierzyłeś to? Jakie są różnice?

Zrobię profesjonalny benchmark w wolnym czasie, ale teraz moje praktyczne doświadczenia

Kluczem jest bramka z dużą liczbą kanałów Supla (15-20). W takiej konfiguracji zaobserwowałem fakt, że pierwsze połączenie SSL przechodzi a kolejne wyrzucają błąd o braku wolnej pamięci.
Wydaje mi się, że ma to związek z pofragmentowaniem sterty? - to ESPUI używa intensywnie std::string i przy budowaniu kontrolek muszą się chyba robić dziury w stercie?
Niestety Arduino-core nie ma żadnych funkcji monitorowania alokacji i dealokacji sterty a ja nie mam czasu na samodzielną kompilację całego pakietu.

W wolnej chwili przejrzę jeszcze raz kod ESPUI i spróbuję go zoptymalizować, ale i tak jestem zadowolony, że udało mi się wtedy naprawić ten błąd z przesyłaniem dużej ilości danych.

I teraz moja prywatna hipoteza robocza - alokator RTOS przydziela bloki pamięci na stercie w średnio zoptymalizowany sposób - jeżeli GUI startuje zbyt wcześnie (???) to "szatkuje" stertę jak kapustę i SSL nie może później zaalokować tych 20-30k w sposób ciągły - zresztą widać to po tym parametrze MaxAllocHeap. Może kluczem jest to, że przy wczesnym starcie GUI nie są jeszcze zwolnione jakieś bloki po starcie Supla/Zigbee?

Obserwowałem podobne zachowania i Twoja hipoteza o tym, że "styrta się pali" może być słuszna
Mam też propozycję. Włącz opóźnienie startu GUI po starcie/restarcie bramki. Niech zostanie te 180s., gdzie i tak zawsze włącza się tryb parowania. Ja to bym nawet poszedł o krok dalej i zrobił coś, co do czego nie byłem jeszcze do niedawna przekonany. Wyłącz GUI podczas normalnej pracy, a niech się włącza tym 5 x boot albo z clouda po następnym resecie. Może to nie jest "eleganckie" rozwiązanie, ale za to jeśli będzie skuteczne, to czego chcieć więcej?

[klew]

Na wyłączonym GUI mam uptime 20 h. To jak na razie rekord . Dam mu jeszcze trochę czasu zanim zacznę coś zmieniać.