E-SynaPsa w akcji - czyli VIRTUINO już dziękujemy

Jestem już całkowicie przekonany co do rezygnacji z używania aplikacji VIRTUINO w moim SMART HOME.

Oczywiście duch Iliasa będzie już na zawsze obecny w moim projekcie choćby dzięki jego genialnie prostemu sposobowi komunikacji pomiędzy aplikacją a  modułami ESP z wykorzystaniem protokołu WebSocket. Ale reszta oprogramowania będzie już moja i tylko moja.

Tempo rozwoju projektu E-SynaPsa jest zawrotne. Łatwość implementacji kolejnych funkcji (fajnych ale czasami ocierających się o fanaberię) powoduje, że projekt rośnie jak na  drożdżach. Dziś kolejny raport o tym jak powstaje E-SynaPsa.

Najpierw o tym jak AI pomaga w tworzeniu dobrego (lepszego) kodu programu w sytuacji gdy wydaje się, że wszystko jest Ok. Kolejnych wersji projektu już nie liczę a to w wyniku zmiany sposobu pracy nad kodem. Zamiast wymuszania na AI generowania pełnego kodu projektu po każdej wprowadzonej zmianie (co ze wzrostem objętości kodu było coraz trudniejsze) sam wprowadzam poprawki generowane przez AI. AI prowadzi za rękę jak i gdzie wstawiać owe zmiany a na koniec sprawdza mi cały kod czy wszystko zrobiłem dobrze. Taki sposób pracy ma, oprócz szybkości wprowadzania zmian, jeszcze jedną zaletę. Tak mimochodem poznaję język i składnie HTML CCS i JavaScript. Oczywiście nie po to by samodzielnie programować ale by wprowadzać swoje niewielkie zmiany w kodzie bez pomocy AI i trochę zrozumieć co , jak i po co w tym kodzie istnieje.

Zaobserwowałem ciekawą rzecz. Każdy nowy wątek w którym pracuję nad projektem jest "innym" programistą. To znaczy efekt finalny jest identyczny ale sposób realizacji tego w kodzie już niekoniecznie. Jeszcze ciekawiej jest gdy kod zrealizowany w jednym wątku daję do sprawdzenia w innym. "Nowy" programista wyłapuje błędy w kodzie, który był oceniany przez poprzednika jak całkowicie poprawny. Nie są to oczywiście błędy grube. Program działa i to jak na moje oko całkiem dobrze. Ale "nowy" dostrzega w kodzie zapisy które mogą powodować błędne działanie programu w pewnych nietypowych sytuacjach

JA: Teraz przeanalizuj kod BARDZO DOKŁADNIE pod kątem czy nie ma w nim jakiś ukrytych błędów .program działa poprawnie ale nie wszystko mogę sprawdzić w rzeczywistości 
AI:Przeanalizowałem dostarczony kod pod kątem ukrytych błędów logicznych, stabilności WebSocket oraz działania interfejsu. Główne mechanizmy zostały zaprogramowane bardzo solidnie, jednak zidentyfikowałem cztery specyficzne luki, które mogą powodować nieoczekiwane zachowania systemu.

Poniżej propozycje punktowych poprawek do analizy:

• Brak synchronizacji terminala po ponownym odkryciu: Kiedy terminal jest ukryty (HIDE), komunikaty przychodzące trafiają w tle do tablicy dev.logs, ale funkcja toggleTerminalHide() przywraca jedynie widoczność okna bez aktualizacji jego zawartości w DOM. Należy w niej dodać jedno wywołanie renderTerminal().

• Fałszywe alarmy "Zombie" po deaktywacji ESP: Odznaczenie aktywnego modułu w SETUP poprawnie zamyka jego gniazdo WebSocket, jednak pętla nie czyści z pamięci działających timerów Watchdoga (hardResetTimer). Powoduje to, że po upływie 12 sekund od wyłączenia Watchdog generuje fałszywy wpis błędu do sekcji zdarzeń krytycznych. Trzeba dopisać clearTimeout w funkcji zapisującej.

