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
Troisieme workflow structurant, et le seul sans tests : c est lui qui decide ce
que la batterie a le droit de prendre, donc lui qui plafonnait le parc a 93 %,
et il n etait meme pas suivi dans le depot avant ce matin.
Vingt scenarios sur le patron de la suite hysteresis, avec le vrai code du node
dans une sandbox et un snapshot capture contre Home Assistant plutot
qu invente — la lecon du 24/08, quand un fixture portait les valeurs de repli du
code au lieu des seuils de production et masquait un bug de bande.
Ils suivent l ordre reel des branches et enferment chaque paire dans son
contrefactuel : hiver sombre contre hiver ensoleille, ete secours contre ete
repos, rattrapage de midi contre midi ou le soleil revient, override actif
contre override expire, et le takeover demande alors que le contacteur est
ouvert. Le releve reel du maintien a 2 A de cette nuit y figure, ainsi que le
topoff a 52,4 V pose ce matin.
Cinq mutations, chacune tombant sur un scenario different. Suite cablee au
push, bloquante comme les trois autres.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le plafond a 93 % n etait pas une protection : le BMS autorisait 53,2 V, nous
imposions 51,3, et la cellule la plus haute du pack recent etait 57 mV sous la
premiere alarme. Le garde-fou datait des cellules faibles du pack ancien, hors
service depuis hier — il protegeait un parc qui n est plus la, au prix de
0,68 kWh, soit 12 % de la reserve utile.
Le helper de tension et ses paliers ne sont lus par personne : les valeurs sont
une table codee en dur dans l Auto Charge Manager, qui entre au passage dans le
depot. Seul le profil de la tranche 90-95 % passe a 52,4 V, soit 3,493 V par
cellule, sous la tension nominale que Pylontech annonce. Verifie dans la
minute : parc de 51,12 a 52,33 V, courant de -5,3 a +16,1 A, aucune alarme.
Et le rapport de nuit part par courriel a 6 h 47. Il ne vit pas dans une
session Claude, qui s arrete avec l ecran, mais dans le service
d historisation, seul composant allume en permanence — il n y avait rien a
surveiller, tout est deja enregistre, il manquait une lecture. Le texte est
ecrit pour etre entendu : pas de tableau, des phrases courtes, des virgules
decimales. Canal : le webhook n8n qui existait deja, teste de bout en bout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Valeurs negatives au point de raccordement, contacteur ferme. La mesure separe
deux phenomenes que rien ne reliait.
Le premier est bien la plaque qui cycle : sur la fenetre de midi, 9 % des
echantillons negatifs, minimum -477 W, mediane -146. Le regulateur ne rattrape
pas un delestage brutal d un kilowatt avec une consigne de repos a 200 W. Elle
passe a 700 : la courbe monte de 500 W et le minimum devient +23 W. Le surcout
va dans le bon sens, cette consigne ne s appliquant que contacteur ferme sans
session reseau — c est-a-dire apres une coupure sur SOC bas ou une fermeture
par la regle de protection, deux cas ou l on veut justement que le reseau
contribue davantage.
Le second, -2819 W pendant deux minutes, n a rien a voir : le debranchement du
vehicule a supprime 2,2 kW d un coup alors que la batterie a 93 % n absorbait
rien et que le MPPT produisait 4 kW. Aucune consigne n absorbe cela. Ce qui l
evite est le correctif du matin sur la regle de protection : la demande sur le
parc valait 741 W, le contacteur n aurait pas ete ferme, et sans reseau il n y
a rien ou injecter.
Golden 80/80, trois attendus mis a jour avec la mesure en commentaire.
Et docker n est pas dans le PATH d une session SSH sur DSM : les commandes de
deploiement appellent desormais /usr/local/bin/docker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le selecteur de vehicule est repasse de JEEP a VW au redemarrage, pour la
deuxieme fois. La cause n est pas celle notee le 04/09 : le paquet declarait
initial: VW, et declarer initial desactive la restauration d etat dans Home
Assistant — le helper est force a cette valeur a chaque demarrage. Preuve par
comparaison : la strategie, creee par l interface donc sans initial, survivait.
Le defaut touchait cinq reglages manuels, dont deux toggles de cablage poses
avec consigne de les activer : le reseau avant depart (P9) et l application de
la cible SOC de l advisor. S ils ont ete actives depuis aout, chaque
redemarrage les a silencieusement remis a zero.
initial retire de ces cinq helpers, la regle inscrite en tete des deux
paquets. Les onze helpers de runtime de l advisor gardent le leur : ils sont
reecrits au cycle suivant et repartir d un etat connu y est voulu.
Redemarrage : 30 s, troisieme mesure identique. Les treize capteurs de la
borne arrivent desormais dans InfluxDB.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le journal a annonce deux fois 4,20 kWh : la vraie charge de nuit, puis onze
minutes de charge diurne. L energie de la borne etait echantillonnee a chaque
cycle et conservee par un GREATEST — un operateur monotone, qui ne peut que
surestimer et qui verrouille la premiere valeur vue. Au premier echantillon de
la session de midi, le capteur portait encore le total de la nuit.
Confrontation des cinq lignes a l integration relue dans InfluxDB sur les
periodes de charge reelles : ecarts de 1, 5, 14, 60 et 1135 %.
Le compteur cumulatif de la borne devient la mesure de reference : releve a
l ouverture, sa difference a la cloture donne l energie sans ambiguite de
semantique ni erreur d integration. last_session_energy est lu une seule fois,
a la cloture, et enregistre comme observation ; le journal ne l affiche que
s il s ecarte de plus de 10 %, ce qui rend visible le cas d une session
commencee avant le demarrage du service au lieu de le substituer en silence.
Les treize capteurs de la borne entrent enfin dans l historisation InfluxDB :
c est leur absence qui empechait d etablir cette semantique.
Second defaut de la meme fonction : l heure de debranchement etait posee en
bloc sur toutes les sessions non marquees des dix-huit dernieres heures. La
session de nuit de la JEEP a ainsi herite du debranchement de la VW — l inverse
du role de cette colonne. La duree de branchement la borne desormais.
Reparation idempotente des lignes existantes, limitee a ce qui a ete verifie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Deux fermetures ce dimanche midi. Mesurees a l instant de la decision,
contacteur encore ouvert donc production non censuree : maison 4025 et 4981 W,
mais parc reellement sollicite 1132 et 772 W pour un plafond de 5100. La
decharge batterie mesuree aux memes instants — 1345 et 1223 W — colle a
maison moins PV, pas a la maison brute. Le solaire couvrait la cuisson ; la
regle a ferme le contacteur pour rien, 0,50 kWh importes en plein soleil.
Elle n avait bien fonctionne hier soir que parce qu il n y avait plus de PV.
Les deux seuils portent desormais sur max(0, maison - PV). Contacteur ouvert
cette grandeur EST la decharge batterie ; ferme, un bridage du MPPT la fait
surestimer, donc l erreur pousse a rester ferme et jamais a relacher tot.
Golden 20 -> 24, dont les deux releves de midi et le contrefactuel du nuage.
Le test de mutation a montre que la premiere serie ne couvrait que le seuil de
fermeture : il a fallu ecrire le cas du soleil revenu pour qu elle morde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Contacteur ferme a 12:07 sur un pic de cuisson, rendu a 12:22 alors que la
maison etait a 3 084 W. A la resolution native, elle oscille avec une periode
de huit secondes entre 2 000 et 3 080 W et franchit le seuil de relachement 3,3
fois par minute ; le workflow a echantillonne 1 980 W. Quinze minutes avant que
le correctif ne parte, le defaut a rejoue devant nous.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La regle du 05/09 ferme quand la maison depasse 80 % du plafond de decharge du
parc — elle a mordu au bon instant hier soir, a -97,4 A pour 100 A autorises.
Mais elle relachait sur un seul echantillon sous 50 %, et la soiree offrait
quatorze occasions de le faire. Le troisieme pic est tombe deux minutes avant
l'ouverture reelle : decale de cinq minutes, elle refermait, et chaque
aller-retour du contacteur coute 50 a 150 Wh.
Les accalmies mesurees sont franchement bimodales — treize de 5 min au plus
pendant la cuisson, une de 201 min apres. Le relachement se mesure donc en
duree, et la duree vient du bilan energetique : 20 min tant que la batterie est
condamnee a toucher son plancher avant les heures creuses (l'energie reseau du
soir est due de toute facon, la tenir ne change que son heure), 6 min des
qu'elle passerait la nuit seule (chaque kWh du soir deplacerait alors un kWh
d'heures creuses vers des heures pleines). Premiere lecture du bilan par le
workflow d'hysteresis.
Le dwell se compte sur la maison, jamais sur le contacteur : l'horodatage est
ecrit qu'il soit ouvert ou ferme, sans quoi la decision detruirait sa propre
cause. Et parce que la tension batterie s'est tue 27 minutes hier soir en
pleine cuisson, le plafond retombe sur la tension nominale du parc, et a defaut
l'horodatage — un fait persiste — tient la protection jusqu'au bout du dwell.
Golden-hysteresis 11 -> 20. Six mutations, chacune tombant sur un jeu different.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Pack ancien : facture 190002543 du 27/04/2023, quatre US2000C a 940
EUR HT. Pack recent : FACLBSPRO2503-0064 du 14/03/2025, quatre a
582,42 EUR - avec, sur la meme facture, le second MultiPlus-II.
Le passage en parallele date donc de mars 2025. Et il est disculpe :
le pack recent a ete installe au meme moment, sous la meme
configuration, et ses soixante cellules sont intactes apres dix-huit
mois. Si le parallele abimait les modules, les deux packs seraient
touches.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
900 evenements en six jours : son tampon est sature, ce qui explique
a lui seul son retrait du parc fin juillet.
Le releve decisif date du 23/07 a 17:20 : a 84 % de charge, sous
seulement 6,5 A, la cellule 15 tombe a 2963 mV pendant que ses
quatorze voisines sont a 3291-3303. Ce n'est pas une decharge
profonde, c'est une cellule qui ne peut plus debiter - environ 43 mOhm
de resistance excedentaire, deux fois et demie la cellule 12 de
...0322.
Consequence pour l'essai de mardi, qui devient asymetrique : un succes
sur cette cellule-la serait decisif pour toutes les autres, un echec
ne condamnerait personne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le tampon d'evenements du BMS - distinct de l'historique, et que je
n'avais pas vu - montre 52 passages sous l'alarme basse repartis sur
19 nuits, avec une tension qui descend de 3072 a 2999 mV. Le temoin de
la meme chaine a un tampon VIDE.
Le SOC du parc a ces moments-la vaut 34 a 41 %. Le plancher dur du
controleur est a 22 % : il n'est jamais atteint, la cellule est
detruite bien avant. Le plancher est exprime dans un SOC que la
cellule endommagee fausse elle-meme.
Cela revise ma recommandation de cet apres-midi. Les 3 kWh que je
disais perdus en retirant les trois modules etaient mesures sur une
plage ou une cellule se detruit ; a plancher reellement sur, cinq
modules sains rendent 9,42 kWh contre 9,29 pour les sept. Le retrait
ne coute rien, et supprime le bridage en prime.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Suivi console des trois modules pendant que l'alarme montait. A
13:04:48 les cellules meneuses sont a 3526 et 3541 mV, a 13:05:08 a
3555 et 3575, et a 13:05:13 le courant de charge autorise tombe de 50
a 30 A. Le seuil lu dans sysinfo est bien celui qui commande.
Ensuite les cellules se detendent et l'alarme repasse au vert, mais le
plafond reste : c'est pour cela que le bridage dure des heures quand
l'alarme ne dure que des minutes.
Le module sain de la meme chaine montre 13 mV au meme instant. Le
bridage est produit par deux modules et subi par les sept.
Les dates des codes-barres sont des dates de fabrication : le pack
sain a sejourne en stock, ce qui reconcilie les six mois d'ecart avec
les deux ans de service. Et comme il a encaisse 345 cycles sans une
seule cellule marquee, les degats de l'autre pack ne viennent pas de
l'usure mais de deux cellules descendues sous trois volts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Elle avancait de 6 h 09 min 12 s, mesure directement en comparant son
RTC a l'horloge du poste - ce qui tranche definitivement contre
l'estimation de huit heures obtenue le matin par correlation.
Le message d'usage annonce time [year] [month] [day] [hour] [minute]
[second] sans preciser que l'annee tient sur deux chiffres : la forme
a quatre chiffres est refusee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Au repos, quatorze de ses cellules tiennent dans quatre millivolts et
la quinzieme est cinquante-cinq millivolts plus bas. Sur son
historique elle oscille sur 683 mV quand ses voisines font 150 -
signature presque identique a la cellule 12 du module 1.
Le module retire du parc a donc moins de cellules malades que deux de
ceux qui y sont restes. Neuf cellules sur les cent cinq du parc, sur
trois modules ; tout le reste est intact.
Le LVHUB n'a rien : les diodes sont vertes et la mesure du courant
prouvait deja qu'il agrege les sept modules. Son journal de
redemarrages, ce sont nos propres branchements de console.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Lecture simultanee : les quatre modules du pack 2 totalisent 50,65 A
quand le GX en rapporte 90,60. La difference, 39,95 A, ce sont les
trois modules du pack 1. Le GX agrege donc bien les sept, et les deux
packs se partagent le courant a cinq pour cent pres.
Ma conclusion de §50 - la moitie du parc invisible - etait donc
fausse. Le hub possede un mode console dans lequel le brancher le fait
probablement entrer, ce qui explique les valeurs aberrantes lues.
Le pack 2 affiche soixante cellules a zero apres 340 cycles. La
reparation porte donc sur huit cellules reparties sur deux modules du
pack 1, et rien d'autre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La console repond depuis Linux. L'adressage a distance fonctionne : un
branchement par pack suffit, et `soh <adresse>` donne le compteur de
sante par cellule en une seconde.
Le module 3 designe exactement les cinq cellules deduites ce matin de
son historique. Le module 1, sain en juillet, est passe de 7 a 498
evenements de surtension en six semaines ; sa cellule 12 oscille sur
691 mV quand ses douze cellules saines font 178 mV.
Ses pires ecarts sont en bas, pas en haut : 317 mV a un pretendu
2 % de charge alors que le parc etait a 3,236 V par cellule. Le BMS
croit la batterie vide parce qu'une cellule l'est. C'est tres
probablement le genou a 33 % mesure dans la courbe energie/SOC.
Correction : le champ SOH de stat n'est pas une note sur 100, le
module irreprochable affiche 0 comme le module abime.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Les exports BatteryView contiennent la sortie brute de la console du
BMS : 1798 enregistrements sur 37 jours, avec les 15 tensions de
cellule a chaque fois. La preuve etait deja ecrite, il n'y avait rien
a attendre de l'apres-midi.
Les cellules 2, 6, 10, 12 et 15 montent a 3554-3649 mV quand les dix
autres plafonnent a 3440, et descendent a 3128-3236 quand les autres
s'arretent a 3252. Monter plus haut ET descendre plus bas est la
signature d'une capacite moindre. Le BMS leur attribue d'ailleurs un
pourcentage de charge distinct dans chaque enregistrement, et note le
module 0 sur 100 contre 100 pour un module sain du meme parc.
L'ecart est de 12 mV a 60 % de charge et de 168 mV a 85 % : c'est
pourquoi un releve du matin ne peut rien montrer.
Deux outils rejouables : la console serie sans dependance, dont le
lecteur de table a ete eprouve sur la sortie reelle avant tout
branchement, et l'analyse d'historique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
L'episode du 04/09 apres-midi etait deja enregistre dans InfluxDB, sans qu'aucun
cable serie ait ete branche : l'alarme "tension de cellule elevee" passe a
warning a 16:36:04, la limite de courant imposee par le BMS tombe de 150 a 20 A
en trois minutes, et le parc n'est alors qu'a 50,76 V pour une CVL autorisee de
53,2 V — il restait 2,4 V de marge.
Ce n'est donc pas la tension du parc qui limite mais UNE cellule. A 50,76 V sur
15 cellules, la moyenne est de 3,384 V : la cellule fautive est ~200 mV
au-dessus des quatorze autres.
Deux corrections a ce que nous croyions : le bridage commence vers 75 % de SOC
et non 94 % (le 94 % est seulement ou le parc finit par arriver a 20 A), et
`cell_imbalance` reste no_alarm tout du long — seule la protection de surtension
se declenche.
Et l'explication de "je ne vois rien dans les logs" : le desequilibre est
invisible sous ~70 % de SOC, la courbe LiFePO4 y etant plate. Une capture faite
le matin batterie a 45 % ne peut rien montrer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
configuration.yaml : sept cles de connexion retirees (api_version, ssl, host,
port, token, organization, bucket), include/exclude/tags conserves. Home
Assistant avait deja importe la connexion dans une entree d'integration, donc
l'historisation n'a jamais ete menacee. Sauvegarde
SAVE_CONFIG/configuration.yaml.bak.20260904-194304, diff verifie.
Redemarrage en 30 s. Apres : InfluxDB recoit 1065 points en 90 s, aucune erreur
au journal, PostgreSQL inchange.
⚠️ Effet de bord releve par le detecteur d'evenements, sans le chercher : le
reglage manuel du selecteur de vehicule fait a 19:36 (VW -> JEEP) a ete ANNULE
par la restauration d'etat du redemarrage (JEEP -> VW a 19:44:12). Ce
selecteur determine l'heure de depart retenue, donc toute la mecanique de nuit.
Regle inscrite : apres un redemarrage, relire les helpers regles a la main dans
l'heure precedente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La console VRM est hebergee dans le cloud Victron et disparait quand une
coupure d'orage emporte Internet. Meme vision, lue sur le reseau local :
reseau, charges, batterie, borne, production, detail par tracker, les flux
dans le temps et l'energie heure par heure.
Tout dans Grafana, rien dans Home Assistant — et pour une raison trouvee en
verifiant si son tableau Energie pouvait servir : gx_device_pv_energy et les
compteurs d'energie batterie du GX se remettent a zero sans le signaler.
state_class total sans last_reset, donc HA n'auto-detecte pas la remise a zero
et a enregistre -373,35 kWh sur l'heure de 07:00. Les energies sont donc
obtenues en INTEGRANT LA PUISSANCE, methode qui ignore le probleme.
Trois versions du calcul avant la bonne : somme ponderee (laissait des trous,
une grandeur stable n'etant jamais reecrite), moyenne des minutes presentes
(sur-comptait : 5,13 kWh a 01 h pour 22 minutes observees), puis axe des
minutes complet + report + avg x count/60 = energie reellement accumulee,
correcte y compris pour l'heure en cours.
Recoupement avec la capture VRM du proprietaire : 8,07 kWh de reseau contre
"Depuis reseau 9,0 kWh", l'ecart valant exactement les treize minutes entre
l'ouverture des heures creuses et le demarrage du service d'historisation.
45/45 requetes verifiees contre les bases reelles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois defauts trouves en LISANT les tableaux, qu'aucune des 19 requetes ne
signalait puisqu'elles s'executaient toutes sans erreur.
1. `historise-evcs.mjs` horodate chaque mesure avec son propre last_updated —
le vrai instant de la mesure, et c'est le bon choix. Mais deux grandeurs ne
partagent alors presque jamais le meme ts : 2656 lignes pour 2656 instants
distincts. Mes GROUP BY ts rendaient une ligne par grandeur avec une seule
colonne remplie, donc la courbe "Excedent" — la grandeur meme du §36 —
etait VIDE sur les 2650 lignes.
2. Le service n'ecrit que les changements, donc un regroupement a la minute
laisse des trous : la difference n'existait que 73 minutes sur 434. Report
de la derniere valeur connue, ce que fait aussi le controleur en temps
reel. 430/435 apres.
3. L'energie horaire par sum(valeur)/60 suppose 60 echantillons par heure ; il
y en a eu 26 a 47. Integration ponderee par la duree, plafonnee a 300 s
pour qu'un arret du service n'extrapole pas une valeur perimee. ~9 %
d'ecart. Le "25 a 58 %" que j'avais d'abord annonce etait faux : il
comparait la somme a la moyenne, qui ignore la duree.
Plus deux corrections d'affichage : la colonne `jour` s'affichait
"2026-09-04 02:00:00" (date nue rendue comme instant UTC), et le decompte des
chargeurs MPPT est de six entites publiees, pas sept.
Lecon : verifier-dashboards.mjs prouve qu'une requete s'EXECUTE, pas qu'elle
rend la grandeur voulue — une colonne integralement nulle passe sans un mot.
Ce sont les courbes regardees a l'ecran qui ont attrape les trois.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois tableaux de bord provisionnes depuis git, sur le modele de la regle R2
(le depot est la source de verite, l'interface ne peut pas les ecraser) :
La nuit SOC reel contre SOC exige par le bilan, et la marge entre les
deux. C'est la question qui avait demande une nuit d'archeologie
le 03/09.
Le solaire l'excedent (§36), la censure, et le mode declare par chacun des
sept chargeurs (§37) — le signal le plus direct dont on dispose.
Prevision l'ecart heure par heure, avec la bande de censure dessous : une
production sous la prevision peut vouloir dire mauvaise
prevision OU absence de preneur.
Les evenements de la table `evenement` deviennent des marqueurs verticaux sur
tous les graphiques — une courbe sans ses evenements ne s'interprete pas.
tools/verifier-dashboards.mjs rejoue CHAQUE requete pour de vrai (SQL contre
PostgreSQL, Flux contre InfluxDB, macros Grafana substituees), annotations
comprises puisqu'elles s'executent sur tous les panneaux. Sans lui une requete
cassee ne se voit qu'a l'ecran, panneau par panneau. 19/19 au deploiement.
Port 3001 et non 3000 : sonde avant d'ecrire la ligne, quelque chose ecoute
deja sur 3000 — la lecon du 5432 deja pris par le PostgreSQL de DSM.
Connexion PostgreSQL par le role evcs_lecture : un tableau de bord ne doit pas
pouvoir ecrire dans la memoire. Aucun secret duplique, aucun secret commite :
le provisionnement les reference par $VARIABLE depuis les deux .env.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Redemarrage de Home Assistant a 07:28, apres la fermeture de la fenetre HC,
aucune charge en cours et PV nul. API de retour en 22 s, capteurs revenus en 31
apres le keepalive Venus, un seul cycle du controleur manque. Aucun trou dans
l historisation PostgreSQL : l ecart maximal entre deux mesures de SOC sur les
40 minutes encadrant le redemarrage est de 80 s et se situe avant, ce qui est la
cadence normale du service.
249 entites distinctes ecrivent dans InfluxDB dans les dix minutes qui suivent,
a la resolution native — jusqu a 84 points en 10 min pour la puissance AC-out.
C est ce que PostgreSQL ne peut pas faire et ce pour quoi la proposition B
existait.
Premiere interrogation reelle de la memoire avec le role de lecture seule : onze
points sous la ligne du bilan ce matin, lisibles en une requete.
Faille de conception reperee et consignee : la table evenement a ete creee pour
consigner deploiements et incidents, mais le role d analyse est en lecture seule
donc je ne peux pas y ecrire. Ce redemarrage aurait du y figurer. A trancher
entre une commande d ecriture dans le service d historisation ou un INSERT
restreint a cette seule table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La veille de nuit a rendu son verdict : UNE seule bascule sur 69 releves entre
01:26 et 07:07. La session reseau unique fait ce pour quoi elle a ete concue,
EDF ferme d un bout a l autre de la fenetre sans creneau ni oscillation.
Mais a 02:50, la voiture finie, le sourceMode est passe a bloque et la consigne
reseau est retombee de 5078 a 50 W. Contacteur ferme, reseau disponible, heures
creuses, et l ESS ne demandait que 50 W pendant que la maison tirait 770 W sur
la batterie. Trois heures et demie, SOC 44 vers 17 pour cent, 2,60 kWh pris a la
batterie quand le reseau etait la et bon marche. L Auto Charge Manager est reste
pret a recharger avec DVCC a 30 A, mais la consigne ne demandait jamais l
energie. C est le defaut du 01/09 revenu ailleurs : j avais etabli que fermer le
contacteur ne suffit pas, puis cree la veille une nouvelle raison de le garder
ferme sans la brancher sur la consigne.
gridSessionActive inclut desormais l engagement de session. Regle : tant que le
contacteur est ferme a notre demande, la consigne couvre la maison, peu importe
laquelle des deux raisons le tient.
Consigne de repos portee de 50 a 200 W a la demande du proprietaire, avec une
justification mesuree : sur 12 074 echantillons du point de raccordement, 17 %
sont negatifs, mediane -18 W. Ce n est pas de l injection — la batterie
debitait 744 W au meme moment et les 22,7 Wh cumules representent 0,9 % de ce
qu elle perdait — c est le regulateur qui chasse autour d une cible trop proche
de zero. A 200 W le point de fonctionnement reste positif sur l essentiel des
excursions, sans supprimer les pointes les plus fortes.
Consigne aussi que le 20 % n est pas le notre mais le plancher de l ESS, qui a
fini par faire de lui-meme a 06:20 ce que la session aurait du faire depuis
02:50, apres avoir vide la batterie de 27 points.
Golden 78 -> 80, deux mutations ciblees. Piege rencontre et documente : la
premiere redaction du contrefactuel portait deux fois la clef balance_status, et
en JavaScript la derniere gagne — il testait donc l inverse de son libelle. Un
contrefactuel doit reposer sur une difference physique, pas sur la surcharge d
une clef deja presente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois corrections a ce que j affirmais. L historique brut ne s arrete pas a
7 jours : il remonte au 14/08, soit 20,8 jours, et s allonge vers les 90
configures — mon chiffre datait du 27/08. La base n est pas corrompue : le
"malformed" venait de ma lecture avec immutable=1, qui ignore le journal WAL. Et
le volume de 10.10.10.17 n est pas de 133 Go mais de 7,0 To dont 5,0 libres :
j avais interroge df sur le dossier parent du point de montage, donc sur la
racine de mon propre poste. Le proprietaire l a releve, capture a l appui.
Cause reelle du manque de memoire : sur 288 entites ayant des statistiques long
terme, les quatre series dont le bilan depend n y etaient pas — consommation,
PV, reseau, courant batterie. Home Assistant ne construit ces statistiques que
pour les capteurs declarant state_class, et neuf capteurs sur vingt a unite
numerique le declaraient. Le SoC le declarait, d ou ses six mois d historique.
Correctif : dix lignes state_class: measurement dans configuration.yaml, rien
d autre, diff verifie, sauvegarde prealable. Exclu volontairement la puissance
nominale des onduleurs, constante a 9000 W. Procedure check_config, mqtt.reload
puis keepalive Venus pour forcer la republication — aucun trou, les series sont
revenues numeriques dans la seconde. 288 entites en statistiques deviennent 299.
Fait a 00:57, vingt-sept minutes avant l ouverture de la fenetre HC, premiere
nuit du test de la session reseau unique : un rechargement MQTT aveugle le
controleur le temps de la republication et ne doit jamais avoir lieu juste avant
01:24.
Consigne aussi la verification de la prevision solaire — le total est bon a 89
et 110 % pres, mais la forme est systematiquement decalee, production plus tot
que prevu et apres-midi sur-promis d un facteur 2 a 3 apres 16 h, ce qui
sous-estime l energie a couvrir — et le constat sur le conseiller en mode ombre,
d accord 92,5 % du temps avec les regles et qui argumente desormais pour le
palier qu on vient de remplacer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
576 paliers de SOC mesures sur 8 jours (tools/mesure-courbe-batterie.mjs,
ajoute) : pour chaque palier ou le SOC reste a une valeur puis descend d un
point, on integre la puissance batterie, en ecartant les paliers ou la batterie
a charge et ceux ou le reseau a apporte quoi que ce soit.
Resultat : plate a 0,169 kWh/point de 33 a 93 — six tranches independantes entre
0,163 et 0,171 — genou net a 32-33, puis 0,097 en dessous. Sous le genou un
point de SOC vaut 57 % de ce qu il vaut au-dessus, ce qui est coherent avec le
parc reel (un module en panne sur huit, un autre qui faiblit).
Energie utile totale de 100 a 22 % : 12,39 kWh mesures, contre 11,70 vus par le
bilan (15 kWh a plat) et 13,65 par INPUT_PARSE (17,5). Les deux constantes
etaient fausses, dans des sens opposes.
Comme 15 kWh se situe ENTRE les deux pentes, l erreur changeait de signe : SOC
requis trop bas de 3 a 4 points pour un petit deficit, trop haut de 4 a 6 pour
un gros. Cela corrige au passage une affirmation inexacte de la section 40, ou
j avais ecrit que required_soc etait systematiquement trop bas d un facteur
1,75 : ce facteur comparait la vitesse de descente du SOC a celle de la ligne,
deux grandeurs differentes, et l ecart venait surtout de la sous-estimation de
la consommation par le profil p50. La correction est posee en tete de la
section 40.
Trois fonctions remplacent les cinq conversions lineaires de BALANCE.js ;
requiredSocAtStartPct reste non ecrete au-dela de 100, l extrapolation utilisant
la pente haute. INPUT_PARSE passe de 17,5 a 16,9 avec la consigne explicite
qu un calcul traversant le genou doit lire la courbe et non cette constante.
Tests du bilan 42/42 apres mise a jour deliberee de six attendus, chacun verifie
a la main contre la courbe. Un libelle corrige : le seuil fixe de 30 % tombait
juste ce matin-la par coincidence, pas par construction. Deux mutations — pente
basse ramenee a la pente haute, puis genou ramene au plancher — font tomber les
six memes scenarios. Golden 78, hysteresis 7 et advisor inchanges.
Les trois nombres sont des resultats de mesure, pas des reglages, et vivent dans
le code avec l outil qui les produit ; a rejouer apres l extension du parc.
Principale erreur restante du bilan, desormais devant la conversion : le profil
de consommation p50 sous-estimait de 33 % les heures 03-06 de la nuit du
02-03/09. A instruire separement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
