Le parc remonte au-dessus de 93 %, et la nuit se raconte par courriel

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

HANDOFF.md

@@ -4794,6 +4794,103 @@ Pour memoire : l'acces SSH par cle a 10.10.10.22 fonctionne et `sudo` y est sans
 mot de passe — la demande de validation avant un `sudo` releve de la regle posee
 par le proprietaire, pas d'une incapacite.
 
+### Le plafond a 93 % de SOC etait notre reglage, pas une protection
+Mesure du 06/09 a 15:01, quatre modules du pack recent :
+
+| | |
+|---|---:|
+| ce que le BMS AUTORISE (`maximum_allowed_charging_voltage`) | **53,2 V** |
+| ce que nous IMPOSIONS | **51,3 V**, soit 3,42 V par cellule |
+| cellules du pack 2 | 3 386 a 3 423 mV, ecart 25-30 mV par module |
+| premiere alarme haute du BMS | 3 480 mV — la plus haute cellule 57 mV en dessous |
+
+Aucune alarme, et le BMS autorisait encore 40 A de charge : c'etait la consigne
+de tension qui plafonnait le SOC. Origine : la gestion « tension de cellule
+elevee » posee pour proteger les cellules faibles du pack ANCIEN (cellule 12 du
+...0322 a 3 649 mV, cellule 15 du ...0324), **hors service depuis le 05/09**.
+Le garde-fou protegeait un parc qui n'est plus la, au prix d'environ
+**0,68 kWh** — 12 % de l'energie utile a quatre modules, precisement ce qui
+manque en fin de nuit. Un Pylontech recale en outre sa jauge de SOC sur une
+charge pleine : ne jamais y arriver la fait deriver.
+
+⚠️ **`input_number.victron_battery_charge_voltage_normal_v` ET SES PALIERS
+hcv_step1/step2 NE SONT LUS PAR PERSONNE.** Verifie : le nom n'apparait nulle
+part dans l'Auto Charge Manager. Les tensions sont une table CODEE EN DUR dans
+le node « Compute Charge Targets » — meme famille que le toggle
+`allow_grid_hc_night`, parse mais cable nulle part jusqu'a P7. La vraie
+protection est le BMS lui-meme, qui a demontre le 05/09 une reaction en CINQ
+SECONDES (cellule au-dessus de 3 550 mV -> plafond de courant effondre) ; elle
+reste entiere.
+
+Table des profils jour de l'ACM, par SOC :
+
+| SOC | profil | courant | tension |
+|---|---|---:|---:|
+| < 80 | pv_boost | 130 A | 51,5 V |
+| 80-90 | pv_mid | 110 A | 51,2 V |
+| **90-95** | **pv_topoff** | 80 A | **51,3 -> 52,4 V** |
+| >= 95 | pv_hold | 30 A | 50,6 V |
+
+Seul `pv_topoff` est modifie : c'est la tranche ou ca plafonnait. `pv_boost` et
+`pv_mid` sont limites par le COURANT, pas par la tension. `pv_hold` n'est pas
+touche — redescendre a 50,6 V une fois le haut atteint est le bon comportement
+pour du LiFePO4, on ne veut pas y sejourner.
+
+52,4 V = **3,493 V par cellule**, SOUS la tension de charge nominale annoncee
+par Pylontech pour l'US2000C (52,5 V) et bien sous les 53,2 V que ce BMS
+autorise. Avec 30 mV d'ecart entre cellules, la plus haute atteint ~3,51 V,
+encore 40 mV sous le seuil de reduction.
+
+**Effet immediat, verifie a 15:14** : consigne DVCC 52,4 V, tension du parc
+51,12 -> **52,33 V**, courant batterie **-5,3 -> +16,1 A**, SOC 93 -> 94 %,
+`tension_de_cellule_elevee` toujours `no_alarm`, plafond BMS inchange a 40 A.
+Le parc reprend de la charge.
+
+Patch rejouable : `tools/patch-20260906c-tension-de-charge-52v4.mjs`. L'Auto
+Charge Manager entre au passage dans le depot :
+`workflows/victron-auto-charge-manager-v1.2.json` — troisieme workflow
+structurant, il n'etait suivi nulle part. Il n'a **pas** de suite de tests.
+
+### Rapport de nuit par courriel — et pourquoi il ne vit pas dans ma session
+Le proprietaire le lit en voiture, en se le faisant lire a voix haute. D'ou la
+forme : pas de tableau, pas de liste a tirets, phrases courtes, et les nombres
+ecrits comme on les prononce (« 4,2 kilowattheures », virgule et non point).
+
+⚠️ **Ce qui ne marche PAS pour surveiller la nuit** : `CronCreate` est en
+memoire dans la session Claude, ne se declenche que si le REPL est vivant et
+inactif, et disparait avec la session. Un sous-agent meurt avec elle aussi. Le
+crontab pose le 05/09 est sur le PC Ubuntu du proprietaire et ne lance que le
+releve des cellules.
+
+Et il n'y a **rien a surveiller** : le service d'historisation tourne toutes les
+soixante secondes sur une machine allumee en permanence et enregistre deja tout.
+Ce qui manquait n'etait pas de la surveillance mais une LECTURE. Le rapport vit
+donc DANS le service (`tools/rapport-nuit.mjs`, appele par
+`historise-evcs.mjs`), envoye a 6 h 47 avec rattrapage jusqu'a 10 h.
+Idempotence par une ligne `evenement` de genre `rapport` — aucun fichier
+d'etat, et redemarrer le conteneur ne renvoie pas le courriel.
+
+Canal : le webhook n8n **deja existant et actif** « Webhook Email solar v2 »
+(`https://n8n.airtria.pro/webhook/solar-email`, id `vfPbPFtfZt58HOt2`), en GET
+avec `to`, `subject`, `message`. Aucun identifiant nouveau : il porte un compte
+SMTP configure. ⚠️ Il declare POST dans ses parametres mais n'est enregistre
+qu'en GET — un POST renvoie 404. Teste de bout en bout le 06/09 a 15:10,
+execution n8n en succes.
+
+Chemins ecartes en route, pour ne pas les re-explorer : `notify` de Home
+Assistant n'a que les applications mobiles, aucun SMTP ; `synodsmnotify` refuse
+le texte libre (« is neither mail string key nor i18n format ») ;
+`notification_send` se bloque ; `sendmail` de DSM rend 0 sans journal, donc sans
+preuve de remise ; et DSM n'a **pas** node, donc un cron hote ne peut rien
+executer.
+
+Le rapport dit : les fermetures du contacteur et l'energie importee, la
+trajectoire du SOC avec l'heure du minimum et l'alerte si le plancher a ete
+touche, les sessions de charge par vehicule, l'injection residuelle — **avec un
+jugement conditionne a la POINTE et non a l'energie**, parce qu'une pointe a
+2 819 W pendant deux minutes n'a rien d'anodin meme si le total reste faible —
+et les incidents techniques.
+
 ### Reste ouvert
 - Detecteur de gel dans le service d'historisation : une grandeur qui ne bouge
   pas alors qu'une autre du meme bilan bouge = alerte. Non fait.