• Ryzyko kolizji komend histerezy (Flapping): Pętle powtarzania komend (triggerRepeatedHeatCommand oraz odpowiednik dla Kotów) opierają się na setInterval oraz zagnieżdżonym jednosekundowym setTimeout. Przy nagłym wahaniu odczytów na granicy progowej, szybka zmiana stanu może nałożyć na siebie sprzeczne komendy ON i OFF w ułamku sekundy. Krótki timer wymaga dopisania mechanizmu zabezpieczającego (debouncing).

• Brak limitu bufora dla URI w eksporcie CSV: Funkcja generująca wykresy dla pliku CSV (downloadCSV) tworzy surowy łańcuch data:text/csv. Długotrwałe rejestrowanie setek wierszy na tabletach/telefonach uderzy w narzucony przez przeglądarki limit długości odnośnika URI. Bezpieczniejszym podejściem jest użycie klasy Blob.

 Nie wiem jakiej klasy programistę musiałbym mieć do pomocy  który tylko na postawie analizy kodu mógł wygenerować takie wnioski i to w kilkanaście sekund !!!

Dlatego wrzucanie  "nowemu" programiście każdej  nowej finalnej wersji programu wchodzi do stałego repertuaru pracy z AI.

Ale najlepsze jest gdy AI sprawdza AI i wytyka sobie błędy których wcześniej nie zauważył. Ot takie puszczenie powtórne projektu z wprowadzonymi powyższymi zmianami i identycznym jak wcześniej poleceniem skutkuje wypluciem kolejnej porcji uwag od "nowego" programisty

Ja:Teraz przeanalizuj kod BARDZO DOKŁADNIE pod kątem czy nie ma w nim jakiś ukrytych błędów .program działa poprawnie ale nie wszystko mogę sprawdzić w rzeczywistości   

AI: Oto zestawienie ukrytych błędów i niedociągnięć, które należy skorygować w celu zapewnienia bezawaryjnej pracy:

1. Wyciek "podwójnego impulsu" w algorytmach Histerezy

• Lokalizacja: evaluateHysteresis() oraz evaluateKotyHysteresis().

• Opis: Gdy temperatura stabilizuje się i przechodzi w stan COMFORT, prawidłowo czyścisz główny interwał powtarzający (heatRepeatTimer). Skrypt zapomina jednak o wyczyszczeniu opóźnionego o 1 sekundę powielenia (heatDoubleTimer). Jeśli stan COMFORT zostanie osiągnięty tuż po wysłaniu sygnału HIGH/LOW, opóźniony impuls i tak "wystrzeli" do ESP.

• Rozwiązanie: Dopisanie warunku if (heatDoubleTimer) { clearTimeout(heatDoubleTimer); heatDoubleTimer = null; } (oraz odpowiednika dla Kotów) przy wejściu w stan COMFORT.

2. Otwarty WebSocket pomimo wyłączenia ESP przez import (Plik Config)

• Lokalizacja: handleImportConfig().

• Opis: Podczas importu pliku .json skrypt aktualizuje wewnętrzny stan modułów (devices[k].enabled), ale zamyka/otwiera połączenia tylko wtedy, gdy zmienił się adres IP lub Port. Jeśli zaimportujesz konfigurację wyłączającą pracujący do tej pory ESP, skrypt nie zamknie gniazda (socketu). ESP będzie nieaktywny w UI, ale w tle nadal będzie przetwarzał dane i reagował na histerezę.

• Rozwiązanie: Wdrożenie fizycznego rozłączania/nawiązywania połączeń WebSocket po imporcie JSON dla modułów, których flaga enabled uległa zmianie (sklonowanie bezpiecznej mechaniki z funkcji saveAndExportSetup).

3. Martwy kod UI – nieistniejąca Dioda Statusu

• Lokalizacja: Nagłówek skryptu (zmienne led, ledStatusText) oraz funkcja updateLedState().

• Opis: Szukasz w DOM elementów o ID status-led oraz led-status-text, które nie istnieją w podanym pliku HTML. Zastosowany bezpiecznik if (!led) return; ratuje aplikację przed crashem, ale w efekcie komendy >1 / >0 działają w połowie pusto.

