§69 — nuit P12, battement de coeur, guichet d'ordres, et la telemetrie BMS qui ment
Nuit : zero bascule du contacteur, 0,00 kWh de reseau contre 14,04 la nuit precedente, charge terminee d'elle-meme a 6,90 kWh, reserve 7,7 kWh. Le plancher P12 n'a jamais ete touche — il est DYNAMIQUE et descend plus vite que le SOC, ce que j'avais mal anticipe en l'annoncant fixe a 47,1 %. Trouvaille principale : 26 entites BMS sur 32 figees depuis 31 h, alarmes comprises, sans que rien ne le signale. Le rechargement de l'integration rafraichit les horodatages mais pas les valeurs. Preuve par la console serie : 41 mV de divergence a 12:30. Le battement de coeur ne couvre PAS ce cas — une entite qui republie la meme valeur reste indetectable. Correction d'une affirmation de la journee : mon « arithmetiquement impossible » comparait une tension de bus a des tensions de cellule sans verifier le point de mesure. Raisonnement faux, conclusion juste, demontree autrement. Les deux packs debitent (99,3 A et 80,7 A pour 180 A au Cerbo) ; pack 1 irreprochable a 3 mV d'ecart entre cellules. A instruire : le pack 2, plus petit et plus vieux, prend 2,5 fois plus de courant par ampere-heure. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
This commit is contained in:
Tallagrand Thierry
118
HANDOFF.md
118
HANDOFF.md
@@ -6687,3 +6687,121 @@ raison de pousser :
|
|||||||
|
|
||||||
---
|
---
|
||||||
*Document mis a jour le : 15/09/2026 (~05:45) — P12 construit, teste (102/102) et deploye ; contrainte du premier cycle trouvee en essai reel*
|
*Document mis a jour le : 15/09/2026 (~05:45) — P12 construit, teste (102/102) et deploye ; contrainte du premier cycle trouvee en essai reel*
|
||||||
|
|
||||||
|
## 69. Session du 16/09/2026 — Premiere nuit P12, battement de coeur, guichet d'ordres, et la telemetrie BMS qui ment
|
||||||
|
|
||||||
|
### La nuit P12 : ce pour quoi elle a ete construite
|
||||||
|
Fenetre HC 01:24-07:24, VW branchee et confirmee par WhatsApp la veille a 19:56.
|
||||||
|
|
||||||
|
| | nuit 14-15/09 | nuit 15-16/09 |
|
||||||
|
|---|---:|---:|
|
||||||
|
| bascules du contacteur | plusieurs | **ZERO** |
|
||||||
|
| reseau importe sur la fenetre | **14,04 kWh** | **0,00 kWh** |
|
||||||
|
| sessions de charge | 2 (VW 7,70 + JEEP 3,10) | 1 (VW 6,90) |
|
||||||
|
| SOC a 07:24 | 69 % | **48 %** |
|
||||||
|
|
||||||
|
Charge 01:24:46 -> 05:54:08, terminee d'elle-meme, **6,90 kWh au compteur**, 6 A
|
||||||
|
du debut a la fin sans aucune montee en courant (confirme independamment :
|
||||||
|
`evcs_current` n'a produit aucun point pendant 153 min). Reserve au-dessus du
|
||||||
|
plancher dur de 22 % : **7,7 kWh**, pour une cible annoncee de 6 kWh.
|
||||||
|
|
||||||
|
⚠️ **Le plancher P12 n'a jamais ete touche, et j'avais mal anticipe pourquoi.**
|
||||||
|
Je l'annoncais fixe a 47,1 % ; il est DYNAMIQUE et descend plus vite que le SOC,
|
||||||
|
puisqu'il reste de moins en moins de nuit a couvrir : 47,1 % a 01:30, 38,2 % a
|
||||||
|
04:00, 27,0 % a 07:00, pour un SOC passant de 79 a 49. L'ecart ne s'est jamais
|
||||||
|
resserre sous 22 points.
|
||||||
|
|
||||||
|
Le lendemain confirme le gain : partie de 47 % au lieu de 69 %, la batterie a
|
||||||
|
absorbe toute la matinee **sans aucun bridage** (7 chargeurs sur 7 en
|
||||||
|
`mppt_active`), avec un pic de production a 10 467 W, la ou la veille elle etait
|
||||||
|
pleine des 15 h.
|
||||||
|
|
||||||
|
### Le selecteur de vehicule est desormais pilote par la reponse WhatsApp
|
||||||
|
Voir §68. Deux ecrivains se battaient sur `session_charge.vehicule` toutes les
|
||||||
|
60 s ; la bagarre s'est arretee a la seconde ou les deux se sont accordes.
|
||||||
|
|
||||||
|
### Battement de coeur — et le service mourait dans la panne qu'il devait signaler
|
||||||
|
`sensor.evcs_historisation_heartbeat` (etat = horodatage ISO UTC, attributs
|
||||||
|
`statut`/`base_joignable`/`cycles_en_echec`/`dernier_echec`), publie HORS du
|
||||||
|
try/catch du cycle, plus `binary_sensor.historisation_evcs_muette` cote HA.
|
||||||
|
Forme figee avec la session OpenClaw pour que les deux battements du systeme
|
||||||
|
soient identiques.
|
||||||
|
|
||||||
|
⚠️ **Le test a trouve que le service CRASHAIT** a la coupure de la base : le
|
||||||
|
client `pg` emet un evenement 'error' sur le socket, et sans ecouteur c'est une
|
||||||
|
exception NON CAPTUREE qui ne passe pas par le try/catch — elle tue le
|
||||||
|
processus. Trois correctifs : ecouteur 'error', reconnexion (un client pg n'est
|
||||||
|
pas reutilisable apres erreur), et connexion initiale non fatale. Eprouve sur une
|
||||||
|
base JETABLE derriere un relais TCP coupable a volonte — jamais sur la
|
||||||
|
production, deux instances double-compteraient l'energie des sessions.
|
||||||
|
La session OpenClaw avait le meme trou et l'a ferme le meme jour.
|
||||||
|
|
||||||
|
### ⚠️ LA TROUVAILLE LA PLUS IMPORTANTE : la telemetrie BMS du Cerbo est PERIMEE
|
||||||
|
**26 entites sur 32** du device `AIRTRIA 8 US2000C` etaient immobiles depuis
|
||||||
|
**31 heures**, toutes au meme instant — le redemarrage de Home Assistant du
|
||||||
|
15/09 a 05:09. Cela inclut le nombre de modules, la capacite installee, les
|
||||||
|
tensions de cellule, et **TOUTES LES ALARMES** : `tension_de_cellule_elevee`,
|
||||||
|
`cell_imbalance`, `internal_failure` affichaient `no_alarm` parce qu'elles
|
||||||
|
etaient figees, pas parce qu'il n'y avait pas d'alarme.
|
||||||
|
|
||||||
|
Le keepalive Venus n'a rien donne. Un `homeassistant.reload_config_entry` sur
|
||||||
|
l'integration `victron_gx` a rafraichi les HORODATAGES — mais pas les valeurs,
|
||||||
|
et elles se figent a nouveau aussitot. Preuve propre, par la console serie :
|
||||||
|
|
||||||
|
12:04 console 3325 mV HA 3,329 V
|
||||||
|
12:17 console 3340 mV HA 3,329 V
|
||||||
|
12:30 console 3370 mV HA 3,329 V ← 41 mV de divergence
|
||||||
|
|
||||||
|
⚠️ **CE QUE LE BATTEMENT DE COEUR NE COUVRE PAS.** Une entite qui republie
|
||||||
|
eternellement la meme valeur reste indetectable : ni `last_changed` ni
|
||||||
|
`last_reported` ne bougent. C'est le meme trou que celui documente en §67, vu
|
||||||
|
depuis l'autre bout. **Aujourd'hui, seule la console serie dit la verite sur les
|
||||||
|
cellules**, et son releve automatique est arrete depuis le 14/09 17:01.
|
||||||
|
|
||||||
|
⚠️ Correction d'une affirmation que j'ai faite dans la journee : j'ai declare
|
||||||
|
« arithmetiquement impossible » un ecart entre 50,20 V au bus et 3,329 V de
|
||||||
|
cellule. Le raisonnement etait FAUX — je comparais une tension lue au bus
|
||||||
|
continu a des tensions de cellule sans verifier qu'elles se rapportaient au meme
|
||||||
|
point. La conclusion tient, mais c'est la console qui la demontre, pas ce calcul.
|
||||||
|
|
||||||
|
### Les deux packs travaillent, et le partage est desequilibre
|
||||||
|
Releve simultane console / Cerbo, le 16/09 a 12:30 :
|
||||||
|
|
||||||
|
pack 1 (4 x US5000, console) 99,3 A cellules a 3 mV d'ecart, tout Normal
|
||||||
|
Cerbo, courant batterie 180,0 A (exactement le plafond DVCC)
|
||||||
|
pack 2, par difference 80,7 A
|
||||||
|
|
||||||
|
Meme preuve qu'au 14/09 : **le Cerbo mesure tout le parc**, seule son
|
||||||
|
enumeration BMS s'arrete a quatre modules. Le pack 1 est irreprochable — 3 mV
|
||||||
|
d'ecart entre cellules, contre 168 mV pour le module malade de l'ancien parc.
|
||||||
|
|
||||||
|
⚠️ **A instruire** : rapporte a la capacite, le pack 2 (250 Ah) prend environ
|
||||||
|
deux fois et demie plus de courant que le pack 1 (400 Ah). Le plus vieux et le
|
||||||
|
plus petit fait le gros du travail. Mesure sur un seul point, dans un courant qui
|
||||||
|
variait beaucoup : a reprendre sur plusieurs echantillons avant d'en conclure.
|
||||||
|
|
||||||
|
### Guichet d'ordres — Airtria demande, le service decide
|
||||||
|
Voir le commit dedie. Liste blanche CHEZ MOI (six ordres), interrupteur
|
||||||
|
`input_boolean.airtria_ordres_enabled` distinct de celui du concierge, a OFF.
|
||||||
|
Neuf essais verifies. Hors liste definitivement : le contacteur EDF, les limites
|
||||||
|
DVCC, la consigne de puissance reseau, les planchers SOC.
|
||||||
|
|
||||||
|
⚠️ Le kill-switch du concierge existait depuis le 13/09 et n'etait affiche sur
|
||||||
|
AUCUN tableau de bord. Corrige : carte « Agents & surveillance » sur EVCS Master.
|
||||||
|
|
||||||
|
### Refonte OpenClaw : ne pas changer de LLM
|
||||||
|
La session OpenClaw a bascule sur le VL-Instruct le 16/09 au matin et a
|
||||||
|
REGRESSE — mais la cause etait un contexte a 86 000 tokens sur 161 messages plus
|
||||||
|
un etat d'agent bloque, pas le modele. Son harnais, bati sur
|
||||||
|
`tools/campagne-conseiller.mjs`, donne **10/10 au modele coder** sur les cas
|
||||||
|
memes qui l'avaient mis en defaut.
|
||||||
|
|
||||||
|
⚠️ Distinction a ne pas flouter : ce resultat mesure le MODELE, pas le CHEMIN DE
|
||||||
|
PRODUCTION. « Le modele n'est pas le coupable » n'est pas « le coupable est
|
||||||
|
mort ». Il autorise a ne pas swapper le LLM, et rien de plus — le guichet attend
|
||||||
|
que la production reproduise le harnais, pas que le harnais soit bon.
|
||||||
|
Mesure de la session OpenClaw qui tranche l'autre question : le coder seul occupe
|
||||||
|
111 Go sur 121 de la Spark. Y deplacer OpenClaw creerait la contention.
|
||||||
|
|
||||||
|
---
|
||||||
|
*Document mis a jour le : 16/09/2026 — nuit P12 sans un kWh achete, battement de coeur, guichet d'ordres, telemetrie BMS periMEe identifiee*
|
||||||
|
|||||||
Reference in New Issue
Block a user