Delta depuis minuit de ac_in_1->ac_out + inverter->ac_out : 25,2 kWh a
17:11 le 26/09 pour ~25 dans VRM. Remise a zero -> indisponible, compteur
muet -> partiel. Tests 59/59, mutation qui mord.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Depuis la panne n8n du 05/09, Claude Code marquait ces deux serveurs
« authentification requise » et tentait un OAuth que n8n n'offre pas.
Memes adresses sans jeton dans opencode. Une configuration differente
repart sans l'etat bloque : connexion retablie le 26/09 (0,8 kWh lu).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Premier releve live (26/09 12:19) : compteur EDF 0,8 = VRM, delta des
compteurs AC-in du MultiPlus 0,7 (0,6 + 0,1, pas apparent de 0,1 kWh).
Repli sur le MultiPlus si le compteur EDF est muet ou remis a zero.
Tests diagnostics 55/55, deux mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Le proprietaire veut que l'agent vocal lui evite d'ouvrir VRM. « Combien ai-je
importe » est une quantite : delta des compteurs cumules AC-in du MultiPlus
(vers ac_out + vers inverter) depuis leur valeur a minuit, lue une fois par
jour dans l'historique HA. Compteur EDF publie en recoupement. Remise a zero ->
indetermine, jamais d'import negatif. Les trois compteurs entrent aussi dans la
table mesure (manque note au HANDOFF §76).
Tests diagnostics 48 -> 54, deux mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Incident du 26/09 : l'agent vocal a annonce le capteur reseau bloque a 07:24,
alors que le contacteur s'etait ouvert a la fin des heures creuses. Le verdict
ne juge l'age de la mesure que contacteur ferme ; ouvert, c'est non_raccorde.
Tests diagnostics 37 -> 48, trois mutations qui mordent.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011xd7aRDEChdShwsECohnDN
Le cable du pack 1 est a puce Prolific, sans pilote sur DSM : lu par un
portable a noyau recent. --suffixe pack1 separe les CSV des deux lecteurs ;
evcs_cellules regarde 15 min (deux lecteurs non synchronises) et publie
modules_lus (9 attendus).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Rebranche pendant que le conteneur tenait ttyUSB0, le cable est revenu en
ttyUSB1 : la garde cree un lien d'apres le numero de serie et recree le
conteneur quand le port change de numero.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Incident 25/09 11:49 : l'agent sans source avait invente 0,56 kWh / zero
reseau / 35 % pour une nuit a 7,9 kWh dont 2,2 reseau. donneesNuit() extrait
de rapport-nuit.mjs (texte identique sur 5 nuits), publie pour l'agent.
Tests 37/37.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
sensor.evcs_production_jour_kwh (somme des 3 yield_today, remises a zero
decalees gerees) et sensor.evcs_charge_solaire (relais de la decision du
controleur, pas un second arbitre). Tests 26/26 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
La fiche OpenClaw basculait G5 de 7/7 a 1/7 sur un ajout sans rapport :
les deux jugements sortent du modele. sensor.evcs_pv_diagnostic (import
teste avant bridage) et sensor.evcs_cellules (perime => aucune valeur
visible), publies meme quand le cycle echoue. Tests 15/15 + mutations.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Les trames BMS cellule de HA sont mortes depuis le 15/09 ; le relevé série est la
source vivante. Le service publie evcs_cell_spread_max_mv, evcs_cell_weakest_module
et evcs_cell_releve_age_min à chaque cycle (publierCellulesHelpers). L'âge donne à
l'agent la discipline anti-valeur-figée (comme le gel GX). Vérifié en réel :
21 mV, âge 1 min, K220803C30160323. Package evcs_cellules.yaml (hors dépôt, HA).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le HANDOFF chargé à chaque session pesait 7566 lignes. Split vérifié par md5 :
§1→§72 (09/07→17/09) déplacés SANS PERTE dans HANDOFF_ARCHIVE_2026.md (non chargé
par CLAUDE.md, grep/lecture à la demande). HANDOFF.md ne garde vivantes que les
sessions récentes §73→§77 + un index des sections archivées. Aucune info perdue,
aucun changement d'@-import nécessaire (l'archive n'est pas référencée).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
9 gammes (snapshots reels figes + attendus), 9/9 sur 3 passages. Coordination
avec SPARK : moi la verite-terrain (PostgreSQL/InfluxDB/historique HA), SPARK le
harnais et la fiche OpenClaw. G5 a echoue 0/3 au premier tour et a fait corriger
la fiche (import reseau force en controle nº1 avant de conclure bridage) ->
verrouille la distinction bridage normal / substitution. Source de verite de la
production PV dans MANUEL §0.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Somme des 3 rendements par chargeur Victron (airtria_mppt1 + mppt_450_200 + v1)
= production reelle du jour. Verifie 24/09 (45,1 kWh) et recoupe par l'integrale
de pv_power_system (44,0). Documente les 3 pieges qui donnent un faux chiffre :
energy_production_today = prevision, gx_device_pv_energy = partiel/gelable,
v1_production_d_hier = la veille. Pour les rapports, le bilan et l'agent vocal.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Envoi decale 06:47 -> 07:30 : apres la fermeture de la fenetre HC (07:24)
l'import de la nuit est termine, donc le total est complet. A 06:47 le rapport
ratait l'import 06:47->07:24 meme apres le fix d'extrapolation (ec5f43e).
Proposition du proprietaire. HANDOFF §76 consigne le bug (extrapolation de la
derniere puissance sur la fenetre future), le fix et ce decalage.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Signale par la session SPARK via les compteurs d'energie Victron : le rapport du
24/09 annoncait 4,2 kWh importes contre ~1,6 mesure. Cause reelle (verifiee en
base) : le rapport tourne a 06:47 mais sa fenetre va jusqu'a 10:00 ; l'ancienne
methode (grille generate_series 1 min + derniere valeur connue + sum/60000)
reportait la derniere puissance connue sur les ~3 h futures -> import fantome.
Ce n'est PAS la cadence d'echantillonnage (donnees eparses, 130 pts/961 min) et
les compteurs d'energie ne sont pas dans la table mesure (seul grid_power_l1).
Fix : integration ponderee par l'intervalle reel entre points (cap 300 s, jamais
d'extrapolation apres le dernier echantillon) et fenetre plafonnee a now().
Applique aux 4 grandeurs integrees (importe/injecte/voiture/batterie_chargee).
Verifie : 1,60 kWh sur fenetre complete (= compteurs), 1,19 en simulation 06:47.
Tous les rapports depuis le 08/09 surestimaient ces kWh ; le reste (SOC,
fermetures, vehicule, injection) etait juste.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le releve serie tournait sur le portable et est mort 4 jours au reboot du 20/09.
Migre sur le .17 (conteneur node + tache de boot root/sh chargeant les pilotes).
Survie prouvee de bout en bout sur reboot + saut majeur DSM 7.3.2 -> 7.4.1, qui a
revele et fait corriger deux pieges (NFS noexec, sudo passwordless efface par
l'update). @reboot du portable retire.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Deux defauts vus au retour de l'update 7.4.1 :
- le montage NFS du depot est noexec, donc la tache DSM qui appelait le chemin nu
du script donnait « Permission denied » et ne chargeait rien. Commande corrigee
en `sh <chemin>` (lit le script au lieu de l'executer).
- la boucle faisait confiance au code retour de modprobe (0 sans charger sur DSM).
Elle verifie maintenant l'etat reel via lsmod apres chaque tentative.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Constate au reboot + update DSM 7.3.2 -> 7.4.1 : le sudo passwordless de TMZF5455
a ete supprime, donc l'auto-elevation du script ne marche plus et la tache de
boot (owner 1026) n'a pas charge les pilotes -> device absent, conteneur Exited.
Les .ko existent toujours en 7.4.1. Le fix durable est une tache Planificateur
en utilisateur root, qui ne depend d'aucun sudo. Note aussi que les updates
majeurs peuvent desactiver les taches declenchees.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
Le .17 passe en DSM 7.4.1 (saut majeur, noyau potentiellement different). Les .ko
etaient charges par chemin fixe /lib/modules/ ; si 7.4.1 les deplace, insmod
echouait. Desormais : modprobe si dispo (gere les dependances), sinon find du .ko
dans /lib/modules et /usr/lib/modules. usbserial reste charge avant ftdi_sio.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
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
