Incident 25/09 11:49 : l'agent sans source avait invente 0,56 kWh / zero
reseau / 35 % pour une nuit a 7,9 kWh dont 2,2 reseau. donneesNuit() extrait
de rapport-nuit.mjs (texte identique sur 5 nuits), publie pour l'agent.
Tests 37/37.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
sensor.evcs_production_jour_kwh (somme des 3 yield_today, remises a zero
decalees gerees) et sensor.evcs_charge_solaire (relais de la decision du
controleur, pas un second arbitre). Tests 26/26 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
La fiche OpenClaw basculait G5 de 7/7 a 1/7 sur un ajout sans rapport :
les deux jugements sortent du modele. sensor.evcs_pv_diagnostic (import
teste avant bridage) et sensor.evcs_cellules (perime => aucune valeur
visible), publies meme quand le cycle echoue. Tests 15/15 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Les trames BMS cellule de HA sont mortes depuis le 15/09 ; le relevé série est la
source vivante. Le service publie evcs_cell_spread_max_mv, evcs_cell_weakest_module
et evcs_cell_releve_age_min à chaque cycle (publierCellulesHelpers). L'âge donne à
l'agent la discipline anti-valeur-figée (comme le gel GX). Vérifié en réel :
21 mV, âge 1 min, K220803C30160323. Package evcs_cellules.yaml (hors dépôt, HA).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le HANDOFF chargé à chaque session pesait 7566 lignes. Split vérifié par md5 :
§1→§72 (09/07→17/09) déplacés SANS PERTE dans HANDOFF_ARCHIVE_2026.md (non chargé
par CLAUDE.md, grep/lecture à la demande). HANDOFF.md ne garde vivantes que les
sessions récentes §73→§77 + un index des sections archivées. Aucune info perdue,
aucun changement d'@-import nécessaire (l'archive n'est pas référencée).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
9 gammes (snapshots reels figes + attendus), 9/9 sur 3 passages. Coordination
avec SPARK : moi la verite-terrain (PostgreSQL/InfluxDB/historique HA), SPARK le
harnais et la fiche OpenClaw. G5 a echoue 0/3 au premier tour et a fait corriger
la fiche (import reseau force en controle nº1 avant de conclure bridage) ->
verrouille la distinction bridage normal / substitution. Source de verite de la
production PV dans MANUEL §0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Envoi decale 06:47 -> 07:30 : apres la fermeture de la fenetre HC (07:24)
l'import de la nuit est termine, donc le total est complet. A 06:47 le rapport
ratait l'import 06:47->07:24 meme apres le fix d'extrapolation (ec5f43e).
Proposition du proprietaire. HANDOFF §76 consigne le bug (extrapolation de la
derniere puissance sur la fenetre future), le fix et ce decalage.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le releve serie tournait sur le portable et est mort 4 jours au reboot du 20/09.
Migre sur le .17 (conteneur node + tache de boot root/sh chargeant les pilotes).
Survie prouvee de bout en bout sur reboot + saut majeur DSM 7.3.2 -> 7.4.1, qui a
revele et fait corriger deux pieges (NFS noexec, sudo passwordless efface par
l'update). @reboot du portable retire.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire ferme la question de force_grid_now — « pour moi c est pour
recharger la voiture » — et en tire le chantier : dissocier la recharge de la
batterie solaire de la fonction EVCS.
Trois pistes mesurees sur banc. La piste d un chemin separe est morte et de la
maniere la plus nette : elle ne se fait pas ecraser par accident, elle
s auto-detruit, puisqu il faudrait que le controleur la connaisse pour qu elle
tienne. La piste du forcage de la cible du bilan est retenue, mais l ENDROIT du
forcage decide de tout : force en aval, le contacteur se ferme, la session
s engage et la consigne reste a 700 W — le defaut du 01/09 a l identique, et le
seul des trois resultats indiagnosticable depuis le tableau de bord parce qu il
A L AIR de marcher.
Point d insertion identifie a une ligne pres dans coverage() : tout en derive,
donc la cible et le manque bougent ensemble par construction au lieu de
dependre d une discipline.
Trois effets consignes, dont deux qui demandent une decision : le plancher monte
aussi la cible prudente, donc la voiture cesse de descendre la batterie pendant
une charge manuelle — structurel, aucune echeance n y change rien ; et le bilan
ignore totalement les fenetres creuses, donc une cible manuelle fuit dans la
journee et bloque la charge du soir. Echeance retenue plutot que bornes : le
bilan repond a « de combien la batterie a besoin », pas a « quand est-ce bon
marche ».
Fait au passage : le courant du module entre dans le releve par cellule, ce qui
rend enfin lisible « le detail de chaque cellule PENDANT la charge ».
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le mecanisme demande par le proprietaire — « ca va pas corriger le probleme si
nous ne sommes pas devant » — est deploye et a fonctionne seul a 14:24 :
strategie rendue a auto_solar_plus, consigne ramenee de 5641 a 700 W au cycle
suivant, contacteur ouvert par l hysteresis 33 s plus tard. La demande retombe
avant que le reseau parte, sans coordination.
Ce qui manquait a force_grid_now n etait pas une interdiction mais une
echeance : la condition porte sur l instant d ENGAGEMENT, pour qu un forcage
pose un soir de cuisson afin de proteger le parc ne soit pas annule a la minute
suivante.
Et la section consigne ce que la session voisine m a fait corriger sur la
surconsigne « voiture fantome ». Trois de mes chiffres etaient faux, tous
defavorables a la correction que je defendais : l episode de midi n etait pas
un defaut (heures creuses, demande, aucune eviction — sept chargeurs en
mppt_active) ; l occurrence de six minutes du 06/09 n existe pas (source_mode
valait Solaire de bout en bout, j avais verifie les ingredients sans demander
au controleur sa decision) ; et l import de 5,87 kWh se repartit en 2,52 pour
la voiture encore branchee, 2,43 pour la batterie et 0,92 pour la maison.
La mesure sur treize jours est conservee parce qu elle sera redemandee : 88
decisions « Reseau HC autorise », toutes avec vehicule, toutes entre 1 h et
6 h, zero a midi, et session_engagee faux 85 fois sur 88 — donc
nightGridSessionCommitted ne couvre pas les nuits ordinaires.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Suite du correctif de l onglet Home Assistant. « La journee » avait le meme
angle mort : cadre sur le jour civil, il s arretait a l heure en cours.
Fenetre portee a la journee ENTIERE (dashboard() gagne un parametre `jusqu`),
serie « Encore attendu » en gris translucide a la suite des barres mesurees,
et colonne « Reste attendu » dans le bandeau du haut, a cote de « Solaire
produit ».
Sur le telephone, aucun panneau ajoute — un panneau de plus y est un ecran de
plus a faire defiler. « Soleil restant » rejoint le bandeau Maintenant, a cote
de Excedent ; « Soleil demain » rejoint La nuit qui vient, puisque c est lui
qui decide jusqu ou la batterie peut descendre.
Trois pieges, tous dans la meme direction. La mesure ne doit pas suivre la
fenetre dans le futur : ENERGIE_SQL construisait son axe entre les deux macros
puis reportait la derniere valeur connue, ce qui aurait rempli les heures a
venir avec la puissance de l instant et gonfle l energie du jour — sa borne
haute est desormais least($__timeTo(), now()). FULL OUTER JOIN et non LEFT :
une periode a venir n a aucune ligne de mesure. Et borne haute stricte, sans
quoi une barre « 18/09 00 h » apparaissait dans La journee.
L heure EN COURS n a volontairement pas de barre de prevision : elle est deja
mesuree pour ses minutes ecoulees.
73/73 requetes valides — mais ce controle prouve l execution, pas la grandeur.
Les deux requetes de La journee ont donc ete rejouees a la main avec la vraie
fenetre : 24 lignes, mesures jusqu a 02 h, prevision de 03 h a 23 h, somme des
barres 36,95 kWh contre 37,0 annonces par le bandeau. C est ce recoupement qui
a fait apparaitre le troisieme piege.
Corrige au passage la note du 08/09 sur l acces a l API Grafana : les
apostrophes du .env sont SIMPLES et non doubles, verifie a l octet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit du 16 au 17/09 : neuf arrets de la charge nuit de la VW, de 30 s a 3 min,
sans que le controleur EVCS ait bouge — sa table de decision ne porte que deux
lignes sur toute la periode. Le journal de bord de Home Assistant montre le
switch de charge passant a off SANS contexte de service, donc commande depuis
le GX, puis le controleur qui reessaie au cycle suivant.
Correlation un pour un avec les actions du chien de garde, trois secondes
avant chacune, et aucune coupure sans action. Son message porte la signature :
« CONTROLEUR MUET — derniere execution il y a NaNs ».
Cause : n8n inscrit une execution AVANT de la demarrer, avec status "new" et
startedAt null. Date.parse(null) vaut NaN, et le test !(ageSec <= 600) — forme
choisie pour echouer du cote sur — declare alors mort le controleur qui vient
precisement de demarrer un cycle. Le signal de vie retourne contre lui-meme.
La fenetre dure moins d une seconde : 3 sondages sur 968 y tombent, 0,3 %. Ce
qui a change le 16/09 n est pas le code mais la PHASE du chien de garde, qui
derive d environ vingt secondes par jour et est venue se poser exactement sur
les instants de declenchement du controleur (:00 et :30) — 34 evenements ce
jour-la contre 1 a 2 les jours precedents. Le defaut dormait depuis le 01/09.
Correction a la session precedente : la nuit du 15 au 16, presentee comme
irreprochable, portait deja trois coupures dont une de trois minutes. Ce que
j avais verifie — consigne a 6 A inchangee pendant 153 min — restait exact et
ne prouvait rien : la consigne ne bouge pas quand la borne s arrete, seule la
puissance tombe.
Second defaut, latent et plus grave : CFG.idleSetpointW valait 50 W quand le
controleur est passe a 700 W le 06/09, donc dangerousSetpoint etait vrai en
permanence et chaque fausse alerte ecrasait aussi la consigne reseau a 50 W.
Sans consequence cette nuit — EDF etait ouvert — mais pendant une nuit ou le
reseau porte la maison, c est le defaut du 04/09 reintroduit.
Trois correctifs : un horodatage manquant n est plus une panne (on prend le
plus recent startedAt exploitable, repli cote sur si aucun) ; valeur de repos
portee a 700 W avec le commentaire qui dit ou vit l autre exemplaire ; et une
panne doit DURER — deux lectures consecutives avant d agir, meme doctrine que
la tolerance batterie et le relachement du contacteur.
Verification par REJEU et non par absence de symptome : le redemarrage a remis
la phase a :07, donc une nuit calme ne prouverait rien. Un serveur local
rejouant la charge JSON exacte capturee a 02:07:01 donne, code d avant,
« MUET — il y a NaNs » et les deux ecritures ; code corrige, « controleur
vivant (execution il y a 36s) » et aucune ecriture. Le filet mord toujours sur
une panne soutenue : 1/2 puis alerte et StartStop = 0 au second cycle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit : zero bascule du contacteur, 0,00 kWh de reseau contre 14,04 la nuit
precedente, charge terminee d'elle-meme a 6,90 kWh, reserve 7,7 kWh. Le plancher
P12 n'a jamais ete touche — il est DYNAMIQUE et descend plus vite que le SOC, ce
que j'avais mal anticipe en l'annoncant fixe a 47,1 %.
Trouvaille principale : 26 entites BMS sur 32 figees depuis 31 h, alarmes
comprises, sans que rien ne le signale. Le rechargement de l'integration
rafraichit les horodatages mais pas les valeurs. Preuve par la console serie :
41 mV de divergence a 12:30. Le battement de coeur ne couvre PAS ce cas — une
entite qui republie la meme valeur reste indetectable.
Correction d'une affirmation de la journee : mon « arithmetiquement impossible »
comparait une tension de bus a des tensions de cellule sans verifier le point de
mesure. Raisonnement faux, conclusion juste, demontree autrement.
Les deux packs debitent (99,3 A et 80,7 A pour 180 A au Cerbo) ; pack 1
irreprochable a 3 mV d'ecart entre cellules. A instruire : le pack 2, plus petit
et plus vieux, prend 2,5 fois plus de courant par ampere-heure.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
En outillant la session OpenClaw, recherche du champ qui distinguerait « pas
ecrit » de « ecrit a l identique ». Home Assistant expose last_reported depuis
2024, cense marquer chaque remontee d etat meme sans changement de valeur. Il ne
sert a rien ici : mesure sur cinq entites, il est rigoureusement EGAL a
last_changed, alors que le controleur reecrit source_mode et night_target_soc a
chaque cycle de 30 s.
Consequence generale : aucun champ de l API ne distingue un ecrivain mort d un
ecrivain qui republie la meme valeur. L anciennete d une entite metier n est
donc jamais une preuve de panne. Releve sur une installation saine :
vehicle_connected inchange depuis 752 min, night_target_soc 194, source_mode
139 — trois faux positifs sur cinq entites.
Regle adoptee avec OpenClaw : la vivacite se lit sur un battement de coeur dedie
dont l etat est un horodatage, seule entite dont l immobilite soit
interpretable. Les entites metier se lisent pour leur VALEUR, jamais pour leur
fraicheur. « inchange depuis X » est un fait, « fige » est un verdict.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
L'enquete sur une reponse fausse du concierge (« 12,1 kWh absorbes cette nuit »,
alors que la voiture en avait pris 3,18) l'a etabli par recoupement :
gx_device_pv_energy valait 29,136 quand la production mesuree de la veille etait
29,13 kWh. Ce sont des compteurs JOURNALIERS ; les sauts negatifs de plusieurs
centaines de kWh sont leur remise a zero vue comme un delta. Ma note du 04/09
les disait « corrompus », c'etait faux — la conclusion pratique, elle, tient.
Le piege qui a produit l'erreur est ailleurs : ils se FIGENT. A 01:32,
dc_battery_charge_energy portait encore la valeur de la veille 17:31:50.
Regle generale ajoutee : verifier last_changed avant de citer une valeur comme
actuelle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire a demande la creation du role. Il existait deja, avec exactement
les deux SELECT du contrat (session_charge, evenement) et aucun droit
d'ecriture. Mon affirmation « toujours pas cree », repetee deux fois dans la
nuit dont une dans un message a la session OpenClaw, etait fausse.
Ce qui manquait n'etait pas le role mais son MOT DE PASSE : absent du .env du
projet, de celui de la pile d'historisation, et des variables du conteneur
openclaw-gateway. Un identifiant que personne ne connaissait.
Renouvele, range dans AIRTRIA_RO_PASSWORD (.env du projet, ignore par git), avec
CONNECTION LIMIT 5 pour qu'un agent emballe ne puisse pas epuiser le pool.
Verifie par 14 essais depuis le poste : SELECT autorise sur session_charge et
evenement, refuse sur les sept autres tables, et refuse pour INSERT, UPDATE,
DELETE, CREATE TABLE et la lecture de pg_authid. Acces reseau confirme :
pg_hba porte host all all all scram-sha-256, et 5433 est joignable depuis
10.10.10.17.
⚠️ ET LE RENOUVELLEMENT A CASSE LE CONCIERGE. La session OpenClaw a repondu
quelques minutes apres qu'elle EST codee pour se connecter en airtria_ro et
qu'elle avait lu evenement le soir meme. Ma verification ne regardait que
Config.Env du conteneur, pas son code : j'ai conclu « rien ne l'utilise » d'une
absence de preuve.
LECON : avant de renouveler un identifiant, l'absence de trace la ou JE range
mes secrets ne prouve pas qu'il est inutilise. Le seul test concluant etait de
demander a l'utilisateur presume — ici une session pair joignable en une minute.
Le nouveau mot de passe ne transite pas par un message d'agent a agent : c'est
au proprietaire de le remettre a OpenClaw.
MANUEL : capacite des vehicules, reference mesuree au compteur de la borne.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne l idee du proprietaire et le calcul qui la fonde, le verrou
anti-oscillateur trouve en construisant, et surtout la contrainte decouverte a
05:30 en conditions reelles : P12 doit gagner le premier cycle de la nuit. Si la
reprise reseau s engage avant lui, le verrou anti-creneaux de juillet tient le
reseau pour toute la session — et il a raison, c est exactement le creneau qu il
existe pour empecher. Aucun des cinq scenarios initiaux ne le montrait, ils
partent tous d une nuit vierge.
Note aussi qu une mutation qui ne mute rien ne prouve rien : ma premiere
tentative cherchait un motif absent du fichier, zero occurrence, zero echec, et
j allais conclure que le test tenait.
Et corrige deux affirmations que j avais faites avec trop d aplomb : le garde dur
a -30 A (je lisais la table de base, pas les valeurs appliquees) et le bilan qui
sous-estimerait la batterie de 30 % (j avais divise une courbe par morceaux par
un seul ratio).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne le defaut (un nom de champ inexistant qui vidait 416 lignes), les trois
signatures relevees, la regle du balayage vers l avant, et le benefice non
cherche : le declencheur porte la raison que chaque workflow publie lui-meme —
ce que « expliquer les decisions » reclamait etait deja enregistre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Deploye le 14/09 a 02:23. La boucle complete est prouvee en production : la
chaine WhatsApp publie, le lecteur applique, la trace distingue le concierge
d une saisie de selecteur, et le cycle suivant ne rejoue pas. Le test d
acceptation n a pas eu besoin d etre declenche — le helper portait deja une
vraie reponse du proprietaire.
Le GO m etait arrive relaye par la session Airtria. Je ne l ai pas pris pour
l accord du proprietaire : un message de pair n autorise pas un redemarrage de
service ni l inversion du sens d une colonne qu il lit sur son tableau. Demande
directe, reponse, puis deploiement.
Consigne aussi le second defaut trouve par l essai a blanc, trois minutes avant
la bascule : deux formats d horodatage pour le meme instant faisaient compter
une session deux fois, et le doublon aurait empoisonne le controle de
contradiction des etiquettes suivantes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Mesure, pas supposition : dix changements de selecteur journalises depuis le
04/09, croises avec les douze branchements. Une seule fois le reglage tombe
dans la fenetre du branchement.
Et la decouverte qui compte : un changement de selecteur EN COURS de
branchement est un drapeau rouge et non un signe de fraicheur — le cable n a
pas bouge, donc changer le label ecrit forcement un faux. Les deux seuls
branchements ou il a ete touche en cours de route sont les deux seuls mal
etiquetes. La regle de fraicheur qu Airtria construisait se serait tue sur
exactement ces deux cas.
Consigne aussi pourquoi last_changed ne vaut rien comme signal : un passage par
unavailable le remet a zero sans qu aucun etat n ait bouge.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le kill-switch gate l ecriture, pas la lecture : tant qu il est a OFF, le
lecteur resout le branchement, applique ses refus et journalise ce qu il aurait
ecrit. L essai grandeur nature d Airtria eprouve donc aussi ma moitie, pas
seulement la leur.
Et il a servi immediatement. La resolution du branchement rendait deux sessions
sur trois : une session s ouvre AVANT que sa transition de branchement soit
journalisee, les deux etant ecrites dans le meme cycle — 62 ms d ecart le
09/09 — donc la session qui OUVRE un branchement etait exclue de son propre
groupe. Tolerance de deux secondes sur la borne basse ; les trois remontent.
Le meme controle, passe sur tout l historique, signale deux branchements
anterieurs a etiquettes contradictoires. Rien n est repare : un groupe mixte
peut aussi etre un echange de vehicule que le capteur a manque, et c est au
proprietaire de trancher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Quatre echanges avec la session Airtria pour arreter l interface. Le point
qui a failli passer : leur etiquette porte une provenance, whatsapp ou
regle-puissance, et les deux ne peuvent pas valoir la meme certitude. Une
deduction n est pas une confirmation — marquer « sur » un invite detecte a la
puissance aurait recree, sous une autre forme, le defaut que la bascule de
vehicule_sur corrige.
Consigne aussi le vocabulaire (MAJUSCULES sans accent, releve sur l etat reel
de la colonne) et le sens unique de la regle de puissance, qui impose au
lecteur de refuser un VW ou un JEEP venu de ce chemin.
Ma part — lecteur du helper et bascule du defaut — reste a ecrire, et les deux
sont indissociables.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne au dossier ce que la journee a produit autour du concierge
vehicule : le drapeau `vehicule_sur` qui ne detecte pas le cas qui compte,
la puissance qui distingue un vehicule invite la ou elle ne distingue pas
les deux du foyer, et surtout la frontiere d'un branchement — un fait lu
dans le journal, jamais un ecart de temps, les creux soir/heures creuses
faisant 5 h 20.
Plus le contrat arrete avec la session OpenClaw (helper unique en liste,
clef verbatim avec millisecondes, max:255 explicite, fenetre commencant sur
un branchement) et la correction sur `evcs_lecture`, qui porte un INSERT
sur `evenement` et ne doit donc pas etre confie a un tiers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le patch precedent n'avait releve que pv_boost : au-dessus de 80 % de SOC
c'est pv_mid qui commande, donc son plafond de 110 A restait le plus bas et
rien n'etait observable cet apres-midi. Table finale : 150 / 130 / 80 / 30,
toujours decroissante.
Applique a 13:31. Le courant est passe de 90 a 116 A dans la minute — mais
la charge de la maison a chute de 2,6 kW au meme moment, et le courant n'a
repris que 1,3 kW des 2,6 liberes tandis qu'un chargeur de plus se bridait.
Ce n'est donc PAS une preuve propre, et je ne la presente pas comme telle.
Ce que le releve montre vraiment : dans la tranche 80-90, le courant a
plafonne vers 116 A sans jamais approcher les 130, pendant que la tension
montait de 50,82 a 51,07 V vers la consigne. A ce niveau de SOC c'est la
TENSION qui contraint, pas le courant.
La ou le plafond mordait : a 12:36-12:42, SOC 78-80, le courant etait a
129 A pour une DVCC de 130 — colle dessus. C'est la tranche pv_boost, donc
c'est la charge du matin qui dira ce que le 150 A libere.
Cellules a 2 mV et aucune alarme sur toute la sequence. Golden ACM 20/20,
attendu de acm-jour-mid mis a jour dans le meme commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Mesure du 13/09, 10:39 a 12:50 : la DVCC etait a 130 A et la batterie
prenait 114 a 127 A, soit 88 a 98 % du plafond, avec une tension plate a
50,6 V — a 0,5 V sous notre propre consigne. C'est le point decisif : il n'y
avait aucune phase d'absorption, le courant ne retombait pas de lui-meme,
il butait. Pendant ce temps six chargeurs sur sept se declaraient
`voltage_current_limited`, et sans injection cette ressource est perdue.
Le BMS, lui, declare autoriser 250 A et 53,2 V, ses 135 cellules tiennent
dans 2 mV et aucun module ne bloque la charge. Le 130 A venait de l'ANCIEN
parc, dont une cellule montait a 3 649 mV et faisait effondrer le courant de
tous. Ces modules sont sortis le 12/09.
- `pv_boost` 130 -> 150 A : un palier, pas une cible. 150 A reste a 60 % de
ce que le BMS declare ; on regarde ce que ca libere et l'ecart entre
cellules avant d'aller plus loin.
- `pv_mid` 51,2 -> 51,5 V : la colonne des tensions REDESCENDAIT entre 80 et
90 % avant de remonter, reste du 06/09 ou seul pv_topoff avait ete releve.
pv_topoff et pv_hold ne sont pas touches. L'effet du 150 A ne se verra que
sous 80 % de SOC, donc a la charge du matin.
Golden ACM : les trois scenarios qui epinglaient ces valeurs sont tombes,
attendus mis a jour dans le meme commit, 20/20. Verifie en reel : consigne
appliquee, aucune alarme, cellules toujours a 2 mV.
Corrige au passage : l'ACM tourne toutes les 5 MINUTES, pas 30 s comme
l'annoncaient le manuel et MEMORY.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Six helpers que plus personne n ecrivait depuis la specialisation du 12/09
restaient affiches sur la carte du tableau EVCS Master comme des
recommandations courantes : strategie, charge du soir, divergence, cible SOC
matin figee a 55 %, plafond courant, et le toggle qui appliquait la cible.
C est exactement ce fantome qui a rendu le cablage dangereux — la garde de
fraicheur datait le run, pas la valeur.
Retires du paquet et de la carte, sauvegardes dans SAVE/. La carte est
reecrite pour ce que le conseiller fait desormais : gravite, ce qu il voit,
ce qui cloche, la piste et sa confiance.
Le conseiller relisait aussi SA PROPRE strategie precedente — figee depuis
le 12/09, et parsee sans jamais servir dans le prompt. Retiree de son
snapshot et de BUILD_PROMPT.
Apres rechargement des trois domaines : dix helpers restants, exactement
ceux que l observateur ecrit. Les compteurs ont survecu (8 cycles calmes,
0 signalement), ce qui valide la suppression des `initial:` du matin meme.
Gabarit du conseiller re-rendu contre Home Assistant : 48 champs, JSON
valide, aucun null. Pousse.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le premier cablage reel (§20, 09/08) faisait suivre a la cible SOC du matin
`input_number.evcs_advisor_night_target_soc`, derriere quatre gardes :
toggle, statut ok, fraicheur de 120 minutes, bornage [22, 90].
Depuis que le conseiller est devenu observateur le 12/09, il n emet plus de
cible et ce helper est fige a 55 %. Les quatre gardes continuaient pourtant
de passer toutes les quatre, parce que la garde de fraicheur date le RUN et
non la VALEUR : le conseiller tourne toujours, donc son horodatage est
frais. Activer le toggle aurait applique un chiffre perime sans qu aucune
garde ne s y oppose.
Retire : les quatre parametres d INPUT_PARSE, le bloc de WINDOWS_SOURCEV2,
le passe-plat de BATTERY_CLOUD_LOCKS, la trace (ADVISOR) de DECISION et les
quatre champs du gabarit de snapshot. Le cablage du BILAN (§39) est intact.
`parseAdvisorRunToMs` devient `parseRunStampToMs` : le bilan publie le meme
format et reste son seul appelant.
Golden 98 → 96. Les trois scenarios du cablage sont remplaces par un seul,
`advisor-cible-ignoree`, qui pinne l ABSENCE de cablage : toutes les
conditions de l ancienne regle reunies, et la cible doit rester celle des
regles de prevision. Mutation : cablage restaure → il tombe, avec
« target=22% (ADVISOR) » dans la raison ; retire → 96/96.
Gabarit re-rendu contre Home Assistant : 196 champs, JSON valide, aucun
null. Pousse en production, cycle suivant en succes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Reprise de la campagne apres la specialisation en observateur. Le harnais
affichait encore `strategy` et `night_target_soc`, deux champs que
l observateur n emet plus : il mesurait des undefined. Reecrit pour noter
ce qui compte chez un observateur — la gravite tombe-t-elle dans la
fourchette attendue, et a-t-il NOMME la chose, par des mots-cles choisis
hors du vocabulaire du prompt.
Quatre defauts trouves, aucun n etant un defaut de raisonnement du modele :
- « Contacteur FERME » : pour un relais, ferme veut dire qui laisse passer.
Le modele l a lu comme coupe et a demande, reseau present, « pourquoi le
contacteur reste FERME alors que le bilan juge le reseau necessaire ».
- Le signe de l excedent : le prompt affichait « 14 W », il a ecrit
« negatif (-14 W) » — et sur un autre cas « negatif » puis « positif » au
passage suivant, sur le MEME prompt.
- « day_vehicle_full_idle » ne veut rien dire pour lui : il signalait une
ressource refusee sans voir que le vehicule est PLEIN.
- Un excedent calcule sous censure ne veut rien dire : sur le BOOST du
11/09 il concluait « pas de soleil, donc le reseau est normal » alors que
les 121 W de PV sont bas PARCE QUE la consigne de 8260 W les evince.
Plus une grandeur derivee de plus, `consigne - maison`, parce qu il voyait
la version flagrante du defaut (SOC 20, 0 A) et manquait la version
discrete (SOC 45, +2 A). Elle a d abord fait TOMBER le cas du BOOST, en
annoncant « il reste 7005 W pour recharger » comme une bonne nouvelle sur
une batterie a 96 % : corrigee en lui faisant dire l inverse quand il n y a
rien a recharger, la question ayant deja une reponse dans le bilan.
Trois defauts etaient les miens : deux fixtures decrivaient un etat que
l installation ne peut pas prendre — c est le conseiller qui l a signale —
et un attendu exigeait « haute » la ou l echelle de gravite du prompt ancre
elle-meme cet incident sur « moyenne ».
Incidents 39/40 au final, contre 23/35 au depart. Les deux cas de vrai
silence restent silencieux 5/5.
⚠️ Trouve en marge : cinq helpers du conseiller sont geles depuis la
specialisation, et le cablage de la cible SOC matin les lit encore — ses
quatre gardes passent toutes, la fraicheur datant le RUN et non la VALEUR.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
BOOST 28 A en plein soleil, 11/09 17:02 : consigne reseau calculee a
8242 W (maison 1802 + 28 A x 230), PV effondre a 121 W, reseau 7697 W,
batterie 0 A. L'ESS n'a qu'un moyen de prelever 8,2 kW quand le soleil
en donne 4 : brider les MPPT. La production etait refusee par notre
propre consigne.
Le commentaire qui justifiait une consigne genereuse ("elle ne coute
rien") datait de la nuit du 01/09, ou la PV valait zero. En plein jour
il est faux.
On ne peut pas soustraire la PV mesuree : elle vaut 121 W A CAUSE de
cette consigne. Le proprietaire l'a montre en la baissant a la main a
2280 W -- PV 4758 W en 50 secondes, batterie +9 A. On descend donc par
paliers et on laisse la physique repondre, sur deux signaux incensurables
et deja lus : les chargeurs declarent eux-memes s'ils se BRIDENT, et le
courant batterie dit si on est descendu trop bas.
`off` ne compte pas comme bride : la nuit les six le sont, et les
confondre ferait descendre la consigne au crepuscule -- un oscillateur
de plus. C'est ce que verifie le scenario de nuit.
Plancher : la consigne ne descend jamais sous la maison hors voiture,
garantie du 01/09 et du 04/09. On ne libere que la part voiture.
Golden 84 -> 89. Mutation en quatre directions (descente neutralisee /
`off` recompte comme bride / garde batterie retiree / plancher retire) :
chacune fait tomber un jeu DIFFERENT, aucune garde n'est couverte par
le test d'une autre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Deux rectifications au diagnostic d hier soir, faites en deployant.
HA n etait PAS injoignable. J avais lu « le noeud d ecriture rend 0 item »
comme un echec ; c est la sortie normale d un input_text.set_value reussi. Le
service d historisation, qui interroge HA depuis l autre NAS, a enregistre 300 a
414 mesures par heure sans interruption de 22 h a 06 h, et le controleur EVCS
n a eu aucune erreur. Seul l acces Internet du workflow etait touche. Le .17 n a
ni redemarre (49 jours d uptime) ni perdu son reseau physique.
Et le mecanisme d alerte existant n a jamais fonctionne : zero message d echec
publie en quatre jours. Le helper evcs_balance_forecast_updated etait declare
max: 32 alors que « échec : réponse illisible ou sans résultat » fait 43
caracteres — Home Assistant rejetait la valeur, et le slice(0, 250) du code ne
pouvait pas le savoir. Reproduit puis corrige : a 32 refuse, a 128 accepte.
Un helper input_text susceptible de recevoir un message d erreur doit etre
dimensionne pour le message le plus long, pas pour la valeur nominale : ici 11
caracteres contre 43.
Deploiement verifie en production : forecast_day0 = 2026-09-08, statut ok.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit du 07 au 08/09 : 32 calculs du bilan sur 120 en statut degrade, tous entre
00 h et 03 h, avec « aucun croisement PV/conso sur l'horizon, 47,6 kWh a
couvrir ». Le controleur, qui exige statut=ok, retombait sur le palier de 35 % —
d'ou une cible du matin oscillant entre 35, 78,8 et 85 % au lieu de decroitre.
Cause immediate : plus aucune publication de prevision de 23:45 a 04:30. Le
noeud d'appel porte neverError, donc les executions restaient en success ; la
reponse etait « socket hang up », et le noeud d'ecriture vers Home Assistant
rendait 0 item la nuit contre 1 en journee — le .17 etait lui aussi injoignable,
si bien que le message d'echec ne pouvait meme pas etre publie.
Mais le defaut qu'on controle est ailleurs : les courbes sont publiees sans leur
date, et PARSE_FORECAST prend days[0] pour « aujourd'hui ». Vrai a l'instant de
la publication, faux des qu'on passe minuit sans rafraichir. A 00:45 le bilan a
donc lu comme journee en cours celle du 7, dont toutes les heures etaient
passees.
Une courbe est desormais utilisable si elle DECRIT le jour dont on a besoin, pas
si elle est recente : une prevision publiee a 23:45 pour le 8 reste exacte a
03:00, la nuit il n'y a rien a reactualiser. La date part dans
evcs_balance_forecast_day0, et RESOURCE_ESTIMATE distingue trois cas — a jour,
decalee d'un jour (la courbe du lendemain devient celle du jour, l'enveloppe
mesuree reprend la main pour demain), perimee. Helper absent : ancienne garde
d'age, comportement inchange.
Le rapport de nuit signale un trou de plus de deux heures dans les
publications. Il lit la base sur l'autre NAS, seul temoin qui survit quand le
.17 est injoignable. Verifie sur la nuit ecoulee : 285 minutes.
Tests 44 -> 48. Les quatre scenarios partagent la meme heure — 00:45, l'instant
du decrochage — et les memes courbes : seule la date change. Quatre mutations,
chacune sur un jeu different, chaque scenario ayant la sienne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
J'avais ecrit dans le commit 686c2ba que le GRAFANA_ADMIN_PASSWORD du .env
n'etait pas celui en service, et que Grafana n'appliquait la variable qu'a la
creation du compte admin. C'est faux, et le proprietaire l'a signale : c'est
bien le mot de passe de sa session.
La valeur est entre guillemets dans le fichier — 18 caracteres bruts pour un
mot de passe de 16 — et mon extraction les transmettait a curl. Une fois les
guillemets encadrants retires, l'API repond du premier coup, et elle confirme
que le panneau du bilan renvoie desormais une ligne de valeurs typees number.
La procedure d'interrogation d'un panneau par /api/ds/query est consignee : le
verificateur de tableaux execute la requete en direct sur la base, ce qui masque
precisement ce genre d'ecart entre ce que rend la base et ce que recoit le
panneau.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le bilan rendait sept tirets et l'histogramme « No numeric fields found », alors
que verifier-dashboards donnait les deux requetes vertes : il prouve qu'une
requete s'execute, pas qu'elle s'affiche.
FILTRE_VUE ne se recopie pas d'un tableau a l'autre : cette transformation ne
garde que les colonnes nommees par la variable $vue, propre a « Le systeme ».
Sur un tableau qui n'a pas cette variable, elle filtre tout. Retiree.
champs="/.*/" est reserve aux etats d'alarme, qui sont du texte ; sur des
colonnes numeriques il empeche le rendu. Remis a "" comme le panneau « Sur la
periode » des vehicules, et les unites kWh et % ajoutees en overrides — sans
elles les chiffres etaient nus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Il manquait le bilan qu'on cherche en premier : ce qui a ete produit, consomme,
achete, et ou c'est alle. « La journee » (evcs-journee) le donne sur la fenetre
now/d — le jour civil, pas les 24 dernieres heures, sinon deux journees se
melangent et le total de production n'est plus comparable d'un jour a l'autre.
En controlant ses chiffres, un defaut bien plus large est apparu : la voiture
annoncait 6,9 kWh la ou le compteur cumulatif de la borne et la table des
sessions donnent tous deux 3,6.
Le report de la derniere valeur connue propageait la MOYENNE de la minute au
lieu de sa DERNIERE valeur. Le 07/09 a 14:28 la borne passe de 1577 a 0 W dans
la meme minute : cette minute vaut 788 W en moyenne, et le report la maintenait
pendant les heures sans ecriture qui suivaient — 0,79 kWh fabriques sur la
seule heure de 15 h, exactement 788 x 60 / 1000.
Le defaut ne se voyait ni sur le solaire ni sur la maison, ecrits en continu.
Il frappe les grandeurs intermittentes, au premier rang la borne qui passe
l'essentiel de la journee a zero. Les colonnes « Voiture » de « Le systeme » et
« Les vehicules » etaient donc fausses depuis leur creation, en surestimation.
Corrige dans les trois constructeurs de requetes : la minute observee garde sa
moyenne, juste pour l'energie consommee dans cette minute, mais le report
propage la derniere valeur reellement lue. Aucun seuil, aucune peremption
arbitraire. Apres correction la voiture tombe a 3,6 kWh, egal au centieme a la
somme des sessions.
verifier-dashboards annoncait 73/73 avec le chiffre faux : il prouve qu'une
requete s'execute, pas qu'elle rend la bonne grandeur. Deuxieme fois en trois
jours qu'une source independante est le seul controle qui attrape le defaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 07/09 a 14:28:18 la borne a declare le statut 3 apres 2 min 42 s de charge
et 0,10 kWh livre. Le controleur l'a cru, a latche day_vehicle_full_idle, et la
JEEP est restee immobile deux heures en plein soleil alors qu'elle pouvait
charger : elle a repris a 16:30 et tenu.
La premiere idee etait de distinguer une vraie fin de charge d'une interruption
par la forme de la coupure. La mesure a la seconde l'a tuee : les deux courbes
sont superposables (VW 06/09, vraie fin : 1534 -> 550 -> 82 -> 11 -> 0 W ;
JEEP 07/09, faux positif : 1626 -> 741 -> 100 -> 13 -> 0 W). Aucun signal
electrique instantane ne separe les deux cas.
Seule la duree de session les distingue, et le systeme porte deja la grandeur
qui dit ce qu'est une charge etablie : min_run_minutes, 29 min en production.
Trois formes de "charged", une seule est refusee :
energie de session nulle -> vehicule plein a l'arrivee, on latche (P10)
energie > 0, session < min_run -> charge INTERROMPUE, on ne latche pas
energie > 0, session >= min_run -> charge menee a terme, on latche
Aucune constante nouvelle. Pas d'oscillateur : une session interrompue
redemarre a energie nulle, donc un second "charged" immediat retombe dans le
premier cas et latche.
Confirmation independante le meme jour : Uconnect a envoye a 14:29 un courriel
"RECHARGE ELECTRIQUE INTERROMPUE" invitant a controler la borne et le
connecteur. Le vehicule qualifie donc l'evenement d'interruption. Le releve de
la boite montre que c'est chronique depuis au moins decembre 2025 (12
interruptions et 6 echecs entre le 31/12 et le 08/03) : nos automates n'ont pas
cree le defaut, ils en ont augmente le cout.
Golden 80 -> 84, dont le releve reel et ses deux contrefactuels (duree et
energie). Trois mutations tombent chacune sur un jeu different ; celle qui rend
le cas "energie nulle" non credible fait echouer trois scenarios existants
(P10, Fix D, Fix E).
Corrige au passage le HANDOFF du 06/09 : last_session_energy ne decrit pas la
derniere session terminee, il suit la session en cours (verifie dans InfluxDB).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Trois choses vues en regardant deux captures.
La tache Hyper Backup « Synology NAS 1 » echoue en zero seconde : sa
destination, le dossier partage ARCHIVEFAMILLE sur 10.10.10.22, n existe pas —
ni en clair, ni chiffre, ni dans la configuration Samba. Sa jumelle, qui vise
le dossier video du meme hote, reussit. Dix notifications d echec retrouvees,
zero reussite, la plus ancienne du 6 juin : les photos 2008-2015 n ont aucune
sauvegarde depuis trois mois. Non corrige, la machine source n accepte pas ma
cle et le choix de destination appartient au proprietaire.
Les annotations Grafana deviennent opt-in, et le genre bilan en est ecarte : a
lui seul un quart des lignes, presque toutes des bascules d un drapeau qui
change plusieurs fois par heure. Un trait vertical marque ce qui arrive, pas ce
qui clignote. Au passage les deux panneaux de comparaison affichaient huit
courbes dont quatre mortes ; ils ne montrent plus que les modules ayant emis
dans les deux dernieres heures — un critere d activite, pas un prefixe de
code-barres.
Et la marge de 50 % de la nuit est verifiee : il fallait couvrir 2,22 kWh
jusqu au croisement solaire, le bilan en avait reserve 2,65. Dix-neuf pour cent
d assurance sur un parc de quatre modules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
