Control Offline - problemy z GUI [bramka Zigbee]

[klew]

Mała ankieta w tym temacie: https://docs.google.com/forms/d/e/1FAIp ... usp=dialog

Potwierdzenie wypełnienia i wysłania ankiety nie przyjdzie na e-mail, bo wyłączyłem zbieranie adresów e-mail (RODO).

ile tam punktów

Tam są dwa pytania. W pierwszym jest jednokrotny wybór, a w drugim można wybór wielokrotny. Drugie pytanie jest opcjonalne

Może, jeśli ktoś wie co te wszystkie podpunkty oznaczają, to jest to proste:D

[Robert Błaszczak]

To jeszcze parę słów wyjaśnienia, dlaczego "staję trochę przysłowiowym okoniem" przy niektórych pomysłach.

1. Największą siłą projektu Supla jest prostota obsługi. Nie rozmawiałem co prawda nigdy w tym temacie z Przemkiem, ale mogę się założyć, że jest to jeden z najważniejszych celów projektu Supla. Oczywiście bramka Z2S nie jest oficjalnym projektem, ale powinna się wpisywać w trend prostoty obsługi i być spójna z urządzeniami oficjalnymi.

2. O bezpieczeństwie GUI podczas pracy bramki już pisałem wcześniej - brak jest jakichkolwiek zabezpieczeń, więc nawet z tego powodu GUI Z2S powinno być domyślnie wyłączone (takie samo zdanie przedstawił kilka postów wyżej Zbyszek @Zibi_007).

3. Bramka ma być przede wszystkim bramką dla urządzeń Zigbee. Angażowanie zasobów sprzętowych ESP32-C6 choćby w działanie GUI jest zbędne i może powodować problemy. A wiemy, że WEBServer zabiera z czasem działania sporo zasobów bramki.

4. Wszelkie dodatkowe funkcjonalności, jakie są oprogramowane przez Łukasza w bramce Z2S (np. Local actions) powinny być docelowo przeniesione do konfigurowania poprzez Cloud, tak aby zachować spójność projektu Supla. Tu bramka Z2S - mam nadzieję - jest motorem rozwoju dla Supli .

5. Jak już Łukasz @vajera doda wszystkie urządzenia Zigbee wyprodukowane przez Chińczyków i będzie dysponował nadmiarem czasu, to można wtedy zająć się takimi tematami

[lukasz06]

Wiem, że zaraz mnie tu większość zakrzyczy, ale ja uważam, że bramka Z2S ma być pośrednikiem w adopcji urządzeń Zigbee do systemu Supla. I to jest jej najważniejszy i nadrzędny cel. A serwowanie GUI podczas pracy ze zbędnymi listami wyboru i innymi wodotryskami zajmującymi cenne zasoby sprzętowe ESP32-C6, jest tematem drugoplanowym i w mojej ocenie niezbyt potrzebnym.
GUI bramki Z2S jest doskonałą funkcjonalnością, ale ono powinno być włączone tylko pod potrzeby konfiguracji i wyłączone podczas normalnego działania bramki.
Ps. Niech ktoś ze zwolenników GUI podczas pracy napisze mi, w jakim celu musi to mieć włączone na stałe. Bardzo mnie ciekawią Wasze argumenty.

Zwolenników GUI podczas pracy chyba nie będzie Ale też powiem co o tym sądzę. Jeśli Robert nawiązałeś do wcześniejszych wypowiedzi to mi osobiście się wydaje że @lukasz06 to zaproponował tylko inną formę wyboru ewentualnej potrzebnej lub potrzebnych zakładek po starcie bramki. Zastrzegł też by w przypadku narażenia zasobów bramki nie skupiać się na tym. Pomysł nie jest zły sam w sobie... opcja wyboru wielokrotnego. A czy to uszczupliło by zasoby bramki, czy ma ochotę na taką zmianę to już w sumie decyzja "głównego inżyniera". Osobiście również uważam że jeśli coś miało by być tylko zmienione kosmetycznie, a wybór GUI przecież mamy i zabierało by jakieś zasoby to bym nie był za tym i nigdy nie byłem nawet w przypadku UPDATE. Choć jak teraz korzystam to pierwsze wrażenie po otwarciu to że fajna i fajnie że jest.
Sam fakt czy ktoś sobie zostawi miniGUI czy extended_gui_mode to i tak dyskusja tego nie zmieni. Jak ktoś wie że za pół godziny będzie potrzebował wejść na bramkę żeby coś zmienić w ustawieniach, poprawić itp to zostawi GUI włączone. Jak ktoś zakończy etap ustawień to wyłączy GUI z nadzieją że szybko nie będzie potrzebne.
Generalnie fajnie że możemy o tym podyskutować bo to oznacza że w bramce jest wiele rzeczy, a ilu użytkowników to każdy może mieć własne sposoby ich wykorzystywania i różne do tego własne opinie.

