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
La colonne du tableau affichait 2022 et 2023 - les annees gravees dans
les codes-barres - quand le texte parlait de 2023 et 2025, les annees
d'achat. Un lecteur y voyait deux jeux de dates contradictoires. La
colonne donne desormais la date d'achat, seule pertinente pour une
garantie. Et « les modules de 2023 » designait en fait le premier lot.
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
Facture 190002543 du 27/04/2023 : quatre US2000C a 940 EUR HT, avec
l'ensemble de l'installation Victron et le forfait de parametrage ESS
realise par le vendeur.
Cela renforce l'argument central : le module temoin n'est pas
seulement du meme parc, il vient de la MEME facture, de la meme
livraison et du meme jour de mise en service que les trois modules
degrades. Quatre modules d'un meme lot ont vecu la meme vie ; trois se
sont abimes, le quatrieme non.
Trois ans et quatre mois de service, bien en deca de la garantie de
cette gamme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Un distributeur qui transmet au constructeur ne doit dependre d'aucun
lien exterieur, et le destinataire final lit peut-etre le chinois
plutot que le francais. Les trois versions HTML rejoignent donc
l'envoi, et le courrier decrit sa piece jointe au lieu de proposer de
la fournir.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le linger systemd aurait fait demarrer une douzaine de services
graphiques sans session ouverte - gnome-remote-desktop et le trousseau
compris. Le proprietaire a tranche pour une entree @reboot qui ne
relance que ce releve.
Consequence technique : on ne peut pas passer par systemctl --user,
qui echouerait faute de gestionnaire de services au demarrage. Le
script fait donc lui-meme le travail d'un superviseur : garde
anti-doublon - deux processus sur le meme port entrelacent leurs
lectures et produisent des relevés faux sans que rien ne le signale -
attente si le port n'est pas encore la, redemarrage apres echec, et
journal tronque au-dela de cinq megaoctets.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le suivi n'ecrivait que l'adresse du module, traduite a l'import par
une table figee sur le pack ancien. Le cable ayant change de pack,
tout releve fait maintenant aurait ete attribue aux mauvais modules.
Le code-barres est desormais resolu au demarrage et ecrit dans le CSV ;
la table ne sert plus qu'aux anciens fichiers.
Le releve tourne sur le poste qui porte le cable serie - le port USB
est la, pas sur le Synology - et n'ecrit qu'un CSV dans le depot
partage. C'est le service d'historisation, cote Synology, qui le verse
en base : le poste n'a donc aucun mot de passe a connaitre.
Archive pour le constructeur : un dossier par code-barres, plus un
manifeste en francais, anglais et chinois qui dit ou regarder en
premier et signale que les CSV sont deja corriges de la derive
d'horloge des BMS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Redige pour un distributeur qui le transmettra au constructeur : les
faits d'abord, la demande ensuite, et surtout les trois elements qui
ecartent une cause d'installation - le module temoin de la meme
chaine a zero evenement, le pack de 2023 en a 38 pour 340 cycles, et
les passages sous le seuil bas surviennent a 34-41 % de SOC parc,
donc en fonctionnement normal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Quatre modules : le BMS annonce 100 A de decharge sous 51 V, soit
5,1 kW, quand la maison a deja pointe a 8 kW en cuisinant. Contacteur
ouvert, la batterie est seule et se fait tirer au-dela de sa limite.
Le declenchement porte sur la CHARGE MAISON, jamais sur le courant
batterie : fermer le contacteur fait chuter ce courant, donc s'en
servir comme critere de relachement ferait que la decision detruirait
sa propre cause. Fermeture a 80 % du plafond, relachement sous 50 %,
les deux seuils derives du plafond annonce par le BMS - ils suivront
donc le parc sans qu'on y touche.
Les tests ont revele un vrai defaut au passage : les trois coupures
immediates s'executent avant la cascade et auraient ouvert le
contacteur que la regle venait de fermer. Elles cedent desormais
devant la charge maison. Preuve par mutation : sans cette garde, un
scenario tombe.
Plafond illisible => regle inerte, comportement historique intact.
11/11.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le GX a pris le retrait du pack ancien : quatre modules vus, plafond
de decharge 150 -> 100 A, soit environ 5,1 kW. La maison a deja pointe
a 8 kW en cuisinant le soir, contacteur ouvert. L'alarme de courant de
decharge et le plafond lui-meme entrent donc dans l'historisation :
c'est la question ouverte de la semaine.
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
La courbe energie/SOC a ete mesuree sur sept modules. Retirer un
module divise la capacite sans changer la forme de la courbe : les
pentes sont donc mises a l'echelle du nombre reellement en service,
lu dans input_number.evcs_balance_modules_en_service. Le controleur
EVCS lit le meme helper pour sa capacite utile - les deux decrivent
forcement le meme parc.
Helper absent, illisible ou hors bornes => sept, la valeur de la
mesure. Les 44 scenarios du bilan et les 80 golden passent donc sans
qu'un seul attendu ait ete touche : la bascule ne change rien tant
que personne ne l'ecrit.
Deux scenarios couvrent la bascule elle-meme, l'un avec quatre
modules (SOC exige 30,5 -> 35,2 %), l'autre avec une valeur
aberrante qui doit retomber sur sept. Preuve par mutation : ignorer
l'echelle fait tomber le premier et lui seul.
Le genou a 33 % est conserve par PRUDENCE et non par mesure :
l'hypothese est qu'il vient des cellules faibles du pack retire, donc
qu'il disparait avec lui. Le garder revient a sous-estimer la
reserve, c'est-a-dire a se tromper du bon cote.
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
Le BMS tient deux tampons distincts et je n'avais extrait que l'un
des deux. history echantillonne toutes les trente minutes sur cinq
semaines ; event n'enregistre que les declenchements, a la seconde,
et remonte jusqu'a mai 2025.
C'est le second qui porte la preuve : le 27/07 sur le module ...0319,
quatre declenchements en trois minutes, cellule haute a 3650 mV. Et
il couvre seize mois, donc il contient le moment ou ces cellules ont
ete abimees.
Premier ecart, sans aucune interpretation : les quatre modules du
pack recent totalisent 38 evenements depuis mai 2025 - 19, 12, 6 et
1. Le module abime en compte 805 a lui seul.
--tampon event ajoute au mode d'extraction distante. Le garde pose
plus tot a d'ailleurs fonctionne : un module a refuse de partir sans
code-barres plutot que de rendre un fichier anonyme.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le generateur separe desormais les MESURES des MOTS : les chiffres
vivent dans gen-rapport-batteries.py, les trois langues dans
rapport_textes.py. Une correction de traduction ne peut donc pas
toucher un chiffre, ni l'inverse - et les trois versions partagent
exactement les memes donnees puisqu'elles lisent la meme source.
La version destinee au fabricant gagne une section que la francaise
n'avait pas : trois questions precises, sur la recuperabilite des
cellules face a leur composante resistive, sur la procedure
recommandee pour un module dans cet etat, et sur ce que compte
exactement le SOHCount par cellule.
Le chinois charge Noto Sans SC et desserre l'interligne ; les mesures
de colonne passent en em plutot qu'en ch, un caractere han n'ayant
pas la largeur d'un zero.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Quatre modules, ecart median de 2 mV chacun, et soixante cellules dont
les amplitudes tiennent toutes entre 168 et 191 mV. Il n'y a rien a
chercher ailleurs que dans les trois modules deja nommes.
Trois des quatre extractions sont sorties sans horloge ni code-barres :
une extraction precedente se deversait encore sur la ligne, et la
premiere commande lisait ces restes - qui contiennent un 168143 - en
croyant avoir sa reponse. La ligne est desormais purgee avant le
reveil, et l'outil refuse de partir sans savoir de qui ni de quand il
parle plutot que de rendre douze minutes inexploitables.
Les trois fichiers ont ete repares : meme chaine, donc meme decalage
de 373 minutes, verifie sur le module dont le dernier enregistrement
tombe a la fin de son extraction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Un module extrait par --historique-distant porte des horodatages lus
au chronometre ; ses vieux exports texte reposent sur une deduction.
Importer les deux pour le meme module poserait deux series decalees de
plusieurs heures, illisibles. L'importeur ecarte donc le texte des
qu'un releve exact existe pour ce code-barres.
--remplacer efface aussi les lignes rangees sous un nom provisoire du
type pack_ancien:2, sans quoi le module nomme et son fantome
coexisteraient dans les listes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
datalist reste local, mais data <adresse> history <n> est adressable
et rend l'enregistrement complet, quinze cellules comprises. Les trois
modules de la chaine ancienne sont donc extraits d'un seul
branchement, tous corriges du meme decalage lu au chronometre : 369
minutes. Les jeux sont enfin comparables entre eux, ce que les
decalages deduits - divergents de deux heures et demie - ne
permettaient pas.
Le module d'adresse 2 donne le temoin qui manquait : meme chaine,
memes courants, memes journees, et ses quinze cellules tiennent dans
onze millivolts d'amplitude les unes des autres, ecart median 6 mV.
Ce qui a tue les autres ne vient donc ni du regime de charge, ni du
pilotage, ni de l'installation.
Sur cette base commune la cellule 14 du module ...0322 passe a 273 mV
et rejoint les atteintes : dix cellules, pas neuf.
L'horloge se propage bien du maitre a sa chaine - j'avais conclu
l'inverse en verifiant une seconde apres l'ecriture, il en faut vingt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
K220803C30160323 complete l'inventaire : les huit modules sont nommes.
La carte adresse -> code-barres ne vaut que pour la chaine du pack
ancien, le pack recent renumerotant lui aussi de 1 a 4 ; l'appliquer
a l'autre chaine attribuerait ses relevés aux mauvais modules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le module ecrit une heure de mur LOCALE. Je l'interpretais comme de
l'UTC, ce qui ajoutait exactement le decalage de Paris a chaque
decalage deduit : d'ou les +7 h 27 et +9 h 59 qui semblaient absurdes
et qui, corriges, tombent sur les valeurs mesurees au chronometre.
La deduction redevient donc fiable, et chaque export voit desormais
son dernier enregistrement atterrir sur l'heure de l'export lui-meme.
Les valeurs mesurees restent en commentaire pour controler la
deduction, pas pour la remplacer.
--remplacer efface les lignes du module avant de reinserer : corriger
un decalage AJOUTAIT sinon une seconde copie decalee, la cle primaire
portant l'instant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Genere par script pour que les mesures restent en tete du fichier et
la mise en page en dessous : mettre a jour une valeur, relancer,
republier.
La figure centrale trace l'amplitude balayee par chaque cellule. C'est
la grandeur qui separe une cellule saine d'une cellule morte sans
demonter quoi que ce soit : une cellule ayant perdu sa capacite se
remplit et se vide avant ses voisines, donc elle balaye une plage bien
plus large a courant identique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le GX n'expose que l'agregat du parc : les quinze tensions d'un module
ne sortent que par la console de son BMS. Le tableau les trace, avec
les paliers d'alarme du materiel lui-meme - 3480, 3520, 3550, 3600 mV
- et met la cellule meneuse en regard du plafond de charge.
Le plafond impose par le BMS, grandeur centrale de tout ce diagnostic,
n'etait pas historise : il l'est desormais, comme l'alarme de tension
de cellule. Ils manquaient tous les deux a la memoire.
Les quatre requetes cellule echouent tant que la table n'existe pas ;
elles passeront apres redemarrage du service et import.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Nouvelle table cellule, indexee par CODE-BARRES et non par adresse :
chaque chaine renumerote ses modules a partir de 1, il existe donc
deux « module 1 » dans ce parc.
L'importeur lit les exports d'historique et les CSV de suivi. Deux
pieges corriges en le construisant : le tampon du BMS est circulaire,
donc le plus grand index n'est pas le plus recent - trier par index
donnait un decalage deduit de -865 h ; et les fichiers d'evenements
portent les memes colonnes sans decrire un echantillonnage regulier,
ils sont ecartes.
La deduction du decalage d'horloge reste approximative : sur BAT3 elle
donne huit heures la ou le chronometre en donne six. La console
inscrit desormais le decalage en tete de chaque export, mesure a la
seconde ou il commence ; l'importeur le prefere toujours a sa propre
deduction.
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
--modules 1,2,3 interroge chaque adresse avec soh, qui donne les quinze
tensions et le compteur de sante par cellule. Sans cet argument on ne
lisait que le module portant le cable, alors que l'adressage a distance
permet de couvrir toute la chaine.
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
Le cable pose sur le hub revele un LVHUB en SysError 0xe000 : courants
de charge et de decharge autorises a zero, tension de coupure basse a
396,8 V, table des unites remplie de valeurs de remplissage, horloge
jamais sortie de 2000-01-01, et un journal de dix-neuf entrees qui ne
contient que « System is restarting » et « System Reset ».
Le parc, lui, fonctionne : SOC 70 %, charge a 23 A, aucune alarme. Le
GX ne lit donc pas le hub - il lirait zero ampere autorise et rien ne
chargerait.
Gain annexe : sysinfo donne l'echelle d'alarme reelle du materiel,
3480 / 3520 / 3550 / 3600 mV en haut et 3100 / 2900 en bas. Le seuil
de 3550 utilise dans l'analyse etait le bon, mais par chance ; il est
desormais reference.
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
La machine Windows 10.10.10.93 porte le cable console et fait tourner
BatteryView. Elle ne repond qu'en SMB : il n'y a rien a interroger a
distance, l'application gardant le port COM pour elle seule.
"help" est une commande de la console serie du BMS, pas une fonction de
BatteryView. Il faut fermer BatteryView pour y acceder, le port etant
exclusif.
Dossier de depot des exports cree, avec la fenetre de capture utile :
a SOC eleve, en pleine charge. En dessous de ~70 % les cellules d'un
LiFePO4 lisent la meme tension et un releve ne peut rien montrer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Quatrieme valeur : « Session », le compteur de la BORNE, celui qui vaut les
8 kWh de VRM et compte depuis le vrai debut de la charge.
Il vient de PostgreSQL et non d'InfluxDB : `sensor.evcs_hq2239dnt7p_*` n'est
pas dans les globs d'entites envoyees a InfluxDB. Plutot que de redemarrer Home
Assistant pour l'y ajouter — en pleine charge, a 4 h du matin — la valeur est
reprise de la table `session_charge`, ou elle est deja enregistree. Le panneau
passe donc en source « Mixed », chaque requete portant la sienne.
La session n'est affichee que si elle date de moins de deux heures : au-dela,
la case reste vide plutot que d'exhiber le reliquat d'une charge terminee la
veille — meme principe que la fenetre de lecture des autres panneaux.
La premiere rangee passe a sept unites de hauteur et la Batterie a neuf
colonnes : quatre et cinq valeurs cote a cote redevenaient illisibles a cinq
unites, c'est le defaut deja corrige une fois sur ce meme panneau.
54/54 requetes verifiees. Valeur attendue a l'ecran : 8,30 kWh.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le tableau annoncait 750 Wh la ou VRM affichait 8 kWh. Ce n'etait pas une
erreur de mesure mais une erreur de SOURCE : j'integrais la puissance depuis le
moment ou mon detecteur avait commence a fonctionner — 03:16 — pour une session
ouverte a 01:25.
Or la borne tient son propre compteur de session,
`sensor.evcs_hq2239dnt7p_last_session_energy`, qui vaut exactement les 8,0 kWh
de VRM et compte depuis le vrai debut. Nouvelle colonne
`energie_station_kwh` : c'est elle qui alimente desormais les totaux et le
graphique.
Mon integration est conservee en colonne « kWh integres » : l'ecart entre les
deux signale un demarrage ou un redemarrage du service en cours de session, ce
qui est une information en soi. Et elle sert de secours si la borne ne publie
rien.
Cherche au passage, sans succes : VRM affiche « Vehicule : Guest EV » mais
AUCUNE entite ne porte ce champ cote Home Assistant. « Guest EV » signifie
d'ailleurs vehicule NON identifie — Victron ne sait pas non plus qui est
branche.
50/53 : les trois requetes en echec portent sur la nouvelle colonne, que la
migration creera au prochain demarrage du service.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
« No data » sur le panneau Chargeur PV a 03:20 : la production avait ete ecrite
pour la derniere fois au coucher du soleil, 370 minutes plus tot, et ma fenetre
etait de 6 h. La valeur zero etait pourtant exacte et connue.
C'est la seconde erreur sur ce meme reglage, en sens inverse de la premiere :
- trop LARGE partout (7 jours), le panneau Reseau affichait un courant vieux de
quatorze heures, parce que ces capteurs passent en `unavailable` quand AC-IN
s'ouvre au lieu de tomber a zero ;
- trop ETROITE partout (6 heures), les entites qui publient un vrai zero au
repos disparaissent de l'ecran alors que leur derniere valeur reste juste.
Il n'y a donc pas de bonne valeur unique. Regle inscrite dans le generateur :
fenetre LARGE (24 h) pour ce qui publie un vrai zero — production PV, borne a
l'arret, trackers ; fenetre COURTE (6 h) pour ce qui disparait, c'est-a-dire
les seules grandeurs du reseau.
Consigne au passage dans le manuel : le proprietaire possede une troisieme
monture, une moto electrique Zero Motorcycles SR/F, a ajouter au selecteur fin
septembre. Avec la remarque qui compte : sa batterie et son chargeur embarque
etant bien plus petits, elle sera peut-etre le premier vehicule du foyer
electriquement distinguable des deux autres.
53/53 requetes verifiees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le service ne journalise que lorsqu'il a ecrit quelque chose. `--tail=5`
affiche donc les cinq dernieres lignes quelles qu'elles soient, y compris des
erreurs anterieures au redemarrage : le proprietaire a relance la commande
quatre fois devant un ecran fige montrant des erreurs deja corrigees, alors que
le service tournait normalement.
`--since 2m` borne le temps et non le nombre de lignes. Ajout aussi de la
verification qui ne ment pas, parce qu'elle regarde le resultat et non le
journal : la fraicheur et l'energie accumulee de la derniere session.
Etat verifie a l'instant : derniere mise a jour il y a 19 s, 0,345 kWh
accumules sur la session JEEP en cours, 18 mesures sur les trois dernieres
minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
`operator is not unique: unknown * unknown`. node-postgres envoie ses
parametres SANS type ; multiplier deux d'entre eux ne permet pas a PostgreSQL
de choisir un operateur.
Et contrairement a ce que j'ai d'abord annonce, ce n'est pas l'ajout de la part
reseau qui a casse la ligne : les DEUX lignes en souffraient. La premiere
version du detecteur de session n'a jamais reussi un seul UPDATE — la session
enregistree a 02:56 affichait 0,000 kWh avec fin = debut, seul l'INSERT avait
abouti. Verifie en rejouant les trois formes contre la vraie base : l'ancienne
echoue, la nouvelle passe.
Lecon consignee dans le README : l'essai a blanc remplace l'envoi a la base par
un compteur, donc il valide la logique et JAMAIS le SQL. Une erreur de typage y
est invisible par construction. D'ou la regle — tout parametre entrant dans un
calcul porte son ::float8 — et l'obligation de lire le journal du conteneur
apres chaque deploiement du service.
Tableaux : 53/53 depuis que la colonne existe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Demande du proprietaire : voir ce que la JEEP ou la VW encaisse dans une
session, et evaluer sur une periode (jour, semaine, mois), en assumant
l'imprecision liee a l'impossibilite d'identifier le vehicule au branchement.
Trois panneaux : les totaux par vehicule sur la periode, l'energie par periode
et par vehicule avec le meme pas adaptatif que les autres tableaux (heure /
jour / mois), et la liste des sessions.
L'incertitude est AFFICHEE plutot que masquee :
- un compteur « Etiquette douteuse » — sessions ou le selecteur a change en
cours de route, ou n'etait pas renseigne ;
- une colonne « Doute » dans le tableau ;
- une serie « Non etiquete » dans le graphique ;
- l'heure de debranchement, qui confirme apres coup puisque les deux vehicules
partent a des heures differentes.
Le commentaire du generateur consigne pourquoi aucune verification n'est
possible : electriquement les deux voitures sont indiscernables (3 680 contre
3 655 W a consigne identique de 20 A), et horairement la routine s'inverse le
week-end, donc une regle horaire serait fausse un week-end sur deux.
Ajout a la table : `energie_reseau_kwh`, la part venue du reseau, fondee sur le
`source_mode` du controleur — son intention — et non sur la puissance reseau
instantanee, laquelle peut alimenter la maison pendant que le soleil alimente
la voiture.
52/53 requetes verifiees. La seule en echec porte sur cette nouvelle colonne,
que la migration creera au prochain demarrage du service.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
L'etiquette du vehicule n'existe QUE pendant la session.
`input_select.victron_evcs_vehicle` est un reglage manuel, il change, et rien
ne conservait sa valeur au moment ou la charge avait lieu — une session d'il y
a trois semaines etait anonyme pour toujours, et toute analyse d'usage
impossible.
Nouvelle table `session_charge` : debut, fin, vehicule tel que le selecteur
l'indiquait PENDANT la session, un drapeau disant s'il a change en cours de
route, energie accumulee, puissance et courant maximum, mode source, et
l'heure de debranchement — qui confirme apres coup, les deux vehicules partant
a des heures differentes.
Le service applique lui-meme la migration au demarrage : `schema.sql` n'est
joue qu'a la creation de la base, une table ajoutee plus tard n'y arriverait
jamais. `CREATE TABLE IF NOT EXISTS` rend l'operation rejouable.
On ne DEVINE rien, et le commentaire du schema dit pourquoi :
- electriquement, la VW accepte 3 680 W et la JEEP 3 655 W a consigne
identique de 20 A — 0,1 A d'ecart, indiscernables ;
- horairement, la routine s'inverse le week-end (la femme du proprietaire
travaille samedi et dimanche matin), donc « midi = JEEP, nuit = VW » serait
faux un week-end sur deux.
Essai a blanc : la session en cours serait correctement inscrite (JEEP,
3396 W, Reseau force, profil night_hc).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Recherche d'un signal permettant d'identifier automatiquement le vehicule
branche, a la demande du proprietaire. Resultat NEGATIF, et il merite d'etre
consigne pour qu'on ne le recherche pas deux fois.
Mesure sur deux sessions a consigne identique de 20 A, etiquetees par le
proprietaire : la VW accepte 3 680 W, la JEEP 3 655 W. Vingt-cinq watts
d'ecart, 0,1 A. Les deux embarquent un chargeur de 3,7 kW et saturent au meme
endroit. Ni la puissance de plateau ni le taux d'acceptation de la consigne ne
les separent.
La piste de la latence de demarrage est inexploitable : la table `decision` ne
commence qu'a 01:37 le 04/09, donc l'ordre de demarrage de la session VW de
cette nuit-la n'a pas ete enregistre et les 761 s calcules sont un artefact.
Ce qui EST un signal, et c'est le proprietaire qui l'apporte : la routine du
foyer. La JEEP charge le midi en semaine (sa femme rentre dejeuner), la VW le
soir et la nuit (son fils part a 9 h). Forte presomption, pas certitude — cette
nuit meme, un samedi, c'est la JEEP qui charge.
Consigne dans MANUEL_COMPLET §0, avec le rappel que le selecteur manuel reste
le seul etiquetage fiable et qu'un redemarrage de Home Assistant peut l'annuler.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
