Effet de bord du correctif precedent : pour montrer les alarmes, qui sont du
texte, j'avais mis « fields: /.*/ » — ce qui fait aussi remonter la colonne
_time des requetes Flux, affichee en gros au-dessus de chaque valeur.
Un panneau stat n'a besoin d'aucun champ temporel. Les requetes ne renvoient
plus que la valeur. Applique a tous les panneaux stat, pas seulement au BMS :
_time n'y servait a rien et restait un piege latent, invisible tant que le
reglage « champs numeriques seulement » le masquait.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le filtre de vue fonctionne sur le graphique en barres — la capture du
proprietaire montrait bien « Solaire, Voiture » seuls — et echouait sur « Les
flux » avec « Data is missing a time field ». La seule difference entre les
deux etait le format de sortie : `table` d'un cote, `time_series` de l'autre.
Un panneau time series accepte parfaitement une trame de type table des lors
qu'elle porte une colonne temporelle, et le rendu est identique. On aligne donc
« Les flux » sur le format dont on a la PREUVE qu'il se laisse filtrer, plutot
que de continuer a deviner comment `time_series` nomme son champ temporel.
Changement circonscrit a ce seul panneau : les trois autres tableaux utilisent
le meme generateur de requete, n'ont pas de filtre de vue, et restent en
time_series.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
1. « Data is missing a time field » sur Les flux. Mon filtre de vue laissait
passer « time » en minuscules, or la source PostgreSQL nomme le champ
temporel « Time » avec une majuscule dans le format time_series. Le filtre
supprimait donc l'axe des temps. Les deux graphies sont desormais acceptees.
2. Les deux alarmes du panneau BMS n'apparaissaient pas. Un panneau stat ne
reduit que les champs NUMERIQUES par defaut, et « no_alarm » est du texte :
il faut "/.*/" pour l'afficher. Applique a ce seul panneau — les autres
n'ont que des nombres et le reglage par defaut y est correct.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois demandes du proprietaire apres usage reel.
1. SELECTEUR DE VUE. Variable « vue » en haut du tableau, dans l'esprit de VRM :
Vue generale / Consommation / Reseau / Batterie / Chargeur VE. La valeur de
chaque option est directement une alternative d'expression reguliere,
consommee par la transformation filterFieldsByName des deux graphiques —
d'ou le separateur « | ». Un seul jeu de requetes, cinq lectures.
2. PAS ADAPTATIF. L'histogramme d'energie suit desormais la periode choisie :
l'heure jusqu'a 4 jours, le jour jusqu'a 70, le mois au-dela. Sans cela
« 30 derniers jours » rendait 720 barres illisibles. C'est ce que fait VRM
en passant de l'heure au jour puis au mois.
3. PANNEAU BATTERIE ILLISIBLE — un defaut que j'avais cree. Cinq valeurs dans
huit colonnes : Grafana reduisait le texte jusqu'a l'illisible. Porte a dix
colonnes avec une taille imposee, plutot que de laisser l'ajustement
automatique decider. Reseau et Charges CA resserres en consequence.
Ajout lie a la panne en cours : panneau « Ce que le BMS impose » — limite de
courant de charge, alarme de tension de cellule, desequilibre, etat de sante.
C'est ce qu'il faudra regarder cet apres-midi.
Sa fenetre de lecture est de 48 h, deliberement differente des 6 h du reste :
un etat d'alarme ne devient jamais indisponible, il se publie, donc sa derniere
valeur EST la valeur courante meme vieille de dix heures. A l'inverse du
courant reseau, dont le capteur disparait et laisse un chiffre qui ment.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois defauts signales par le proprietaire sur une capture prise a 00:04.
1. FENETRE GLISSANTE. La plage etait « aujourd'hui » : a 00:04 il n'y avait que
quatre minutes a montrer. Passee a 24 h glissantes. Les etiquettes d'heure
portent desormais le jour, sans quoi « 22 h » designerait deux heures
differentes dans la meme fenetre.
2. VALEUR PERIMEE PRESENTEE COMME ACTUELLE — le vrai defaut. Le panneau Reseau
affichait « Courant 2,2 A » : ecrit QUATORZE HEURES plus tot, du temps ou le
contacteur etait ferme, alors qu'il est ouvert depuis 10:08. Cause : ma
fenetre de lecture de 7 jours, posee pour eviter les cases vides.
Les capteurs du reseau passent en `unavailable` quand AC-IN disparait ; ils
ne tombent pas a zero. Leur derniere valeur numerique reste donc celle
d'avant. Fenetre ramenee a 6 h : assez large pour couvrir une nuit sans
soleil et une borne au repos — dont les zeros sont VRAIS — assez etroite
pour ecarter une lecture de quatorze heures.
3. Une absence de mesure s'affiche desormais comme un tiret, jamais comme zero.
Verifie apres coup sur les valeurs reelles : Reseau Courant = tiret (la valeur
fausse a disparu), Chargeur PV = 0 W et Chargeur VE = 0 A conserves puisque
justes, Batterie et Charges CA en direct.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
L'episode du 04/09 apres-midi etait deja enregistre dans InfluxDB, sans qu'aucun
cable serie ait ete branche : l'alarme "tension de cellule elevee" passe a
warning a 16:36:04, la limite de courant imposee par le BMS tombe de 150 a 20 A
en trois minutes, et le parc n'est alors qu'a 50,76 V pour une CVL autorisee de
53,2 V — il restait 2,4 V de marge.
Ce n'est donc pas la tension du parc qui limite mais UNE cellule. A 50,76 V sur
15 cellules, la moyenne est de 3,384 V : la cellule fautive est ~200 mV
au-dessus des quatorze autres.
Deux corrections a ce que nous croyions : le bridage commence vers 75 % de SOC
et non 94 % (le 94 % est seulement ou le parc finit par arriver a 20 A), et
`cell_imbalance` reste no_alarm tout du long — seule la protection de surtension
se declenche.
Et l'explication de "je ne vois rien dans les logs" : le desequilibre est
invisible sous ~70 % de SOC, la courbe LiFePO4 y etant plate. Une capture faite
le matin batterie a 45 % ne peut rien montrer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Generateur rejouable (tools/gen-page-batteries.py) plutot qu'un HTML ecrit a la
main : les chiffres viennent des mesures et se recalculent.
Base : 37 nuits completes issues des statistiques long terme de Home Assistant
(fin juillet au 4 septembre, maison seule, voiture deduite) et la courbe
energie/SOC etablie sur 576 paliers.
Le chiffre qui cadre la decision : les 7 modules actifs delivrent 10,7 kWh a la
maison, la nuit mediane en demande 13,2 — la batterie passe la nuit seule
1 fois sur 37. Reparer le module en panne porte cela a 5/37 seulement ; deux
modules de plus le portent a 32/37. Reparer seul ne resout rien.
Second point, moins attendu : au-dela de la consommation nocturne le stockage
ne cycle plus. Le surplus de milieu de journee est un probleme de preneur, pas
de stockage — la voiture absorbe deja 9,8 kWh/jour en mediane.
Reserve inscrite en clair : toutes les mesures sont d'ete, les compteurs
exploitables ne remontant qu'a fin juillet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
configuration.yaml : sept cles de connexion retirees (api_version, ssl, host,
port, token, organization, bucket), include/exclude/tags conserves. Home
Assistant avait deja importe la connexion dans une entree d'integration, donc
l'historisation n'a jamais ete menacee. Sauvegarde
SAVE_CONFIG/configuration.yaml.bak.20260904-194304, diff verifie.
Redemarrage en 30 s. Apres : InfluxDB recoit 1065 points en 90 s, aucune erreur
au journal, PostgreSQL inchange.
⚠️ Effet de bord releve par le detecteur d'evenements, sans le chercher : le
reglage manuel du selecteur de vehicule fait a 19:36 (VW -> JEEP) a ete ANNULE
par la restauration d'etat du redemarrage (JEEP -> VW a 19:44:12). Ce
selecteur determine l'heure de depart retenue, donc toute la mecanique de nuit.
Regle inscrite : apres un redemarrage, relire les helpers regles a la main dans
l'heure precedente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Home Assistant 2026.8 avertit que la configuration YAML de la CONNEXION
InfluxDB est depreciee et cessera de fonctionner en 2026.9.0. Il a deja importe
l'existant dans une entree d'integration (source: import, titre
"evcs (http://10.10.10.22:8086)") : l'historisation continue de fonctionner,
seule la duplication reste a retirer.
Le fichier de reference du depot ne porte donc plus api_version, ssl, host,
port, token, organization ni bucket. include / exclude / tags restent en YAML :
c'est le perimetre des entites historisees, non concerne par la depreciation.
Le jeton vit desormais dans l'entree d'integration ; influxdb_token reste dans
secrets.yaml comme copie de reference et ne doit pas etre supprime.
Rien n'est modifie sur l'installation : le retrait des sept lignes de
configuration.yaml demande un redemarrage de Home Assistant, a faire hors des
fenetres qui comptent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La console VRM est hebergee dans le cloud Victron et disparait quand une
coupure d'orage emporte Internet. Meme vision, lue sur le reseau local :
reseau, charges, batterie, borne, production, detail par tracker, les flux
dans le temps et l'energie heure par heure.
Tout dans Grafana, rien dans Home Assistant — et pour une raison trouvee en
verifiant si son tableau Energie pouvait servir : gx_device_pv_energy et les
compteurs d'energie batterie du GX se remettent a zero sans le signaler.
state_class total sans last_reset, donc HA n'auto-detecte pas la remise a zero
et a enregistre -373,35 kWh sur l'heure de 07:00. Les energies sont donc
obtenues en INTEGRANT LA PUISSANCE, methode qui ignore le probleme.
Trois versions du calcul avant la bonne : somme ponderee (laissait des trous,
une grandeur stable n'etant jamais reecrite), moyenne des minutes presentes
(sur-comptait : 5,13 kWh a 01 h pour 22 minutes observees), puis axe des
minutes complet + report + avg x count/60 = energie reellement accumulee,
correcte y compris pour l'heure en cours.
Recoupement avec la capture VRM du proprietaire : 8,07 kWh de reseau contre
"Depuis reseau 9,0 kWh", l'ecart valant exactement les treize minutes entre
l'ouverture des heures creuses et le demarrage du service d'historisation.
45/45 requetes verifiees contre les bases reelles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
L'application Grafana de l'App Store ne parle qu'a Grafana Cloud ; une instance
auto-hebergee se consulte au navigateur, epingle sur l'ecran d'accueil. Reste
que les trois tableaux existants sont dessines pour un ecran large.
Contrainte de conception, verifiee et notee dans le README : sous ~770 px,
Grafana passe CHAQUE panneau en pleine largeur et les empile. Le nombre de
panneaux devient le nombre d'ecrans a faire defiler. D'ou six panneaux
seulement, et les chiffres regroupes dans deux panneaux "stat" — plusieurs
valeurs dans un meme panneau restent cote a cote, la ou six panneaux separes
auraient fait six ecrans.
La reponse d'abord : batterie, marge (ce qu'elle a moins ce qu'il lui faut),
excedent. Puis l'energie a couvrir et l'heure du relais solaire. Puis les deux
courbes qui expliquent ces chiffres, la frise du reseau, et les huit derniers
evenements.
26/26 requetes verifiees contre les bases reelles.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois defauts trouves en LISANT les tableaux, qu'aucune des 19 requetes ne
signalait puisqu'elles s'executaient toutes sans erreur.
1. `historise-evcs.mjs` horodate chaque mesure avec son propre last_updated —
le vrai instant de la mesure, et c'est le bon choix. Mais deux grandeurs ne
partagent alors presque jamais le meme ts : 2656 lignes pour 2656 instants
distincts. Mes GROUP BY ts rendaient une ligne par grandeur avec une seule
colonne remplie, donc la courbe "Excedent" — la grandeur meme du §36 —
etait VIDE sur les 2650 lignes.
2. Le service n'ecrit que les changements, donc un regroupement a la minute
laisse des trous : la difference n'existait que 73 minutes sur 434. Report
de la derniere valeur connue, ce que fait aussi le controleur en temps
reel. 430/435 apres.
3. L'energie horaire par sum(valeur)/60 suppose 60 echantillons par heure ; il
y en a eu 26 a 47. Integration ponderee par la duree, plafonnee a 300 s
pour qu'un arret du service n'extrapole pas une valeur perimee. ~9 %
d'ecart. Le "25 a 58 %" que j'avais d'abord annonce etait faux : il
comparait la somme a la moyenne, qui ignore la duree.
Plus deux corrections d'affichage : la colonne `jour` s'affichait
"2026-09-04 02:00:00" (date nue rendue comme instant UTC), et le decompte des
chargeurs MPPT est de six entites publiees, pas sept.
Lecon : verifier-dashboards.mjs prouve qu'une requete s'EXECUTE, pas qu'elle
rend la grandeur voulue — une colonne integralement nulle passe sans un mot.
Ce sont les courbes regardees a l'ecran qui ont attrape les trois.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Grafana journalise au niveau ERREUR l'absence des dossiers de provisionnement
`plugins/` et `alerting/`, que ce deploiement n'utilise pas. Le service
demarre et fonctionne parfaitement, mais un journal qui crie au loup apprend a
etre ignore — et celui-la sera lu pour comprendre un incident.
Deux dossiers vides, avec un .gitkeep qui explique pourquoi ils existent
(git ne versionne pas les dossiers vides). Effet au prochain demarrage du
conteneur, rien d'urgent.
Deploiement verifie en reel : Grafana repond 200 sur http://10.10.10.22:3001,
database ok, provisionnement des tableaux termine sans erreur.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
`condition: service_healthy` rendait le demarrage de Grafana dependant du
healthcheck de PostgreSQL (intervalle 1 min). Grafana n'a pourtant besoin
d'aucune base pour demarrer, seulement pour repondre a une requete : la
condition ajoutait un mode de panne sans contrepartie, et un outil de
diagnostic doit surtout etre disponible quand quelque chose va mal.
Ramene a un simple ordre de demarrage.
Procedure corrigee sur deux points constates au deploiement reel :
- `sudo` est obligatoire sur DSM (socket Docker inaccessible autrement) ;
- le `git pull` que j'avais indique n'a aucun sens : /volume2/projects cote
Syno et /mnt/projects cote poste sont le meme dossier (export NFS depuis
10.10.10.22), il n'existe qu'une seule copie du depot.
Configuration verifiee en la rejouant dans un conteneur local, volume nomme
compris : deux sources de donnees, trois tableaux dans le dossier EVCS,
database ok, aucune erreur de provisionnement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois tableaux de bord provisionnes depuis git, sur le modele de la regle R2
(le depot est la source de verite, l'interface ne peut pas les ecraser) :
La nuit SOC reel contre SOC exige par le bilan, et la marge entre les
deux. C'est la question qui avait demande une nuit d'archeologie
le 03/09.
Le solaire l'excedent (§36), la censure, et le mode declare par chacun des
sept chargeurs (§37) — le signal le plus direct dont on dispose.
Prevision l'ecart heure par heure, avec la bande de censure dessous : une
production sous la prevision peut vouloir dire mauvaise
prevision OU absence de preneur.
Les evenements de la table `evenement` deviennent des marqueurs verticaux sur
tous les graphiques — une courbe sans ses evenements ne s'interprete pas.
tools/verifier-dashboards.mjs rejoue CHAQUE requete pour de vrai (SQL contre
PostgreSQL, Flux contre InfluxDB, macros Grafana substituees), annotations
comprises puisqu'elles s'executent sur tous les panneaux. Sans lui une requete
cassee ne se voit qu'a l'ecran, panneau par panneau. 19/19 au deploiement.
Port 3001 et non 3000 : sonde avant d'ecrire la ligne, quelque chose ecoute
deja sur 3000 — la lecon du 5432 deja pris par le PostgreSQL de DSM.
Connexion PostgreSQL par le role evcs_lecture : un tableau de bord ne doit pas
pouvoir ecrire dans la memoire. Aucun secret duplique, aucun secret commite :
le provisionnement les reference par $VARIABLE depuis les deux .env.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Une courbe sans ses evenements ne s interprete pas. Le service voit passer les
etats toutes les minutes : autant qu il en tire les conclusions plutot que d
attendre que quelqu un y pense.
Douze etats DISCRETS suivis — contacteur EDF, session reseau de nuit, verrou
hysteresis, vehicule branche, strategie, vehicule selectionne, etat BatteryLife,
mode de l Auto Charge Manager, reseau necessaire, vigilance orage, production
bridee. Les grandeurs continues restent dans mesure et les decisions dans
decision : un evenement qui double une autre table est du bruit. Une lecture
unavailable n est pas une transition mais une absence de lecture, elle n est pas
consignee.
Le redemarrage de Home Assistant est detecte sans capteur d uptime, qui n existe
pas ici : au redemarrage HA restaure ses helpers et leur pose un last_changed
neuf. Le 04/09 a 07:28:49, 352 entites partageaient la seconde du redemarrage
dont 183 input_number. Le service prend donc le mode des last_changed des
input_number — aucune entite codee en dur, et l estimation se corrige d
elle-meme puisque entre deux redemarrages seuls les helpers reellement ecrits s
ecartent du mode. Sous dix helpers d accord, la signature est jugee trop faible
et rien n est affirme.
Un episode d indisponibilite de Home Assistant est journalise AU RETOUR avec sa
duree : au moment de la panne, la base n est peut-etre pas joignable non plus.
Au premier cycle l etat est enregistre SANS rien journaliser, sinon chaque
redemarrage du service produirait douze fausses transitions ; seul le demarrage
du service est consigne.
Verifie de bout en bout en conditions reelles et non seulement a blanc : essai a
blanc avec cycle court, bascule reelle du selecteur de vehicule puis
restauration. Amorcage sans fausse transition, cycle sans changement a zero
evenement, les deux bascules relevees, etat restaure.
Documente aussi le GRANT INSERT sur la seule table evenement pour le role d
analyse — insert seulement, ni update ni delete : on ajoute une annotation,
jamais on ne reecrit ni n efface les precedentes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Redemarrage de Home Assistant a 07:28, apres la fermeture de la fenetre HC,
aucune charge en cours et PV nul. API de retour en 22 s, capteurs revenus en 31
apres le keepalive Venus, un seul cycle du controleur manque. Aucun trou dans
l historisation PostgreSQL : l ecart maximal entre deux mesures de SOC sur les
40 minutes encadrant le redemarrage est de 80 s et se situe avant, ce qui est la
cadence normale du service.
249 entites distinctes ecrivent dans InfluxDB dans les dix minutes qui suivent,
a la resolution native — jusqu a 84 points en 10 min pour la puissance AC-out.
C est ce que PostgreSQL ne peut pas faire et ce pour quoi la proposition B
existait.
Premiere interrogation reelle de la memoire avec le role de lecture seule : onze
points sous la ligne du bilan ce matin, lisibles en une requete.
Faille de conception reperee et consignee : la table evenement a ete creee pour
consigner deploiements et incidents, mais le role d analyse est en lecture seule
donc je ne peux pas y ecrire. Ce redemarrage aurait du y figurer. A trancher
entre une commande d ecriture dans le service d historisation ou un INSERT
restreint a cette seule table.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La veille de nuit a rendu son verdict : UNE seule bascule sur 69 releves entre
01:26 et 07:07. La session reseau unique fait ce pour quoi elle a ete concue,
EDF ferme d un bout a l autre de la fenetre sans creneau ni oscillation.
Mais a 02:50, la voiture finie, le sourceMode est passe a bloque et la consigne
reseau est retombee de 5078 a 50 W. Contacteur ferme, reseau disponible, heures
creuses, et l ESS ne demandait que 50 W pendant que la maison tirait 770 W sur
la batterie. Trois heures et demie, SOC 44 vers 17 pour cent, 2,60 kWh pris a la
batterie quand le reseau etait la et bon marche. L Auto Charge Manager est reste
pret a recharger avec DVCC a 30 A, mais la consigne ne demandait jamais l
energie. C est le defaut du 01/09 revenu ailleurs : j avais etabli que fermer le
contacteur ne suffit pas, puis cree la veille une nouvelle raison de le garder
ferme sans la brancher sur la consigne.
gridSessionActive inclut desormais l engagement de session. Regle : tant que le
contacteur est ferme a notre demande, la consigne couvre la maison, peu importe
laquelle des deux raisons le tient.
Consigne de repos portee de 50 a 200 W a la demande du proprietaire, avec une
justification mesuree : sur 12 074 echantillons du point de raccordement, 17 %
sont negatifs, mediane -18 W. Ce n est pas de l injection — la batterie
debitait 744 W au meme moment et les 22,7 Wh cumules representent 0,9 % de ce
qu elle perdait — c est le regulateur qui chasse autour d une cible trop proche
de zero. A 200 W le point de fonctionnement reste positif sur l essentiel des
excursions, sans supprimer les pointes les plus fortes.
Consigne aussi que le 20 % n est pas le notre mais le plancher de l ESS, qui a
fini par faire de lui-meme a 06:20 ce que la session aurait du faire depuis
02:50, apres avoir vide la batterie de 27 points.
Golden 78 -> 80, deux mutations ciblees. Piege rencontre et documente : la
premiere redaction du contrefactuel portait deux fois la clef balance_status, et
en JavaScript la derniere gagne — il testait donc l inverse de son libelle. Un
contrefactuel doit reposer sur une difference physique, pas sur la surcharge d
une clef deja presente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La commande de controle affichee par creer-role-lecture.sh manquait sudo :
elle echouait sur la socket Docker au lieu de tester le role, donc elle ne
controlait rien.
exporter-jeton-influx.sh recopie le jeton d ecriture InfluxDB du .env local
(droits 600, lisible du seul compte DSM) vers le .env a la racine du depot,
lisible depuis le poste de travail. Sans ce pont il faudrait afficher le jeton
pour le recopier a la main dans le secrets.yaml de Home Assistant, qui vit sur
une autre machine — exactement ce qu on cherche a ne plus faire. Rien n est
affiche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le proprietaire releve, a juste titre, que ma commande precedente lui demandait
de CHOISIR un mot de passe — trois messages apres lui avoir explique qu un
secret se genere et ne se choisit pas. Contradiction corrigee par un script.
creer-role-lecture.sh cree le role evcs_lecture en lecture seule, tire son mot
de passe avec openssl et le depose directement dans le .env a la racine du
depot, sans jamais l afficher : rien a recopier entre deux endroits, donc rien
a exposer dans une capture. Il est rejouable — si le role existe et que son mot
de passe est deja dans le fichier, il ne fait rien.
Deux raisons de ne pas analyser avec le compte evcs : une memoire dont tout
l interet est de ne pas etre reecrite ne se consulte pas avec un compte qui peut
ecrire, et un mot de passe range dans un fichier lisible par un autre compte ne
doit pas etre celui qui gouverne la base. Les privileges par defaut couvrent les
tables futures, et un REVOKE explicite ferme l ecriture par ceinture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le demarrage a echoue sur "listen tcp4 0.0.0.0:5432: bind: address already in
use". Synology fait tourner son propre PostgreSQL sur le port standard pour ses
services internes ; on ne le deloge pas, on se met a cote. Notre base est donc
publiee sur 5433, et ce port ne sert qu a l analyse depuis un poste de travail.
Corrige au passage une erreur de conception que ce plantage a revelee : j avais
repris network_mode bridge du chien de garde, ou il se justifiait parce qu il
n a qu un conteneur et doit joindre le GX. Ici il prive les trois services du
reseau interne de compose, donc de la resolution par nom — ce qui m avait
conduit a coder l adresse 10.10.10.22 en dur dans le service d historisation
pour qu il rejoigne une base situee dans le meme compose. Supprime : les
conteneurs se parlent desormais par nom de service, sans dependre du port
publie ni d une IP.
InfluxDB a demarre du premier coup, 8086 etant libre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Question du proprietaire : HA_TOKEN il l a, mais les mots de passe PostgreSQL
et InfluxDB, il les invente ? Non — ils se generent. Les deux bases n existent
pas encore, c est ce fichier qui decide de leurs identifiants, et personne ne
les tape jamais : les conteneurs les lisent dans .env et Home Assistant lit le
jeton dans son propre secrets.yaml.
preparer-env.sh les tire avec openssl rand, reprend HA_TOKEN du .env a la
racine plutot que d en creer un nouveau, pose les droits a 600, et affiche la
ligne a recopier dans secrets.yaml. Il refuse d ecraser un .env existant :
regenerer les mots de passe d une base deja creee la rendrait inaccessible.
Corrige au passage un piege laisse dans l exemple : POSTGRES_PASSWORD et
PGPASSWORD etaient deux variables a tenir egales a la main. Le fichier s appelle
desormais .env, donc compose l utilise aussi pour la substitution, et le service
d historisation reprend le mot de passe par substitution. Un seul secret
PostgreSQL desormais.
Generateur essaye dans un bac a sable : fichier conforme, refus de regeneration
verifie. Fichiers d echange des editeurs ajoutes au gitignore.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le proprietaire a tranche : on met les deux en service et on decidera a l usage
s il faut garder les deux. Elles ne repondent pas a la meme question.
PostgreSQL garde ce que n8n CALCULE — sorties du bilan, decisions du
controleur, prevision telle qu elle a ete publiee — parce que ce ne sont pas des
capteurs, donc qu aucune statistique Home Assistant ne les retient, et parce que
ce sont des vecteurs, du texte et des jointures. Cinq tables, une vue de confort
qui repond a la question restee sans reponse le 03/09 : ce que le bilan exigeait
contre le SOC reellement atteint, heure par heure.
InfluxDB garde ce que Home Assistant OBSERVE, a la resolution native et sur tout
le perimetre energie, y compris les entites auxquelles personne n a encore
pense. C est exactement ce qui a manque le 03/09, quand les modes des chargeurs
MPPT se sont reveles etre le bon signal alors que personne ne les enregistrait.
Les deux sur 10.10.10.22 : cette machine ne porte qu un service, quand
10.10.10.17 en porte quatre. Le volume n est pas l argument, les deux Synology
ont des teraoctets libres.
L alimentation de PostgreSQL ne passe volontairement PAS par n8n. Tout ce que
n8n calcule, il le publie deja dans des helpers Home Assistant : les lire donne
la meme information sans toucher aux trois workflows de production stabilises
hier soir ni creer d identifiant dans n8n. L horodatage retenu est celui de Home
Assistant et non celui du sondage, si bien qu une valeur inchangee porte la meme
clef primaire et n est pas reecrite : on enregistre quand la grandeur bouge, pas
quand on regarde.
Essai a blanc verifie sur l installation reelle : 15 mesures, 1 ligne de bilan,
1 decision, 2 previsions, avec les bonnes dates. Le mode blanc comptait d abord
les lignes ecrites, donc zero par construction — corrige pour compter ce qu il
ecrirait, sans quoi il ne verifiait rien.
Le branchement de Home Assistant sur InfluxDB demande un redemarrage et n est
donc PAS applique : le fichier de configuration est pret, a poser en milieu de
matinee, jamais entre 01:24 et 07:24.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Trois corrections a ce que j affirmais. L historique brut ne s arrete pas a
7 jours : il remonte au 14/08, soit 20,8 jours, et s allonge vers les 90
configures — mon chiffre datait du 27/08. La base n est pas corrompue : le
"malformed" venait de ma lecture avec immutable=1, qui ignore le journal WAL. Et
le volume de 10.10.10.17 n est pas de 133 Go mais de 7,0 To dont 5,0 libres :
j avais interroge df sur le dossier parent du point de montage, donc sur la
racine de mon propre poste. Le proprietaire l a releve, capture a l appui.
Cause reelle du manque de memoire : sur 288 entites ayant des statistiques long
terme, les quatre series dont le bilan depend n y etaient pas — consommation,
PV, reseau, courant batterie. Home Assistant ne construit ces statistiques que
pour les capteurs declarant state_class, et neuf capteurs sur vingt a unite
numerique le declaraient. Le SoC le declarait, d ou ses six mois d historique.
Correctif : dix lignes state_class: measurement dans configuration.yaml, rien
d autre, diff verifie, sauvegarde prealable. Exclu volontairement la puissance
nominale des onduleurs, constante a 9000 W. Procedure check_config, mqtt.reload
puis keepalive Venus pour forcer la republication — aucun trou, les series sont
revenues numeriques dans la seconde. 288 entites en statistiques deviennent 299.
Fait a 00:57, vingt-sept minutes avant l ouverture de la fenetre HC, premiere
nuit du test de la session reseau unique : un rechargement MQTT aveugle le
controleur le temps de la republication et ne doit jamais avoir lieu juste avant
01:24.
Consigne aussi la verification de la prevision solaire — le total est bon a 89
et 110 % pres, mais la forme est systematiquement decalee, production plus tot
que prevu et apres-midi sur-promis d un facteur 2 a 3 apres 16 h, ce qui
sous-estime l energie a couvrir — et le constat sur le conseiller en mode ombre,
d accord 92,5 % du temps avec les regles et qui argumente desormais pour le
palier qu on vient de remplacer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Informations donnees par le proprietaire, a ne pas lui faire repeter.
La consommation est pilotee par les repas et non par une courbe lisse : quatre
personnes, bouilloire a 05:45, grille-pain a 08:00, cuisson du soir dont
l heure varie entre 20 h et 23 h selon les jours, et des repas differents d un
jour a l autre. Un profil horaire moyen ne represente donc rien, et moyenner
deux jours dont le pic est a 20 h et a 23 h produit un profil que ni l un ni
l autre ne ressemble. C est la cause la plus probable de la sous-estimation du
profil p50 mesuree la nuit du 02-03/09. Le proprietaire souligne aussi qu une
decharge courte mais forte n a pas le meme effet sur le stockage et l autonomie
qu une decharge lente de meme energie, et que ce n est pas lineaire — la courbe
energie/SOC du 03/09 ne dit rien du rendement sous fort courant.
Strategie hivernale : deux charges reseau par jour, batterie a 85 % en heures
creuses de nuit pour faire la jonction avec le PV du matin, puis une recharge de
midi pour tenir jusqu a la fenetre suivante. C est un contournement manuel de la
meme famille que les charges programmees ESS et la consigne a 4200 W ; le besoin
reste entier et ne doit pas etre retire avant que le bilan sache le produire
seul. Le cablage du 03/09 ne couvre que la session de nuit.
Un pack bloque la charge a 94 %, ce qui explique que la courbe mesuree s arrete
a 93. En rebranchant le pack isole, le blocage pourrait descendre a 85 %, valeur
possiblement fausse et donc a mesurer. Si le blocage reel est a 85, le plafond
de 90 % de la cible du matin devient inatteignable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
576 paliers de SOC mesures sur 8 jours (tools/mesure-courbe-batterie.mjs,
ajoute) : pour chaque palier ou le SOC reste a une valeur puis descend d un
point, on integre la puissance batterie, en ecartant les paliers ou la batterie
a charge et ceux ou le reseau a apporte quoi que ce soit.
Resultat : plate a 0,169 kWh/point de 33 a 93 — six tranches independantes entre
0,163 et 0,171 — genou net a 32-33, puis 0,097 en dessous. Sous le genou un
point de SOC vaut 57 % de ce qu il vaut au-dessus, ce qui est coherent avec le
parc reel (un module en panne sur huit, un autre qui faiblit).
Energie utile totale de 100 a 22 % : 12,39 kWh mesures, contre 11,70 vus par le
bilan (15 kWh a plat) et 13,65 par INPUT_PARSE (17,5). Les deux constantes
etaient fausses, dans des sens opposes.
Comme 15 kWh se situe ENTRE les deux pentes, l erreur changeait de signe : SOC
requis trop bas de 3 a 4 points pour un petit deficit, trop haut de 4 a 6 pour
un gros. Cela corrige au passage une affirmation inexacte de la section 40, ou
j avais ecrit que required_soc etait systematiquement trop bas d un facteur
1,75 : ce facteur comparait la vitesse de descente du SOC a celle de la ligne,
deux grandeurs differentes, et l ecart venait surtout de la sous-estimation de
la consommation par le profil p50. La correction est posee en tete de la
section 40.
Trois fonctions remplacent les cinq conversions lineaires de BALANCE.js ;
requiredSocAtStartPct reste non ecrete au-dela de 100, l extrapolation utilisant
la pente haute. INPUT_PARSE passe de 17,5 a 16,9 avec la consigne explicite
qu un calcul traversant le genou doit lire la courbe et non cette constante.
Tests du bilan 42/42 apres mise a jour deliberee de six attendus, chacun verifie
a la main contre la courbe. Un libelle corrige : le seuil fixe de 30 % tombait
juste ce matin-la par coincidence, pas par construction. Deux mutations — pente
basse ramenee a la pente haute, puis genou ramene au plancher — font tomber les
six memes scenarios. Golden 78, hysteresis 7 et advisor inchanges.
Les trois nombres sont des resultats de mesure, pas des reglages, et vivent dans
le code avec l outil qui les produit ; a rejouer apres l extension du parc.
Principale erreur restante du bilan, desormais devant la conversion : le profil
de consommation p50 sous-estimait de 33 % les heures 03-06 de la nuit du
02-03/09. A instruire separement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
§26 avait pose l objectif et designe le critere. Avant d ecrire quoi que ce
soit, j ai mesure les kWh reellement sortis de la batterie par point de SOC sur
cinq fenetres et trois nuits : 0,164 a 0,171 kWh/point au-dessus de 42 %, soit
environ 17 kWh, mais 0,121 entre 45 et 22 % et 0,082 entre 33 et 20 %. En bas
d echelle un point de SOC vaut moitie moins, alors que BALANCE.js convertit avec
une constante unique de 15 kWh. required_soc y est donc systematiquement trop
bas — c est le facteur 1,75 mesure la nuit du 02-03/09, ou le SOC descendait
bien plus vite que la ligne.
Cette mesure a dicte la conception : le relachement de la session ne peut pas
etre un seuil de SOC, puisqu il porterait sur une grandeur fausse et que tout
seuil que le SOC repasse ensuite rouvre l oscillateur du 27/08. Les deux
variantes evidentes — relacher sur required_soc, ou sur required_soc_prudent
avec la bande p50/p80 — ont ete ecartees pour cette raison.
Retenu : engagement sur le bilan (batterie sous la cible), relachement a la fin
de la fenetre. L oscillation devient structurellement impossible, la condition
de sortie etant monotone : une fenetre ne se ferme qu une fois. Un nouveau
helper input_boolean.victron_evcs_night_grid_session_committed porte
l engagement, cree par input_boolean.reload sans redemarrage HA et ecrit
seulement sur changement reel ; sans cette persistance la garde redeviendrait
une bande, donc un oscillateur.
Effet : l ACM recharge jusqu a la cible puis tient la batterie a 2 A, la maison
finit la nuit sur le reseau en heures creuses au lieu de vider la reserve, et la
batterie arrive a l aube pres de sa cible avec de la place pour le solaire. La
coupure immediate E2 de l hysteresis exige l absence d override et le helper
takeover reste ON : aucune modification du workflow d hysteresis.
Golden 75 -> 78. Le scenario epingle quelques heures plus tot comme limite
connue devient celui du correctif, attendu mis a jour dans le meme commit.
Quatre mutations ; la plus parlante retire la garde bilan et fait tomber les
trois scenarios anti-oscillateur du 27/08 — les tests de l ancien correctif
protegent le nouveau code.
Prerequis identifie et non traite : la conversion kWh vers points de SOC est une
constante la ou la realite est une courbe. Consequence, un sous-declenchement
possible en bas d echelle, jamais une oscillation. Prochain chantier du bilan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La regle classait le lendemain en trois paliers a partir de son TOTAL (>= 18 kWh
-> 35 %, >= 10 -> 55 %, sinon 85 %) et ignorait donc l heure d arrivee de
l energie. Le 03/09 demain annoncait 33,9 kWh — donc "fort", donc 35 % — avec un
matin creux (0,03 kWh a 7 h, 0,77 a 8 h) et un croisement a 9 h. Meme defaut que
le plancher du soir, a l autre bout de la nuit.
Releve de la nuit 02-03/09, requis contre reel : 00:30 62,4 / 53 ; 03:00
50,4 / 45 ; 04:30 41,7 / 37 ; 06:00 37,1 / 22 — cible fixe a 35 tout du long.
Le required_soc decroit proprement avec la nuit qui se consomme (6,1 -> 0 kWh a
couvrir), la batterie est restee sous la ligne toute la nuit, et le bilan le
savait des 00:30. A 03:00 EDF a ete relache cinq points sous la ligne ; le
reseau est revenu de 07:24 a 10:33 au plein tarif, 1,49 kWh.
La cible vaut desormais min(90, max(palier ou advisor, required_soc)). Sens
unique delibere : la direction corrigee est celle de l echec observe, et le
principe unificateur des deux cablages est que le bilan ne pousse jamais dans le
sens "couvre moins bien la nuit". Plafond 90 parce qu au-dela la batterie cesse
d etre un puits et evince la production du matin, et parce que le bilan publie
sans ecretage des valeurs superieures a 100 — sans ce plafond la cible serait
inatteignable et EDF resterait allume toute la nuit. C est deja la borne du
chemin advisor, aucune constante nouvelle.
Pas d oscillateur : required_soc decroit de facon monotone pendant la nuit et la
passe unique de recovery reste en place. Gardes et repli identiques au plancher
du soir, kill-switch existant.
Golden 70 -> 75. Quatre mutations font tomber chacune exactement un scenario
different. Un cinquieme scenario fige une LIMITE CONNUE, mesuree par sonde : la
passe unique de recovery latche le relachement pour toute la session, donc la
cible dynamique n ameliore que la premiere passe. §26 avait deja designe le bon
critere de re-engagement — un budget d energie restant a couvrir, qui appartient
au bilan ; la suite touche la machine a etats de la nuit et fera l objet d un
chantier propre.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
grep evcs_balance sur les deux workflows de decision renvoyait 0 depuis la mise
en service du bilan le 26/08 : il calculait l heure de croisement, l energie a
couvrir et le SOC requis, et personne ne l ecoutait. Le 03/09 a 19:44 les deux
nombres coexistaient dans le meme systeme — evening_soc_start_min a 85 %, un
niveau qui ne sait rien de la nuit, contre evcs_balance_required_soc a 99,7 %,
l energie a couvrir jusqu au croisement de 9 h. A SOC 94 le premier autorisait
la charge, le second disait que la batterie ne passerait pas la nuit seule.
Le plancher de demarrage du soir vaut desormais max(regle, bilan). Sens unique
delibere : le bilan peut durcir, jamais relacher. L assouplir — il dira souvent
moins de 85 % par forte prevision d ete — autoriserait des charges qui n ont pas
lieu aujourd hui, decision distincte a valider pour elle-meme. Le max rend au
passage la garde robuste sans borne ni ecretage : une valeur nulle, negative ou
aberrante ne peut pas relacher le plancher.
Portee demarrage : le plancher de maintien reste min(...), donc a 80 %, et
aucune charge en cours n est coupee. L abondance P6 continue de primer, etant
une preuve mesuree que la ressource depasse ce que le systeme absorbe.
Gardes : fraicheur inferieure a 30 min (six cycles du bilan), horodatage futur
rejete, statut ok, valeur finie. Sinon regle historique. Aucun nouveau toggle :
evcs_balance_enabled a OFF arrete les ecritures du bilan, balance_last_run se
fige, la fraicheur expire et le plancher retombe seul sur 85 % en une
demi-heure — un helper de plus aurait fait doublon.
Gabarit complet re-rendu contre HA : 195 champs, JSON valide, aucun null.
parseAdvisorRunToMs reutilise, l advisor et le bilan publiant le meme format.
Golden 66 -> 70. Quatre mutations — bilan ignore, Math.max remplace par une
affectation directe, garde de fraicheur supprimee, garde de statut supprimee —
font tomber chacune exactement un scenario, et un different a chaque fois.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le correctif precedent bloque l incident de 19:44, mais un excedent proche de
zero est ambigu : c est la signature de la censure ET celle de l equilibre de
fin de journee. Le releve du 03/09 contient les deux avec le meme excedent —
18:50 : +14 W, ressource refusee ; 19:41 : +1 W, plus rien a donner. Rejeu du
19:41 : batteryAssistSolarStartOk etait encore vrai. Trois minutes avant
l incident, le systeme aurait commis la meme faute.
Le plan annoncait de lire evcs_balance_pv_censored. Lecture de CENSORSHIP.js :
ce drapeau est un OU de motifs dont l un est exactement le proxy qu on voulait
remplacer (socPct >= 90 et batterie sans puits). Et il est reste ON jusqu au
calcul de 19:50, soit cinq minutes APRES le demarrage de la charge — ce qui l a
fait basculer n est pas la censure mais sun_elevation passant sous 10 degres.
Il n aurait pas bloque l incident.
Le signal juste, ce sont les chargeurs eux-memes : sept entites
sensor.*_mppt_operation_mode, jamais lues par aucun workflow. mppt_active = je
suis a mon point de puissance maximale, je donne tout ; voltage_current_limited
ou off = je me retiens faute de preneur. Le 03/09 elles ont bascule a 19:20,
soit 24 minutes avant pv_censored, sans aucun proxy et a la cadence de la
boucle. Contre-verification le 01/09 a 14:22 : les trackers restaient limites
PENDANT une charge de 3,4 kW sous 6,9 kW de PV, donc le signal ne s auto-annule
pas a midi.
Collecte sans aucun entity_id code en dur (selectattr sur mppt et
operation_mode), expression testee sur /api/template puis gabarit complet
re-rendu : 191 champs, JSON valide, aucun null. Lectures inexploitables
ecartees, et repli sur le comportement anterieur quand il n en reste aucune.
Garde de DEMARRAGE uniquement, structurellement : la lier au sourceMode ou au
maintien ferait que la charge, en donnant un preneur au MPPT, detruirait sa
propre condition d autorisation — le bistable de l abondance P6 corrige le
24/08.
Golden 64 -> 66. Mutation dans trois directions : garde neutralisee -> 1 echec
cible, provocation toujours refusee -> 3 echecs, lecture illisible traitee
comme "a fond" -> 1 echec sur le scenario de repli.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Le 03/09 a 19:44, voiture branchee : PV 758 W, maison 1202 W, batterie deja
a -12 A, nuit qui tombe. Le controleur a lance 1,6 kW de charge parce que
pv_start_min_w (700 W) est une puissance PV absolue : "758 >= 700, donc il y
a du soleil". L excedent valait -444 W. En 33 minutes la voiture a pris
0,897 kWh et la batterie en a rendu 1,479 kWh (SOC 94 -> 85), la veille d une
nuit que le bilan energetique annoncait deja deficitaire.
Rejeu du releve dans la vraie chaine : rawSolarStartOk ET
batteryAssistSolarStartOk etaient tous deux vrais. Corriger le seul seuil PV
n aurait donc rien change ; les deux chemins sont traites ensemble.
La grandeur juste est ce qui reste une fois la maison servie. Sans injection
et reseau absent, PV - maison(hors EVCS) vaut la puissance batterie au signe
pres, et separe les deux situations que la mesure PV seule confond : sous
censure la production se cale sur la maison, l excedent vaut ~0 et il y a de
la ressource refusee ; en deficit reel l excedent est negatif et la batterie
porte deja la maison. Zero est la frontiere physique entre les deux, verifiee
sur le releve du 03/09 (excedent positif sur toute la plage ou pv_censored
etait ON, negatif ensuite).
Aucune constante nouvelle, aucun champ de snapshot, aucun helper :
derived.houseNonEvcsW existait deja. Le chemin "soleil reel" reutilise
pv_start_min_w tel quel, applique a la bonne grandeur ; le chemin
"provocation" exige seulement excedent >= 0. Demarrage uniquement : les
conditions de maintien gardent leur plancher et leur tolerance temporelle.
Golden 61 -> 64, autour d une paire de releves reels pris a 54 minutes d ecart
dont les lectures PV ne different que de 11 W (769 puis 758) : le premier
demarre, le second non. apresmidi-provocation-p3 est corrige : il portait
PV 300 W, maison 600 W, batterie +2 A reseau ouvert, un trou de 300 W que rien
n alimente, et passait quand meme parce que le demarrage ne regardait jamais
le bilan. Mutation dans les deux sens : 2 echecs cibles a chaque fois,
excedent-censure-demarre restant vert (il tient par le chemin assistance).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
La table des bandes SOC declarait depuis toujours un courant souple tolere
pendant des minutes et un courant dur tolere quelques secondes. Les deux
tolerances etaient calculees, exportees dans le debug, et lues par aucune
decision : le controleur comparait un echantillon instantane a un plancher,
toutes les 30 s.
A SOC 94 la batterie est en float et son courant oscille entre +1,8 et -2,6 A
d'un echantillon a l'autre. Le test devenait un tirage a pile ou face et la
charge du vehicule s'arretait sur du bruit : deux fois le 01/09, quatre a six
fois par jour la semaine precedente. Chaque arret coutait environ 0,45 kWh,
la batterie etant pleine et le vehicule le seul preneur.
Le correctif est purement temporel : aucun seuil n'est deplace, aucune
constante ajoutee. La tolerance de la bande est branchee sur les trois
conditions de MAINTIEN, via un helper de persistance qui porte le debut du
depassement en cours. Le plancher de demarrage et le garde dur restent
instantanes : la tolerance est du confort, jamais du risque.
Golden 56 -> 61. Preuve par mutation dans les deux sens : tolerance supprimee
-> 2 echecs cibles, tolerance infinie -> 3 echecs cibles, l'arret dur restant
vert dans les deux cas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Sonde de 777 W reellement publiee sur le topic de consigne du GX,
relue, puis valeur d origine remise par le script. Le dry-run supprimait
exactement ce maillon.
Et la fin de session s est deroulee dans le bon ordre sans coordination :
consigne retombee a 50 W a 03:31:30 avec l etat de fin de charge, puis
contacteur ouvert 34 s plus tard. La demande baisse avant que le reseau
parte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
Docker de Synology refuse un bind-mount dont le dossier hote est absent,
la ou Docker standard le creerait. deploy/watchdog/logs est desormais
versionne vide, et le compose le dit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ
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
