§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
2026-09-16 12:31:41 +02:00
parent 54b0dd14b8
commit c589da8f9a

View File

@@ -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*
## 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*