Il demandait « quel vehicule ? » a l ouverture d une session de charge. Trop
tard, et ca s est vu ce soir : a 19:55 la voiture est branchee, le selecteur
perime depuis six jours, et aucune question ne peut partir parce qu aucune
session n existe — la borne ne tire rien, il fait nuit. La premiere session de
la nuit serait nee etiquetee VW sans que personne ne soit consulte.
On etiquette desormais le BRANCHEMENT. C est d ailleurs l invariant du projet —
un cable, un vehicule — et ca rend la question possible des l instant ou on sait
qu il y a une voiture.
Deux temps. Le lecteur accepte une clef `branchement` en plus des `sessions`, et
memorise l etiquette dans une table dediee ; une passe differee, a chaque cycle,
la pose sur les sessions du branchement AU FUR ET A MESURE qu elles s ouvrent,
sans nouvelle question. Bornee par le debranchement suivant, avec les deux
secondes de tolerance du 09/09 — une session s ouvre jusqu a 62 ms avant que sa
transition de branchement soit journalisee.
L ancien contrat reste accepte : une etiquette portant des sessions fonctionne
comme avant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le hub reconnait les deux groupes — LED verte et trois bips, son accuse de
reception — mais le Cerbo n en enumere qu un : 4 modules et 400 Ah la ou le parc
en compte 9 et 650.
Le releve de reference apporte le fait qui manquait : a 20:14 les quatre US5000
debitent 24 A au total pendant que le Cerbo annonce 41 A au parc. Les 17 A
d ecart sont le pack 2, qui porte donc bien du courant sans etre enumere. Le
courant mesure au shunt n est pas un indicateur d enumeration — seuls
nombre_de_modules_en_ligne et capacite_installee le sont.
Quatre etapes par risque croissant, la premiere ne touchant a aucun cable : un
redemarrage du Cerbo, l inventaire ayant deja change une fois le 13/09 a 21:35,
evenement isole verifie comme n etant pas un redemarrage de Home Assistant.
Regle de securite tiree de l incident d aujourd hui : fermer EDF AVANT toute
manoeuvre. Couper la communication du BMS arrete la gestion batterie, donc l
onduleur, donc la maison — 72 secondes dans le noir a 16:24. EDF deja ferme, la
maison passe en direct et ne voit rien.
L etape 4 renvoie a la documentation constructeur et n avance aucune theorie de
cablage : sur du materiel batterie je ne raisonne pas de memoire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
L oscillation rapide se calibre sans ambiguite : sur le contacteur reseau, le
plus grand ecart pathologique vaut 193 s et le plus petit ecart normal 857 s,
facteur 4,4 sans aucune valeur entre les deux. Quatre bascules en dix minutes
isole exactement la salve du 12/09 et reste muet sur dix entites pendant dix
jours.
Piege trouve en calibrant : les plus petits ecarts normaux de plusieurs entites
valent 242 a 320 s, c est-a-dire la cadence des workflows. Ce ne sont pas des
oscillations mais deux executions consecutives qui changent d avis — toute
regle a deux bascules en cinq minutes se declenche sur le fonctionnement normal.
En revanche la regle des sessions reseau repetees NE SE CALIBRE PAS : les ecarts
entre fermetures forment un continuum de 4 minutes a 24 heures, sans
discontinuite. Or c est la pathologie la plus couteuse des deux. Je ne pose pas
de seuil dessus : elle demande une formulation metier et plus d historique, et
la bacler serait refaire l erreur que ce projet a payee six fois.
La regle de la mesure figee, elle, se valide sur un incident reel : le 05/09 la
tension et le courant batterie se sont tus 27 minutes pendant que le SOC, issu
du meme flux, publiait toutes les deux minutes. Le discriminant est relatif, pas
absolu — un silence long est normal pour une grandeur intermittente.
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
auteurDeLaTransition filtrait sur x.context_name. Ce champ n existe pas dans le
journal de bord de Home Assistant : la fonction rendait null a tous les coups et
les 416 transitions journalisees portaient un auteur vide. Personne ne s en
etait apercu parce qu un auteur absent ressemble a un auteur inconnaissable.
Le contexte etait la, sous d autres noms, avec trois signatures distinctes
relevees sur des transitions dont je connaissais l auteur : une ligne voisine
script/automation qui se nomme ; un service exterieur dont la rafale se CLOT par
une ligne de narration portant le nom du workflow ET sa raison ; ou une simple
derivation depuis un autre capteur — qui n est pas un auteur et ne doit pas etre
annoncee comme tel.
On balaie vers l AVANT pour trouver la narration : un workflow ecrit ses helpers
puis se journalise, donc vers l arriere on ramasserait celle du precedent.
Verifie sur la seconde ou l Auto Charge Manager et le Water Heater Advisor
ecrivent ensemble — chaque helper revient a son propre workflow, 3 sur 3.
Benefice non cherche : le declencheur porte desormais la raison que le workflow
a lui-meme publiee. C est ce que « expliquer les decisions » reclamait, et
c etait deja dans le journal.
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
Airtria envoie la clef telle que PostgreSQL l affiche — 2026-09-12
11:55:54.493+02 — et la base me la rend en ISO. Meme instant, caracteres
differents : mon Set les comptait deux fois, et le journal annoncait « 2
sessions, dont 1 ajoutee par le branchement » la ou le branchement n en
contient qu une.
L UPDATE resistait, les deux formes se transtypant en timestamptz. Ce qui ne
resistait pas, c est le tableau sessions du detail, qui portait le doublon —
et c est precisement lui que le controle de contradiction interroge sur les
etiquettes suivantes.
Trouve par le journal du service en essai a blanc, trois minutes avant la
bascule du kill-switch. Mon harnais de verification ne pouvait pas le voir :
il comptait les lignes SQL, pas les elements du Set.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Les trois pieces soudees, parce qu aucune ne tient seule. Le defaut de la
colonne passe a faux ; plus rien dans le chemin d ecriture ordinaire ne peut le
mettre a vrai ; le libelle Grafana « selecteur change » devient « a confirmer »,
et le compteur « Etiquette douteuse » devient « A confirmer ».
L ancienne semantique — « le selecteur n a pas bouge pendant la session » — ne
prouvait rien : le selecteur est reste sur VW du 07/09 au 13/09 et les onze
sessions fausses portaient toutes true. La mesure d hier a acheve de la
disqualifier : sur douze branchements, le selecteur n a ete regle au bon moment
qu une seule fois.
Rattrapage des lignes anterieures a faux, sauf les six que le proprietaire a
arbitrees lui-meme le 13/09 — une vraie confirmation humaine, seulement donnee
de vive voix, qu il serait absurde de jeter. Une ligne de journal l explique.
Rien n est deploye : le service tourne encore l ancien code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Treize paquets et dix-sept cartes n existaient qu en un seul exemplaire vivant
sur le partage de 10.10.10.17. La sauvegarde quotidienne les couvre contre la
perte, mais elle ne donne ni diff ni historique : le retrait des initial: du
06/09, les helpers de la reserve d orage, la politique batterie dynamique, la
carte du conseiller reecrite hier n avaient aucune trace de leur evolution.
⚠️ Ce sont des COPIES. La source de verite reste le partage — c est l inverse
de src/nodes/, et le LISEZMOI le dit en tete pour qu une prochaine session
n edite pas la copie en croyant changer l installation.
Verifie avant de verser : aucun identifiant en clair. Le paquet du bilan ne
porte que la DECLARATION de la cle Forecast.Solar, en mode password ; sa valeur
vit dans .storage, qui n entre pas ici.
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
Le proprietaire demande comment suivre l'effet du relevement du plafond.
Verification faite : la DVCC n'apparait que dans deux tableaux de debug, et
l'ecart entre cellules comme le mode des chargeurs solaires n'apparaissent
NULLE PART — alors que ce sont exactement les trois grandeurs a regarder.
Deux capteurs modeles crees (`batterie_qui_limite.yaml`), parce que le
systeme publiait les ingredients sans jamais la grandeur :
- **Ecart entre cellules** : le BMS donne la plus haute et la plus basse,
mais c'est leur difference qui dit si le parc est sain. 2 mV aujourd'hui,
contre 168 mV sur l'ancien module 3 juste avant qu'il fasse effondrer le
courant de tout le monde. C'est le garde-fou d'un relevement de plafond.
- **Chargeurs qui se retiennent** : six entites publient leur regime et
aucune n'etait affichee, alors que c'est le seul signal DIRECT de
ressource refusee — la puissance mesuree etant censuree par construction
sur une installation sans injection. `off` ne compte pas : la nuit tout
est `off` sans que rien ne soit refuse.
Carte « Charge de la batterie — qui limite ? » sur le tableau Bilan : le
courant pris face au plafond que NOUS imposons et a celui que le BMS
autorise, idem pour la tension, puis l'ecart entre cellules et les
chargeurs brides. Avec le mode d'emploi de lecture, parce qu'une carte qui
ne dit pas comment l'interpreter se lit de travers.
Nombre de modules et capacite installee du BMS volontairement absents : ils
ne comptent que le groupe maitre (4 modules, 400 Ah pour un parc de neuf).
Le paquet du concierge vehicule entre aussi dans le depot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
`energie_compteur_kwh` vaut la difference de deux releves du compteur
cumulatif de la borne, proches de 3 800 kWh : en double precision la
soustraction rend « 0.8000000000001819 » pour une mesure dont la resolution
est de 0,1 kWh. Arrondi a l ecriture, au millieme, plutot que de laisser
chaque lecteur s en charger.
Signale par la session OpenClaw en calibrant son module de detection sur la
table. Cosmetique pour la logique, mais ce projet a deja paye le prix de la
fausse precision affichee comme une mesure.
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
Correction de ma propre correction. J'avais mis 09/09 15:55 en JEEP et
laisse les deux sessions suivantes en VW — physiquement impossible, il n'y
a qu'un point de charge et le journal `evenement` montre aucun
debranchement entre mercredi 15:55 et jeudi 09:05.
L'explication du proprietaire est exactement ce qu'aucune regle ne
produira : sa femme a branche la JEEP l'apres-midi, et le soir son fils
n'a PAS debranche pour mettre la VW a la place — il a roule a l'essence le
jeudi. Trois sessions, un seul cable, un seul vehicule, et une decision
humaine que ni l'heure, ni la puissance, ni l'historique ne laissent
deviner.
La reparation passe de quatre a six lignes. Etiquettes finales sur la
semaine : 5 VW, 6 JEEP, 1 MEGANE.
Lecon inscrite dans le commentaire : la frontiere d'un branchement est un
FAIT lu dans `evenement`, jamais un ecart de temps — les creux entre la
session du soir et celle des heures creuses font 5 h 20 et ne se
distinguent pas d'une nuit entiere.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Verification des droits reels : SELECT sur toutes les tables, plus INSERT
sur `evenement` — un octroi deliberé et documente plus haut dans ce meme
README (les annotations qu aucun service ne peut deviner s ecrivent a la
main), mais que deux autres passages decrivaient comme « lecture seule ».
Je l ai moi-meme affirme a un pair qui prepare un acces pour un agent
externe. La consequence est concrete : confier ce role a un tiers lui
donnerait l ecriture sur le journal qui alimente les annotations Grafana,
le rapport de nuit et l attribution des transitions — et ses lignes y
seraient indiscernables des notres.
Pour un tiers : un role dedie, SELECT sur les seules tables necessaires.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le selecteur de vehicule est reste sur VW du 07/09 20:49 au 13/09 : onze
sessions consecutives ont herite de cette etiquette, toutes marquees
« sur » — le drapeau `vehicule_sur` ne passe a faux que si le selecteur
bouge PENDANT une session, donc un selecteur perime reste fiable a ses
propres yeux.
Quatre lignes corrigees, apres arbitrage du proprietaire :
mer 09/09 15:55 6,61 kWh -> JEEP
ven 11/09 16:54 7,45 kWh -> MEGANE
sam 12/09 11:42 0,09 kWh -> JEEP
sam 12/09 11:55 5,94 kWh -> JEEP
La session du 11/09 n'est ni la VW ni la JEEP : 6 360 W a 28 A quand les
deux vehicules du foyer plafonnent vers 3 680 W. C'est une Megane de
service. Ce cas n'etait documente nulle part, et il corrige la doctrine
« vehicules indiscernables » : elle ne vaut que pour la VW et la JEEP l'une
par rapport a l'autre, un vehicule invite se lit dans `p_max_w`.
Les sept autres lignes etaient justes — par chance, la VW etant celle qui
charge le plus souvent.
L'arbitrage a repose sur un contexte qu'aucun capteur ne produit : sa femme
(JEEP) en conges, son fils (VW) en stage sans retour le midi. C'est
l'argument central pour l'agent conversationnel — il dit lui-meme qu'il lui
est plus facile de donner cela par WhatsApp que de venir sur un PC.
Reparation idempotente, fenetre d'une minute, verifiee en lecture avant
ecriture : chaque predicat vise exactement une ligne, energies concordantes.
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
Quand il n y a rien a signaler il n y a pas de piste, et le repli sur le
constat faisait afficher la meme phrase deux fois de suite sur la carte —
et serait parti en double dans la colonne `piste` de la table
d observation, ou elle ne serait plus interrogeable pour rien.
« [95%] rien a creuser » garde la confiance visible et dit la verite.
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
Les treize captures de la soiree du 12/09 : les tentatives sur le LVHUB,
les lectures des deux chaines pendant qu elles etaient separees, puis la
chaine complete une fois les neuf modules reunis. Elles sont la matiere
brute derriere la procedure de mise en service a deux groupes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Ses helpers sont ecrases toutes les quinze minutes : un signalement grave
emis a 3 h du matin avait disparu au reveil, et rien dans la memoire du
projet n en gardait trace. C est precisement ce que le proprietaire
demandait quand il a dit vouloir un outil pour garder une trace des
evolutions — voir un comportement idiot du systeme ne sert a rien si
personne ne peut le relire le lendemain.
Une table `observation`, alimentee par le service d historisation, clef sur
l horodatage du marqueur du conseiller : rejouer un cycle n invente rien et
un conseiller a l arret n ecrit pas la meme ligne toutes les minutes. La
confiance est extraite de `_reason` (« [NN%] la piste ») pour rester
interrogeable sans decouper une chaine en SQL.
`node tools/enquete.mjs observations [heures] [gravite]` ne montre par
defaut que ce qui a ete signale, et compte a part les cycles calmes : un
observateur qui fonctionne est silencieux la plupart du temps, et noyer les
signalements sous des centaines de « rien a dire » les rendrait invisibles.
Essai a blanc : observation=1, le service ecrirait bien sa ligne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Releve par le proprietaire : l extremite etiquetee « BATTERY » va sur le
maitre, celle etiquetee « Inverter » va sur le LV-HUB. Tous les autres
cables de communication Pylontech sont 8 broches droit, donc reversibles ;
celui-ci ne l est pas, et rien sur le connecteur ne le signale.
La raison est dans l annotation du schema constructeur, que j avais
extraite sans en tirer la consequence : « The first 3 pins ON THE PORT OF
BATTERY SIDE should be NULL. » Les broches ne sont coupees qu a UNE
extremite. Inverse, le cable presente un 8-broches complet au maitre et
un cable ampute au hub — les deux erreurs a la fois.
Piege supplementaire : l etiquette dit « Inverter » parce que le cable a
ete fabrique pour relier une batterie a un onduleur ; c est pourtant bien
cette extremite qui va au hub.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Trouvee par le proprietaire apres une soiree de fausses pistes. Le detail
qui debloque tout n est ecrit nulle part dans la documentation Pylontech :
⚠️ LE CABLE MAITRE 1 -> LV-HUB DOIT ETRE DEBRANCHE PENDANT TOUTE
L INITIALISATION. La doc dit « puis connectez le cable » sans preciser
qu il doit etre ABSENT auparavant. Avec le cable en place,
l initialisation ne va jamais a son terme, les trois bips ne se
produisent pas, et le hub reste rouge quoi qu on fasse.
Consigne aussi : les deux cables ne sont pas interchangeables (hub vers
maitre = 3 premieres broches NON connectees, reference 5WRPY01-00132 ;
partout ailleurs 8 broches droit), la semantique des LED du hub (le ROUGE
signale un groupe RETIRE, ce n est pas une panne), et les quatre fausses
pistes suivies ce soir pour ne pas les refaire.
Resultat : 9 modules, SOC 81 %, 130 A charge / 250 A decharge, aucune
alarme, parc declare a 13 equivalents. La reserve utile est passee de
6,8 a environ 22 kWh dans la journee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Les trois modules en panne ont GONFLE. Cela annule le plan d essai a
l alimentation stabilisee propose le 05/09 : un module gonfle a produit
du gaz, il ne se charge pas, ne s ouvre pas, ne se met pas sous tension.
Cible : 5 US2000C (les 4 recents plus K220803C30160323, le module ancien
sain) et 4 US5000, accouples par le LV Hub — soit 13 equivalents.
⚠️ Point le plus important de la procedure : sans batterie, le MultiPlus
s arrete et il n y a plus rien sur AC-out, meme contacteur ferme. La
maison sera hors tension pendant l intervention s il n existe pas de
bypass manuel — et Home Assistant comme n8n tournent sur le .17, alimente
par la maison.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 12/09, le contacteur reseau a bascule six fois en dix minutes. Trouver
le coupable a demande sept requetes enchainees — executions n8n des deux
workflows, liste des ecrivains, puis automations.yaml — parce que la
table des evenements disait QUE ca avait bascule, jamais PAR QUI.
Home Assistant le savait pourtant. Son logbook resout le contexte d un
changement d etat et nomme l auteur. Sur la coupure de 06:29:44 :
auteur : automation.victron_grid_off_si_soc_35
declencheur : triggered by numeric state of sensor.victron_battery_soc
Un appel par transition REELLE — quelques-uns par jour, pas par cycle.
Echec de lecture => pas d auteur, la ligne est ecrite quand meme : on ne
devine jamais.
⚠️ L auteur est colle au RESUME, pas seulement au detail jsonb. C est le
resume que Grafana affiche en annotation sur TOUS les tableaux et dans
les panneaux « journal des evenements », et que le rapport de nuit
reprend. Le mettre la le rend visible partout sans toucher a un seul
tableau.
remonte l auteur et son declencheur : l enquete de ce
matin tient desormais en UNE commande, et l observateur pourra nommer le
coupable au lieu de dire « un des trois ».
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Apres specialisation, l observateur discriminait parfaitement (5/5 dans
les deux sens) mais notait l oscillation « moyenne » au lieu de
« haute » : j avais pose quatre niveaux sans jamais dire ce que chacun
signifie. Defaut de briefing, pas de detection.
L echelle est desormais ancree sur des cas mesures de cette installation
— la consigne reseau qui evince 5,6 kW de solaire pour « moyenne », le
contacteur qui bascule six fois en dix minutes pour « haute » — avec une
regle explicite : UNE OSCILLATION EST TOUJOURS DE GRAVITE HAUTE, parce
que c est la repetition qui fait le degat et que c est precisement ce
qu aucune regle locale ne peut voir.
Mesure apres ancrage : oscillation « haute » 3/3, systeme calme
« aucune » 3/3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
SPECIALISATION. Campagne du 12/09 : lui demander d observer ET de
planifier degradait les deux — l ecart de cible entre passages est passe
de 0 a 35 points sur certains cas des l ajout de la mission
d observation. Il ne planifie plus : la planification est faite par le
bilan, qui est calcule, mesure et teste a 48/48. Sortie reduite a
constat / gravite / ce_qui_cloche / piste. Prompt 7609 -> 6250 caracteres.
Mesure apres specialisation, horloge epinglee : oscillation reelle
detectee 5/5, contrefactuel calme 5/5. La discrimination est parfaite.
⚠️ Mais la gravite est retombee de « haute » a « moyenne » : mon echelle
a quatre niveaux n est ancree sur aucun exemple. Defaut de briefing a
corriger, pas defaut de detection.
Le compteur mesure desormais le VOLUME de signalements : on ne peut pas
verifier automatiquement s il a raison, on peut mesurer s il crie au loup.
COUCHE D ENQUETE. Trouver le coupable ce matin a demande sept requetes
enchainees ; rien n y exigeait un humain, seulement d appeler des outils
et d enchainer d apres ce qu on vient de lire. Six sous-commandes en
LECTURE SEULE, exposees en ligne de commande pour qu OpenClaw — que le
proprietaire veut utiliser — ou tout autre pilote les appelle sans
reecriture : bascules, mesures, decisions, ecrivains, bilan, cherche.
`bascules` calcule l ecart entre transitions successives du meme objet :
c est la signature d une oscillation, et l appelant n a pas a la refaire.
L enquete de ce matin se rejoue en trois commandes, jusqu a
automations.yaml ligne 22.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Essai du 12/09 : avec la seule liste des ecrivains, le conseiller voyait
le conflit mais accusait les deux workflows n8n — l intrus etait une
automatisation Home Assistant. La carte sait lire QUI PEUT ecrire, elle
ne peut pas deviner QUI DEVRAIT : le proprietaire est une decision
humaine, desormais declaree et commentee dans l outil.
Resultat : 3 ecrivains hors proprietaire sur le contacteur reseau, 1 sur
le courant de la borne, 1 sur le verrou. Injectee dans le briefing entre
bornes explicites, regeneree par --injecte.
Le conseiller enonce maintenant la bonne forme (« contradiction entre le
proprietaire et un autre ecrivain ») mais ne nomme toujours pas lequel :
il lui manque l ATTRIBUTION — rien ne relie une bascule a son auteur. Le
contexte Home Assistant distingue un appel de service d une
automatisation ; c est la prochaine piste.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 12/09 : cinq automates ecrivent sur le contacteur reseau, chacun
localement correct, aucun ne voit les autres, et personne n avait la
liste. Une automatisation HA coupait a 35 % de SOC pendant que le bilan
demandait 42,8 % — le conflit a dure sept mois sans etre vu.
Genere depuis les sources (n8n par l API, automatisations, scripts et
paquets HA), jamais tenu a la main : une carte maintenue a la main
pourrit, et c est exactement ce qu on veut eviter. Chaque execution ecrit
un instantane et affiche l ecart avec le precedent — la trace des
evolutions demandee.
Premiere sortie : 4 ecrivains concurrents sur le contacteur reseau,
2 sur le courant de la borne, 2 sur le verrou hysteresis, et dix valeurs
de SOC figees entre 20 et 100 dont le 35 fautif, present six fois.
Destine a etre lu par le conseiller : c est ce qui lui permettra de dire
« cet ecrivain contredit celui-la », au lieu d un detecteur code en dur
qui doublerait une capacite qu il a deja demontree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Idee du proprietaire, et elle est meilleure que la mienne : ce systeme
n a pas besoin qu on lui suggere une strategie de plus, il a besoin que
quelqu un VOIE que « je coupe EDF, non je remets, et hop je coupe » est
absurde. Cinq automates ecrivent sur la meme installation, chacun
localement correct, aucun ne voit les autres. Leurs pannes sont des
CONTRADICTIONS, et elles ne se lisent que dans la SUITE des evenements —
jamais dans un instantane.
Le 12/09 au matin le contacteur reseau a bascule toutes les 4 minutes
pendant dix minutes : une automatisation HA coupait a 35 % de SOC,
l hysteresis rallumait. Aucun automate ne l a vu ; un humain oui.
Sortie elargie : `constat`, `gravite` (aucune/faible/moyenne/haute) et
`ce_qui_cloche`, valides strictement, publies dans trois helpers et dans
le logbook. Le snapshot porte desormais l anciennete des cinq transitions
cles (contacteur, verrou, takeover, etat EVCS, mode ACM).
⚠️ VALIDATION SCINDEE. Essai sur l oscillation reelle : le modele a
produit un constat JUSTE et un `current_max_a` de 100, hors bornes. La
validation tout-ou-rien jetait le diagnostic avec le champ fautif —
c est-a-dire exactement ce qu on lui demande, perdu a cause de ce qu on
ne lui demande plus. Les champs d ACTION gardent leurs bornes mais sont
NEUTRALISES au lieu de faire echouer l observation ; `actionUtilisable`
est le seul drapeau qui autoriserait un jour un cablage, et les compteurs
ne comptent que lui.
Tests advisor : +6. Deux attendus mis a la nouvelle semantique dans le
meme commit (hors bornes -> observation gardee, action neutralisee).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Diagnostic du proprietaire, et il est juste : le conseiller n est pas
utilisable parce qu on lui donne des consignes fausses et des informations
partielles.
CONSIGNES FAUSSES. Son briefing enoncait mot pour mot la regle des paliers
(« forecast fort >= 18 kWh => cible ~35 % »), celle que le bilan a demontree
fausse le 03/09. Il declarait 17,5 kWh de batterie (mesure : 6,8 sur quatre
modules) et 9 kWc de panneaux (16,1 en realite). Retires. La capacite est
desormais CALCULEE depuis la courbe mesuree et le parc declare.
INFORMATIONS PARTIELLES. Il ne recevait AUCUNE sortie du bilan. Il ignorait
donc l heure de croisement, l energie a couvrir et le SOC requis -- les
seules grandeurs sur lesquelles la question se decide. +23 champs au
snapshot : bilan complet, parc, limites BMS, consigne reseau, modes des
chargeurs solaires, vehicule selectionne.
Ajoute aussi ce que personne ne lui disait : sans vehicule branche il y a
quand meme quelque chose a decider (c est la maison qui traverse la nuit),
les chargeurs declarent eux-memes s ils se brident, la cuisson du soir se
decale de trois heures, l hiver la nuit est plus longue de deux heures en
temps solaire.
PREUVE. Rejeu de la nuit bloquee du 12/09 a 04:00, sans aucune aide :
avant auto_solar_plus, cible 35 %, « prevision forte => cible basse »
apres force_grid_now, cible 60 %, « bilan exige 3.13 kWh avant 09h »
Le bilan demandait 59,1 %. En production a la meme heure, il n avait rien vu
-- quatre fois de suite.
COMPTEUR. Il comparait la STRATEGIE, constante a auto_solar_plus : 517
accords contre 23, soit 95,7 % — un score qui mesurait une constante. Il
compare desormais la CIBLE, contre le BILAN, et ne compte rien quand le
bilan est indisponible plutot que de compter faux.
Tests advisor : 3 nouveaux sur le compteur (ecart 2 pts -> accord, 13 pts ->
divergence, bilan indisponible -> aucun comptage). Perimetre mode ombre
inchange et toujours verifie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le dashboard affichait « capacite batterie utile 15 kWh » a cote d un parc
de 4 US2000C. Le proprietaire l a releve : le chiffre est faux, et il ne
pilote rien -- depuis le 03/09 la capacite se deduit de la COURBE mesuree
mise a l echelle du parc declare, et ce helper n est plus lu que comme
garde de completude du bilan. Retire de la carte, remplace par la valeur
calculee (6,8 kWh a 4 equivalents, 20,3 a 12).
Et j avais introduit une incoherence hier en portant le max du helper a
24 : le controleur et le bilan retombaient sur 7 au-dessus de 16, soit une
erreur d un facteur 3 sur la capacite, en silence. Les trois bornes sont
alignees a 24.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Quatre US5000 arrivent aujourd'hui. Les bandes de politique batterie sont
en amperes ABSOLUS (souple -50 A / dur -100 A au-dessus de 90 % de SOC,
etc.) et decrivent le parc de 4 modules sur lequel elles sont en vigueur
-- l'arret dur du 11/09 a mordu au bon endroit, 87 A pour une limite de
70. Les garder telles quelles briderait un parc trois fois plus gros au
niveau de l'ancien.
Deux lectures, aucune table reecrite :
- ECHELLE : le parc DECLARE (`evcs_balance_modules_en_service`, en
equivalents US2000C -- un US5000 en vaut DEUX), le meme helper que la
capacite utile et que le bilan energetique. Une seule valeur a tenir a
jour, et les trois consommateurs restent forcement d'accord.
- PLAFOND : ce que le BMS declare accepter a l'instant
(`maximum_allowed_discharge_current` / `_charge_current`, nouvellement
lus dans le snapshot). On ne s'autorise jamais plus.
⚠️ On ne met PAS a l'echelle sur la limite BMS lue en direct : elle
s'effondre quand une cellule monte en tension (04/09 : plafond de charge
de 150 a 20 A en cinq secondes). Une regle de confort ne suit pas un
signal aussi nerveux ; elle se plafonne dessus, c'est tout.
Parc absent ou BMS illisible => echelle 1, plafond inactif, comportement
inchange. C'est pourquoi les 95 scenarios existants passent sans
modification.
Golden 95 -> 98. Mutation : echelle neutralisee -> seul
`parc-double-decharge-toleree` tombe ; plafond BMS ignore -> seul
`parc-double-plafond-bms` tombe.
Verifie en production : execution 05:28:30 en succes, le gabarit rend
bms_max_discharge_current_a=100, bms_max_charge_current_a=100,
modules_en_service=4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit du 11-12/09, vehicule rendu la veille : le bilan a reclame entre
92 % et 59 % de SOC a CHAQUE calcul de la nuit, `reseau_necessaire` vrai
partout, et rien ne s'est passe. SOC fige a 20 % de 23:43 a l'aube,
consigne reseau a 700 W depuis 18:36 -- soit exactement la maison.
L'hysteresis avait bien ferme le contacteur (SOC <= 20), mais fermer le
contacteur ne suffit pas : il faut DEMANDER la puissance (lecon du
01/09). Personne ne la demandait, parce que la session reseau de nuit
exigeait un vehicule branche.
Or le besoin n'a rien a voir avec la voiture : c'est la MAISON qui doit
traverser la nuit, et le bilan sait exactement ce qu'il lui faut. La
fenetre HC suffit comme condition d'engagement. Le relachement reste la
fin de fenetre, donc monotone, donc toujours immune a l'oscillation
(§40) -- la mutation le verifie.
Cout evite : a 07:24 le SOC etait encore sous le seuil OFF de
l'hysteresis (30), donc le contacteur serait reste ferme et la maison
serait passee au PLEIN TARIF jusqu'au croisement PV de 9 h. C'est le
1,49 kWh deja consigne le 03/09.
Golden 91 -> 95. Mutation : exigence de vehicule retablie -> seul le
scenario d'incident tombe ; borne de fenetre retiree -> le scenario de
fin de fenetre du 03/09 tombe AUSSI, donc la monotonie est bien testee.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Incident 11/09 18:00, voiture a 28 A : la descente avait amene la
consigne a 1281 W alors que le solaire portait tout (PV 6058 W, reseau
1163 W). Un nuage a fait chuter la PV de 4,6 kW en une minute ; le reseau
etant plafonne a 1281 W, toute la difference est tombee sur la batterie
-- 87 A pour une limite dure de 70 -> `battery_current_hard_stop`, charge
coupee, redemarrage a 6 A.
Sans injection la production peut s'effondrer de plusieurs kW en quelques
secondes, et une boucle a 30 s ne rattrape pas cela : le reseau doit etre
DEJA autorise a prendre le relais. Second plancher : la consigne ne
descend jamais au point ou la perte totale du solaire depasserait ce que
la batterie sait encaisser, budget pris sur la politique par bande de SOC
(§35) avec 20 % de marge sous la limite DURE -- c'est elle qui coupe.
Sur le releve de l'incident, le plancher vaut 4829 W : au moment du
nuage la batterie n'aurait pris que 28 A au lieu de 87.
Contrepartie assumee : a 28 A la descente est nettement moins profonde
qu'a 6 A. C'est proportionne, le courant de la voiture est ce qui cree
l'exposition -- et proteger le materiel prime sur les kilowattheures.
Golden 90 -> 91. Mutation : plancher retire -> 2 scenarios tombent ;
budget pris sur la limite souple au lieu de la dure -> 3 tombent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Premiere version du credit solaire, en production 12 minutes : la
consigne descendait bien a 2241 W et la PV remontait a 7074 W, puis tous
les chargeurs repassant `mppt_active`, la condition de descente devenait
fausse, le besoin revenait au plafond et la consigne etait REECRITE a
7100 W. La PV s'effondrait a 1785 W, les chargeurs se bridaient, on
redescendait. Oscillateur de periode ~5 min -- le sixieme du projet, et
celui-ci vient de moi.
Releve : 17:40:30 -> 2241 / 17:47:19 -> 7100 / 17:47:28 PV 1785 /
17:48:30 -> 7368 / 17:49:30 -> 2186 / 17:50:30 -> 3762.
Une fois descendue, la consigne est TENUE tant que le solaire produit.
Rien a memoriser : la valeur vit dans le GX, et le plancher maison la
fait remonter d'elle-meme si la maison grossit. La nuit les chargeurs
sont `off`, donc ne produisent pas : on retombe sur le comportement
historique ou la consigne monte au plafond pour que le reseau porte
maison et voiture (§31, §57).
Golden 89 -> 90. Mutation : remettre le besoin au plafond fait tomber le
seul scenario `consigne-credit-converge-tient` ; appliquer le maintien la
nuit fait tomber les TROIS scenarios de session reseau nocturne, dont
deux anterieurs a ce chantier.
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
Le format « une ligne par grandeur » etait illisible, et la hauteur du panneau
n'en montrait que trois sur sept. Le tableau rend desormais une ligne
d'en-tetes et une ligne de valeurs, ce qui est la forme attendue pour un
resume.
C'est toujours un panneau `table` et pas un `stat` : ce dernier, sur exactement
cette requete, affichait sept « — » alors que l'API montrait qu'il recevait
sept champs de type number avec leurs valeurs. Une note le rappelle dans le
generateur pour ne pas y revenir.
Les unites reviennent en overrides puisque les libelles n'ont plus a les
porter, avec deux colorations utiles : le reseau importe passe a l'ambre au-dela
de 3 kWh et a l'orange au-dela de 8, l'autonomie a un fond vert au-dessus de
85 %.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Quatre tentatives sur le panneau stat : selecteur de champs, unites, bornes de
l'axe, GROUP BY, retrait de la colonne texte et de son override. A chaque fois
sept « — » a l'ecran.
L'acces a l'API Grafana, obtenu entre-temps, a tranche : /api/ds/query montre
que le serveur renvoyait bien sept champs de type number avec leurs valeurs, y
compris sur la fenetre exacte de la derniere capture. Ce n'etait donc ni la
requete, ni le cache du navigateur, ni le provisioning — md5 du fichier servi
et version en base verifies. Le panneau recevait les donnees et ne les rendait
pas.
Le bilan sort desormais en LIGNES, une par grandeur, dans un panneau table :
celui-ci affiche toujours ce qu'il recoit, et le format se lit tres bien pour un
bilan. L'unite est portee par le libelle, ce qui permet de melanger kWh et
pourcentage dans la meme colonne.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
L'API Grafana, enfin accessible, a montre que le serveur renvoyait bien une
ligne de valeurs au panneau : le defaut etait donc dans le rendu, pas dans la
donnee. Restaient deux elements que le panneau « Sur la periode » des vehicules,
lui fonctionnel, n'a pas : une colonne de texte dans le resultat, et un override
`custom.hidden` pose pour la masquer — propriete qui n'existe pas sur un
panneau stat.
Les deux disparaissent. Le GROUP BY, lui, reste necessaire et s'ecrit desormais
sur une expression constante, `GROUP BY (1 = 1)`, qui ne demande aucune colonne
dans le SELECT. PostgreSQL refuse `GROUP BY true` (non-integer constant) mais
accepte cette forme.
Verifie par l'API sur la fenetre « Last 24 hours » : sept champs, tous de type
number, valeurs presentes.
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 panneau rendait sept « — » malgre trois tentatives : correction du selecteur
de champs, ajout des unites, bornes de l'axe tirees des donnees au lieu des
macros de temps. Verifie entre-temps que ce n'etait ni le cache du navigateur
ni le rechargement — le md5 du fichier servi par Grafana est identique a celui
du depot — et que le serveur ne journalisait aucune erreur de requete.
Il ne restait qu'une difference structurelle avec l'histogramme du meme
tableau, qui partage exactement les memes CTE et s'affiche sans probleme :
celui-ci groupe par heure, le bilan agregeait globalement. Le bilan groupe
desormais sur une colonne constante, masquee a l'affichage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
