La tache DSM « Au demarrage » CHARGE_PILOTES a ete creee en owner 1026 (TMZF5455),
pas root (verifie en base esynoscheduler). insmod aurait echoue en silence au
boot -> pas de /dev/ttyUSB0 -> conteneur bloque. Le script se re-exec via sudo -n
(passwordless pour cet utilisateur sur le .17) quand il n'est pas root. Teste en
lançant le script sans prefixe sudo : il s'eleve et charge les pilotes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le releve tournait sur le PC portable (deploy/releve-cellules/lancer.sh) : ferme,
il ne releve plus, et le 20/09 son @reboot a refuse de relancer sur un faux
positif du garde anti-doublon -> 4 jours de trou dans la table cellule, Grafana
"No data". Le portable n'a pas vocation a rester allume.
Deplacement vers le Synology .17 (ARCHIVE3, DS920+), toujours allume :
- compose.yaml : conteneur node:20 en uid 1026:100 (le montage NFS peut ecraser
root ; le dossier CSV est g+w pour users), device /dev/ttyUSB0 mappe, depot
monte en /depot. Ecrit les CSV comme avant ; le service d'historisation du .22
les ingere sans changement. restart:unless-stopped remplace la boucle lancer.sh.
- charger-pilotes.sh : DSM embarque usbserial.ko + ftdi_sio.ko mais ne les charge
pas d'office. Script root (Planificateur DSM au boot) qui insmod les deux et
ouvre les droits de /dev/ttyUSB0.
- README.md : deploiement, bascule depuis le portable, verification.
Garde anti-blocage dans pylontech-console.mjs (--suivi) : lireJusqua resout au
timeout au lieu de rejeter, donc un port fige renvoie du vide en boucle sans
jamais crasher -- exactement le hang du 20/09. Un controle du mtime du CSV force
process.exit(1) apres 3x le pas sans ecriture, pour que le superviseur (conteneur
ou lancer.sh) rouvre le port.
Menage : modified/*.bak-* (rollbacks locaux) ignores comme prepush-* ; ajout des
relevés de mesure batterie des sessions 16-20/09.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 180 A venait de nous (monte 130->150->180 le 13/09, §64), pas du BMS qui
autorise 250. Il bridait reellement : PV 10,6 kW, excedent ~187 A que la
batterie prendrait, plafonnee a 180. Parc sain (cellules pack 2 a 3-6 mV) : on
prend toute la marge, direct a 250 sur decision du proprietaire.
golden-acm 20/20 (2 attendus 180->250), mutation : retour 180 -> 2 echecs.
patch rejouable tools/patch-20260920b-boost-250a.mjs.
⚠️ Surveillance pack 2, surtout module rang 5 (K220803C30160323, le plus ancien).
Pack 1 (US5000) hors surveillance continue (2e cable en commande).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le 52,4 V avait ete pose le 06/09 pour menager la cellule 12 faible du pack
ANCIEN (§57). Ce pack est sorti. Cellules du pack 2 a 3-6 mV, la plus haute a
3356 mV, loin des 3550 mV ou le BMS reduit le courant. On releve le top-off
pour atteindre une charge plus pleine et RECALIBRER la jauge SOC Pylontech (qui
derive tant qu'on n'atteint jamais 100 %). 52,8 V = 3,52 V/cellule, sous les
53,2 V autorises par le BMS.
⚠️ Cellules du pack 1 (US5000) pas encore sous surveillance continue (2e cable
en commande). Proprietaire a autorise explicitement malgre le caveat.
patch rejouable tools/patch-20260920-topoff-52v8.mjs. golden-acm 20/20, attendu
acm-jour-topoff mis a jour (52,4->52,8), mutation : retour a 52,4 -> 1 echec.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Re-mesure du 20/09 sur le parc a 13 modules assaini (cellules 3-6 mV) :
tools/mesure-courbe-batterie.mjs donne 0,30 kWh/point PLAT de 25 a 97 %, PLUS DE
GENOU. Le genou a 33 % etait la signature de la cellule 12 morte du pack ancien
(§50), il a disparu avec elle — exactement ce que predisait la note de prudence
du 03/09. La reserve utile a quasiment double (12,4 -> ~23 kWh de 100 a 22 %).
Le scaling modules/7 rattrapait par chance la partie HAUTE (0,169x13/7=0,31 ~
mesure) mais SOUS 33 % le bilan croyait 0,18 kWh/point contre 0,30 reels ->
required_soc surestime en bas d'echelle. Corrige :
- BALANCE.js : kneePct 33->0, pentes 0,169/0,097 -> 0,1615 plat (x13/7 = 0,30).
- INPUT_PARSE : batteryUsableCapacityKwh 2,414 -> 2,308 kWh/module (0,30/13x100).
- helper evcs_balance_usable_capacity_kwh 15 -> 23 (inerte mais coherent).
Tests : bilan 50/50 apres re-figeage des 10 attendus (verifies a la main : ex
rejeu 24/08, 0,82 kWh -> 22 + 0,82/0,1615 = 27,1 % contre 30,5 avant). Mutation
deux sens : ancien genou -> 10 echecs, pente fausse -> 11. Golden controleur
116/116 inchange (capacite -4 %, aucun basculement discret).
⚠️ Courbe a REMESURER apres toute evolution du parc. 2e cable console en
commande pour surveiller aussi les cellules du pack 1 (US5000), aujourd'hui hors
surveillance continue (trames etendues Cerbo mortes, §69).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Grief du proprietaire du 19/09 : JEEP branchee, du soleil, borne figee apres un
swap rapide -> rien qui charge, et il ne l'a su qu'en regardant. Le service
d'historisation detecte desormais l'episode et le SIGNALE dans un helper ;
la session OpenClaw lira ce helper et enverra l'alerte WhatsApp (son cote).
Critere, robuste par la censure sans injection : batterie pleine => MPPT bride
=> PV ~ conso => excedent ~ 0 => PAS d'alerte. Un excedent POSITIF qui persiste
(> 500 W) avec vehicule branche + borne < 300 W + etat controleur bloquant,
tenu > 10 min => il manque un preneur a de l'energie gratuite => signalement.
Un seul par episode (dedup sur son debut), helper efface a la resolution.
- helper input_text.evcs_alerte_charge (max 255, sans initial:), reload fait.
- detecterAnomalieCharge() + ecrireHelperTexte(), appele dans cycle().
- etat d'episode en processus (repart de null au redemarrage, se re-arme en 10
min sur une anomalie reelle).
⚠️ SEUILS A CALIBRER sur l'historique avant d'etre figes. Le helper reste
INERTE tant que SPARK n'a pas cable l'envoi : deployer maintenant ne fait rien
partir.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Filet MANUEL complementaire a P11-bis : quand meme le second signal echoue
(borne physiquement coincee), l'appui sur input_boolean.evcs_reset_borne force
une session fraiche pour un cycle -> nettoie le collant -> retest du vehicule.
Momentane : le controleur (HA_SERVICE_CALLS) le rebascule off apres avoir agi,
il ne peut donc pas forcer un retest en boucle.
- gabarit + INPUT_PARSE (params.resetBorneRequested) + sessionFresh (OU bouton)
- helper_reset_borne_ack : turn_off si le bouton etait ON
- paquet evcs_reset_borne.yaml (SANS initial:, lecon du 06/09), reload fait
- golden 115 -> 116 : reset-borne-force-retest (session etablie + bouton ON ->
retest + ack off). Mutation : bouton neutralise -> le scenario tombe.
Gabarit rendu contre HA : 203 champs, aucun null.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Incident du 19/09 : VW debranchee ~14:50, JEEP branchee, mais le swap n'a dure
que 14 s. La borne a GELE son etat (charging_time reste a 1h25, jamais
reinitialise) → P11 (base uniquement sur charging_time <= 90s) restait aveugle
→ le collant 'vehicule plein' de la VW bloquait la JEEP, qui n'a pas charge de
l'apres-midi. Un debranchement FRANC de 30s a tout debloque (borne reset).
Le last_changed du capteur de connexion, lui, a bien bouge sur le swap de 14 s
(14:54:17). C'etait l'info qui manquait : personne ne la lisait. sessionFresh
gagne donc un SECOND terme, l'age du dernier (re)branchement, meme fenetre 90s,
independant de la borne :
- gabarit : evcs_vehicle_connected_ts (as_timestamp du last_changed, patron
acin1_last_changed_ts §29) ;
- INPUT_PARSE : evcsVehicleConnectedAgeSec (Infinity si absent => repli sur) ;
- WINDOWS : sessionFresh = charging_time bas OU reconnexion recente.
Golden 113 -> 115 : p11bis-swap-rapide-borne-figee (charging_time fige 1h25 +
reconnexion 30s -> retest) et son contrefactuel reconnexion-vieille (2h -> reste
collant). Gabarit rendu contre HA : 202 champs, aucun null. Mutation deux sens :
retrait du signal -> le swap tombe ; fenetre infinie -> l'etablie tombe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Six leviers epuises. Le GX cree les topics etendus en value:null (decodeur qui
attend et ne recoit pas). Mort datee au redemarrage HA du 15/09 (§69), donc
cause logicielle Venus, pas materielle. Ne plus toucher au materiel batterie.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne les trois configs testees (lues en MQTT direct + console), les trois
conclusions dures (detail deja mort le 15/09 ; inverser le maitre n'agit pas ;
coupable = hub/agregation), la resolution du mystere des 3 bips (chainage
inter-groupes seulement en sens US5000-tete), et la config a garder.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Incident du 18/09 13:08-13:14 : clic BOOST 28 A, le controleur demande le
reseau, l'hysteresis met ~1 min a fermer le contacteur, et pendant ce trou il
MAINTIENT 13 A sur la batterie (hold_min_run_wait_grid_takeover). Le garde
batterie mord a -32,4 A, 23 secondes AVANT l'arrivee d'EDF, et pose 20 min de
verrou — que rien ne leve quand le reseau arrive. Resultat : contacteur ferme,
import qui tourne, voiture a l'arret.
Trois volets :
1. hold_min_run_wait_grid_takeover retombe au courant MINI — miroir de la
sequence d'ouverture (§30) : on ne tient pas la puissance sur la source
qu'on quitte. A 6 A le garde n'aurait jamais mordu.
2. Le stop encode si le reseau etait present : absent => blockReason
'grid_battery_guard_no_grid'. Present => verrou plein inchange (incident du
01/09, consigne insuffisante) — c'est ce qui interdit l'oscillateur
stop/retry a reseau present.
3. BCL leve le verrou '_no_grid' des que le reseau arrive. Reseau toujours
absent : la branche anterieure wait_grid_source protege deja (epingle).
Golden 108 -> 113. Mutations en trois directions, chacune tombant sur un
scenario different. Piege du fixture note en commentaire : ses seuils ne sont
pas a l'echelle du parc reel (fenetre garde reseau / hard general etroite).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le remplacement du commit precedent avait atterri sur l'en-tete de
--historique-distant au lieu de celui de --suivi : le nouveau fichier de suivi
sortait sans la colonne, et le rang restait NULL en base. Corrige, et retire de
la branche historique ou il n'avait rien a faire.
Trouve aussi en relancant : le releve est SUPERVISE par
deploy/releve-cellules/lancer.sh (@reboot, boucle de relance a 60 s, garde
anti-doublon). Ne jamais le relancer a la main — tuer le processus node suffit,
le superviseur repart seul avec le code a jour ; un lancement manuel cree un
doublon sur le port serie et entrelace les lectures.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire demandait si le rang dans le pack etait accessible ou si seul
le code-barres l'etait. Il l'etait depuis le debut : l'outil de releve resout
adresse <-> code-barres au demarrage mais ne l'ecrivait pas. Desormais :
- pylontech-console.mjs --suivi ecrit une colonne 'adresse' (vide en mono-module,
jamais devinee) ;
- historise-evcs.mjs l'ingere par son NOM dans cellule.rang, enregistre PAR
RELEVE et non dans une table figee — un recablage du LVHUB renumerote, et
l'historique de chaque ligne doit garder le rang vrai a son instant ;
- Grafana : colonne 'Rang' dans le tableau de sante, et la liste deroulante
des modules affiche 'rang - code-barres' quand le rang est connu.
75/75 requetes valides.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Signale par le proprietaire avant le PUT : « il faut ajouter la periode HC
12h24 jusqu a 14h24 ». Il avait raison, et le trou etait plus profond qu une
borne manquante — l engagement de session etait gate sur `night_hc` SEUL,
parce que §40 ne traitait que la nuit.
Consequence : la charge HC manuelle qu on venait d ecrire ne pouvait RIEN faire
a midi. Le plancher relevait bien la cible du bilan, mais aucune session ne
s engageait, donc pas de takeover, pas de contacteur, pas de consigne. Le
reglage aurait releve le plancher de demarrage du soir — donc bloque la charge
du vehicule — sans jamais charger la batterie. Le pire des deux mondes.
⚠️ ET LE CRITERE N EST PAS LE MEME AUX DEUX FENETRES. La nuit, on compare le SOC
a `batteryMorningTargetPct`, qui contient le palier de prevision (35/55/85). A
midi ce palier n a aucun sens : il vaut 35 par beau temps, donc un SOC de 30 %
EN PLEIN SOLEIL engagerait une session reseau — la substitution du solaire par
le reseau qu on a mis des semaines a eteindre.
A midi le critere honnete est le SOC requis du bilan lui-meme, qui s auto-regule :
le croisement PV etant passe, l energie a couvrir vaut zero et le requis retombe
au plancher dur. Releve du 17/09 a 13:51, plein soleil : required_soc = 22,0 pour
energy_to_cover = 0,0. Il ne remonte qu un jour sombre — ou quand le proprietaire
pose un plancher manuel, ce qui est exactement le cas d usage.
Golden 106 -> 108. Les deux scenarios sont une paire : meme heure, meme profil,
seul le ciel change. Sombre avec un bilan qui reclame 85 % -> la session
s engage ; ensoleille avec un bilan a 22 % et un SOC de 30 % SOUS le palier du
matin -> aucun engagement.
Mutations : retour au gate night_hc seul -> le scenario sombre ; critere de la
nuit applique a midi -> le contrefactuel ensoleille. Chacune tombe sur un jeu
different. Hysteresis 24, ACM 20, bilan 50 inchanges.
⚠️ AUCUN PUT. Il en faut desormais DEUX — le bilan et le controleur — et ils
attendent tous les deux sa validation.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Decision du proprietaire, dans ses termes : « contraindre le bilan, un seul
arbitre ». Ce projet a deja paye cher les automates concurrents — charges
programmees de l ESS, consigne a 4200 W, plancher SOC du GX — et un bouton qui
ecrirait sa propre cible en aurait cree un quatrieme.
⚠️ LE FORCAGE EST EN AMONT, DANS coverage(), ET NULLE PART AILLEURS. Mesure sur
banc : ecrire directement dans balance_required_soc engage bien la session —
contacteur ferme, takeover ON — mais laisse la consigne reseau a 700 W, donc la
batterie recoit une centaine de watts. C est le defaut du 01/09 a l identique,
et le seul des trois resultats INDIAGNOSTICABLE depuis le tableau de bord : il a
l air de marcher. La raison est que required_soc ENGAGE la session et
grid_energy_needed_kwh la FINANCE. Pose dans coverage(), le plancher fait bouger
les deux ensemble par construction.
Sens unique, comme les cablages de §38, §39 et §40 : le plancher ne peut que
RELEVER l exigence. Un reglage trop bas est sans effet, il ne desarme rien.
DEUX NOMBRES ET PAS UN, et c est architectural. `..._target` est le reglage du
proprietaire ; `..._floor` est sa valeur EFFECTIVE, mise a zero hors des fenetres
d heures creuses par une automatisation Home Assistant, et c est elle que le
bilan lit. Le bilan repond a « de combien la batterie a besoin », pas a « quand
est-ce bon marche » : il ne contient aucune notion d heure creuse (zero
occurrence de hc_night ou hc_midday dans tout src/energy-balance/) et doit le
rester. Home Assistant detient le calendrier tarifaire, le bilan detient
l energie.
Sans ce filtrage le plancher fuit dans la journee et mord sur
BATTERY_CLOUD_LOCKS — eveningSocStartFloorPct = max(eveningSocStartMin,
balanceRequiredSocPct) — au point de bloquer le demarrage de la charge du
vehicule le soir. Ce n est pas theorique, c est une ligne qui s applique tous les
soirs.
Le bouton se desarme a la sortie de la fenetre ou il a servi : une demande de
charge est un geste ponctuel, pas un reglage permanent oublie.
⚠️ EFFET STRUCTUREL CONSIGNE, qu aucune echeance ne corrige : coverage() est
appelee pour le profil typique ET le profil prudent, donc le plancher releve
aussi required_soc_prudent, qui est le plancher de P12. Pendant une charge
manuelle, la voiture cesse de descendre la batterie. Coherent, mais une nuit ou
l on veut les deux on n aura que l un.
Bilan 48 -> 50. Mutations : plancher ignore -> le scenario qui le releve ;
plancher qui remplace au lieu de relever -> le contrefactuel a 25 %. Chacune
tombe sur un jeu different. gridEnergyNeededKwh ajoute au resume de test : il
manquait alors qu il est desormais consomme en aval par la consigne reseau.
Gabarit du bilan rendu contre Home Assistant : 42 champs, JSON valide, helper
absent lu « unknown » donc plancher nul — le repli est sur avant meme que les
helpers existent.
⚠️ AUCUN PUT VERS n8n. Le workflow du bilan tourne toujours sans ce changement.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire ferme la question de force_grid_now — « pour moi c est pour
recharger la voiture » — et en tire le chantier : dissocier la recharge de la
batterie solaire de la fonction EVCS.
Trois pistes mesurees sur banc. La piste d un chemin separe est morte et de la
maniere la plus nette : elle ne se fait pas ecraser par accident, elle
s auto-detruit, puisqu il faudrait que le controleur la connaisse pour qu elle
tienne. La piste du forcage de la cible du bilan est retenue, mais l ENDROIT du
forcage decide de tout : force en aval, le contacteur se ferme, la session
s engage et la consigne reste a 700 W — le defaut du 01/09 a l identique, et le
seul des trois resultats indiagnosticable depuis le tableau de bord parce qu il
A L AIR de marcher.
Point d insertion identifie a une ligne pres dans coverage() : tout en derive,
donc la cible et le manque bougent ensemble par construction au lieu de
dependre d une discipline.
Trois effets consignes, dont deux qui demandent une decision : le plancher monte
aussi la cible prudente, donc la voiture cesse de descendre la batterie pendant
une charge manuelle — structurel, aucune echeance n y change rien ; et le bilan
ignore totalement les fenetres creuses, donc une cible manuelle fuit dans la
journee et bloque la charge du soir. Echeance retenue plutot que bornes : le
bilan repond a « de combien la batterie a besoin », pas a « quand est-ce bon
marche ».
Fait au passage : le courant du module entre dans le releve par cellule, ce qui
rend enfin lisible « le detail de chaque cellule PENDANT la charge ».
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire veut « dans Grafana le detail de chaque cellule pendant la
charge ». Le detail existait deja ; ce qui manquait etait le « pendant la
charge » — rien ne disait QUAND le module chargeait, et un ecart entre cellules
ne veut rien dire hors de son courant : le 05/09 la cellule meneuse etait a
3555 mV sous 50 A et a 3496 mV sous 30 A, meme module, meme tension de parc.
Le releve console porte le courant depuis le 17/09, mais l ingestion ecrivait
`null` : elle ne lisait que les quinze tensions. Elle repere maintenant la
colonne `courant_mA` PAR SON NOM — les US5000 et les US2000C n emettent pas les
memes colonnes, et une position ferait lire la mauvaise grandeur des qu on
deplace le cable d un pack a l autre. Absente des anciens fichiers, donc les
lignes deja versees gardent leur courant inconnu.
Deux panneaux au tableau « Les batteries ».
« Sante des modules — tous, d un coup d oeil » : le resume qu on lit en premier,
tous modules ensemble, la ou les autres panneaux demandent de choisir un module
d avance. Ecart maintenant, ecart maximum sur la periode, cellule la plus haute
et la plus basse, courant au moment du releve, date du dernier releve. Releve au
deploiement : cinq modules vivants, ecarts de 1 a 3 mV — le parc restant est
sain, les trois modules atteints sont sortis le 12/09.
« Le module chargeait-il ? » : le courant du MODULE, lu dans la table des
cellules et non dans celle du parc, ce qui permet de voir qu un module se
charge moins que ses voisins.
Verifie contre la base et pas seulement execute : 75/75 requetes valides ne
prouve que l execution, donc les deux nouvelles ont ete rejouees avec la vraie
fenetre et rendent bien les grandeurs voulues.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Ecrit par la session voisine docker22-b2, verifie et commite ici : `git` echoue
chez elle sur ce depot (dubious ownership) et elle ne touche pas a
`safe.directory` sans consigne du proprietaire. Laisser ce travail non suivi
dans un arbre partage en NFS, c est l etat qui se fait ecraser au premier
`n8n-extract`.
Quand la garde du bilan tombait — statut degrade, mesure perimee, champ
illisible — la consigne revenait a `maison + plafond de borne`, y compris sans
voiture. Le defaut d origine survivait donc exactement la ou le systeme est
deja degrade. Mesure sur le chemin concerne (midi, fenetre HC autorisee, aucun
vehicule, bilan indisponible) : 5725 W autorises pour une maison a 900 W.
Deux changements, aucune variable ajoutee. La branche de repli du plafond
emploie `evcsSetpointShareW` au lieu du plafond brut ; et `gridSetpointLoadW`
n a plus qu une branche, la distinction n ayant de sens que tant que le repli
gardait l emprunt. L invariant du 01/09 et du 04/09 reste tenu PAR LA FORME :
le plafond vaut maison plus un terme positif ou nul.
⚠️ Le commentaire conserve la trace d un disjoint
`nightGridSessionCommitted || forceGridRequested` sur la part voiture, ecrit
puis MESURE puis retire : il ecrase le terme batterie du bilan, puisque
max(4825 emprunte, 1538 mesure) retient l emprunt. Cout mesure, trois attendus
figes d un coup — 2380 -> 5437, 2380 -> 5437, 4219 -> 6301. Il avait un sens
tant que la consigne n avait aucun terme batterie ; depuis qu elle en a un, ce
n est plus une protection mais un court-circuit. Sans cette trace quelqu un le
reintroduira en croyant combler un trou, comme le plafond de borne lui-meme,
qui etait une bonne idee le jour ou il a ete ecrit.
Golden 105 -> 106. Mutation verifiee ici : plafond de borne remis dans le repli
-> 1 seul echec sur 106, le nouveau scenario, 1130 attendu contre 5725 obtenu.
Il est donc le seul a couvrir ce chemin. Les autres suites intactes
(hysteresis 24, ACM 20, advisor, bilan 48).
⚠️ AUCUN PUT VERS n8n. La production tourne toujours la version poussee a
00:24, sans ce correctif. Le PUT attend la validation du proprietaire.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
J avais declare le quatrieme mutant incouvrable : remettre le terme batterie
dans le plancher nuage ne faisait echouer aucun test, et je pensais qu aucun
scenario ne pouvait le distinguer, parce qu il faudrait faire coexister une
descente de credit solaire (donc du soleil) avec un manque batterie en fenetre
creuse (donc la nuit).
L erreur etait dans le « donc la nuit ». Il y a DEUX fenetres creuses, et celle
de midi (12:24-14:24) admet simultanement le soleil fort, les chargeurs brides
et le manque batterie. Rien ne s exclut.
Et le vrai discriminant n est pas l heure, c est un DVCC HAUT. A 30 A le terme
batterie plafonne sous le budget de surtension et les deux variantes rendent la
meme chose ; a 180 A — le profil de boost de journee de l ACM — il vaut 6639 W
et le plancher pollue bloque la descente.
Scenario ajoute, forme reelle de l episode du 17/09 (force_grid pose a midi,
soleil, aucune voiture) avec en plus un manque batterie :
formule correcte : 4219 W
mutant M4 : 7309 W
3090 W d ecart. Avec le terme batterie dans le plancher, la consigne reste trop
haute et evince le solaire : c est le defaut du 11/09 reintroduit par la porte
de derriere. Le scenario ne teste donc pas une bizarrerie de forme, il protege
contre le retour d un incident connu.
Les deux valeurs ont ete obtenues independamment sur deux implementations
distinctes et concordent au watt.
Golden 104 -> 105.
⚠️ RIEN N EST POUSSE VERS n8n.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Elle empruntait le plafond de la borne — `maison + physicalCapA x V` — qui n a
aucune relation physique avec ce dont la batterie a besoin. Qu il tombe juste
etait un accident : le 17/09 a 13:51, voiture partie depuis cinq minutes,
consigne a 7032 W pour une maison a 933 W.
Elle additionne desormais des besoins NOMMES : la maison toujours, la voiture
seulement si un vehicule est branche, la batterie seulement dans une fenetre
d heures creuses — recharger la batterie sur le reseau n a de sens economique
que la. Hors fenetre le terme vaut zero, donc la division par un temps qui tend
vers zero disparait par construction et non par garde.
MAX ET NON ADDITION. La consigne est une AUTORISATION, pas une prediction : le
fichier le dit deja — « la consigne dit ce que le reseau a le DROIT de servir,
DVCC dit ce que la batterie a le droit de prendre ». Additionner deux
autorisations independantes n est pas plus honnete, seulement plus permissif.
Mesure : avec l addition, `consigne-session-engagee-couvre-la-maison` passe de
5595 a 6341 W — une autorisation en plus sur le chemin dominant (85 nuits sur
88 ont un vehicule) pour corriger un chemin emprunte zero fois en treize jours.
LE TERME BATTERIE EST BORNE PAR DVCC, PAS PAR LE BMS NI PAR LE TEMPS. Le BMS
declare 250 A, soit 12,2 kW : au-dessus de GRID_SETPOINT_MAX_W, il ne bornerait
rien. Et un plancher d horizon ne borne que le diviseur : en fin de fenetre
(14 min, manque 5,672 kWh) la division rend 17 kW, ecretes a 10 000, soit PIRE
que les 5437 empruntes qu on remplace. Avec DVCC le terme vaut 1538 W et la
consigne 2380 W. Corollaire : le plancher d horizon devient sans objet, il ne
reste qu une garde d une minute contre la division par zero.
Le manque vient de `evcs_balance_grid_energy_needed_kwh` et non de
`energy_to_cover_kwh` : la premiere est le MANQUE, nulle des que la batterie
couvre et convertie par la courbe mesuree par morceaux ; la seconde est
l energie que la batterie devra FOURNIR et ne tombe jamais a zero tant qu il
reste de la nuit — 11,96 kWh annonces le 17/09 a 20:00 avec un SOC de 91 %.
Le plancher nuage suit la voiture et PAS la batterie : il couvre l exposition
creee par le courant du vehicule ; une recharge batterie qui ralentit quand le
solaire s effondre ne coupe personne.
INVARIANT TENU PAR LA FORME : `maison + max(...)` ne peut jamais descendre sous
la maison, quel que soit DVCC. La regle du 01/09 et du 04/09 est donc garantie
par construction. Toute lecture manquante retombe sur la formule d avant.
Golden 102 -> 104. `nuit-sans-vehicule-session-engage` passe de 5437 a 2380 et
recoit le manque explicitement, sans quoi il heritait du zero de la fixture et
decrivait un etat impossible (SOC 20 pour un requis de 59,1 avec batterie
couverte). Deux scenarios ajoutes : la fin de fenetre bornee par DVCC — celui
qui protege contre la regression de 10 kW — et le contrefactuel a vehicule
branche qui epingle le choix du max.
Mutations : plafond DVCC retire -> 2 echecs dont la fin de fenetre ; max
remplace par une addition -> le contrefactuel seul ; bilan ignore -> les deux
scenarios pilotes par le bilan. Les autres suites sont intactes
(hysteresis 24, ACM 20, advisor, bilan 48).
⚠️ RIEN N EST POUSSE VERS n8n : la regle du depot impose la validation du
proprietaire avant tout PUT.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le mecanisme demande par le proprietaire — « ca va pas corriger le probleme si
nous ne sommes pas devant » — est deploye et a fonctionne seul a 14:24 :
strategie rendue a auto_solar_plus, consigne ramenee de 5641 a 700 W au cycle
suivant, contacteur ouvert par l hysteresis 33 s plus tard. La demande retombe
avant que le reseau parte, sans coordination.
Ce qui manquait a force_grid_now n etait pas une interdiction mais une
echeance : la condition porte sur l instant d ENGAGEMENT, pour qu un forcage
pose un soir de cuisson afin de proteger le parc ne soit pas annule a la minute
suivante.
Et la section consigne ce que la session voisine m a fait corriger sur la
surconsigne « voiture fantome ». Trois de mes chiffres etaient faux, tous
defavorables a la correction que je defendais : l episode de midi n etait pas
un defaut (heures creuses, demande, aucune eviction — sept chargeurs en
mppt_active) ; l occurrence de six minutes du 06/09 n existe pas (source_mode
valait Solaire de bout en bout, j avais verifie les ingredients sans demander
au controleur sa decision) ; et l import de 5,87 kWh se repartit en 2,52 pour
la voiture encore branchee, 2,43 pour la batterie et 0,92 pour la maison.
La mesure sur treize jours est conservee parce qu elle sera redemandee : 88
decisions « Reseau HC autorise », toutes avec vehicule, toutes entre 1 h et
6 h, zero a midi, et session_engagee faux 85 fois sur 88 — donc
nightGridSessionCommitted ne couvre pas les nuits ordinaires.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Carte conditionnelle qui n apparait QUE lorsque force_grid_now est actif, et
qui dit depuis combien de temps et quand ca s arrete — ou, en rouge, que
l expiration est desactivee. Un contournement manuel qui n affiche pas son
echeance se lit comme un etat permanent, et c est ce qui a laisse tourner une
charge reseau au plein tarif.
Les trois reglages (interrupteur, duree maximale, derniere expiration)
rejoignent la carte « Parametres utilisateur », sous la strategie qu ils
bornent.
Verifie en reel : 14:24:06 la strategie repasse en auto_solar_plus, 14:24:30 le
controleur passe en source Solaire et ramene la consigne reseau de 5641 a
700 W, 14:25:03 l hysteresis ouvre le contacteur. La demande baisse AVANT que
le reseau parte — la sequence d ouverture de la §30, obtenue par construction.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Constate le 17/09 : force_grid_now pose a la main a 12:58 pendant les heures
creuses de midi a ferme le contacteur et lance une charge batterie a 7,7 kW,
et RIEN dans le systeme ne l arrete. WINDOWS_SOURCEV2 evalue
`else if (forceGridRequested) sourceMode='grid_forced'` avant tout test de
profil ; l hysteresis maintient l override tant que le motif « pas de
demande » est absent, et `vehicle_not_connected` n en fait pas partie, si
bien que le depart du vehicule ne libere rien. A 14:24 la fenetre economique
se ferme et l import continue au plein tarif jusqu a ce qu un humain soit
devant l ecran.
Le manque n est pas une interdiction, c est une ECHEANCE — le proprietaire
ferme deliberement le contacteur, soit pour charger en heures creuses, soit
pour proteger le parc pendant une pointe de consommation. Deux sorties :
1. sortie de la fenetre d heures creuses DANS LAQUELLE il a ete engage. La
condition porte sur l instant d engagement et pas seulement sur l heure
courante, sinon un force_grid_now pose un soir de cuisson pour proteger le
parc serait annule a la minute suivante ;
2. plafond de duree (180 min par defaut), filet pour le cas engage hors
fenetre et oublie.
Les bornes des fenetres sont LUES dans les helpers victron_evcs_hc_*, jamais
recopiees : elles ont deja change une fois (01:30 -> 01:24 le 09/07) et une
copie divergerait en silence.
Huit cas rejoues contre le moteur de gabarits de Home Assistant, 8/8, dont les
trois qui comptent : la sortie de fenetre expire, la protection du parc a
20:30 ne s annule NI a 20:35 NI a 22:00, et le plafond de duree la reprend a
23:45. Le mecanisme fait donc bien la difference entre une echeance et une
interdiction.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Suite du correctif de l onglet Home Assistant. « La journee » avait le meme
angle mort : cadre sur le jour civil, il s arretait a l heure en cours.
Fenetre portee a la journee ENTIERE (dashboard() gagne un parametre `jusqu`),
serie « Encore attendu » en gris translucide a la suite des barres mesurees,
et colonne « Reste attendu » dans le bandeau du haut, a cote de « Solaire
produit ».
Sur le telephone, aucun panneau ajoute — un panneau de plus y est un ecran de
plus a faire defiler. « Soleil restant » rejoint le bandeau Maintenant, a cote
de Excedent ; « Soleil demain » rejoint La nuit qui vient, puisque c est lui
qui decide jusqu ou la batterie peut descendre.
Trois pieges, tous dans la meme direction. La mesure ne doit pas suivre la
fenetre dans le futur : ENERGIE_SQL construisait son axe entre les deux macros
puis reportait la derniere valeur connue, ce qui aurait rempli les heures a
venir avec la puissance de l instant et gonfle l energie du jour — sa borne
haute est desormais least($__timeTo(), now()). FULL OUTER JOIN et non LEFT :
une periode a venir n a aucune ligne de mesure. Et borne haute stricte, sans
quoi une barre « 18/09 00 h » apparaissait dans La journee.
L heure EN COURS n a volontairement pas de barre de prevision : elle est deja
mesuree pour ses minutes ecoulees.
73/73 requetes valides — mais ce controle prouve l execution, pas la grandeur.
Les deux requetes de La journee ont donc ete rejouees a la main avec la vraie
fenetre : 24 lignes, mesures jusqu a 02 h, prevision de 03 h a 23 h, somme des
barres 36,95 kWh contre 37,0 annonces par le bandeau. C est ce recoupement qui
a fait apparaitre le troisieme piege.
Corrige au passage la note du 08/09 sur l acces a l API Grafana : les
apostrophes du .env sont SIMPLES et non doubles, verifie a l octet.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit du 16 au 17/09 : neuf arrets de la charge nuit de la VW, de 30 s a 3 min,
sans que le controleur EVCS ait bouge — sa table de decision ne porte que deux
lignes sur toute la periode. Le journal de bord de Home Assistant montre le
switch de charge passant a off SANS contexte de service, donc commande depuis
le GX, puis le controleur qui reessaie au cycle suivant.
Correlation un pour un avec les actions du chien de garde, trois secondes
avant chacune, et aucune coupure sans action. Son message porte la signature :
« CONTROLEUR MUET — derniere execution il y a NaNs ».
Cause : n8n inscrit une execution AVANT de la demarrer, avec status "new" et
startedAt null. Date.parse(null) vaut NaN, et le test !(ageSec <= 600) — forme
choisie pour echouer du cote sur — declare alors mort le controleur qui vient
precisement de demarrer un cycle. Le signal de vie retourne contre lui-meme.
La fenetre dure moins d une seconde : 3 sondages sur 968 y tombent, 0,3 %. Ce
qui a change le 16/09 n est pas le code mais la PHASE du chien de garde, qui
derive d environ vingt secondes par jour et est venue se poser exactement sur
les instants de declenchement du controleur (:00 et :30) — 34 evenements ce
jour-la contre 1 a 2 les jours precedents. Le defaut dormait depuis le 01/09.
Correction a la session precedente : la nuit du 15 au 16, presentee comme
irreprochable, portait deja trois coupures dont une de trois minutes. Ce que
j avais verifie — consigne a 6 A inchangee pendant 153 min — restait exact et
ne prouvait rien : la consigne ne bouge pas quand la borne s arrete, seule la
puissance tombe.
Second defaut, latent et plus grave : CFG.idleSetpointW valait 50 W quand le
controleur est passe a 700 W le 06/09, donc dangerousSetpoint etait vrai en
permanence et chaque fausse alerte ecrasait aussi la consigne reseau a 50 W.
Sans consequence cette nuit — EDF etait ouvert — mais pendant une nuit ou le
reseau porte la maison, c est le defaut du 04/09 reintroduit.
Trois correctifs : un horodatage manquant n est plus une panne (on prend le
plus recent startedAt exploitable, repli cote sur si aucun) ; valeur de repos
portee a 700 W avec le commentaire qui dit ou vit l autre exemplaire ; et une
panne doit DURER — deux lectures consecutives avant d agir, meme doctrine que
la tolerance batterie et le relachement du contacteur.
Verification par REJEU et non par absence de symptome : le redemarrage a remis
la phase a :07, donc une nuit calme ne prouverait rien. Un serveur local
rejouant la charge JSON exacte capturee a 02:07:01 donne, code d avant,
« MUET — il y a NaNs » et les deux ecritures ; code corrige, « controleur
vivant (execution il y a 36s) » et aucune ecriture. Le filet mord toujours sur
une panne soutenue : 1/2 puis alerte et StartStop = 0 au second cycle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le graphe « production prevue et realisee heure par heure » du troisieme
onglet du bilan energetique ne montrait que du passe : sa courbe « prevue »
etait la prevision publiee le matin de chaque jour ECOULE, et la fenetre
s arretait a l heure en cours. C est un instrument de mesure du biais, pas
une prevision.
Deux courbes desormais, et elles n ont ni la meme provenance ni le meme
usage. Pour un jour ecoule, ce qui avait ete annonce LE MATIN MEME reste la
seule reference honnete : une prevision revisee a 18 h connait deja la
journee, la comparer au reel ne mesure plus rien. Pour les heures a venir,
c est la DERNIERE publication qui fait foi — aujourd hui jusqu au soir,
demain en entier. Les deux se touchent sur l heure en cours au lieu de
laisser un trou, et la seconde est tracee en pointilles.
Au-dela de l heure en cours, « reel » et « bridage » valent NULL et non
zero : un zero dessinerait une chute de production qui n a pas eu lieu.
Defaut trouve en chemin : l ecart moyen comptait l heure EN COURS, mesuree
sur ses seules minutes ecoulees. A 14h05 son reel vaut cinq minutes de
production contre une prevision d heure pleine, soit -92 % qui n existent
pas. La colonne `clos` l exclut. Et la serie mesuree s arrete desormais a
la minute courante et non au debut de l heure, si bien que l heure en cours
est reellement tracee au lieu de valoir zero.
Le partage aujourd hui / demain se fait en SQL, dans le fuseau deja utilise
par le reste de la requete : le conteneur repond en UTC a `date`, il ne
doit pas servir d arbitre.
Fenetre de la carte portee a hier / aujourd hui / demain (graph_span 3d,
span end day offset +1d) : sans cela la prevision, qui est justement ce
qu on veut voir, tombe hors du cadre. Verifie dans le paquet installe :
`span.offset` exige bien un signe, et l offset decale les deux bornes.
Verification en production : 47 points de prevision publies, du 17/09 01 h
au 18/09 23 h, 33,3 kWh encore attendus aujourd hui et 34,5 annonces pour
demain.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
La colonne courant_mA etait vide depuis la mise en service : le mode --modules
interroge chaque adresse avec soh <n>, qui donne les quinze tensions mais AUCUN
courant. La source juste est pwr, qui rend courant, tension et SOC pour TOUS les
modules en un seul appel — une commande serie par cycle au lieu d'une par
module.
⚠️ LE TABLEAU pwr N'A PAS LES MEMES COLONNES SELON LA FAMILLE DE MODULES.
Mesure du 16/09 : les US5000 (firmware B69.26) intercalent Tlow.Id, Thigh.Id,
Vlow.Id et Vhigh.Id que les US2000C (B69.13) n'ont pas. Un parseur a index figes
lit donc n'importe quoi des qu'on change de pack — c'est la meme famille de
piege que le trou de 44 h. Les colonnes sont resolues PAR LEUR NOM dans
l'en-tete. Les trois utiles (Volt, Curr, Coulomb) precedent Time, dont la valeur
contient une espace, donc le decoupage positionnel reste valable.
Echec de pwr non bloquant : on ecrit la ligne sans courant plutot que de perdre
les tensions, qui sont l'essentiel du releve.
Verifie sur cinq modules, trois cycles : courant et SOC par module dans le
journal et dans le CSV. Pack 2 a 13:18 — 9,5 + 9,4 + 9,0 + 9,2 + 9,1 = 46,2 A,
SOC 82/79/83/81/87 %.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
MODULES=1,2,3,4,5. Le cinquieme etait vivant et ignore depuis la mise en service
du releve : constate le 16/09, la chaine enumerait un module 5 a 50,7 V / 14,6 A
/ 80 % que personne ne lisait. Son code-barres est K220803C30160323 — le seul
module sain de l'ANCIEN parc (zero cellule marquee, zero compteur, cf. §51), que
le proprietaire a garde. Ecart de cellules 6 mV contre 2 a 4 pour les quatre
Y230202C de 2023 : acceptable.
⚠️ Il faut relancer le SUPERVISEUR et pas seulement son fils : lancer.sh lit
MODULES a son demarrage, donc tuer le processus node laisse le superviseur
relancer avec l'ancienne liste.
⚠️ TROU DE 44 H dans la table cellule, du 14/09 17:01 au 16/09 13:02, explique :
le cable console etait sur le PACK 1 pendant cette periode, et les US5000
n'emettent pas le meme tableau console que les US2000C — colonnes Tlow.Id,
Thigh.Id, Vlow.Id, Vhigh.Id presentes chez les uns, absentes chez les autres.
Le parseur du releve ne sait lire que le format US2000C : sur le pack 1 il
journalise « module N : illisible » et n'ecrit rien. Rien d'autre ne le signale.
A traiter si le releve doit un jour couvrir le pack 1.
⚠️ Et mes propres commandes console s'entrelacent avec le releveur sur le meme
port serie : la garde anti-doublon de lancer.sh ne filtre que son propre motif.
Les « illisible » de 12:42 et 12:52 sont de mon fait. Arreter le releveur avant
toute lecture manuelle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Nuit : zero bascule du contacteur, 0,00 kWh de reseau contre 14,04 la nuit
precedente, charge terminee d'elle-meme a 6,90 kWh, reserve 7,7 kWh. Le plancher
P12 n'a jamais ete touche — il est DYNAMIQUE et descend plus vite que le SOC, ce
que j'avais mal anticipe en l'annoncant fixe a 47,1 %.
Trouvaille principale : 26 entites BMS sur 32 figees depuis 31 h, alarmes
comprises, sans que rien ne le signale. Le rechargement de l'integration
rafraichit les horodatages mais pas les valeurs. Preuve par la console serie :
41 mV de divergence a 12:30. Le battement de coeur ne couvre PAS ce cas — une
entite qui republie la meme valeur reste indetectable.
Correction d'une affirmation de la journee : mon « arithmetiquement impossible »
comparait une tension de bus a des tensions de cellule sans verifier le point de
mesure. Raisonnement faux, conclusion juste, demontree autrement.
Les deux packs debitent (99,3 A et 80,7 A pour 180 A au Cerbo) ; pack 1
irreprochable a 3 mV d'ecart entre cellules. A instruire : le pack 2, plus petit
et plus vieux, prend 2,5 fois plus de courant par ampere-heure.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Valide separement par le proprietaire le 16/09, comme la session OpenClaw et moi
l'avions demande : c'est la premiere fois qu'une reponse WhatsApp touche au
PILOTAGE et non a une etiquette consultative.
⚠️ LA LISTE BLANCHE EST DANS LE SERVICE, JAMAIS CHEZ L'AGENT — moindre
privilege : il demande, il ne decide pas de ce qui est demandable. Six ordres
admis : p12, p9, hc_nuit, strategie, vehicule, plafond_edf (borne 6-28).
Les options d'un input_select sont lues EN DIRECT sur l'entite, jamais codees en
dur : ZERO sera consomme sans modification quand la moto reviendra.
⚠️ HORS LISTE DEFINITIVEMENT : le contacteur EDF, les limites DVCC, la consigne
de puissance reseau, les planchers SOC de securite — exactement ceux qui peuvent
vider la batterie sous son plancher, la gaver sur le reseau, ou evincer le
solaire une journee entiere.
Garde supplementaire : un ordre de pilotage exige un canal HUMAIN. Une regle qui
deduit « il faudrait activer P12 » n'a rien a faire ici — c'est une decision,
pas une observation.
Interrupteur DISTINCT de celui du concierge (input_boolean.airtria_ordres_enabled,
a OFF), pour que couper le pilotage ne coupe pas l'etiquetage des vehicules.
Il gate l'ECRITURE, pas la lecture : a OFF le service journalise ce qu'il aurait
fait, ce qui permet d'eprouver la chaine avant qu'elle ne compte.
NEUF ESSAIS, tous verifies. Refuses : ordre edf, dvcc, consigne_reseau,
soc_stop_min (hors liste) · source regle-puissance (canal non humain) ·
plafond 45 A (hors bornes) · strategie « turbo » et vehicule « MEGANE » (absents
des options, listees en direct). Applique : plafond_edf 28 -> 20, journalise avec
l'etat anterieur ; rejeu du MEME confirmed_at -> ordre=0, rien ; nouveau
confirmed_at -> restauration a 28. P12 intact tout du long.
⚠️ DEFAUT TROUVE EN EPROUVANT CECI : le mode --once n'appelait pas
assurerConnexion(). Une base absente au demarrage lui donnait client = null,
donc un TypeError au lieu d'un message clair. Trouve sur un simple mauvais
numero de port. Corrige.
Carte « Agents & surveillance » completee : le guichet et son dernier ordre, a
cote du concierge et de l'etat du service.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Question du proprietaire : « il est ou cet interrupteur, dans quel dashboard ».
Reponse : celui du guichet d ordres n existe pas encore (annonce comme une
intention, pas construit). Mais la question en revele un vrai trou —
input_boolean.airtria_concierge_enabled existe depuis le 13/09 et n etait
affiche sur AUCUN tableau de bord. Il fallait passer par les outils de
developpement pour l atteindre. Un interrupteur d urgence hors de portee n en
est pas un.
La carte groupe desormais ce qui tourne tout seul et de quoi le couper :
le kill-switch du concierge, la derniere reponse WhatsApp recue, le selecteur
de vehicule qu elle pilote, et l etat du service d historisation (battement de
coeur, age, cause du dernier echec).
Le toggle du guichet d ordres viendra s y ajouter quand il sera construit.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
binary_sensor.historisation_evcs_muette + sensor de l age du battement.
Bascule a 'on' dans les deux cas : statut degrade (le service vit mais ses
cycles echouent, la base typiquement) et battement plus vieux que 5 minutes
(le service ne publie plus du tout). Cinq minutes = cinq cycles manques.
Verifie en simulant les deux pannes sur le capteur source : degrade+frais -> on,
ok+vieux de 10 min -> on avec age=10, puis retour a off en 18 s des que le
service de production a repris la main. Un detecteur qu on n a pas vu detecter
n est pas un detecteur.
⚠️ Toute automatisation qui alerte sur ce drapeau doit porter for: 00:05:00 :
le capteur source est cree par l API, il n existe donc pas pendant une minute au
plus apres un redemarrage de Home Assistant, et le drapeau passerait a on
brievement a chaque fois.
Le paquet porte aussi la raison pour laquelle un capteur DEDIE est necessaire
la ou la fraicheur d une entite metier ne dit rien : last_reported == last_changed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Valide par le proprietaire le 16/09. Le service publie desormais
sensor.evcs_historisation_heartbeat a chaque cycle : etat = horodatage ISO 8601
UTC, attributs statut (ok|degrade), base_joignable, cycles_en_echec,
dernier_echec. Forme figee avec la session OpenClaw pour que les deux battements
du systeme soient identiques.
POURQUOI UN CAPTEUR DEDIE. Mesure du 16/09 : Home Assistant ne materialise pas
une ecriture identique, et last_reported — le champ introduit en 2024 pour
marquer chaque remontee d'etat — est rigoureusement EGAL a last_changed. Aucun
champ de l'API ne distingue donc un ecrivain mort d'un ecrivain qui republie la
meme valeur. Sur une installation saine, trois entites sur cinq paraissaient
figees. La vivacite se lit donc sur ce capteur seul, dont l'etat est un
horodatage : il change forcement a chaque ecriture.
L'appel est HORS du try/catch du cycle, dans les deux branches. C'est tout le
correctif : base morte, le battement part quand meme en portant degrade et la
cause. Avant, un cycle en echec n'ecrivait que sur console.error, et l'incident
n'etait journalise qu'au RETOUR a la normale — dans PostgreSQL, donc jamais
quand c'est PostgreSQL qui est tombe.
⚠️ CE QUE LE TEST A TROUVE, ET QUI RENDAIT LE BATTEMENT INUTILE. Eprouve sur une
base JETABLE derriere un relais TCP coupable a volonte (pas sur la production :
deux instances sur la meme base double-compteraient l'energie des sessions, le
UPDATE energie_kwh = energie_kwh + ... n'est pas idempotent). Premier essai : le
service a CRASHE a la coupure. Le client pg emet un evenement 'error' sur le
socket ; sans ecouteur, c'est une exception non capturee qui ne passe PAS par le
try/catch du cycle — il n'attend qu'une promesse — et qui tue le processus. Le
service mourait donc exactement dans la panne que le battement existe pour
signaler.
Trois correctifs qui en decoulent : un ecouteur 'error' qui marque la connexion
morte au lieu de faire tomber le processus ; une reconnexion, un client pg
n'etant pas reutilisable apres erreur (sans elle le service resterait vivant mais
definitivement muet) ; et une connexion initiale non fatale, pour qu'une base
absente au demarrage ne tue pas le service — un service mort ne signale rien.
Sequence complete verifiee : base vivante -> ok ; coupure -> service VIVANT,
degrade, base_joignable false, cycles_en_echec 2, cause « connect ECONNREFUSED » ;
retour -> reconnexion automatique, ok, et l'episode journalise avec sa duree.
Le message de reprise disait « Home Assistant injoignable » quelle que soit la
cause ; il nomme desormais ce qui a reellement echoue.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
En outillant la session OpenClaw, recherche du champ qui distinguerait « pas
ecrit » de « ecrit a l identique ». Home Assistant expose last_reported depuis
2024, cense marquer chaque remontee d etat meme sans changement de valeur. Il ne
sert a rien ici : mesure sur cinq entites, il est rigoureusement EGAL a
last_changed, alors que le controleur reecrit source_mode et night_target_soc a
chaque cycle de 30 s.
Consequence generale : aucun champ de l API ne distingue un ecrivain mort d un
ecrivain qui republie la meme valeur. L anciennete d une entite metier n est
donc jamais une preuve de panne. Releve sur une installation saine :
vehicle_connected inchange depuis 752 min, night_target_soc 194, source_mode
139 — trois faux positifs sur cinq entites.
Regle adoptee avec OpenClaw : la vivacite se lit sur un battement de coeur dedie
dont l etat est un horodatage, seule entite dont l immobilite soit
interpretable. Les entites metier se lisent pour leur VALEUR, jamais pour leur
fraicheur. « inchange depuis X » est un fait, « fige » est un verdict.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
L'enquete sur une reponse fausse du concierge (« 12,1 kWh absorbes cette nuit »,
alors que la voiture en avait pris 3,18) l'a etabli par recoupement :
gx_device_pv_energy valait 29,136 quand la production mesuree de la veille etait
29,13 kWh. Ce sont des compteurs JOURNALIERS ; les sauts negatifs de plusieurs
centaines de kWh sont leur remise a zero vue comme un delta. Ma note du 04/09
les disait « corrompus », c'etait faux — la conclusion pratique, elle, tient.
Le piege qui a produit l'erreur est ailleurs : ils se FIGENT. A 01:32,
dc_battery_charge_energy portait encore la valeur de la veille 17:31:50.
Regle generale ajoutee : verifier last_changed avant de citer une valeur comme
actuelle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire a demande la creation du role. Il existait deja, avec exactement
les deux SELECT du contrat (session_charge, evenement) et aucun droit
d'ecriture. Mon affirmation « toujours pas cree », repetee deux fois dans la
nuit dont une dans un message a la session OpenClaw, etait fausse.
Ce qui manquait n'etait pas le role mais son MOT DE PASSE : absent du .env du
projet, de celui de la pile d'historisation, et des variables du conteneur
openclaw-gateway. Un identifiant que personne ne connaissait.
Renouvele, range dans AIRTRIA_RO_PASSWORD (.env du projet, ignore par git), avec
CONNECTION LIMIT 5 pour qu'un agent emballe ne puisse pas epuiser le pool.
Verifie par 14 essais depuis le poste : SELECT autorise sur session_charge et
evenement, refuse sur les sept autres tables, et refuse pour INSERT, UPDATE,
DELETE, CREATE TABLE et la lecture de pg_authid. Acces reseau confirme :
pg_hba porte host all all all scram-sha-256, et 5433 est joignable depuis
10.10.10.17.
⚠️ ET LE RENOUVELLEMENT A CASSE LE CONCIERGE. La session OpenClaw a repondu
quelques minutes apres qu'elle EST codee pour se connecter en airtria_ro et
qu'elle avait lu evenement le soir meme. Ma verification ne regardait que
Config.Env du conteneur, pas son code : j'ai conclu « rien ne l'utilise » d'une
absence de preuve.
LECON : avant de renouveler un identifiant, l'absence de trace la ou JE range
mes secrets ne prouve pas qu'il est inutilise. Le seul test concluant etait de
demander a l'utilisateur presume — ici une session pair joignable en une minute.
Le nouveau mot de passe ne transite pas par un message d'agent a agent : c'est
au proprietaire de le remettre a OpenClaw.
MANUEL : capacite des vehicules, reference mesuree au compteur de la borne.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Corriger le selecteur a la main ne corrige rien : « demain si je dis JEEP il va
rester sur VW, donc la solution c'est de le piloter quand je reponds ».
Le selecteur n'est pas qu'une etiquette. Le CONTROLEUR n8n le lit pour en
deduire l'heure de depart (VW 08:50, JEEP 06:30), donc minutesUntilDeparture,
donc batteryRecoveryUrgent — qui coupe P12 et ferme EDF trente minutes avant le
depart suppose. Mesure de cette nuit : selecteur reste sur JEEP alors que la VW
etait branchee et confirmee par WhatsApp a 19:56 => EDF se serait ferme a 06:00
pour rien, la voiture etant pleine depuis 05:30 et la batterie a 51 %.
Deux correctifs, indissociables.
1. piloterSelecteurVehicule() : une reponse du proprietaire ecrit
input_select.victron_evcs_vehicle. UNE SEULE FOIS par reponse — la fonction
appelante est idempotente par confirmed_at — donc le dernier mot reste a
l'humain quel que soit le canal. Seulement pour les labels qui SONT des
options du selecteur : MEGANE, INVITE et ZERO n'y figurent pas, et l'heure de
depart n'a aucun sens pour un vehicule de passage.
2. ecrireSession() n'ecrase plus une session confirmee. Cette ligne reecrivait
le vehicule depuis le selecteur a CHAQUE CYCLE d'une session ouverte, pendant
que appliquerEtiquettesEnAttente remettait l'etiquette juste apres : deux
ecrivains sur la meme colonne toutes les 60 s, et une ligne de journal a
chaque passe — une soixantaine le 15/09. Le drapeau vehicule_sur dit « un
humain a confirme » : quand il est vrai, le selecteur n'a plus voix au
chapitre.
Preuve du diagnostic, par l'experience : le dernier « Etiquette VW posee » est a
01:40:58, le selecteur passe a VW a 01:41:59, et plus une seule ligne ensuite.
La bagarre s'arrete a la seconde ou les deux ecrivains s'accordent.
Preuve du correctif 2, en lecture seule sur les lignes reelles : sur les deux
sessions VW, l'expression d'avant ecrirait JEEP, la nouvelle garde VW ; sur les
sessions JEEP les deux concordent. Et sur un cas synthetique non confirme, la
nouvelle expression suit bien le selecteur — la garde est ciblee.
DEFAUT TROUVE EN RELISANT LA SORTIE DU PREMIER ESSAI A BLANC : sans garde, un
--dry-run aurait pilote le selecteur pour de vrai. Seule l'egalite fortuite
actuel === label avait evite l'ecriture. Garde posee, puis eprouvee en mettant
le selecteur sur JEEP : la sortie annonce « [blanc] piloterait JEEP -> VW » et
le selecteur est reste JEEP.
MANUEL : capacite des vehicules. La VW annonce 10 kWh de plaque pour 42 km ;
la reference MESUREE au compteur de la borne est 7,70 kWh pour une charge menee
a son terme (15/09 01:25-03:41). C'est ce chiffre qui dimensionne une nuit, pas
la plaque. La JEEP n'est pas mesuree de la meme facon : ne pas lui appliquer
les 7,70 kWh.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire veut comparer prevision et production heure par heure sur une
semaine, dans son tableau de bilan. Les courbes de prevision vivent dans des
input_text ECRASES a chaque publication : HA n en garde aucun historique. La
base, elle, a treize jours de previsions horaires et la production mesuree.
Le service pousse donc la serie dans un capteur cree par l API HA, dont les
attributs portent les tableaux — un input_text plafonne a 255 caracteres ne
tiendrait pas 168 points.
⚠️ Premiere ecriture de ce service vers Home Assistant, qui a toujours ete
lecteur. Perimetre minuscule et delibere : un capteur, son propre espace de
noms, aucun actionneur.
⚠️ Et la troisieme serie n est pas decorative. Une heure BRIDEE n est pas
comparable : production sous la prevision peut vouloir dire mauvaise prevision
OU batterie pleine. Les mesures le montrent — le 13/09 a 15 h, prevu 5,32 et
realise 1,82 avec 100 % de bridage, l ecart n est pas meteorologique ; le 15/09
a 13 h, prevu 3,92 et realise 7,12 sans aucun bridage, la prevision SOUS-estime
de 82 %. Sans la bande, la courbe ferait accuser la meteo a tort.
L etat du capteur porte l ecart moyen sur les seules heures comparables — non
bridees — qui est le seul chiffre qui juge vraiment la prevision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Consigne l idee du proprietaire et le calcul qui la fonde, le verrou
anti-oscillateur trouve en construisant, et surtout la contrainte decouverte a
05:30 en conditions reelles : P12 doit gagner le premier cycle de la nuit. Si la
reprise reseau s engage avant lui, le verrou anti-creneaux de juillet tient le
reseau pour toute la session — et il a raison, c est exactement le creneau qu il
existe pour empecher. Aucun des cinq scenarios initiaux ne le montrait, ils
partent tous d une nuit vierge.
Note aussi qu une mutation qui ne mute rien ne prouve rien : ma premiere
tentative cherchait un motif absent du fichier, zero occurrence, zero echec, et
j allais conclure que le test tenait.
Et corrige deux affirmations que j avais faites avec trop d aplomb : le garde dur
a -30 A (je lisais la table de base, pas les valeurs appliquees) et le bilan qui
sous-estimerait la batterie de 30 % (j avais divise une courbe par morceaux par
un seul ratio).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Idee du proprietaire, apres la nuit du 14 au 15/09 : 8 kWh achetes au reseau, la
batterie encore a 69 % a 5 h du matin, et une prevision de 38,7 kWh le lendemain
dont 10,5 auraient ete ecretes faute de place. Payer du reseau la nuit pour
ecreter le solaire le lendemain, c est perdre deux fois.
Le mode `battery_assist_night` existait pour exactement ca, et etait MORT depuis
toujours : il exige `batteryCurrentA >= plancher de decharge` (0 A), impossible
la nuit puisque la maison tire sur la batterie. On ne cree donc pas un chemin,
on rend viable celui qui existe — en remplacant un test de COURANT impossible
par un test d ENERGIE.
Le plancher n est PAS une constante nouvelle : c est `required_soc_prudent`, que
le bilan publie deja en profil p80. La voiture descend la batterie jusqu au
niveau qui lui permet encore de tenir jusqu au croisement PV, et pas plus bas.
La bascule vers le reseau est automatique quand le surplus est epuise — la
soupape decrite par le proprietaire, sans aucune regle horaire.
⚠️ Verrou anti-oscillateur, et il n est pas decoratif. Le plancher descend
pendant la nuit et le SOC aussi : voiture en charge le SOC perd 7,1 pt/h contre
3,7 pour le plancher, mais voiture ARRETEE il n en perd que 2,6. Le surplus
reapparaitrait tout seul et la charge repartirait. Une seule passe par session
de nuit, comme la recovery batterie depuis le 27/08.
Les gardes de courant restent : commonSafety, l arret dur, et la garde souple
avec sa tolerance temporelle — c est elle qui arretera la charge quand la bande
de SOC deviendra trop basse pour le courant tire. Ce qu on retire est uniquement
le plancher de PROFIL, qui interdisait de demarrer des que la batterie n etait
pas a l equilibre.
Cinq scenarios, six mutations qui mordent chacune sur un jeu different. Deux
d entre elles ont trouve de vraies faiblesses : les attendus ne verifiaient que
le choix du mode et pas que la voiture charge, et la garde de fraicheur du bilan
n etait couverte par aucun scenario.
Rien n est deploye et le toggle est a off.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le proprietaire demande d assouplir la garde de decharge souple en bande 40-60,
de -12 a -15 A de base — 39 a 49 A appliques sur treize modules, soit 3,5 A par
equivalent US2000 et 19 % de ce que le BMS autorise. Son argument : en ete, avec
52 panneaux et une production bridee des midi, garder le parc plein n a aucun
sens, et cette nuit a coute 8 kWh de reseau en touchant a peine la batterie.
Le reglage aurait ete perdu. Les cinquante helpers de la table de politique
batterie portaient un `initial:`, qui DESACTIVE la restauration d etat : chaque
redemarrage de Home Assistant les remet a leur valeur d origine, en silence. Et
un redemarrage etait prevu le soir meme pour le tableau du moniteur LLM.
Meme defaut que les cinq helpers corriges le 06/09 — selecteur de vehicule,
toggles de cablage — mais ici sur une table entiere de REGLAGE, donc sur tout
ajustement futur et pas seulement celui-ci.
Les valeurs par defaut restent dans INPUT_PARSE, qui les applique quand le
helper est absent. Rien n est perdu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le paquet propose par la session Airtria portait trois entites — interrupteur
d alertes, RAM disponible, libelle d etat. Il lui manquait celle sans laquelle
les trois autres mentent : un horodatage ecrit a chaque passage.
Sans lui, un moniteur mort est indiscernable d un systeme sain. Les trois
entites gardent leur derniere valeur, qui dit « tout va bien », indefiniment.
C est exactement l incident du 08/09 sur la prevision solaire, ou 4 h 45 de
panne n ont laisse aucune trace. Et on ne peut PAS deduire la fraicheur du
last_updated des autres entites : Home Assistant ne rafraichit pas l horodatage
d un helper reecrit a l identique — une RAM stable une heure produirait la meme
illusion.
Ajoutes : l horodatage, le modele charge, un capteur d age, et deux alarmes —
moniteur muet, RAM sous le seuil ou earlyoom tue le plus gourmand.
Defaut trouve et corrige apres creation : l alarme RAM se declenchait avant que
le moniteur ait tourne une seule fois, une valeur jamais ecrite valant zero.
Une mesure qu on n a pas recue n est pas une mesure basse. Elle est desormais
conditionnee a la fraicheur.
Tableau separe des tableaux energie : ce qu il montre n a aucun rapport avec le
photovoltaique.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Il vient de me dire directement quel vehicule est branche. C est une
confirmation humaine au meme titre qu une reponse WhatsApp, mais le code ne
reconnaissait que ce canal-la et aurait marque sa parole « non confirmee ».
Les canaux humains sont desormais enumeres explicitement — whatsapp et
proprietaire — plutot que teste contre une seule valeur. Enumeres, et non
inverses : un canal inconnu ne doit pas valoir confirmation par defaut.
`regle-puissance` n y est pas et n y sera jamais, c est une deduction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Plusieurs scans successifs, aucun changement — l inventaire reste a 4 modules et
400 Ah. La capture au bandeau bleu a ete prise PENDANT un scan : il s est donc
bien declenche et n a rien trouve de plus.
Ce que ca elimine : l inventaire simplement perime. Le Cerbo redemande et le BMS
agrege lui repond quatre. Le probleme n est pas cote Cerbo mais dans ce que le
hub lui presente — ce qui promeut l etape 3, la seule qui demande si le pack 2
est joignable du tout par ce chemin.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le bloc qui inverse la semantique de vehicule_sur n etait pas garde : a chaque
redemarrage il remettait les lignes anterieures a faux puis les six arbitrees a
vrai. Le resultat restait juste — l operation est idempotente en sortie — mais
elle ecrivait une ligne de journal trompeuse a chaque fois. Quatre en une
journee, qui seraient apparues en annotation sur tous les tableaux Grafana comme
autant de faux evenements.
Garde sur la trace elle-meme : si la ligne de journal existe, c est fait.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Il demandait « quel vehicule ? » a l ouverture d une session de charge. Trop
tard, et ca s est vu ce soir : a 19:55 la voiture est branchee, le selecteur
perime depuis six jours, et aucune question ne peut partir parce qu aucune
session n existe — la borne ne tire rien, il fait nuit. La premiere session de
la nuit serait nee etiquetee VW sans que personne ne soit consulte.
On etiquette desormais le BRANCHEMENT. C est d ailleurs l invariant du projet —
un cable, un vehicule — et ca rend la question possible des l instant ou on sait
qu il y a une voiture.
Deux temps. Le lecteur accepte une clef `branchement` en plus des `sessions`, et
memorise l etiquette dans une table dediee ; une passe differee, a chaque cycle,
la pose sur les sessions du branchement AU FUR ET A MESURE qu elles s ouvrent,
sans nouvelle question. Bornee par le debranchement suivant, avec les deux
secondes de tolerance du 09/09 — une session s ouvre jusqu a 62 ms avant que sa
transition de branchement soit journalisee.
L ancien contrat reste accepte : une etiquette portant des sessions fonctionne
comme avant.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