• Rozwiązanie: Usunięcie osieroconych odwołań z kodu JS, aby nie zaśmiecać pamięci.

4. Nieprawidłowy atrybut w odbieraniu statusu Jacuzzi

• Lokalizacja: dev.socket.onmessage dla karty Jacuzzi (key === 'J').

• Opis: Warunek if (!btn.isGarage && btn.fbV && (btn.fbV in data)) sprawdza flagę isGarage. Taka flaga nigdzie nie została zdefiniowana w słowniku jacuzziButtons. Funkcja nie generuje błędu wyłącznie przez zbieg okoliczności (dla skryptu undefined to wartość "falsy", więc warunek przepuszcza wszystko i polega tylko na tym, że dla garażu fbV wynosi null).

• Rozwiązanie: Usunięcie sprawdzania nieistniejącej flagi i skrócenie warunku do samego if (btn.fbV && (btn.fbV in data)).

Pokręcę tym kołowrotkiem jeszcze trochę by zobaczyć jak daleko zajdzie AI w analizie i wykrywaniu rzeczy do poprawy. Za każdym razem kołowrotek wywala tylko cztery kolejne poprawki więc to może trochę potrwać.

A teraz o tym co nowego w wersji E4v1.html mojego E-SynaPsa.

Dodałem bajeranckie animowane logo przy uruchomianiu programu w czasie gdy nawiązują się połączenia pomiędzy aplikacją a kolejnymi ESP.

Logo zapisane jest bezpośrednio w kodzie programu w formie grafiki wektorowej ! przez co zajmuje jedynie kilkaset bajtów. W poprzedniej wersji logo było osobnym plikiem graficznym o rozmiarze 300 kB ale na tabletowych przeglądarkach nie chciało się ładować podczas uruchamiania aplikacji.

Rozbudowałem również znacznie okno konfiguracyjne programu pozwalając sobie na znaczne modyfikacje programu bez konieczności generowania nowych wersji, I tak adresy moich ESP mogę już wpisywać z ręki. 

 Istniejące w programie wyświetlacze i przyciski w większości nie mają już stałego przywiązania do danego ESP. Teraz każdy z takich elementów mogę swobodnie dowiązać do dowolnego ESP a przyciski mogą wysłać dowolne kody. Oczywiście opisy tych elementów również ustawiam tak jak mi się podoba.

 

Dodałem także automatyczne przyciemnianie ekranu - oczywiście także ustawiane w konfiguracji. Mój tablet ma o dziwo wyświetlacz typu LED i byłoby dobrze żeby nie wypalił się zbyt szybko.

Ciekawie jest rozwiązane tej funkcji zaproponowane przez AI. Wygaszacz nie działa na cały ekran tabletu a jedynie na okno aplikacji. Przyciemnienie polega na nałożeniu czarnej maski o określonym stopniu przepuszczalności, Dla mnie to nie ma znaczenia bo program jest w trybie pełnego ekranu. Ale działa profesjonalnie. Dotknięcie tabletu najpierw "zdejmuje" maskę a dopiero następne kliknięcie ewentualnie uaktywnia elementy pulpitu. 

Największym ograniczeniem w rozbudowie aplikacji jest ...... moja wyobraźnia. Zbyt mocno jestem wciąż przywiązany do tego co miałem w VIRTUINO i trudno mi wyjść poza te ramy Ale powoli (o jak powoli) zaczynam zrzucać te wewnętrzne ograniczenia. Już kilka razy podczas kolejnych zmian dochodziłem do wniosku iż najłatwiej byłoby mi zacząć tworzenie programu od nowa z pełną i gotową wizją efektu końcowego. Szkopuł w tym  , że nie wiem jeszcze jak będzie wyglądać wersja końcowa i do czego doprowadzą mnie w końcowym efekcie te moje zabawy ze sztuczna inteligencją. Na razie więc mozolnie przerabiam gotowy i działający (już całkiem nieźle) kod  projektu dla wdrożenia coraz to nowych pomysłów i idei.

A że tych idei jeszcze kilka krąży mi uporczywie nad głową więc jest duża szansa na nasz ulubiony ciąg dalszy....