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
Le panneau rendait sept « — » alors que sa requete donnait les bons totaux en
psql, avec la substitution exacte que Grafana applique, et que le serveur ne
journalisait aucune erreur : une ligne de NULL, donc un axe de minutes vide
cote Grafana.
Les bornes de generate_series venaient de $__timeFrom() et $__timeTo(). Elles
viennent desormais du min et du max de la table sur la fenetre, et la seule
macro restante est $__timeFilter(ts) — exactement la forme du panneau « Sur la
periode » des vehicules, qui lui a toujours fonctionne.
C'est aussi plus juste physiquement : on n'extrapole plus au-dela de la
derniere mesure observee.
Note d'exploitation : le GRAFANA_ADMIN_PASSWORD du .env n'est pas celui en
service. Grafana n'applique cette variable qu'a la creation initiale de
l'admin, jamais a un compte deja existant — l'API refuse donc ce mot de passe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le bilan rendait sept tirets et l'histogramme « No numeric fields found », alors
que verifier-dashboards donnait les deux requetes vertes : il prouve qu'une
requete s'execute, pas qu'elle s'affiche.
FILTRE_VUE ne se recopie pas d'un tableau a l'autre : cette transformation ne
garde que les colonnes nommees par la variable $vue, propre a « Le systeme ».
Sur un tableau qui n'a pas cette variable, elle filtre tout. Retiree.
champs="/.*/" est reserve aux etats d'alarme, qui sont du texte ; sur des
colonnes numeriques il empeche le rendu. Remis a "" comme le panneau « Sur la
periode » des vehicules, et les unites kWh et % ajoutees en overrides — sans
elles les chiffres etaient nus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Il manquait le bilan qu'on cherche en premier : ce qui a ete produit, consomme,
achete, et ou c'est alle. « La journee » (evcs-journee) le donne sur la fenetre
now/d — le jour civil, pas les 24 dernieres heures, sinon deux journees se
melangent et le total de production n'est plus comparable d'un jour a l'autre.
En controlant ses chiffres, un defaut bien plus large est apparu : la voiture
annoncait 6,9 kWh la ou le compteur cumulatif de la borne et la table des
sessions donnent tous deux 3,6.
Le report de la derniere valeur connue propageait la MOYENNE de la minute au
lieu de sa DERNIERE valeur. Le 07/09 a 14:28 la borne passe de 1577 a 0 W dans
la meme minute : cette minute vaut 788 W en moyenne, et le report la maintenait
pendant les heures sans ecriture qui suivaient — 0,79 kWh fabriques sur la
seule heure de 15 h, exactement 788 x 60 / 1000.
Le defaut ne se voyait ni sur le solaire ni sur la maison, ecrits en continu.
Il frappe les grandeurs intermittentes, au premier rang la borne qui passe
l'essentiel de la journee a zero. Les colonnes « Voiture » de « Le systeme » et
« Les vehicules » etaient donc fausses depuis leur creation, en surestimation.
Corrige dans les trois constructeurs de requetes : la minute observee garde sa
moyenne, juste pour l'energie consommee dans cette minute, mais le report
propage la derniere valeur reellement lue. Aucun seuil, aucune peremption
arbitraire. Apres correction la voiture tombe a 3,6 kWh, egal au centieme a la
somme des sessions.
verifier-dashboards annoncait 73/73 avec le chiffre faux : il prouve qu'une
requete s'execute, pas qu'elle rend la bonne grandeur. Deuxieme fois en trois
jours qu'une source independante est le seul controle qui attrape le defaut.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 07/09 a 14:28:18 la borne a declare le statut 3 apres 2 min 42 s de charge
et 0,10 kWh livre. Le controleur l'a cru, a latche day_vehicle_full_idle, et la
JEEP est restee immobile deux heures en plein soleil alors qu'elle pouvait
charger : elle a repris a 16:30 et tenu.
La premiere idee etait de distinguer une vraie fin de charge d'une interruption
par la forme de la coupure. La mesure a la seconde l'a tuee : les deux courbes
sont superposables (VW 06/09, vraie fin : 1534 -> 550 -> 82 -> 11 -> 0 W ;
JEEP 07/09, faux positif : 1626 -> 741 -> 100 -> 13 -> 0 W). Aucun signal
electrique instantane ne separe les deux cas.
Seule la duree de session les distingue, et le systeme porte deja la grandeur
qui dit ce qu'est une charge etablie : min_run_minutes, 29 min en production.
Trois formes de "charged", une seule est refusee :
energie de session nulle -> vehicule plein a l'arrivee, on latche (P10)
energie > 0, session < min_run -> charge INTERROMPUE, on ne latche pas
energie > 0, session >= min_run -> charge menee a terme, on latche
Aucune constante nouvelle. Pas d'oscillateur : une session interrompue
redemarre a energie nulle, donc un second "charged" immediat retombe dans le
premier cas et latche.
Confirmation independante le meme jour : Uconnect a envoye a 14:29 un courriel
"RECHARGE ELECTRIQUE INTERROMPUE" invitant a controler la borne et le
connecteur. Le vehicule qualifie donc l'evenement d'interruption. Le releve de
la boite montre que c'est chronique depuis au moins decembre 2025 (12
interruptions et 6 echecs entre le 31/12 et le 08/03) : nos automates n'ont pas
cree le defaut, ils en ont augmente le cout.
Golden 80 -> 84, dont le releve reel et ses deux contrefactuels (duree et
energie). Trois mutations tombent chacune sur un jeu different ; celle qui rend
le cas "energie nulle" non credible fait echouer trois scenarios existants
(P10, Fix D, Fix E).
Corrige au passage le HANDOFF du 06/09 : last_session_energy ne decrit pas la
derniere session terminee, il suit la session en cours (verifie dans InfluxDB).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Trois choses vues en regardant deux captures.
La tache Hyper Backup « Synology NAS 1 » echoue en zero seconde : sa
destination, le dossier partage ARCHIVEFAMILLE sur 10.10.10.22, n existe pas —
ni en clair, ni chiffre, ni dans la configuration Samba. Sa jumelle, qui vise
le dossier video du meme hote, reussit. Dix notifications d echec retrouvees,
zero reussite, la plus ancienne du 6 juin : les photos 2008-2015 n ont aucune
sauvegarde depuis trois mois. Non corrige, la machine source n accepte pas ma
cle et le choix de destination appartient au proprietaire.
Les annotations Grafana deviennent opt-in, et le genre bilan en est ecarte : a
lui seul un quart des lignes, presque toutes des bascules d un drapeau qui
change plusieurs fois par heure. Un trait vertical marque ce qui arrive, pas ce
qui clignote. Au passage les deux panneaux de comparaison affichaient huit
courbes dont quatre mortes ; ils ne montrent plus que les modules ayant emis
dans les deux dernieres heures — un critere d activite, pas un prefixe de
code-barres.
Et la marge de 50 % de la nuit est verifiee : il fallait couvrir 2,22 kWh
jusqu au croisement solaire, le bilan en avait reserve 2,65. Dix-neuf pour cent
d assurance sur un parc de quatre modules.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Troisieme workflow structurant, et le seul sans tests : c est lui qui decide ce
que la batterie a le droit de prendre, donc lui qui plafonnait le parc a 93 %,
et il n etait meme pas suivi dans le depot avant ce matin.
Vingt scenarios sur le patron de la suite hysteresis, avec le vrai code du node
dans une sandbox et un snapshot capture contre Home Assistant plutot
qu invente — la lecon du 24/08, quand un fixture portait les valeurs de repli du
code au lieu des seuils de production et masquait un bug de bande.
Ils suivent l ordre reel des branches et enferment chaque paire dans son
contrefactuel : hiver sombre contre hiver ensoleille, ete secours contre ete
repos, rattrapage de midi contre midi ou le soleil revient, override actif
contre override expire, et le takeover demande alors que le contacteur est
ouvert. Le releve reel du maintien a 2 A de cette nuit y figure, ainsi que le
topoff a 52,4 V pose ce matin.
Cinq mutations, chacune tombant sur un scenario different. Suite cablee au
push, bloquante comme les trois autres.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le plafond a 93 % n etait pas une protection : le BMS autorisait 53,2 V, nous
imposions 51,3, et la cellule la plus haute du pack recent etait 57 mV sous la
premiere alarme. Le garde-fou datait des cellules faibles du pack ancien, hors
service depuis hier — il protegeait un parc qui n est plus la, au prix de
0,68 kWh, soit 12 % de la reserve utile.
Le helper de tension et ses paliers ne sont lus par personne : les valeurs sont
une table codee en dur dans l Auto Charge Manager, qui entre au passage dans le
depot. Seul le profil de la tranche 90-95 % passe a 52,4 V, soit 3,493 V par
cellule, sous la tension nominale que Pylontech annonce. Verifie dans la
minute : parc de 51,12 a 52,33 V, courant de -5,3 a +16,1 A, aucune alarme.
Et le rapport de nuit part par courriel a 6 h 47. Il ne vit pas dans une
session Claude, qui s arrete avec l ecran, mais dans le service
d historisation, seul composant allume en permanence — il n y avait rien a
surveiller, tout est deja enregistre, il manquait une lecture. Le texte est
ecrit pour etre entendu : pas de tableau, des phrases courtes, des virgules
decimales. Canal : le webhook n8n qui existait deja, teste de bout en bout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Valeurs negatives au point de raccordement, contacteur ferme. La mesure separe
deux phenomenes que rien ne reliait.
Le premier est bien la plaque qui cycle : sur la fenetre de midi, 9 % des
echantillons negatifs, minimum -477 W, mediane -146. Le regulateur ne rattrape
pas un delestage brutal d un kilowatt avec une consigne de repos a 200 W. Elle
passe a 700 : la courbe monte de 500 W et le minimum devient +23 W. Le surcout
va dans le bon sens, cette consigne ne s appliquant que contacteur ferme sans
session reseau — c est-a-dire apres une coupure sur SOC bas ou une fermeture
par la regle de protection, deux cas ou l on veut justement que le reseau
contribue davantage.
Le second, -2819 W pendant deux minutes, n a rien a voir : le debranchement du
vehicule a supprime 2,2 kW d un coup alors que la batterie a 93 % n absorbait
rien et que le MPPT produisait 4 kW. Aucune consigne n absorbe cela. Ce qui l
evite est le correctif du matin sur la regle de protection : la demande sur le
parc valait 741 W, le contacteur n aurait pas ete ferme, et sans reseau il n y
a rien ou injecter.
Golden 80/80, trois attendus mis a jour avec la mesure en commentaire.
Et docker n est pas dans le PATH d une session SSH sur DSM : les commandes de
deploiement appellent desormais /usr/local/bin/docker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le selecteur de vehicule est repasse de JEEP a VW au redemarrage, pour la
deuxieme fois. La cause n est pas celle notee le 04/09 : le paquet declarait
initial: VW, et declarer initial desactive la restauration d etat dans Home
Assistant — le helper est force a cette valeur a chaque demarrage. Preuve par
comparaison : la strategie, creee par l interface donc sans initial, survivait.
Le defaut touchait cinq reglages manuels, dont deux toggles de cablage poses
avec consigne de les activer : le reseau avant depart (P9) et l application de
la cible SOC de l advisor. S ils ont ete actives depuis aout, chaque
redemarrage les a silencieusement remis a zero.
initial retire de ces cinq helpers, la regle inscrite en tete des deux
paquets. Les onze helpers de runtime de l advisor gardent le leur : ils sont
reecrits au cycle suivant et repartir d un etat connu y est voulu.
Redemarrage : 30 s, troisieme mesure identique. Les treize capteurs de la
borne arrivent desormais dans InfluxDB.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le journal a annonce deux fois 4,20 kWh : la vraie charge de nuit, puis onze
minutes de charge diurne. L energie de la borne etait echantillonnee a chaque
cycle et conservee par un GREATEST — un operateur monotone, qui ne peut que
surestimer et qui verrouille la premiere valeur vue. Au premier echantillon de
la session de midi, le capteur portait encore le total de la nuit.
Confrontation des cinq lignes a l integration relue dans InfluxDB sur les
periodes de charge reelles : ecarts de 1, 5, 14, 60 et 1135 %.
Le compteur cumulatif de la borne devient la mesure de reference : releve a
l ouverture, sa difference a la cloture donne l energie sans ambiguite de
semantique ni erreur d integration. last_session_energy est lu une seule fois,
a la cloture, et enregistre comme observation ; le journal ne l affiche que
s il s ecarte de plus de 10 %, ce qui rend visible le cas d une session
commencee avant le demarrage du service au lieu de le substituer en silence.
Les treize capteurs de la borne entrent enfin dans l historisation InfluxDB :
c est leur absence qui empechait d etablir cette semantique.
Second defaut de la meme fonction : l heure de debranchement etait posee en
bloc sur toutes les sessions non marquees des dix-huit dernieres heures. La
session de nuit de la JEEP a ainsi herite du debranchement de la VW — l inverse
du role de cette colonne. La duree de branchement la borne desormais.
Reparation idempotente des lignes existantes, limitee a ce qui a ete verifie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Deux fermetures ce dimanche midi. Mesurees a l instant de la decision,
contacteur encore ouvert donc production non censuree : maison 4025 et 4981 W,
mais parc reellement sollicite 1132 et 772 W pour un plafond de 5100. La
decharge batterie mesuree aux memes instants — 1345 et 1223 W — colle a
maison moins PV, pas a la maison brute. Le solaire couvrait la cuisson ; la
regle a ferme le contacteur pour rien, 0,50 kWh importes en plein soleil.
Elle n avait bien fonctionne hier soir que parce qu il n y avait plus de PV.
Les deux seuils portent desormais sur max(0, maison - PV). Contacteur ouvert
cette grandeur EST la decharge batterie ; ferme, un bridage du MPPT la fait
surestimer, donc l erreur pousse a rester ferme et jamais a relacher tot.
Golden 20 -> 24, dont les deux releves de midi et le contrefactuel du nuage.
Le test de mutation a montre que la premiere serie ne couvrait que le seuil de
fermeture : il a fallu ecrire le cas du soleil revenu pour qu elle morde.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Contacteur ferme a 12:07 sur un pic de cuisson, rendu a 12:22 alors que la
maison etait a 3 084 W. A la resolution native, elle oscille avec une periode
de huit secondes entre 2 000 et 3 080 W et franchit le seuil de relachement 3,3
fois par minute ; le workflow a echantillonne 1 980 W. Quinze minutes avant que
le correctif ne parte, le defaut a rejoue devant nous.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La regle du 05/09 ferme quand la maison depasse 80 % du plafond de decharge du
parc — elle a mordu au bon instant hier soir, a -97,4 A pour 100 A autorises.
Mais elle relachait sur un seul echantillon sous 50 %, et la soiree offrait
quatorze occasions de le faire. Le troisieme pic est tombe deux minutes avant
l'ouverture reelle : decale de cinq minutes, elle refermait, et chaque
aller-retour du contacteur coute 50 a 150 Wh.
Les accalmies mesurees sont franchement bimodales — treize de 5 min au plus
pendant la cuisson, une de 201 min apres. Le relachement se mesure donc en
duree, et la duree vient du bilan energetique : 20 min tant que la batterie est
condamnee a toucher son plancher avant les heures creuses (l'energie reseau du
soir est due de toute facon, la tenir ne change que son heure), 6 min des
qu'elle passerait la nuit seule (chaque kWh du soir deplacerait alors un kWh
d'heures creuses vers des heures pleines). Premiere lecture du bilan par le
workflow d'hysteresis.
Le dwell se compte sur la maison, jamais sur le contacteur : l'horodatage est
ecrit qu'il soit ouvert ou ferme, sans quoi la decision detruirait sa propre
cause. Et parce que la tension batterie s'est tue 27 minutes hier soir en
pleine cuisson, le plafond retombe sur la tension nominale du parc, et a defaut
l'horodatage — un fait persiste — tient la protection jusqu'au bout du dwell.
Golden-hysteresis 11 -> 20. Six mutations, chacune tombant sur un jeu different.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
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