Dokładnie jest tak jak piszesz.
Przecież sam szef pytał, czy ktoś by chciał aby dodać jakąś zakładkę na starcie. Ja używam Gui dużo, głównie do diagnostyki jakiś problemów, ostatnio wyłączający się termostat.
Ale spoko, nie ma tematu, to była tylko propozycja aby ułatwić Łukaszowi, bo jak co chwilę ktoś będzie prosił że chce na starcie to czy tamto, to pomyślałem, żeby samemu sobie mógł zdecydować i tym.
Druga sprawa, to jakby te ustawienia przenieś do Cloud to bramkę można by było trochę odchudzić

[zzrr]

.....
5. Jak już Łukasz @vajera doda wszystkie urządzenia Zigbee wyprodukowane przez Chińczyków i będzie dysponował nadmiarem czasu, to można wtedy zająć się takimi tematami

Aaaa.... co jak co ale punkt 5 mnie osobiście przekonał

[zzrr]

Mała ankieta w tym temacie: https://docs.google.com/forms/d/e/1FAIp ... usp=dialog

Potwierdzenie wypełnienia i wysłania ankiety nie przyjdzie na e-mail, bo wyłączyłem zbieranie adresów e-mail (RODO).

Świetna zabawa Oczywiście ankieta wypełniona.

[Zibi_007]

Mała ankieta w tym temacie: https://docs.google.com/forms/d/e/1FAIp ... usp=dialog

Potwierdzenie wypełnienia i wysłania ankiety nie przyjdzie na e-mail, bo wyłączyłem zbieranie adresów e-mail (RODO).

Wypełniłem, ale z doświadczenia wiem, że te ankiety niewiele wnoszą.
Lepiej dać się tutaj wypowiedzieć ludziom, co i tak robimy

[Zibi_007]

To jeszcze parę słów wyjaśnienia, dlaczego "staję trochę przysłowiowym okoniem" przy niektórych pomysłach.

1. Największą siłą projektu Supla jest prostota obsługi. Nie rozmawiałem co prawda nigdy w tym temacie z Przemkiem, ale mogę się założyć, że jest to jeden z najważniejszych celów projektu Supla. Oczywiście bramka Z2S nie jest oficjalnym projektem, ale powinna się wpisywać w trend prostoty obsługi i być spójna z urządzeniami oficjalnymi.

2. O bezpieczeństwie GUI podczas pracy bramki już pisałem wcześniej - brak jest jakichkolwiek zabezpieczeń, więc nawet z tego powodu GUI Z2S powinno być domyślnie wyłączone (takie samo zdanie przedstawił kilka postów wyżej Zbyszek @Zibi_007).

3. Bramka ma być przede wszystkim bramką dla urządzeń Zigbee. Angażowanie zasobów sprzętowych ESP32-C6 choćby w działanie GUI jest zbędne i może powodować problemy. A wiemy, że WEBServer zabiera z czasem działania sporo zasobów bramki.

4. Wszelkie dodatkowe funkcjonalności, jakie są oprogramowane przez Łukasza w bramce Z2S (np. Local actions) powinny być docelowo przeniesione do konfigurowania poprzez Cloud, tak aby zachować spójność projektu Supla. Tu bramka Z2S - mam nadzieję - jest motorem rozwoju dla Supli .

5. Jak już Łukasz @vajera doda wszystkie urządzenia Zigbee wyprodukowane przez Chińczyków i będzie dysponował nadmiarem czasu, to można wtedy zająć się takimi tematami

Widzisz i to jest konkretna argumentacja, w moim odczuciu lepsza od ankiety.
I dobry przyczynek do dalszej dyskusji.

[KrzysztofS]

Mała ankieta w tym temacie: https://docs.google.com/forms/d/e/1FAIp ... usp=dialog

Potwierdzenie wypełnienia i wysłania ankiety nie przyjdzie na e-mail, bo wyłączyłem zbieranie adresów e-mail (RODO).

