La regle « tenir jusqu'a la prochaine HC » (8de284c) et le plancher de charge
HC manuelle (2654592, 18/09) etaient muets en production : la colle recopie le
snapshot champ par champ et les avait oublies. Les tests appelaient BALANCE
directement. Garde-fou : tout champ lu par BALANCE doit etre produit par
PREPARE_BALANCE (mutation verifiee).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Nuit du 26-27/09 : P12 a charge la JEEP sur la batterie (72 -> 44 %) ; la
journee sombre n'a pas reconstitue la reserve. Strategie : voiture branchee =
charge en HC sur le reseau ; la batterie tient jusqu'a la prochaine HC, midi
complete si besoin.
- HA transmet la fin de la fenetre HC en cours et le debut des suivantes (le
calendrier reste dans HA, §73)
- pendant une fenetre HC, required_soc >= SOC pour atteindre la PROCHAINE HC
(engage ET finance la session, insere dans coverage() comme le plancher
manuel) ; required_soc_prudent (plancher de P12) >= SOC pour atteindre la
NUIT SUIVANTE -> journee sombre = voiture sur le reseau HC
- a midi la session et la voiture en grid_hc_allowed se chargent ensemble
(aucun changement du controleur)
- 4 scenarios reels du 27/09, bilan 54/54, deux mutations qui mordent
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Decision du proprietaire (28/09) : Forecast.Solar renvoie des totaux quasi
constants (~26 kWh) pour 40-47 reels ; VRM suivait mieux le reel sur 10 jours
(erreur 21 % contre 32 %, 14 % contre 36 % sur les 5 derniers). Le bilan
lit VRM des maintenant ; les deux previsions sont enregistrees (colonne
source, cle etendue) pour les comparer dans une semaine.
- input_select.evcs_balance_forecast_source (vrm | forecast_solar) = retour
arriere en un geste ; helpers evcs_balance_vrm_* au format du bilan
- historisation : lecture VRM (jeton dans .env, jamais dans HA) toutes les
15 min, vrmVersCourbes (jour et heure de Paris), tests 69/69
- modele du bilan conditionnel ; bilan 50/50, deploye
- evcs_prevision_contre_reel porte sur la source active
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Incident 27-28/09 : l'agent presentait le surplus solaire de demain comme
de l'energie batterie et lisait une projection de jour du controleur la
nuit. Ce capteur ne relaie que le bilan (meme arbitre que la decision de
nuit) ; bilan > 30 min -> indisponible. Tests 65/65.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Incident 27/09 : l'agent annoncait « vers 90 % » de sa tete. La prevision
Forecast.Solar sous-estime d'environ 50-60 % : on publie des faits (SOC,
ecart de prevision), jamais un SOC projete. Tests 61/61.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
Delta depuis minuit de ac_in_1->ac_out + inverter->ac_out : 25,2 kWh a
17:11 le 26/09 pour ~25 dans VRM. Remise a zero -> indisponible, compteur
muet -> partiel. Tests 59/59, mutation qui mord.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011uJ47NxgfpGnuuMr3f2n7Z
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
