Chaque soir ~1 h, une heure de deficit encore ensoleillee etait classee
« minoree » d'apres le taux de censure de l'enveloppe, alors que sa production
venait de la courbe horaire VRM / Forecast.Solar. Le bilan passait `degrade`
et le controleur l'ignorait (plancher du soir a 85 % fixe). Les heures lues
dans la courbe sont desormais `courbe`. Verifie : 18:20 ok, chiffres
identiques a 18:15 degrade. Bilan 72/72.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
18:03 le 29/09 : « prevision indisponible » avec 16 points de marge, parce
que le bilan etait `degrade` (forme minoree sur une heure de deficit, chaque
soir ~1 h). Statut `sous_reserve` avec la reserve dans le texte ;
`indisponible` seulement sans bilan, perime ou statut inconnu, avec la raison.
Diagnostics 90/90.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Le jour, sans rien a couvrir avant le retour du solaire, le texte parlait de
la nuit ecoulee (« 0 kWh jusqu au retour du solaire vers 10 h, la batterie
suffit »). Etat `jour` : la prevision se fait le soir, avec un repere
provisoire (prochaine traversee prudente) et l'achat si EDF s'engage.
Diagnostics 87/87.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Nuit du 28-29/09 : « environ 0,14 kWh a prendre sur EDF » annonces, 4,6 importes.
0,14 etait le manque de la batterie ; une session engagee fait passer toute la
maison sur le reseau jusqu'a 07:24. Le bilan publie la maison non couverte sur
la fenetre HC de nuit (input_number.evcs_balance_night_hc_house_kwh) et
sensor.evcs_prevision_nuit annonce import_prevu_kwh = maison + manque ;
reseau_necessaire_kwh supprime. Bilan 72/72, diagnostics 85/85.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Le service publie le facteur nuit prevue / nuit moyenne (sensor.evcs_nuit_maison_prevue_kwh),
le bilan l'applique a son profil de 21:30 a 09:00. Diagnostics 81/81, bilan 68/68.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Trois verdicts au lieu de deux ; « la batterie suffit » exige le requis PRUDENT.
Attribut soc_requis_maintenant_pct (l'ancien nom se lisait comme un SOC du matin).
Tests 73/73, mutation qui mord.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
ZERO ajoutee au selecteur avec son heure de depart (P9). Le bilan lit la
capacite et la puissance de charge mesurees du vehicule selectionne ; 0 =
inconnue (regle muette / pas de borne). Bilan 64/64, golden 123/123.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Regle du proprietaire (28/09). Le bilan compare le besoin saisi (niveau x capacite
mesuree - deja delivre) au solaire disponible avant le depart de 15:30 (mar/mer/
ven/sam) sans descendre la batterie sous le plancher « tenir jusqu'a la prochaine
HC ». Le controleur relaie le verdict sous les gardes du bilan ; session de midi
engagee -> voiture sur le reseau avec la batterie. Bilan 61/61, golden 121/121.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
La regle « tenir jusqu'a la prochaine HC » (8de284c) et le plancher de charge
HC manuelle (2654592, 18/09) etaient muets en production : la colle recopie le
snapshot champ par champ et les avait oublies. Les tests appelaient BALANCE
directement. Garde-fou : tout champ lu par BALANCE doit etre produit par
PREPARE_BALANCE (mutation verifiee).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Nuit du 26-27/09 : P12 a charge la JEEP sur la batterie (72 -> 44 %) ; la
journee sombre n'a pas reconstitue la reserve. Strategie : voiture branchee =
charge en HC sur le reseau ; la batterie tient jusqu'a la prochaine HC, midi
complete si besoin.
- HA transmet la fin de la fenetre HC en cours et le debut des suivantes (le
calendrier reste dans HA, §73)
- pendant une fenetre HC, required_soc >= SOC pour atteindre la PROCHAINE HC
(engage ET finance la session, insere dans coverage() comme le plancher
manuel) ; required_soc_prudent (plancher de P12) >= SOC pour atteindre la
NUIT SUIVANTE -> journee sombre = voiture sur le reseau HC
- a midi la session et la voiture en grid_hc_allowed se chargent ensemble
(aucun changement du controleur)
- 4 scenarios reels du 27/09, bilan 54/54, deux mutations qui mordent
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Decision du proprietaire (28/09) : Forecast.Solar renvoie des totaux quasi
constants (~26 kWh) pour 40-47 reels ; VRM suivait mieux le reel sur 10 jours
(erreur 21 % contre 32 %, 14 % contre 36 % sur les 5 derniers). Le bilan
lit VRM des maintenant ; les deux previsions sont enregistrees (colonne
source, cle etendue) pour les comparer dans une semaine.
- input_select.evcs_balance_forecast_source (vrm | forecast_solar) = retour
arriere en un geste ; helpers evcs_balance_vrm_* au format du bilan
- historisation : lecture VRM (jeton dans .env, jamais dans HA) toutes les
15 min, vrmVersCourbes (jour et heure de Paris), tests 69/69
- modele du bilan conditionnel ; bilan 50/50, deploye
- evcs_prevision_contre_reel porte sur la source active
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Incident 27-28/09 : l'agent presentait le surplus solaire de demain comme
de l'energie batterie et lisait une projection de jour du controleur la
nuit. Ce capteur ne relaie que le bilan (meme arbitre que la decision de
nuit) ; bilan > 30 min -> indisponible. Tests 65/65.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Incident 27/09 : l'agent annoncait « vers 90 % » de sa tete. La prevision
Forecast.Solar sous-estime d'environ 50-60 % : on publie des faits (SOC,
ecart de prevision), jamais un SOC projete. Tests 61/61.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Delta depuis minuit de ac_in_1->ac_out + inverter->ac_out : 25,2 kWh a
17:11 le 26/09 pour ~25 dans VRM. Remise a zero -> indisponible, compteur
muet -> partiel. Tests 59/59, mutation qui mord.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Premier releve live (26/09 12:19) : compteur EDF 0,8 = VRM, delta des
compteurs AC-in du MultiPlus 0,7 (0,6 + 0,1, pas apparent de 0,1 kWh).
Repli sur le MultiPlus si le compteur EDF est muet ou remis a zero.
Tests diagnostics 55/55, deux mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Le proprietaire veut que l'agent vocal lui evite d'ouvrir VRM. « Combien ai-je
importe » est une quantite : delta des compteurs cumules AC-in du MultiPlus
(vers ac_out + vers inverter) depuis leur valeur a minuit, lue une fois par
jour dans l'historique HA. Compteur EDF publie en recoupement. Remise a zero ->
indetermine, jamais d'import negatif. Les trois compteurs entrent aussi dans la
table mesure (manque note au HANDOFF §76).
Tests diagnostics 48 -> 54, deux mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Incident du 26/09 : l'agent vocal a annonce le capteur reseau bloque a 07:24,
alors que le contacteur s'etait ouvert a la fin des heures creuses. Le verdict
ne juge l'age de la mesure que contacteur ferme ; ouvert, c'est non_raccorde.
Tests diagnostics 37 -> 48, trois mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Incident 25/09 11:49 : l'agent sans source avait invente 0,56 kWh / zero
reseau / 35 % pour une nuit a 7,9 kWh dont 2,2 reseau. donneesNuit() extrait
de rapport-nuit.mjs (texte identique sur 5 nuits), publie pour l'agent.
Tests 37/37.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
sensor.evcs_production_jour_kwh (somme des 3 yield_today, remises a zero
decalees gerees) et sensor.evcs_charge_solaire (relais de la decision du
controleur, pas un second arbitre). Tests 26/26 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
La fiche OpenClaw basculait G5 de 7/7 a 1/7 sur un ajout sans rapport :
les deux jugements sortent du modele. sensor.evcs_pv_diagnostic (import
teste avant bridage) et sensor.evcs_cellules (perime => aucune valeur
visible), publies meme quand le cycle echoue. Tests 15/15 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Le 180 A venait de nous (monte 130->150->180 le 13/09, §64), pas du BMS qui
autorise 250. Il bridait reellement : PV 10,6 kW, excedent ~187 A que la
batterie prendrait, plafonnee a 180. Parc sain (cellules pack 2 a 3-6 mV) : on
prend toute la marge, direct a 250 sur decision du proprietaire.
golden-acm 20/20 (2 attendus 180->250), mutation : retour 180 -> 2 echecs.
patch rejouable tools/patch-20260920b-boost-250a.mjs.
⚠️ Surveillance pack 2, surtout module rang 5 (K220803C30160323, le plus ancien).
Pack 1 (US5000) hors surveillance continue (2e cable en commande).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 52,4 V avait ete pose le 06/09 pour menager la cellule 12 faible du pack
ANCIEN (§57). Ce pack est sorti. Cellules du pack 2 a 3-6 mV, la plus haute a
3356 mV, loin des 3550 mV ou le BMS reduit le courant. On releve le top-off
pour atteindre une charge plus pleine et RECALIBRER la jauge SOC Pylontech (qui
derive tant qu'on n'atteint jamais 100 %). 52,8 V = 3,52 V/cellule, sous les
53,2 V autorises par le BMS.
⚠️ Cellules du pack 1 (US5000) pas encore sous surveillance continue (2e cable
en commande). Proprietaire a autorise explicitement malgre le caveat.
patch rejouable tools/patch-20260920-topoff-52v8.mjs. golden-acm 20/20, attendu
acm-jour-topoff mis a jour (52,4->52,8), mutation : retour a 52,4 -> 1 echec.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Re-mesure du 20/09 sur le parc a 13 modules assaini (cellules 3-6 mV) :
tools/mesure-courbe-batterie.mjs donne 0,30 kWh/point PLAT de 25 a 97 %, PLUS DE
GENOU. Le genou a 33 % etait la signature de la cellule 12 morte du pack ancien
(§50), il a disparu avec elle — exactement ce que predisait la note de prudence
du 03/09. La reserve utile a quasiment double (12,4 -> ~23 kWh de 100 a 22 %).
Le scaling modules/7 rattrapait par chance la partie HAUTE (0,169x13/7=0,31 ~
mesure) mais SOUS 33 % le bilan croyait 0,18 kWh/point contre 0,30 reels ->
required_soc surestime en bas d'echelle. Corrige :
- BALANCE.js : kneePct 33->0, pentes 0,169/0,097 -> 0,1615 plat (x13/7 = 0,30).
- INPUT_PARSE : batteryUsableCapacityKwh 2,414 -> 2,308 kWh/module (0,30/13x100).
- helper evcs_balance_usable_capacity_kwh 15 -> 23 (inerte mais coherent).
Tests : bilan 50/50 apres re-figeage des 10 attendus (verifies a la main : ex
rejeu 24/08, 0,82 kWh -> 22 + 0,82/0,1615 = 27,1 % contre 30,5 avant). Mutation
deux sens : ancien genou -> 10 echecs, pente fausse -> 11. Golden controleur
116/116 inchange (capacite -4 %, aucun basculement discret).
⚠️ Courbe a REMESURER apres toute evolution du parc. 2e cable console en
commande pour surveiller aussi les cellules du pack 1 (US5000), aujourd'hui hors
surveillance continue (trames etendues Cerbo mortes, §69).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Filet MANUEL complementaire a P11-bis : quand meme le second signal echoue
(borne physiquement coincee), l'appui sur input_boolean.evcs_reset_borne force
une session fraiche pour un cycle -> nettoie le collant -> retest du vehicule.
Momentane : le controleur (HA_SERVICE_CALLS) le rebascule off apres avoir agi,
il ne peut donc pas forcer un retest en boucle.
- gabarit + INPUT_PARSE (params.resetBorneRequested) + sessionFresh (OU bouton)
- helper_reset_borne_ack : turn_off si le bouton etait ON
- paquet evcs_reset_borne.yaml (SANS initial:, lecon du 06/09), reload fait
- golden 115 -> 116 : reset-borne-force-retest (session etablie + bouton ON ->
retest + ack off). Mutation : bouton neutralise -> le scenario tombe.
Gabarit rendu contre HA : 203 champs, aucun null.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Incident du 19/09 : VW debranchee ~14:50, JEEP branchee, mais le swap n'a dure
que 14 s. La borne a GELE son etat (charging_time reste a 1h25, jamais
reinitialise) → P11 (base uniquement sur charging_time <= 90s) restait aveugle
→ le collant 'vehicule plein' de la VW bloquait la JEEP, qui n'a pas charge de
l'apres-midi. Un debranchement FRANC de 30s a tout debloque (borne reset).
Le last_changed du capteur de connexion, lui, a bien bouge sur le swap de 14 s
(14:54:17). C'etait l'info qui manquait : personne ne la lisait. sessionFresh
gagne donc un SECOND terme, l'age du dernier (re)branchement, meme fenetre 90s,
independant de la borne :
- gabarit : evcs_vehicle_connected_ts (as_timestamp du last_changed, patron
acin1_last_changed_ts §29) ;
- INPUT_PARSE : evcsVehicleConnectedAgeSec (Infinity si absent => repli sur) ;
- WINDOWS : sessionFresh = charging_time bas OU reconnexion recente.
Golden 113 -> 115 : p11bis-swap-rapide-borne-figee (charging_time fige 1h25 +
reconnexion 30s -> retest) et son contrefactuel reconnexion-vieille (2h -> reste
collant). Gabarit rendu contre HA : 202 champs, aucun null. Mutation deux sens :
retrait du signal -> le swap tombe ; fenetre infinie -> l'etablie tombe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Incident du 18/09 13:08-13:14 : clic BOOST 28 A, le controleur demande le
reseau, l'hysteresis met ~1 min a fermer le contacteur, et pendant ce trou il
MAINTIENT 13 A sur la batterie (hold_min_run_wait_grid_takeover). Le garde
batterie mord a -32,4 A, 23 secondes AVANT l'arrivee d'EDF, et pose 20 min de
verrou — que rien ne leve quand le reseau arrive. Resultat : contacteur ferme,
import qui tourne, voiture a l'arret.
Trois volets :
1. hold_min_run_wait_grid_takeover retombe au courant MINI — miroir de la
sequence d'ouverture (§30) : on ne tient pas la puissance sur la source
qu'on quitte. A 6 A le garde n'aurait jamais mordu.
2. Le stop encode si le reseau etait present : absent => blockReason
'grid_battery_guard_no_grid'. Present => verrou plein inchange (incident du
01/09, consigne insuffisante) — c'est ce qui interdit l'oscillateur
stop/retry a reseau present.
3. BCL leve le verrou '_no_grid' des que le reseau arrive. Reseau toujours
absent : la branche anterieure wait_grid_source protege deja (epingle).
Golden 108 -> 113. Mutations en trois directions, chacune tombant sur un
scenario different. Piege du fixture note en commentaire : ses seuils ne sont
pas a l'echelle du parc reel (fenetre garde reseau / hard general etroite).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Signale par le proprietaire avant le PUT : « il faut ajouter la periode HC
12h24 jusqu a 14h24 ». Il avait raison, et le trou etait plus profond qu une
borne manquante — l engagement de session etait gate sur `night_hc` SEUL,
parce que §40 ne traitait que la nuit.
Consequence : la charge HC manuelle qu on venait d ecrire ne pouvait RIEN faire
a midi. Le plancher relevait bien la cible du bilan, mais aucune session ne
s engageait, donc pas de takeover, pas de contacteur, pas de consigne. Le
reglage aurait releve le plancher de demarrage du soir — donc bloque la charge
du vehicule — sans jamais charger la batterie. Le pire des deux mondes.
⚠️ ET LE CRITERE N EST PAS LE MEME AUX DEUX FENETRES. La nuit, on compare le SOC
a `batteryMorningTargetPct`, qui contient le palier de prevision (35/55/85). A
midi ce palier n a aucun sens : il vaut 35 par beau temps, donc un SOC de 30 %
EN PLEIN SOLEIL engagerait une session reseau — la substitution du solaire par
le reseau qu on a mis des semaines a eteindre.
A midi le critere honnete est le SOC requis du bilan lui-meme, qui s auto-regule :
le croisement PV etant passe, l energie a couvrir vaut zero et le requis retombe
au plancher dur. Releve du 17/09 a 13:51, plein soleil : required_soc = 22,0 pour
energy_to_cover = 0,0. Il ne remonte qu un jour sombre — ou quand le proprietaire
pose un plancher manuel, ce qui est exactement le cas d usage.
Golden 106 -> 108. Les deux scenarios sont une paire : meme heure, meme profil,
seul le ciel change. Sombre avec un bilan qui reclame 85 % -> la session
s engage ; ensoleille avec un bilan a 22 % et un SOC de 30 % SOUS le palier du
matin -> aucun engagement.
Mutations : retour au gate night_hc seul -> le scenario sombre ; critere de la
nuit applique a midi -> le contrefactuel ensoleille. Chacune tombe sur un jeu
different. Hysteresis 24, ACM 20, bilan 50 inchanges.
⚠️ AUCUN PUT. Il en faut desormais DEUX — le bilan et le controleur — et ils
attendent tous les deux sa validation.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Decision du proprietaire, dans ses termes : « contraindre le bilan, un seul
arbitre ». Ce projet a deja paye cher les automates concurrents — charges
programmees de l ESS, consigne a 4200 W, plancher SOC du GX — et un bouton qui
ecrirait sa propre cible en aurait cree un quatrieme.
⚠️ LE FORCAGE EST EN AMONT, DANS coverage(), ET NULLE PART AILLEURS. Mesure sur
banc : ecrire directement dans balance_required_soc engage bien la session —
contacteur ferme, takeover ON — mais laisse la consigne reseau a 700 W, donc la
batterie recoit une centaine de watts. C est le defaut du 01/09 a l identique,
et le seul des trois resultats INDIAGNOSTICABLE depuis le tableau de bord : il a
l air de marcher. La raison est que required_soc ENGAGE la session et
grid_energy_needed_kwh la FINANCE. Pose dans coverage(), le plancher fait bouger
les deux ensemble par construction.
Sens unique, comme les cablages de §38, §39 et §40 : le plancher ne peut que
RELEVER l exigence. Un reglage trop bas est sans effet, il ne desarme rien.
DEUX NOMBRES ET PAS UN, et c est architectural. `..._target` est le reglage du
proprietaire ; `..._floor` est sa valeur EFFECTIVE, mise a zero hors des fenetres
d heures creuses par une automatisation Home Assistant, et c est elle que le
bilan lit. Le bilan repond a « de combien la batterie a besoin », pas a « quand
est-ce bon marche » : il ne contient aucune notion d heure creuse (zero
occurrence de hc_night ou hc_midday dans tout src/energy-balance/) et doit le
rester. Home Assistant detient le calendrier tarifaire, le bilan detient
l energie.
Sans ce filtrage le plancher fuit dans la journee et mord sur
BATTERY_CLOUD_LOCKS — eveningSocStartFloorPct = max(eveningSocStartMin,
balanceRequiredSocPct) — au point de bloquer le demarrage de la charge du
vehicule le soir. Ce n est pas theorique, c est une ligne qui s applique tous les
soirs.
Le bouton se desarme a la sortie de la fenetre ou il a servi : une demande de
charge est un geste ponctuel, pas un reglage permanent oublie.
⚠️ EFFET STRUCTUREL CONSIGNE, qu aucune echeance ne corrige : coverage() est
appelee pour le profil typique ET le profil prudent, donc le plancher releve
aussi required_soc_prudent, qui est le plancher de P12. Pendant une charge
manuelle, la voiture cesse de descendre la batterie. Coherent, mais une nuit ou
l on veut les deux on n aura que l un.
Bilan 48 -> 50. Mutations : plancher ignore -> le scenario qui le releve ;
plancher qui remplace au lieu de relever -> le contrefactuel a 25 %. Chacune
tombe sur un jeu different. gridEnergyNeededKwh ajoute au resume de test : il
manquait alors qu il est desormais consomme en aval par la consigne reseau.
Gabarit du bilan rendu contre Home Assistant : 42 champs, JSON valide, helper
absent lu « unknown » donc plancher nul — le repli est sur avant meme que les
helpers existent.
⚠️ AUCUN PUT VERS n8n. Le workflow du bilan tourne toujours sans ce changement.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Ecrit par la session voisine docker22-b2, verifie et commite ici : `git` echoue
chez elle sur ce depot (dubious ownership) et elle ne touche pas a
`safe.directory` sans consigne du proprietaire. Laisser ce travail non suivi
dans un arbre partage en NFS, c est l etat qui se fait ecraser au premier
`n8n-extract`.
Quand la garde du bilan tombait — statut degrade, mesure perimee, champ
illisible — la consigne revenait a `maison + plafond de borne`, y compris sans
voiture. Le defaut d origine survivait donc exactement la ou le systeme est
deja degrade. Mesure sur le chemin concerne (midi, fenetre HC autorisee, aucun
vehicule, bilan indisponible) : 5725 W autorises pour une maison a 900 W.
Deux changements, aucune variable ajoutee. La branche de repli du plafond
emploie `evcsSetpointShareW` au lieu du plafond brut ; et `gridSetpointLoadW`
n a plus qu une branche, la distinction n ayant de sens que tant que le repli
gardait l emprunt. L invariant du 01/09 et du 04/09 reste tenu PAR LA FORME :
le plafond vaut maison plus un terme positif ou nul.
⚠️ Le commentaire conserve la trace d un disjoint
`nightGridSessionCommitted || forceGridRequested` sur la part voiture, ecrit
puis MESURE puis retire : il ecrase le terme batterie du bilan, puisque
max(4825 emprunte, 1538 mesure) retient l emprunt. Cout mesure, trois attendus
figes d un coup — 2380 -> 5437, 2380 -> 5437, 4219 -> 6301. Il avait un sens
tant que la consigne n avait aucun terme batterie ; depuis qu elle en a un, ce
n est plus une protection mais un court-circuit. Sans cette trace quelqu un le
reintroduira en croyant combler un trou, comme le plafond de borne lui-meme,
qui etait une bonne idee le jour ou il a ete ecrit.
Golden 105 -> 106. Mutation verifiee ici : plafond de borne remis dans le repli
-> 1 seul echec sur 106, le nouveau scenario, 1130 attendu contre 5725 obtenu.
Il est donc le seul a couvrir ce chemin. Les autres suites intactes
(hysteresis 24, ACM 20, advisor, bilan 48).
⚠️ AUCUN PUT VERS n8n. La production tourne toujours la version poussee a
00:24, sans ce correctif. Le PUT attend la validation du proprietaire.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
J avais declare le quatrieme mutant incouvrable : remettre le terme batterie
dans le plancher nuage ne faisait echouer aucun test, et je pensais qu aucun
scenario ne pouvait le distinguer, parce qu il faudrait faire coexister une
descente de credit solaire (donc du soleil) avec un manque batterie en fenetre
creuse (donc la nuit).
L erreur etait dans le « donc la nuit ». Il y a DEUX fenetres creuses, et celle
de midi (12:24-14:24) admet simultanement le soleil fort, les chargeurs brides
et le manque batterie. Rien ne s exclut.
Et le vrai discriminant n est pas l heure, c est un DVCC HAUT. A 30 A le terme
batterie plafonne sous le budget de surtension et les deux variantes rendent la
meme chose ; a 180 A — le profil de boost de journee de l ACM — il vaut 6639 W
et le plancher pollue bloque la descente.
Scenario ajoute, forme reelle de l episode du 17/09 (force_grid pose a midi,
soleil, aucune voiture) avec en plus un manque batterie :
formule correcte : 4219 W
mutant M4 : 7309 W
3090 W d ecart. Avec le terme batterie dans le plancher, la consigne reste trop
haute et evince le solaire : c est le defaut du 11/09 reintroduit par la porte
de derriere. Le scenario ne teste donc pas une bizarrerie de forme, il protege
contre le retour d un incident connu.
Les deux valeurs ont ete obtenues independamment sur deux implementations
distinctes et concordent au watt.
Golden 104 -> 105.
⚠️ RIEN N EST POUSSE VERS n8n.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Elle empruntait le plafond de la borne — `maison + physicalCapA x V` — qui n a
aucune relation physique avec ce dont la batterie a besoin. Qu il tombe juste
etait un accident : le 17/09 a 13:51, voiture partie depuis cinq minutes,
consigne a 7032 W pour une maison a 933 W.
Elle additionne desormais des besoins NOMMES : la maison toujours, la voiture
seulement si un vehicule est branche, la batterie seulement dans une fenetre
d heures creuses — recharger la batterie sur le reseau n a de sens economique
que la. Hors fenetre le terme vaut zero, donc la division par un temps qui tend
vers zero disparait par construction et non par garde.
MAX ET NON ADDITION. La consigne est une AUTORISATION, pas une prediction : le
fichier le dit deja — « la consigne dit ce que le reseau a le DROIT de servir,
DVCC dit ce que la batterie a le droit de prendre ». Additionner deux
autorisations independantes n est pas plus honnete, seulement plus permissif.
Mesure : avec l addition, `consigne-session-engagee-couvre-la-maison` passe de
5595 a 6341 W — une autorisation en plus sur le chemin dominant (85 nuits sur
88 ont un vehicule) pour corriger un chemin emprunte zero fois en treize jours.
LE TERME BATTERIE EST BORNE PAR DVCC, PAS PAR LE BMS NI PAR LE TEMPS. Le BMS
declare 250 A, soit 12,2 kW : au-dessus de GRID_SETPOINT_MAX_W, il ne bornerait
rien. Et un plancher d horizon ne borne que le diviseur : en fin de fenetre
(14 min, manque 5,672 kWh) la division rend 17 kW, ecretes a 10 000, soit PIRE
que les 5437 empruntes qu on remplace. Avec DVCC le terme vaut 1538 W et la
consigne 2380 W. Corollaire : le plancher d horizon devient sans objet, il ne
reste qu une garde d une minute contre la division par zero.
Le manque vient de `evcs_balance_grid_energy_needed_kwh` et non de
`energy_to_cover_kwh` : la premiere est le MANQUE, nulle des que la batterie
couvre et convertie par la courbe mesuree par morceaux ; la seconde est
l energie que la batterie devra FOURNIR et ne tombe jamais a zero tant qu il
reste de la nuit — 11,96 kWh annonces le 17/09 a 20:00 avec un SOC de 91 %.
Le plancher nuage suit la voiture et PAS la batterie : il couvre l exposition
creee par le courant du vehicule ; une recharge batterie qui ralentit quand le
solaire s effondre ne coupe personne.
INVARIANT TENU PAR LA FORME : `maison + max(...)` ne peut jamais descendre sous
la maison, quel que soit DVCC. La regle du 01/09 et du 04/09 est donc garantie
par construction. Toute lecture manquante retombe sur la formule d avant.
Golden 102 -> 104. `nuit-sans-vehicule-session-engage` passe de 5437 a 2380 et
recoit le manque explicitement, sans quoi il heritait du zero de la fixture et
decrivait un etat impossible (SOC 20 pour un requis de 59,1 avec batterie
couverte). Deux scenarios ajoutes : la fin de fenetre bornee par DVCC — celui
qui protege contre la regression de 10 kW — et le contrefactuel a vehicule
branche qui epingle le choix du max.
Mutations : plafond DVCC retire -> 2 echecs dont la fin de fenetre ; max
remplace par une addition -> le contrefactuel seul ; bilan ignore -> les deux
scenarios pilotes par le bilan. Les autres suites sont intactes
(hysteresis 24, ACM 20, advisor, bilan 48).
⚠️ RIEN N EST POUSSE VERS n8n : la regle du depot impose la validation du
proprietaire avant tout PUT.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne l idee du proprietaire et le calcul qui la fonde, le verrou
anti-oscillateur trouve en construisant, et surtout la contrainte decouverte a
05:30 en conditions reelles : P12 doit gagner le premier cycle de la nuit. Si la
reprise reseau s engage avant lui, le verrou anti-creneaux de juillet tient le
reseau pour toute la session — et il a raison, c est exactement le creneau qu il
existe pour empecher. Aucun des cinq scenarios initiaux ne le montrait, ils
partent tous d une nuit vierge.
Note aussi qu une mutation qui ne mute rien ne prouve rien : ma premiere
tentative cherchait un motif absent du fichier, zero occurrence, zero echec, et
j allais conclure que le test tenait.
Et corrige deux affirmations que j avais faites avec trop d aplomb : le garde dur
a -30 A (je lisais la table de base, pas les valeurs appliquees) et le bilan qui
sous-estimerait la batterie de 30 % (j avais divise une courbe par morceaux par
un seul ratio).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Idee du proprietaire, apres la nuit du 14 au 15/09 : 8 kWh achetes au reseau, la
batterie encore a 69 % a 5 h du matin, et une prevision de 38,7 kWh le lendemain
dont 10,5 auraient ete ecretes faute de place. Payer du reseau la nuit pour
ecreter le solaire le lendemain, c est perdre deux fois.
Le mode `battery_assist_night` existait pour exactement ca, et etait MORT depuis
toujours : il exige `batteryCurrentA >= plancher de decharge` (0 A), impossible
la nuit puisque la maison tire sur la batterie. On ne cree donc pas un chemin,
on rend viable celui qui existe — en remplacant un test de COURANT impossible
par un test d ENERGIE.
Le plancher n est PAS une constante nouvelle : c est `required_soc_prudent`, que
le bilan publie deja en profil p80. La voiture descend la batterie jusqu au
niveau qui lui permet encore de tenir jusqu au croisement PV, et pas plus bas.
La bascule vers le reseau est automatique quand le surplus est epuise — la
soupape decrite par le proprietaire, sans aucune regle horaire.
⚠️ Verrou anti-oscillateur, et il n est pas decoratif. Le plancher descend
pendant la nuit et le SOC aussi : voiture en charge le SOC perd 7,1 pt/h contre
3,7 pour le plancher, mais voiture ARRETEE il n en perd que 2,6. Le surplus
reapparaitrait tout seul et la charge repartirait. Une seule passe par session
de nuit, comme la recovery batterie depuis le 27/08.
Les gardes de courant restent : commonSafety, l arret dur, et la garde souple
avec sa tolerance temporelle — c est elle qui arretera la charge quand la bande
de SOC deviendra trop basse pour le courant tire. Ce qu on retire est uniquement
le plancher de PROFIL, qui interdisait de demarrer des que la batterie n etait
pas a l equilibre.
Cinq scenarios, six mutations qui mordent chacune sur un jeu different. Deux
d entre elles ont trouve de vraies faiblesses : les attendus ne verifiaient que
le choix du mode et pas que la voiture charge, et la garde de fraicheur du bilan
n etait couverte par aucun scenario.
Rien n est deploye et le toggle est a off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le hub reconnait les deux groupes — LED verte et trois bips, son accuse de
reception — mais le Cerbo n en enumere qu un : 4 modules et 400 Ah la ou le parc
en compte 9 et 650.
Le releve de reference apporte le fait qui manquait : a 20:14 les quatre US5000
debitent 24 A au total pendant que le Cerbo annonce 41 A au parc. Les 17 A
d ecart sont le pack 2, qui porte donc bien du courant sans etre enumere. Le
courant mesure au shunt n est pas un indicateur d enumeration — seuls
nombre_de_modules_en_ligne et capacite_installee le sont.
Quatre etapes par risque croissant, la premiere ne touchant a aucun cable : un
redemarrage du Cerbo, l inventaire ayant deja change une fois le 13/09 a 21:35,
evenement isole verifie comme n etant pas un redemarrage de Home Assistant.
Regle de securite tiree de l incident d aujourd hui : fermer EDF AVANT toute
manoeuvre. Couper la communication du BMS arrete la gestion batterie, donc l
onduleur, donc la maison — 72 secondes dans le noir a 16:24. EDF deja ferme, la
maison passe en direct et ne voit rien.
L etape 4 renvoie a la documentation constructeur et n avance aucune theorie de
cablage : sur du materiel batterie je ne raisonne pas de memoire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le patch precedent n'avait releve que pv_boost : au-dessus de 80 % de SOC
c'est pv_mid qui commande, donc son plafond de 110 A restait le plus bas et
rien n'etait observable cet apres-midi. Table finale : 150 / 130 / 80 / 30,
toujours decroissante.
Applique a 13:31. Le courant est passe de 90 a 116 A dans la minute — mais
la charge de la maison a chute de 2,6 kW au meme moment, et le courant n'a
repris que 1,3 kW des 2,6 liberes tandis qu'un chargeur de plus se bridait.
Ce n'est donc PAS une preuve propre, et je ne la presente pas comme telle.
Ce que le releve montre vraiment : dans la tranche 80-90, le courant a
plafonne vers 116 A sans jamais approcher les 130, pendant que la tension
montait de 50,82 a 51,07 V vers la consigne. A ce niveau de SOC c'est la
TENSION qui contraint, pas le courant.
La ou le plafond mordait : a 12:36-12:42, SOC 78-80, le courant etait a
129 A pour une DVCC de 130 — colle dessus. C'est la tranche pv_boost, donc
c'est la charge du matin qui dira ce que le 150 A libere.
Cellules a 2 mV et aucune alarme sur toute la sequence. Golden ACM 20/20,
attendu de acm-jour-mid mis a jour dans le meme commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Mesure du 13/09, 10:39 a 12:50 : la DVCC etait a 130 A et la batterie
prenait 114 a 127 A, soit 88 a 98 % du plafond, avec une tension plate a
50,6 V — a 0,5 V sous notre propre consigne. C'est le point decisif : il n'y
avait aucune phase d'absorption, le courant ne retombait pas de lui-meme,
il butait. Pendant ce temps six chargeurs sur sept se declaraient
`voltage_current_limited`, et sans injection cette ressource est perdue.
Le BMS, lui, declare autoriser 250 A et 53,2 V, ses 135 cellules tiennent
dans 2 mV et aucun module ne bloque la charge. Le 130 A venait de l'ANCIEN
parc, dont une cellule montait a 3 649 mV et faisait effondrer le courant de
tous. Ces modules sont sortis le 12/09.
- `pv_boost` 130 -> 150 A : un palier, pas une cible. 150 A reste a 60 % de
ce que le BMS declare ; on regarde ce que ca libere et l'ecart entre
cellules avant d'aller plus loin.
- `pv_mid` 51,2 -> 51,5 V : la colonne des tensions REDESCENDAIT entre 80 et
90 % avant de remonter, reste du 06/09 ou seul pv_topoff avait ete releve.
pv_topoff et pv_hold ne sont pas touches. L'effet du 150 A ne se verra que
sous 80 % de SOC, donc a la charge du matin.
Golden ACM : les trois scenarios qui epinglaient ces valeurs sont tombes,
attendus mis a jour dans le meme commit, 20/20. Verifie en reel : consigne
appliquee, aucune alarme, cellules toujours a 2 mV.
Corrige au passage : l'ACM tourne toutes les 5 MINUTES, pas 30 s comme
l'annoncaient le manuel et MEMORY.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le premier cablage reel (§20, 09/08) faisait suivre a la cible SOC du matin
`input_number.evcs_advisor_night_target_soc`, derriere quatre gardes :
toggle, statut ok, fraicheur de 120 minutes, bornage [22, 90].
Depuis que le conseiller est devenu observateur le 12/09, il n emet plus de
cible et ce helper est fige a 55 %. Les quatre gardes continuaient pourtant
de passer toutes les quatre, parce que la garde de fraicheur date le RUN et
non la VALEUR : le conseiller tourne toujours, donc son horodatage est
frais. Activer le toggle aurait applique un chiffre perime sans qu aucune
garde ne s y oppose.
Retire : les quatre parametres d INPUT_PARSE, le bloc de WINDOWS_SOURCEV2,
le passe-plat de BATTERY_CLOUD_LOCKS, la trace (ADVISOR) de DECISION et les
quatre champs du gabarit de snapshot. Le cablage du BILAN (§39) est intact.
`parseAdvisorRunToMs` devient `parseRunStampToMs` : le bilan publie le meme
format et reste son seul appelant.
Golden 98 → 96. Les trois scenarios du cablage sont remplaces par un seul,
`advisor-cible-ignoree`, qui pinne l ABSENCE de cablage : toutes les
conditions de l ancienne regle reunies, et la cible doit rester celle des
regles de prevision. Mutation : cablage restaure → il tombe, avec
« target=22% (ADVISOR) » dans la raison ; retire → 96/96.
Gabarit re-rendu contre Home Assistant : 196 champs, JSON valide, aucun
null. Pousse en production, cycle suivant en succes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
SPECIALISATION. Campagne du 12/09 : lui demander d observer ET de
planifier degradait les deux — l ecart de cible entre passages est passe
de 0 a 35 points sur certains cas des l ajout de la mission
d observation. Il ne planifie plus : la planification est faite par le
bilan, qui est calcule, mesure et teste a 48/48. Sortie reduite a
constat / gravite / ce_qui_cloche / piste. Prompt 7609 -> 6250 caracteres.
Mesure apres specialisation, horloge epinglee : oscillation reelle
detectee 5/5, contrefactuel calme 5/5. La discrimination est parfaite.
⚠️ Mais la gravite est retombee de « haute » a « moyenne » : mon echelle
a quatre niveaux n est ancree sur aucun exemple. Defaut de briefing a
corriger, pas defaut de detection.
Le compteur mesure desormais le VOLUME de signalements : on ne peut pas
verifier automatiquement s il a raison, on peut mesurer s il crie au loup.
COUCHE D ENQUETE. Trouver le coupable ce matin a demande sept requetes
enchainees ; rien n y exigeait un humain, seulement d appeler des outils
et d enchainer d apres ce qu on vient de lire. Six sous-commandes en
LECTURE SEULE, exposees en ligne de commande pour qu OpenClaw — que le
proprietaire veut utiliser — ou tout autre pilote les appelle sans
reecriture : bascules, mesures, decisions, ecrivains, bilan, cherche.
`bascules` calcule l ecart entre transitions successives du meme objet :
c est la signature d une oscillation, et l appelant n a pas a la refaire.
L enquete de ce matin se rejoue en trois commandes, jusqu a
automations.yaml ligne 22.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Idee du proprietaire, et elle est meilleure que la mienne : ce systeme
n a pas besoin qu on lui suggere une strategie de plus, il a besoin que
quelqu un VOIE que « je coupe EDF, non je remets, et hop je coupe » est
absurde. Cinq automates ecrivent sur la meme installation, chacun
localement correct, aucun ne voit les autres. Leurs pannes sont des
CONTRADICTIONS, et elles ne se lisent que dans la SUITE des evenements —
jamais dans un instantane.
Le 12/09 au matin le contacteur reseau a bascule toutes les 4 minutes
pendant dix minutes : une automatisation HA coupait a 35 % de SOC,
l hysteresis rallumait. Aucun automate ne l a vu ; un humain oui.
Sortie elargie : `constat`, `gravite` (aucune/faible/moyenne/haute) et
`ce_qui_cloche`, valides strictement, publies dans trois helpers et dans
le logbook. Le snapshot porte desormais l anciennete des cinq transitions
cles (contacteur, verrou, takeover, etat EVCS, mode ACM).
⚠️ VALIDATION SCINDEE. Essai sur l oscillation reelle : le modele a
produit un constat JUSTE et un `current_max_a` de 100, hors bornes. La
validation tout-ou-rien jetait le diagnostic avec le champ fautif —
c est-a-dire exactement ce qu on lui demande, perdu a cause de ce qu on
ne lui demande plus. Les champs d ACTION gardent leurs bornes mais sont
NEUTRALISES au lieu de faire echouer l observation ; `actionUtilisable`
est le seul drapeau qui autoriserait un jour un cablage, et les compteurs
ne comptent que lui.
Tests advisor : +6. Deux attendus mis a la nouvelle semantique dans le
meme commit (hors bornes -> observation gardee, action neutralisee).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Diagnostic du proprietaire, et il est juste : le conseiller n est pas
utilisable parce qu on lui donne des consignes fausses et des informations
partielles.
CONSIGNES FAUSSES. Son briefing enoncait mot pour mot la regle des paliers
(« forecast fort >= 18 kWh => cible ~35 % »), celle que le bilan a demontree
fausse le 03/09. Il declarait 17,5 kWh de batterie (mesure : 6,8 sur quatre
modules) et 9 kWc de panneaux (16,1 en realite). Retires. La capacite est
desormais CALCULEE depuis la courbe mesuree et le parc declare.
INFORMATIONS PARTIELLES. Il ne recevait AUCUNE sortie du bilan. Il ignorait
donc l heure de croisement, l energie a couvrir et le SOC requis -- les
seules grandeurs sur lesquelles la question se decide. +23 champs au
snapshot : bilan complet, parc, limites BMS, consigne reseau, modes des
chargeurs solaires, vehicule selectionne.
Ajoute aussi ce que personne ne lui disait : sans vehicule branche il y a
quand meme quelque chose a decider (c est la maison qui traverse la nuit),
les chargeurs declarent eux-memes s ils se brident, la cuisson du soir se
decale de trois heures, l hiver la nuit est plus longue de deux heures en
temps solaire.
PREUVE. Rejeu de la nuit bloquee du 12/09 a 04:00, sans aucune aide :
avant auto_solar_plus, cible 35 %, « prevision forte => cible basse »
apres force_grid_now, cible 60 %, « bilan exige 3.13 kWh avant 09h »
Le bilan demandait 59,1 %. En production a la meme heure, il n avait rien vu
-- quatre fois de suite.
COMPTEUR. Il comparait la STRATEGIE, constante a auto_solar_plus : 517
accords contre 23, soit 95,7 % — un score qui mesurait une constante. Il
compare desormais la CIBLE, contre le BILAN, et ne compte rien quand le
bilan est indisponible plutot que de compter faux.
Tests advisor : 3 nouveaux sur le compteur (ecart 2 pts -> accord, 13 pts ->
divergence, bilan indisponible -> aucun comptage). Perimetre mode ombre
inchange et toujours verifie.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
