Aucune sauvegarde HA n avait jamais ete faite, et git ne la couvrait pas
-- un seul fichier HA y etait versionne. HA declarait pourtant trois
destinations Synology, dont 10.10.10.22 et une troisieme machine en
10.10.10.50 absente de toute la documentation du projet.
Quotidienne 04:45, sept copies, base d historique exclue (20 Mo au lieu
de 4,4 Go), poussee sur les trois machines. La configuration passe par
le websocket car l API REST ne l expose pas.
Verifiee archive en main : .storage, packages, dashboards, secrets et
custom_components presents, base d historique absente comme voulu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le controleur pilote depuis cette nuit la consigne de puissance reseau.
S il meurt en pleine session, elle reste haute et le reseau reprend la
place du solaire toute la journee. Ce chien de garde repare ce risque.
Signal de vie : l API d executions n8n, pas un helper HA. Verifie que HA
ne rafraichit pas l horodatage d un input_text reecrit a l identique --
surplus_state paraissait fige depuis 40 min alors que tout tournait.
Il agit en MQTT direct sur le GX Venus, troisieme machine independante
des deux NAS, jamais via HA ni via le cloud Tuya. Il ne decide rien : il
remet la consigne au repos, arrete la borne, et se tait. Une seule
action par panne, verrou jusqu au retour du controleur.
Tests : controleur vivant, panne simulee, et verrou sur 5 cycles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le depot git est deja sur le second Synology. Aucune sauvegarde HA
n existe. La cle de chiffrement n8n tient dans 56 octets sans copie.
Et le contacteur EDF est un Tuya CLOUD : couper le reseau depend
d internet, sur un site ou l orage emporte la connexion.
Le GX Venus (10.10.10.9) est en revanche une troisieme machine avec son
propre broker MQTT : consigne reseau, DVCC et arret de borne y sont
atteignables sans HA ni cloud. C est le socle d un chien de garde.
Meteo-France est installee : la reserve d orage tourne deja.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Fermer le contacteur ne suffit pas : au-dessus du SOC minimal, l ESS en
autoconsommation ne preleve que sa consigne et laisse la batterie porter
maison et voiture. Nuit du 01/09 : charge HC demarree a 01:25, arretee a
01:26 par le garde batterie, contacteur ferme et inerte jusqu a 02:00.
La consigne a 4200 W du proprietaire n etait pas decorative : c est elle
qui faisait fonctionner la prise de relais nocturne depuis le 07/08. La
retirer le 31/08 a supprime la substitution de journee et casse la nuit.
Le controleur ecrit desormais la consigne lui-meme, a partir du besoin
mesure, seulement pendant une session reseau deliberee, avec une bande
asymetrique : trop basse se corrige tout de suite, trop haute ne coute
rien. Deux ecritures en 25 minutes au lieu d une toutes les 30 s.
Golden 51 -> 56. Verifie en reel : batterie a 0 A, voiture a 3500 W.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Integration de l historique HA sur 8 jours : 64% de l energie livree au
vehicule vient d un excedent reel, 16% sort de la reserve batterie. La
frontiere se ferme entre 18h30 et 19h50 fin aout, franchement.
Cote reserve nocturne, le bilan repond deja et il repond mal a notre
avantage : sept jours sur huit, meme pleine, la batterie ne passe pas la
nuit. Le deficit est structurel, ce qui est evitable c est de l aggraver.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le plafond majore (28 A en BOOST) n est legitime que tant que le reseau alimente
AC-IN : sinon les deux MultiPlus portent seuls la voiture plus la maison, le
mecanisme du W-105. Personne ne baissait avant l ouverture -- c est l hysteresis
qui ouvre, l EVCS l apprenait apres coup -- et quand il l apprenait, la reduction
attendait le cooldown de courant et descendait d un pas a la fois.
Correctif sans poignee de main ni helper nouveau : le plafond majore exige que
l EVCS DEMANDE lui-meme le reseau. Sa demande tombe au cycle ou la fenetre se
ferme (30 s), l hysteresis ne peut ouvrir qu ensuite (override disparu PUIS
min_on, cycle 1 min) : l EVCS baisse toujours avant, mecaniquement.
Second volet : un plafond n est pas une cible qu on approche. Reduction
immediate et directe au plafond, sans cooldown.
Le calcul du plafond a ete deplace apres sourceMode dans WINDOWS_SOURCEV2 ; rien
entre les deux ne le lisait, verifie avant de bouger.
Helper a 20 A par defaut : comportement inchange. Le correctif ne mord que sur
le BOOST 28 A, le cas dangereux.
Golden 48 -> 51, chaque cas apparie a son contrefactuel. Mutations des deux
volets separement : 1 puis 2 echecs cibles, restauration 51/51.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
A la fermeture du contacteur, PV, import et courant batterie ne decrivent aucun
regime permanent pendant ~150 s (mesure du 31/08). La boucle de 30 s y prenait
cinq decisions, et la moyenne PV 10 min en gardait la trace dix minutes de plus
-- le systeme lisait "plus de soleil", en concluait qu il avait besoin du
reseau, et confirmait sa propre premisse.
Aucun seuil nouveau : le systeme publiait deja l horodatage de la transition et
personne ne le lisait. Pendant la fenetre, on ne demarre pas et on ne laisse pas
une charge s arreter sur ces mesures ; les step-down restent libres.
Deux asymetries voulues : la fenetre ne s ouvre qu a l ARRIVEE du reseau (a sa
disparition les onduleurs reprennent tout, les gardes doivent agir plus vite),
et elle suspend le confort, jamais le risque.
Golden 42 -> 48, chaque cas apparie a son contrefactuel hors fenetre. Mutation :
gridSettling force a false -> 2 echecs cibles, restauration -> 48/48.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Campagne decisive a SOC 90-92 %, batterie n absorbant plus que 22 A. La
fermeture du contacteur fait bien chuter la production de 79 % en un pas de
mesure (2663 -> 559 W), simultanement a l apparition de l import -- l
observation du proprietaire est exacte. Mais la recuperation est totale en
~2 min 30 : import 112 W et production 3158 W, au-dessus du niveau d avant.
Etat etabli hors transitoire : -7,0 % et +2,0 % contre les phases ouvertes
voisines. Aucune substitution permanente.
Meme mecanisme qu a batterie preneuse ; sans tampon, la seule variable d
ajustement est le bridage des MPPT, d ou l effet spectaculaire. Avec l ancienne
consigne a 4200 W le transitoire ne pouvait pas se terminer. Cout par
fermeture : ~150 Wh batterie pleine, ~50 Wh sinon.
Ni VEConfigure ni firmware justifies par ces mesures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Nuit complete + deux campagnes alternees apres la correction de la consigne
reseau (4200 -> 50 W) : l'import colle a la consommation, la production monte
librement contacteur ferme, et les transitions locales donnent +0,5 % et
+13,1 % la ou le 27/08 mesurait -73 %.
Le transitoire de fermeture est caracterise : le reseau reprend toute la maison
et le solaire bascule vers la batterie, puis l'import retombe a la consigne en
~2 min 15 (25 W, 52 W). Cout ~50-60 Wh par fermeture.
Outillage : tools/test-edf-alterne.mjs (protocole alterne, restauration
garantie) et tools/analyse-test-alterne.mjs. Deux pieges d'instrumentation
corriges -- garde meteo quand les phases ouvertes divergent entre elles, et
biais du parseur qui laissait tomber les lignes ou le premier tracker etait
bride.
Reste ouvert : le cas batterie pleine, celui que le proprietaire designe comme
decisif, ou le solaire n'a plus de destination quand le reseau reprend la maison.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le mode ESS passe en « Optimise sans BatteryLife » depuis l'ecran GX — le mode
n'est pas expose a Home Assistant, contrairement a tous les autres reglages ESS.
La limite de SOC active tombe immediatement de 40 a 20 %, au lieu de descendre
par paliers de 5 % sur quatre jours, et l'etat BatteryLife devient
self_consumption_soc_above_min.
Le GX cesse ainsi d'entretenir une limite dynamique que rien dans les workflows
ne lisait et qui montait de 5 % chaque nuit. C'est le troisieme acteur non lu de
la decision reseau neutralise en quatre jours, apres les charges programmees de
l'ESS et la consigne de puissance a 4200 W.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois reglages GX modifies ce soir, journal rempli dans la procedure.
Le point de consigne reseau passe de 4200 a 50 W a 21:46 : c'est la correction
visee, et desormais la seule variable qui separe l'installation des mesures du
27/08. Le test alterne pourra donc etre interprete.
Deux parametres avaient ete pris pour des limites de SOC alors qu'ils sont des
pourcentages des courants declares par la batterie. A 20 % de DCL la decharge
aurait ete plafonnee a 30 A, soit 1,5 kW, quand la maison avait tire 73,7 A le
soir meme. Remis a 100 % / 100 %, leur valeur par defaut : Victron les range
lui-meme sous « parametres obsoletes », DVCC en est le proprietaire reel.
Le plancher ESS descend de 40 a 20 % pour cesser de concurrencer la cible du
matin du controleur. Mais la limite qui agit reellement reste a 40 % :
BatteryLife maintient sa propre limite dynamique, qui monte de 5 % chaque nuit
et ne redescend que de 5 % par journee de charge complete — l'historique de
sept jours ne la montre jamais sous 40. Soit on attend quatre jours, soit on
bascule le mode ESS sur « sans BatteryLife ». Les deux options sont
documentees, le choix revient au proprietaire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le symptome prouve le 27/08 (73 % de la production solaire remplacee par du
reseau des que le contacteur se ferme) trouve une explication complete cote
GX, sans toucher aux onduleurs.
number.gx_device_ac_power_setpoint vaut 4200 W la ou le defaut Victron est
50 W. C'est le Grid setpoint de l'ESS : la puissance que le systeme s'efforce
en permanence de prelever sur le reseau. L'ESS regulant la puissance au point
de raccordement, son seul levier pour faire place a cet import quand la maison
et la batterie sont deja servies est de brider les MPPT via DVCC.
Les deux campagnes du 27/08 se reconcilient arithmetiquement : a 10:47 l'import
monte a 4113 W, soit la consigne ; a 11:38 la batterie en absorption n'accepte
que ~1070 W et conso 2258 + batterie 1070 - PV 1043 = 2285 W contre 2287
mesures. Le residu constant de ~1040 W etait la signature d'un plancher, pas
d'une reduction proportionnelle.
Seconde trouvaille : le SOC minimal de l'ESS est a 40 %, au-dessus de la cible
de 35 % du controleur. Le GX recharge donc sur le reseau de sa propre
initiative des que le controleur relache — etat `recharge` observe les 29 et
30/08. Troisieme automate contradictoire sur la meme batterie apres les charges
programmees. Arbitrage laisse au proprietaire.
L'assistant ESS tourne et aucune alarme VE.Bus n'est levee : l'hypothese d'un
assistant perdu au passage en parallele est affaiblie, pas eliminee. La partie
VEConfigure reste donc en seconde intention dans la procedure, avec sauvegarde
obligatoire et interdiction de relancer le System Configurator.
Aucun reglage n'est modifie ici : ce commit ne contient que le diagnostic et la
procedure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Une coupure reseau n arrete pas l installation : le solaire et la batterie
continuent, seul le filet de secours disparait. La reserve a tenir est donc la
couverture prudente p80 que le bilan calcule deja — aucune constante nouvelle.
En deficit c est la fenetre traversee, en surplus la prochaine, car a 15 h la
reponse « rien a couvrir » est exacte et inutile.
Le seuil d activation est la vigilance orange, echelle officielle de
Meteo-France et non un nombre choisi ici. Le snapshot lit l alerte sans
connaitre la commune, donc le code marche des l installation de l integration
et publie « indisponible » en attendant.
Tests 38 -> 42. Le fixture du test de perimetre ombre ne contenait pas storm :
les nouvelles ecritures n etaient pas couvertes. Corrige, assertion explicite,
preuve par mutation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Protocole alterne OFF/ON/OFF/ON, 15 s d echantillon, avec la tension batterie
et l etat des chargeurs MPPT — des capteurs qu aucun workflow ne lisait.
PV 3858 W hors reseau, 1112 W reseau present, 4025 W hors reseau, 1043 W
reseau present, 4358 W a la fin. Consommation inchangee, DVCC constant,
batterie loin de la saturation. Bascule en 75-90 s, retour en 32 s, quatre
fois. La production moyenne est plus haute a la fin qu au debut : l hypothese
nuages du test precedent est morte.
Ce n est pas la censure normale par manque de preneur : le solaire alimentait
integralement les memes charges 90 s plus tot. Anomalie apparue depuis le
passage des deux MultiPlus II en maitre/esclave. Piste configuration ESS en
parallele avant tout firmware.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le test infirme deux hypotheses et en decouvre une troisieme. La limite DVCC
reste a 130 A pendant toute la fenetre : l Auto Charge Manager n est pas en
cause. Aucun bridage du MPPT visible, mais la batterie avait 25 points de
marge — la condition du proprietaire (batterie pleine) n est pas reproduite,
donc son observation n est pas contredite, seulement pas testee.
En revanche, fermer EDF fait importer du reseau en rampe jusqu a 4113 W pour
charger la batterie, conso maison a 880 W. A la coupure le courant batterie
tombe de 104,6 a 25,7 A en 15 s. Les programmations ESS etaient deja
desactivees : le proprietaire de cet ordre reste a identifier.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois fenetres actives tous les jours (01:35 et 07:30 vers 45 %, 12:24 vers
55 %) chargeaient la batterie sur le reseau des qu EDF etait present, en
concurrence avec la cible du matin de l EVCS. C etait un contournement manuel
du proprietaire, utile l hiver, inutile l ete. Les cinq sont desactivees : le
controleur EVCS est seul proprietaire de la decision reseau.
Consigne le besoin hivernal correspondant : en heure solaire l hiver ajoute
~2 h de nuit a couvrir, donc la cible du matin doit monter vers 80 % et se
deduire du croisement production/consommation, pas d un palier fixe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La bande de 2 points du Fix A engageait le takeover a SOC 33 et le relachait
a 35 : 0,34 kWh, soit une demi-heure de conso nocturne plate. Trois cycles EDF
la nuit du 26-27/08, six la nuit du 20-21/08, 2,5 kWh importes pour rien.
Une seule passe de recovery par session de nuit. Le plancher dur reste un
terme independant, l hysteresis garde sa bande 20/30, et le vrai critere de
re-engagement (un budget d energie) appartient au bilan, pas a une constante
de plus ici.
Golden 40 -> 42, preuve par mutation. Documente aussi deux acteurs non lus :
les charges programmees de l ESS (45 % la nuit, contre notre cible 35 %) et
le regime majoritairement hors reseau.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le drapeau « degrade » introduit la veille s'allumait de 20 h a 07 h toutes les
nuits. La qualite de forme d'une heure vient du taux de censure ; les heures
sans soleil portent un taux de 1 faute d'avoir quoi que ce soit a observer, pas
parce que la mesure serait douteuse. Comme les heures de deficit sont justement
les heures sans soleil, le drapeau se declenchait exactement quand le bilan
sert.
Une heure dont l'enveloppe demontree est nulle recoit desormais la qualite
'nuit'. Scenario epingle sur l'enveloppe et le taux de censure releves en
production, pas sur le fixture — dont la nuit valait 0 et qui ne reproduisait
donc pas le defaut. Preuve par mutation : avant 'minoree', apres 'nuit'.
Suite 37 -> 38. Documente la nuit du 25-26/08 : profil corrige verifie a
0,2 kWh/h pres, bilan qui predit le point bas a un point pres, et non-linearite
du SOC mesuree (huit points en dix-sept minutes pour 0,16 kWh).
Journal de la premiere nuit observee avec le bilan en service : 12,30 kWh
importes, dont 1,19 kWh entre 06 h et 07 h sans aucun vehicule en charge, en
deux cycles EDF de ~25 min. Cause : la cible SOC du matin (35 %, valeur de
table) avec liberation a `SOC > cible` et rearmement a `SOC <= cible - 2` —
meme pathologie que les trois oscillateurs du 24/08, sur un autre seuil.
Corrige aussi le chiffre de la part matinale de production, une troisieme fois :
l'enveloppe subissait le meme decalage d'une heure. Le « 39,3 % du matin » est
abandonne dans le manuel comme dans le journal de chantier.
Ajoute la note sur `initial: off` du toggle advisor : tout redemarrage de Home
Assistant le repositionne a OFF.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
`bucketHourly` garde la derniere valeur de chaque heure : le delta entre H-1
et H est l'energie depensee PENDANT H. `deltaSeries` le rangeait sous H-1.
Discret sur un compteur dense, catastrophique sur un compteur epars — et les
compteurs de cette installation le sont : `ac_in_1_to_ac_out` ne peuple que 57
heures sur 267, `evcs_total` 57 sur 264, parce qu'ils n'emettent que lorsqu'ils
avancent. Une heure vide vaut « zero energie », donc toute l'energie d'un
intervalle a trou a ete consommee pendant l'heure FINALE. Rangee sous l'heure
initiale, l'import reseau de la nuit suivante atterrissait sur la derniere
heure de la nuit precedente.
Mesure du 25/08 : consumption_p50[8] = 2,90 kWh/h pour 0,80 reellement — six
echantillons sur douze portaient un delta etale sur 17 heures. Le bilan
reclamait environ deux fois trop d'energie le matin (3,37 kWh annonces a 06 h
contre 1,35 mesures), et donc un SOC requis de 44,5 % la ou 31 % suffisait.
L'enveloppe de production etait decalee de la meme heure, ce qui a contribue a
surestimer la part matinale de la production dans le journal de chantier.
Ajoute aussi un statut `degrade` : le bilan publie ses chiffres quand aucun
croisement n'apparait sur l'horizon ou quand les heures de deficit reposent sur
une forme minoree, mais il ne les presente plus comme fiables. La nuit du 25/08,
avant la mise en service de la courbe horaire, il a publie un SOC requis de
100 % avec un statut `ok`.
Tests 36 -> 37, dont `compteur-epars-attribution-horaire` (rafale reseau de
1/2/3 kWh a 01/02/03 h : montants distincts pour qu'un decalage d'un cran soit
impossible a confondre). Mutation verifiee : l'ancienne attribution le fait
echouer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Premiere execution reelle sur la courbe horaire (25/08 02:40) : croisement a
09 h, 4,39 kWh a couvrir, SOC requis 51,3 % pour 42 % reels, reseau necessaire
1,39 kWh. La traversee nocturne suivante s'affichait "17 h -> ?" : avec un
horizon de 30 h, la fenetre commencant en fin d'apres-midi ne se refermait pas
au croisement du lendemain matin. Porte a 40 h, la courbe couvrant 48 h.
L'energie manquante de stockage s'affichait non arrondie dans le texte de la
raison (2.9000000000000017).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
RESOURCE_ESTIMATE consomme desormais la courbe horaire publiee par le workflow
de prevision : forme et magnitude d'un seul tenant, sur 6 jours, avec les trois
plans reels et sans censure. Plus de repartition au prorata, plus de
renormalisation — le noeud se simplifie.
L'enveloppe est retrogradee en repli, utilisee seulement si la courbe est
absente ou vieille de plus d'une heure, le champ `mode` disant laquelle a
servi. Elle garde un role de repere de vraisemblance mais n'ecrete PLUS la
prevision : etant minoree l'apres-midi, elle tronquerait a tort une prevision
correcte.
Piege corrige au passage : le nouveau champ `source` entrait en collision avec
l'objet `source` deja present dans la sortie et etait silencieusement ecrase.
Renomme en `mode`.
Suite portee a 35 scenarios (courbe fraiche lue telle quelle, courbe perimee
basculant en repli).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Workflow "EVCS Solar Forecast V1" (07P8I349ugna9FH4), actif, cadence 15 min —
la frequence de rafraichissement de la prevision elle-meme, l'API precisant
qu'interroger plus souvent n'a aucun interet. 96 appels par jour pour un quota
de 300 par heure.
Rien n'est code en dur : la cle d'API, les plans et les coordonnees viennent
tous de Home Assistant. La cle vit dans un input_text en mode password, exclue
du recorder, et n'apparait ni dans le depot ni dans le JSON du workflow —
l'URL est assemblee a l'execution par BUILD_FORECAST_URL, qui refuse
explicitement de construire une URL incomplete plutot que de gaspiller le
quota sur un appel malforme.
BUILD_HA_CALLS_FORECAST ne publie rien en cas d'echec plutot que d'ecraser une
prevision valide par du vide.
Suite portee a 33 scenarios, dont le refus sur cle absente, sur plans mal
formes, sur kill-switch, et la preservation de la prevision precedente en cas
d'echec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Configuration appliquee (3 plans, inverter_size 11000, cle Professional) : la
prevision du jour passe de 30,2 a 43,5 kWh, aucune erreur au journal. Pieges
d'API notes : convention d'azimut inverse (0 = sud), et plans multiples en
triplets successifs dans le chemin, pas en listes separees par virgules (422).
Test : forme ciel clair contre enveloppe mesuree — matin 21,4 % contre 39,3 %
(c'etait 15,1 % avant), ecart absolu moyen de 4,5 a 2,53 points. Amelioration
nette mais ecart residuel.
Confrontation plan par plan contre le MPPT correspondant, sur les 4 heures a
censure <= 4 % : le modele ciel clair de Forecast.Solar presente exactement le
meme biais que mon modele geometrique local. Deux modeles independants
s'accordent et divergent de l'enveloppe — c'est donc l'enveloppe qui a tort.
Mecanisme : un maximum horaire pris sur des jours differents surpondere le
matin, dont la variabilite jour a jour est plus forte qu'a midi.
Correction assumee : le "39,3 % du matin mesures" cite toute la journee comme
preuve du defaut de configuration etait lui-meme gonfle. Le defaut etait reel,
son ampleur surestimee.
Consequence : l'enveloppe doit ceder la place a la courbe horaire de l'API dans
RESOURCE_ESTIMATE, qui apporte forme et magnitude sur 6 jours.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Tentative de produire la forme horaire depuis la geometrie et les quatre
orientations reelles, pour eviter l'abonnement. Abandonnee pour trois raisons
cumulees.
Seules 4 heures de la journee sont exploitables (censure 0-4 % de 08 a 11 h,
puis 59 % a 12 h, 77 % a 13 h, 81 % a 14 h) : ajuster une forme journaliere sur
quatre heures propres n'est pas serieux. L'enveloppe n'est de plus pas une
courbe de journee valide — c'est le maximum horaire pris independamment sur des
jours differents, donc plus plate que n'importe quelle journee reelle. Enfin le
modele direct seul predit zero production matinale sur le plan ouest la ou la
mesure donne 14 % a 9 h : il manquait le rayonnement diffus, dont la fraction
ajustee part en butee sans converger, le modele restant trop pique sur midi
pour les quatre plans a la fois.
Decouverte utile : correspondance etablie entre entrees MPPT et orientations —
airtria_mppt1 = 10 PV sud-est (pic 11 h), v1 = 3 PV suiveur (pic 9 h),
RS450 tracker_solar_1/2/3 = 3 strings sud (pics 13-14 h), tracker_solar_4 =
string ouest (trainee jusqu'a 19 h). Chaque plan est donc confrontable a sa
propre mesure.
Consequence : l'abonnement Professional est le bon choix, pour une raison que
je n'avais pas identifiee en le deconseillant. Avec la cle, n8n interrogera
api.forecast.solar directement et obtiendra la courbe horaire complete, que
l'integration HA n'expose pas meme abonnee. Cette courbe remplacera a la fois
la forme et la magnitude dans RESOURCE_ESTIMATE.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
52 panneaux RECOM/SILLIA 310 Wc, 16 120 Wc au total, quatre orientations :
10 en sud-est a 40 degres (2 strings de 5), 30 plein sud a 35 degres (3 strings
de 10), 9 plein ouest a 45 degres (1 string de 9), et 3 sur un tracker qui
demarre plein est puis suit la course du soleil, dont la moitie passe a l'ombre
du support des 30 panneaux sud en fin d'apres-midi.
Configuration Forecast.Solar reelle lue dans .storage : un seul plan, plein sud
a 25 degres, 15 000 Wc, avec un inverter_size de 8 000 W alors que
l'installation a deja produit 10 770 W mesures — le plafond tronque donc toute
prevision. Les quatre plans a declarer et la valeur d'inverter_size corrigee
sont inscrits dans la doc.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Les cartes markdown utilisaient un bloc YAML replie (content: >), qui remplace
les retours a la ligne par des espaces : les tableaux markdown perdaient leur
structure et s'affichaient comme une ligne de texte avec des barres verticales.
Passage en bloc litteral (content: |) sur les six cartes, et le tableau des
profils emet desormais chaque ligne sur la meme ligne que la boucle, sinon
Jinja intercale une ligne vide entre chaque rangee et casse le tableau.
Ajout d'un repli lisible quand les profils ne sont pas encore publies.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Dashboard YAML dedie "bilan-energetique", declare dans configuration.yaml et
copie versionnee dans dashboards/ du depot.
Vue Bilan : la comparaison qui decidera du cablage — seuil calcule, seuil fixe
encore en vigueur, SOC reel — avec un commentaire automatique disant lequel des
deux est trop haut ou trop bas ; la decision immediate ; la prochaine traversee
deficitaire ; une alerte conditionnelle chiffrant la capacite manquante quand
meme une batterie pleine ne passe pas ; l'etat de bridage de la production avec
son motif ; deux graphiques d'historique sur 48 h.
Vue Profils et reglages : tableau horaire des quatre profils avec le taux de
censure par heure, capacite batterie modifiable, kill-switch, statut.
configuration.yaml sauvegarde dans SAVE_CONFIG/ avant modification,
check_config valide, redemarrage HA effectue, journal sans erreur nouvelle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
5c — BALANCE ne repondait qu'a "combien jusqu'a ce que le solaire prenne le
relais". A 15 h la reponse est zero : exacte mais inutile, le deficit qui
approche etant celui de la nuit. Ajout de la prochaine traversee deficitaire
(heure de debut, energie, SOC a atteindre avant). Ce SOC n'est PAS ecrete a
100 % : au-dela, meme une batterie pleine ne passe pas, et le manque est
publie comme storage_shortfall_kwh — c'est le chiffre du dimensionnement.
5b — Workflow "EVCS Energy Profiles Daily V1" (N6UaB4ZozsbRPrFb), actif,
03:30 : lit /api/history/period sur 30 jours glissants et republie les quatre
CSV (conso p50 et p80, enveloppe de production, taux de censure).
CONSUMPTION_PROFILE devient DAILY_PROFILES et sait desormais decoder la
reponse brute de l'API en plus des series deja pretes.
Piege trouve : sans end_time, /api/history/period ne renvoie qu'UNE journee,
silencieusement. Mes premieres mesures "sur 3 jours" n'en couvraient qu'une.
Validation croisee : profils calcules depuis l'API REST (etats bruts, 11 j)
contre profils calcules depuis les statistiques long terme (28 j) — 0,20 kWh/h
d'ecart absolu moyen, par deux chemins de donnees independants.
BUILD_HA_CALLS_PROFILES refuse d'ecraser les profils en place si l'historique
ne couvre pas les 24 heures. Meme garantie de perimetre que le bilan.
Suite a 27 scenarios.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Workflow n8n "EVCS Energy Balance V1" (id QoSfPeyGq35orF1K), actif, cycle de
5 min : snapshot HA -> CENSORSHIP et RESOURCE_ESTIMATE en parallele ->
PREPARE_BALANCE -> BALANCE -> BUILD_HA_CALLS -> appels de service HA.
MODE OMBRE garanti structurellement : BUILD_HA_CALLS n'ecrit que vers des
entites evcs_balance_* plus une trace logbook. La suite de tests echoue si une
ecriture sort de ce perimetre — verifie par mutation, l'injection d'un
turn_on sur switch.edf_general_ok_switch fait rougir la suite. Kill-switch
input_boolean.evcs_balance_enabled : a OFF, aucune ecriture du tout.
Package HA evcs_energy_balance.yaml : 18 helpers. Profils de consommation,
enveloppe de production et taux de censure amorces avec les valeurs calculees
sur 28 jours reels ; capacite utile posee a 15 kWh (7 modules actifs).
Outillage : gen-energy-balance-workflow.mjs, enregistrement dans
lib-node-map.mjs, suite cablee dans n8n-push.mjs (bloquante). Suite a 24
scenarios.
Premiere execution reelle : le bilan s'est declare indisponible faute
d'entrees, exactement comme prevu, au lieu d'inventer des valeurs. Le format
du snapshot (corps JSON dans `data`) et la lecture des profils CSV ont ete
corriges ensuite.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
BALANCE.js ne pilote rien : il publie les faits qui remplacent les seuils fixes
— heure de croisement, energie a couvrir, SOC requis (remplacant de
grid_soc_off), energie reseau strictement necessaire, surplus disponible pour
le vehicule, indice de confiance. Sans une de ses entrees il se declare
inutilisable et les controleurs gardent leurs regles.
Deux niveaux de prudence. Le premier jet n'utilisait que le profil p80 et
exigeait 48 % de SOC pour franchir la matinee du 24/08, soit plus cher que le
seuil fixe de 30 % qu'il remplace. Corrige : la decision reseau, reevaluee a
chaque cycle et reversible, utilise le profil typique p50 ; le prudent p80 sert
a la planification. La marge de securite de 10 % ajoutee au depart etait une
constante arbitraire et un double comptage : mesure faite, p80(somme) egale
somme(p80) sur toutes les fenetres, les heures de consommation etant fortement
correlees. Marge supprimee.
Rejeu fige de la matinee du 24/08 (SOC 21 %, capacite 15 kWh, production
reellement mesuree) : croisement a 08 h, 0,82 kWh a couvrir contre 0,80 calcule
a la main, SOC requis 27,5 %, une session reseau de 0,97 kWh. Suite a 21
scenarios.
MANUEL_COMPLET section 0 : description materielle complete relevee dans VRM et
completee par le proprietaire — 2 MultiPlus-II 48/5000 en parallele, 53
panneaux sur trois orientations (10 est/sud-est, 30 sud, 10 ouest, 3 sur un
petit MPPT), parc Pylontech, borne 32 A. Explique pourquoi aucun modele
solaire mono-plan ne peut representer la production, et pourquoi Forecast.Solar
mal configure se trompe de repartition.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
RESOURCE_ESTIMATE.js. Recalage de la prevision : ecarte, la censure est
correlee au beau temps (facteur 4,29 a 9 h sur 27 echantillons contre 0,48 a
15 h sur 3), les donnees manquantes ne le sont pas au hasard. Forme
geometrique : ecartee, un plan unique ajuste sur les heures propres converge
sur plein est 20 degres et predit 2,0 % de la journee a 18 h contre 5,8 %
mesures — le champ a plusieurs orientations que ce modele ne represente pas.
Retenu : forme = enveloppe horaire demontree (comportement reel du champ, sans
modele), magnitude = prevision Forecast.Solar (meteo, insensible a notre
batterie). L'enveloppe de l'apres-midi etant elle-meme censuree, le noeud
publie un indice de confiance et signale les heures minorees au lieu de les
presenter comme fiables. Sans enveloppe, il se declare inutilisable plutot que
d'inventer une forme.
Defaut trouve au passage : l'orientation declaree a Forecast.Solar ne
correspond pas au champ. Matin 07-11 h, 15,1 % de la journee prevus contre
39,3 % reels ; apres-midi 14-18 h, 52,1 % contre 35,2 %. Les totaux
journaliers tiennent, la repartition intra-journaliere est inutilisable.
Suite portee a 17 scenarios.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Parc reel : 8 US2000C en 2 packs de 4 avec hub, packs d'ages differents, un
module en panne et isole (7 actifs), un autre qui faiblit. Consequence :
batteryUsableCapacityKwh = 17,5 code en dur dans INPUT_PARSE surestime la
reserve reelle de 15 a 20 %. Aucun capteur de capacite ou de sante batterie
n'existe cote HA.
Energie perdue faute de puits : la premiere estimation (23,9 kWh/jour, 38 %)
etait fausse. Le facteur de recalage global de 1,22 est domine par les heures
de 8-9 h ou il vaut 4 a 7. Probleme structurel : la censure est correlee au
beau temps, donc les donnees manquantes ne le sont pas au hasard et aucun
facteur appris sur cet echantillon n'est transportable. Cela invalide le plan
initial de l'etape 3.
Estimation retenue, borne basse sans recalage, plafonnee par l'enveloppe
horaire reellement demontree : 11,8 kWh/jour en moyenne, 23 % de la ressource.
On jette donc plus qu'on n'importe (7,83 kWh/jour) : l'energie existe, il
manque le reservoir. +8 kWh utiles sont a la fois necessaires et remplissables.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le proprietaire vise l'autonomie et doit decider combien de batteries ajouter.
La ressource gaspillee par la censure est exactement l'energie qu'un stockage
supplementaire capterait : le bilan doit donc aussi estimer l'energie perdue
faute de puits et le gain par kWh ajoute.
Constat mesure sur 27 jours : import reseau 7,83 kWh/jour en moyenne, un seul
jour sur 27 a zero ; decharge batterie 11,5 kWh/jour en moyenne, p90 14,3, max
16,1 sur 17,5 utiles. La batterie se vide presque integralement chaque jour :
c'est elle le facteur limitant, pas la puissance des onduleurs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
CONSUMPTION_PROFILE.js : compteurs d'energie cumules -> deltas horaires ->
distribution par heure de la journee -> percentiles. La consommation du
vehicule est retiree : c'est une charge pilotable, elle ne doit pas polluer le
profil de la charge subie. Les remises a zero de compteur et les deltas
implausibles sont jetes, jamais rattrapes par une valeur inventee, et une heure
sans assez de jours observes est marquee non fiable au lieu d'etre publiee en
silence.
Valide sur 28 jours reels (639 heures, 0 reset) : 31,9 kWh/jour typique hors
vehicule, 42,8 kWh au p80. Le profil tient dans un helper input_text
(119 caracteres sur 255).
Verification prealable de la methode : seulement 7,8 % des heures de deficit
sont censurees. Censure et deficit sont physiquement presque exclusifs, donc la
grandeur qui pilote la decision EDF est mesuree sur des donnees propres.
Suite tests/energy-balance/ etendue aux deux noeuds : 14 scenarios.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Sans injection reseau, PV_mesuree = min(ressource, conso + absorption batterie).
La mesure est donc censuree a droite des que la batterie est pleine ou que le
reseau alimente AC-IN. Mesure sur l'historique du 28/07 au 24/08 : 48 % des
heures de jour sont censurees, 77 a 96 % a partir de 13 h. Un profil de
production bati sur la mesure brute mesure en realite sa propre consommation.
src/energy-balance/HA_SNAPSHOT_TEMPLATE.json.tpl : 26 champs, dont tous les
signaux qu'aucun workflow ne lisait jusqu'ici — etats des trois MPPT, etat
VE.Bus, alarme de surcharge onduleur, ESS BatteryLife, etat du bus DC, statut
natif de la borne, prevision horaire, elevation du soleil.
src/energy-balance/CENSORSHIP.js : qualifie chaque echantillon (censure et ses
motifs, exploitabilite) et verifie en continu l'identite du bus DC
PV + VE.Bus = batterie, qui boucle a 95 W pres — un capteur qui derive devient
detectable. Ne decide rien.
tests/energy-balance/ : 10 scenarios, dont un snapshot reel du 24/08 14:29
(soleil 52 degres, prevision 3462 W, production bridee a 1159 W, SOC 94 %)
correctement classe censure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Journal leger pour ne rien perdre en route (documentation definitive a la fin,
comme convenu) : decisions actees, sorties attendues du bilan, et backlog des
defauts releves en chemin — doublon unique_id victron_vebus_dc_power,
evcsDedicatedMaxW code en dur, alarmes et etats MPPT jamais lus, controle de
vraisemblance PV + VE.Bus = batterie, etats zombies source_lost.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
tools/ha-service.mjs comble le trou des MCP disponibles : ha-get-state lit un
etat, ha-set-helper ecrit un helper, mais aucun n'appelle un service. Or
homeassistant.check_config et homeassistant.restart sont indispensables apres
une modification de configuration.yaml (le recorder n'est pas rechargeable a
chaud). Meme schema que tools/n8n-push.mjs : fetch, jamais curl, jeton lu dans
.env, jamais en dur. Les services destructifs exigent --yes explicite.
.env ajoute a .gitignore : il contenait HA_TOKEN et n'etait pas exclu, un
git add -A l'aurait pousse sur le remote (le fichier n'etait pas encore suivi).
Note : configuration.yaml (hors depot, sur le NAS) recoit
recorder.purge_keep_days = 90 pour pouvoir rejouer un incident plusieurs
semaines apres coup. Sauvegarde dans SAVE_CONFIG/.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Incident du 24/08 12:24-12:28 : bascule de profil vers midday_hc_or_solar
avec SOC 58 %. Plancher de demarrage = min(midday_soc_min 75, abondance P6
40) = 40 ; plancher de maintien = max(soc_stop_min 29, 75-15) = 60. Le
systeme avait donc le droit de DEMARRER ce qu'il n'avait pas le droit de
MAINTENIR : cycle limite a la periode de min_run (3 min) sur toute la bande
[40 %, 60 %], et ~2,6 kW de PV ecretes a chaque creux (PV 10,24 kW -> 7,64 kW
quand la borne s'arrete, ESS sans injection).
Deux volets indissociables dans BATTERY_CLOUD_LOCKS.js :
- effectiveSocHoldFloor = min(regle du profil, plancher de demarrage
effectif). Sans abondance, comportement inchange.
- l'abondance P6 se prouve au demarrage (batterie >= +20 A) mais se maintient
en charge (batterie >= 0) : sinon la charge du vehicule, qui detourne
precisement le surplus, detruit sa propre condition d'autorisation.
Golden 39 -> 40. Preuve par mutation sur midday-inversion-start-hold : code
d'avant -> stop / "Conditions de maintien perdues", apres -> step_up 19 A.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Fix G provoquait un yoyo EDF de 2-4 min (coupure a SOC 21 en bypass min_on
contre rallumage a SOC 20 en bypass cooldown) : son garde `soc > gridSocOn`
ne protegeait que l'instant de l'engagement sur SOC bas, pas la phase de
remontee 20 -> 30. jsCode restaure byte-identique a la version pre-Fix-G.
Le fixture de test portait les fallbacks du code (22/35) au lieu des valeurs
de production lues via MCP (20/30), et le scenario de non-regression testait
SOC 18 %, le seul point que Fix G epargnait. Suite reecrite avec les
garde-fous manquants h-recovery-band-no-cut-21/-25. Mutation : Fix G
reapplique -> 4/7 echecs, retire -> 7/7.
Documentation du diagnostic des deux oscillateurs (yoyo EDF et oscillation
de la charge EVCS en plein soleil) dans MANUEL_COMPLET 11.8 et HANDOFF 25.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Ajout de la configuration MCP (5 serveurs n8n) et du CLAUDE.md qui charge
AGENTS.md/HANDOFF.md/MEMORY.md/docs/MANUEL_COMPLET.md, ainsi que les skills
n8n de référence (.claude/skills/*, docs uniquement, pas de code exécuté).
.claude/settings.local.json reste ignoré (déjà dans .gitignore).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Incident nuit 21-22/08 : la fenêtre HC nuit se ferme pendant que le véhicule
est encore en session active (pas encore flag "charge terminée"). L'EVCS
relâche correctement son override, mais émet un état transitoire générique
(stop_source_lost/idle_wait_source) qu'aucune règle de coupure immédiate du
workflow Grid Hysteresis (Fix C/E2) ne reconnaît. EDF restait alors maintenu
des heures par la boucle générique jusqu'au seuil statique gridSocOff,
plafonnant le MPPT Victron à ~100W et privant la maison de solaire.
Nouvelle règle générique (Compute Grid Hysteresis) basée sur evcsGridOverride
plutôt que sur une liste blanche de noms de surplus_state — couvre donc aussi
tout futur état non énuméré. Garde anti-glitch sur lecture HA invalide.
Nouvelle suite tests/golden-hysteresis/ (7 scénarios, première pour ce
workflow), câblée bloquante dans tools/n8n-push.mjs. Déployé et validé
(golden-hysteresis 7/7, golden EVCS 39/39 inchangé).
Écarte le diagnostic incomplet laissé par un autre agent dans HANDOFF.md
(edf_general_ok_off côté EVCS aurait créé un deuxième écrivain non coordonné
sur le même switch).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- WINDOWS: dayVehicleFullIdle (statut 3 ou VDF, héritages jour<->nuit),
sourceMode blocked même face au solaire
- DECISION: branche collante day_vehicle_full_idle au-dessus des gardes
- échappatoires force_charge_now/force_grid_now (golden)
- golden 33->36, validé live 10:04:30 (latch en 16 s sur la VW pleine)
- HANDOFF §22 + MANUEL états collants
- DECISION: branche done/recovery_done remontée dans la cascade principale
(avant mustStopHard) → le collant se réécrit chaque cycle, survit aux
micro-charges de la VW et aux hard stops batterie
- branche Fix E interne supprimée (remplacée par la branche haute)
- golden 25→26 (night-hard-stop-necrase-pas-done)
- HANDOFF §19