Wypełniłem i chciałbym jeszcze coś dodać, ponieważ brakuje mi w tej ankiecie miejsca na komentarz.
Jestem zwykłym użytkownikiem tej bramki. Dodaję urządzenie i zapominam. Czasem zmienię czas raportowania.
Czasem zajrzę na Forum do działu Zigbee aby zobaczyć co jest nowego.
A tam czytam:

@vajera - dodaj mi funkcję SperDustBustMaxEnergy do VB. Nie powiem po co i dlaczego ale jak zadziała to sobie wykorzystam i może się pochwalę. No i nie zapomnij uwzględnić tego w logice bo może kiedyś skorzystam

Cytat wyżej jest z głowy, nie mam na myśli nikogo konkretnego. Pokazuję tylko, gdzie leży problem.
@vajera dodaje taką funkcję, korzysta, a może i nie, jeden użytkownik, trudno znaleźć jakiś opis tej funkcji na Forum, co w efekcie powoduje, że nikt o niej nie wie.
Po to są chyba dostępne źródła, że jak ktoś bardzo potrzebuje jakiejś niszowej funkcji to sobie może dodać. Jak nie wie jak to dopytaj wtedy autora.
Kolejne takie prośby robią moim skromnym zdaniem z kodu bramki śmietnik. Siedzę trochę w różnych projektach i widziałem na własne oczy jak niejeden super obiecujący projekt został tak zabity.
Wiem, że moje zdanie liczy się tu najmniej, ale skoro jest taka dyskusja, to się wypowiadam. A teraz sobie na mnie poużywajcie

[zzrr]

......
A tam czytam:

@vajera - dodaj mi funkcję SperDustBustMaxEnergy do VB. Nie powiem po co i dlaczego ale jak zadziała to sobie wykorzystam i może się pochwalę. No i nie zapomnij uwzględnić tego w logice bo może kiedyś skorzystam

Cytat wyżej jest z głowy, nie mam na myśli nikogo konkretnego. Pokazuję tylko, gdzie leży problem.
@vajera dodaje taką funkcję, korzysta, a może i nie, jeden użytkownik, trudno znaleźć jakiś opis tej funkcji na Forum, co w efekcie powoduje, że nikt o niej nie wie

No to w końcu czytasz czy to z głowy? Bo to ciekawe co napisałeś.

[vajera]

Uwaga - poniżej oryginalna wiadomość, którą napisałem między 19 a 20, ale nie zdążyłem jej wysłać - zaraz napiszę dlaczego ...

Czytam sobie przez cały dzień tę dyskusję, więc na dobranoc postanowiłem się z Wami podzielić moją dzisiejszą przygodą

Problemy z pamięciożernością GUI występują już od dłuższego czasu i dosyć szybko odkryłem, że są proporcjonalne do liczby zakładek, stąd powtarzane często zalecenia unikania FullGUI, wprowadzenie opóźnienia startu GUI itp.

Muszę przyznać, że cały czas miałem z tyłu głowy ten problem i próbowałem go rozwiązać - niestety zewnętrzna biblioteka ESPUI przerosła mnie i długo nie byłem w stanie ustalić, gdzie jest źródło problemu...aż do dzisiaj.

Zacząłem bardzo szczegółowo analizować kod i zużycie pamięci na poszczególnych etapach budowania FullGUI - nie będę wchodził w szczegóły, ale ostateczny wnioski były następujące:

- ESPUI dla każdej kontrolki HTML (etykieta, przycisk, przełącznik, lista) generuje obiekt Control,

- rozmiar pojedynczego obiektu Control 120 bajtów - pikuś ...ale

- FullGUI ma 470 kontrolek = 56 kB! pamięci RAM na same obiekty Control,

- dodatkowo twórca ESPUI "poszedł na łatwiznę" i zrobił te kontrolki na obiektach typu String a to są bardzo pamięciożerne struktury,

- ostatecznie, to wszystko powodowało, że samo zbudowanie struktur FullGUI - bez wysyłania danych HTML itp. zajmowało...80 kB...DRAMAT...

Przysiadłem na kodem tego ESPUI i systematycznie przerabiałem String na const char*, co wcale nie było takie proste, ale... rozmiar Control z 120 bajtów zszedł na 64 bajty.

Podsumowując - po moich dzisiejszych przeróbkach biblioteki ESPUI - GUI wydaje się pracować znacznie lepiej, również w opcji FULL, natomiast wciąż jeszcze widzę przestrzeń do optymalizacji tej biblioteki.