Files

Tallagrand Thierry f0479945c4 Fenetre d etablissement : ne plus decider sur les mesures du transitoire

A la fermeture du contacteur, PV, import et courant batterie ne decrivent aucun
regime permanent pendant ~150 s (mesure du 31/08). La boucle de 30 s y prenait
cinq decisions, et la moyenne PV 10 min en gardait la trace dix minutes de plus
-- le systeme lisait "plus de soleil", en concluait qu il avait besoin du
reseau, et confirmait sa propre premisse.

Aucun seuil nouveau : le systeme publiait deja l horodatage de la transition et
personne ne le lisait. Pendant la fenetre, on ne demarre pas et on ne laisse pas
une charge s arreter sur ces mesures ; les step-down restent libres.

Deux asymetries voulues : la fenetre ne s ouvre qu a l ARRIVEE du reseau (a sa
disparition les onduleurs reprennent tout, les gardes doivent agir plus vite),
et elle suspend le confort, jamais le risque.

Golden 42 -> 48, chaque cas apparie a son contrefactuel hors fenetre. Mutation :
gridSettling force a false -> 2 echecs cibles, restauration -> 48/48.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ

2026-08-31 18:18:03 +02:00

115 KiB

Raw Blame History

HANDOFF.md — EVCS / Grid Hysteresis — État au 09/07/2026

1. Contexte Projet

Installation : Victron ESS sans injection réseau. Batterie 17,5 kWh utile.
Workflows n8n actifs :
- HA Snapshot EVCS Surplus Controller V2.6 (id ATswvGfG4KJUls0K) — pilote la borne EVCS (30 s)
- Victron - Battery / Grid Hysteresis Fix V1 (id 7iIlu7LLTW7TZA8o) — pilote le switch EDF (1 min)
Accès :
- HA : http://10.10.10.17:8123 — jeton dans jeton_EVCS.txt (⚠️ en clair, à révoquer si dépôt partagé)
- n8n : https://n8n.airtria.pro — clé API dans ~/.config/opencode/opencode.json (mcp.n8n-mcp)
- MCP opencode (option 1 déployée) : 5 serveurs distants dans ~/.config/opencode/opencode.json (ha-get-state, ha-set-helper, grid-set-state, victron-set-charge-limits, pv-get-forecast) → endpoints SSE https://n8n.airtria.pro/mcp/<path>/sse. Les 4 outils paramétrés utilisent $fromAI(...) (corrigé le 09/07). ⚠️ Endpoints MCP n8n sans authentification — à sécuriser (Bearer sur les nodes MCP Server Trigger).
Fichiers de référence locaux :
- WINDOWS/WINDOW_SOURCEV2.js, BATTERY/BATTERY_CLOUD_LOCKS.js, HYSTERESIS/COMPUTE.js — copies de lecture (le code qui fait foi est dans n8n)
- modified/GRID_HYSTERESIS_backup_20260709-*.json — rollback avant P1
- modified/EVCS_V2.6_backup_20260709-*.json — rollbacks avant P2 puis P3 (2 fichiers)

2. Architecture Data-Flow

EVCS V2.6 (30s) :
  HA Snapshot (template) → INPUT_PARSE → WINDOWS_SOURCEV2
    → BATTERY_CLOUD_LOCKS → DECISION_ENGINEV2 → HA_SERVICE_CALLS_OUTPUT
    → Build Actions → Execute HA Service

Grid Hysteresis (1min) :
  HA Snapshot → Compute Grid Hysteresis → Build Actions → Execute HA Service

Communication inter-workflows via helpers HA : input_text.victron_evcs_source_mode (labels FR), input_boolean.victron_evcs_night_grid_takeover_needed, input_text.victron_evcs_surplus_state, input_select.victron_evcs_strategy.

3. Patchs déployés le 09/07/2026 (session opencode)

P1 — Grid Hysteresis (déployé, vérifié)

Entité fantôme corrigée : le snapshot lisait input_select.victron_evcs_user_strategy (inexistante → toujours unknown). Corrigé en input_select.victron_evcs_strategy. Conséquence avant fix : les overrides force_grid_now/force_charge_now et la coupure « voiture pleine » ne fonctionnaient JAMAIS dans l'hystérésis.
Switch EDF unavailable : nouvel état switch_unavailable = aucun ordre, aucun timestamp, réévaluation complète au retour du switch. Avant : spam turn_on chaque minute + rallumage aveugle à la reconnexion (incident du 08-09/07 : disjoncteur physique coupé par l'utilisateur, EDF rallumé à 00:41 au retour, batterie chargée sur réseau à SOC 48 %).
last_on_at : réécrit uniquement sur vraie transition (latch OFF→ON), plus à chaque retry. Avant : hold_on_min_runtime pouvait durer éternellement.
Bug latent corrigé : le bloc turn_off_force_grid_vehicle_full (V2.5) était écrasé par la chaîne principale (code mort). Flag forcedCut ajouté.

P2 — EVCS V2.6 : continuité takeover nuit / anti-créneaux (déployé, vérifié en réel)

Le snapshot relit night_takeover_prev (= helper takeover du cycle précédent).
nightTakeoverLatched dans WINDOWS_SOURCEV2 et BATTERY_CLOUD_LOCKS : une fois le réseau HC engagé en session nuit, on y reste jusqu'à fin de session (fenêtre/débranchement) ou SOC ≥ 90 (NIGHT_TAKEOVER_RELEASE_SOC_PCT).
Supprime le cycle « château fort » : batterie→jeep→seuil 20 %→EDF ON→30 %→EDF OFF→batterie...
Vérifié en production dans la nuit du 09/07 : takeover engagé à SOC 35 %, EDF resté ON, Jeep en charge continue (hold_min_run).

P3 — EVCS V2.6 : provocation PV batteries pleines (déployé, dry-run complet)

Problème (ancien sujet de ce HANDOFF) : sans injection, batteries pleines ⇒ MPPT bridé à la conso maison ⇒ aucun seuil PV observable ; en plus forecastBufferKwh (10,5 kWh véhicule soustraits) toujours ≤ 0 l'après-midi, et cloudDebt en deadlock (batterie pleine = courant nul = dette jamais remboursée). Sonde afternoon inopérante (probe_enabled = off + seuil PV 1000 W).
Fix : pvProvocationEligible = SOC ≥ 90 && batterie non déchargée → solar_potential (intégré à isHighBatteryForPotential, donc actif sur les 4 profils jour). Gardes aval intactes.
Attention réglage : soc_start_min (HA) = 94 ⇒ plancher de démarrage hors fenêtre. Le déclenchement pratique est donc SOC ≥ 94 %. Baisser ce helper à 90 pour aligner.

P4 — Maintien SOC adapté au forecast pendant le takeover nuit (déployé 09/07 après-midi)

Découverte clé : Victron - Auto Charge Manager V1.2 (id cTeeHy4ePiVeELLh) est le propriétaire des limites DVCC (MaxChargeCurrent/MaxChargeVoltage via MQTT, feedback : sensor.victron_max_charge_current_setting). Son mode « nuit idle » laissait 30 A de charge batterie dès que EDF était ON → batterie rechargée à fond pendant un takeover.
ACM patché : nouvelle branche prioritaire evcs_takeover_hold / evcs_takeover_recover : si night_grid_takeover_needed ON + EDF ON → SOC < cible-1 : recharge 30 A ; sinon maintien 2 A / 50.1 V (maison + VE sur HC, batterie en pause). Cible lue depuis input_number.victron_evcs_night_target_soc (écrite par le workflow EVCS : forecast fort→35 %, moyen→55 %, faible→85 % — donc été ~35, hiver ~85 comme demandé).
EVCS patché : avant minuit (20h→8h), la cible matin utilise max(today_remaining, tomorrow_kwh) (sinon today_remaining≈0 à 23h → cible 85 % à tort en été). Ajout tomorrow_kwh au snapshot + parsed.tomorrowKwh.
Dry-runs : 8 scénarios ACM + 2 scénarios cible EVCS validés (voir session 09/07).

Autres réalisations du 09/07 (après-midi)

Borne fantôme résolue : firmware EVCS 2.05 → 2.08 (session repartie de zéro, détection véhicule correcte). Les 19 kWh affichés étaient un cumul de session non réinitialisé.
Dashboard « EDF Urgence » créé via API HA (sidebar) : scripts script.edf_urgence_off (hystérésis OFF + latch OFF + stratégie stop + switch OFF — rien ne rallume), script.edf_force_on, script.edf_rendre_la_main + cartes d'état et « pourquoi ».
Incident Synology : NAS éteint dans la nuit (cause à chercher dans les logs DSM) → n8n + HA morts → EDF resté ON toute la nuit, batterie chargée à 96 % sur réseau. ⚠️ SPOF structurel : tout le contrôle vit sur le Synology.

P5 — Plafond courant EVCS configurable quand EDF est ON (déployé 09/07 soir)

Le plafond 20 A venait de cfg.evcsDedicatedMaxW (4900−300 W / 230 V) codé en dur dans INPUT_PARSE.
Nouveau helper input_number.evcs_plafond_courant_edf_on (6–32 A, défaut 20) : quand AC-IN est physiquement présent (acin1_available, pas juste le switch), le plafond = helper ; hors réseau, retour au plafond câblé ~20 A. Dry-run 5 scénarios OK (dont disjoncteur coupé).
Subtilité : victron_evcs_current_max_auto_a (22) plafonne EN PLUS les modes auto ; en force_grid/force_charge seul le nouveau helper compte.
Boutons dashboards (EVCS Master = fichier YAML /mnt/ARCH3/docker/HA/dashboards/evcs_master.yaml édité via NFS ; EDF Urgence = API) : carte « Plafonds courant EVCS » + boutons ⚡ BOOST EDF 28A (script.evcs_boost_edf : plafonds 28/28 + force_grid_now + consigne 28) et Retour normal (script.evcs_boost_off : 20/22 + auto_solar_plus).
Sémantique clarifiée : « Courant demandé » = « Consigne envoyée » = number.victron_evcs_set_current_command (réécrit toutes les 30 s par le workflow) ; « Consigne lue » = readback borne. En force_charge_now, PV ≥ 700 W ⇒ source « Solaire » ⇒ gardes nuages/batterie freinent : pour une grosse charge, force_grid_now.

P6 — Override « abondance » du plancher SOC de démarrage (déployé 12/07 midi)

Symptôme : 12/07 midi, PV 8,9 kW, batterie en charge +125 A, Jeep branchée → EVCS bloqué idle_wait_conditions. Cause unique (dry-run) : plancher SOC fenêtre midi (input_number.victron_evcs_midday_soc_min = 75) > SOC 66.
Fix (BATTERY_CLOUD_LOCKS) : si pvPowerAvg10m ≥ 4000 W et batteryCurrentA ≥ +20 A (abondance physique : la batterie monte même avec l'EVCS), plancher de démarrage abaissé à 40 % (effectiveSocStartFloor). Jours nuageux : planchers d'origine intacts. Debug exporté : solarAbundance, effectiveSocStartFloor (safeguards).
Vérifié en réel : déploiement 12:43 → start_min_current immédiat → charge 12 A.
Observation borne : après des heures branchée en statut 6, la Jeep a mis ~2,5 min à s'engager ; le workflow renvoie turn_on toutes les 30 s (retry intégré suffisant).
Planchers de référence : matin 35, midi 75, soir ?, hors fenêtre 94 (soc_start_min).

Maintenance du 09/07 soir (analyse des messages d'erreurs)

W-105 borne (surcharge) : survenu en charge 20 A sur onduleur seul (disjoncteur EDF coupé). Déjà couvert : gardes vebus_overload + P5 (plafond retombe à 20 A si AC-IN absent).
saveDataErrorExecution: all activé sur les 8 workflows critiques (diagnostic des prochaines erreurs avec données des nodes ; Water Heater V2.3 avait erré 4× le 09/07 20:20-20:35, cause inconnue faute de données, rétabli seul).
Garage Thermal : la prise switch.clim_hygro_socket_1 est débranchée volontairement par moments → l'appel au switch est maintenant conditionné à sa disponibilité (execute: switchAvailable). Plus de warnings « missing entity » toutes les 10 min. Backup modified/GARAGE_backup_*.
Templates MQTT durcis (33 occurrences, configuration.yaml + packages/victron_vebus_mqtt.yaml) : garde value_json is defined → plus d'erreurs value_json is undefined aux reconnexions MQTT. Backups SAVE_CONFIG/*.bak.20260709-234800, check_config valid, mqtt.reload fait. ⚠️ Après un mqtt.reload, les sensors restent unknown jusqu'à republication Venus : publier R/c0619ab34ac5/keepalive (payload vide) force la republication complète.

4. Root Cause de l'incident « EDF ON à 48 % sans charge Jeep » (nuit 08→09/07)

Chaîne complète reconstituée via l'historique HA :

Borne fantôme au matin du 08/07 (« véhicule en charge » sans véhicule) + force_grid_now de la veille ⇒ EDF maintenu ON (la coupure voiture-pleine était du code mort, cf. P1.1/P1.4).
L'utilisateur coupe le disjoncteur physique ⇒ switch unavailable pendant ~5 h.
Le workflow reste coincé en hold_on_min_runtime (P1.3) en spammant turn_on (P1.2).
00:40:54 : le switch revient ⇒ 00:41:03 EDF ON sans cause actuelle ⇒ Multiplus charge la batterie sur réseau (2980 W) ⇒ coupé à 01:06 (min_on 25 min, SOC ≥ 30). Tous les maillons sont corrigés par P1.

5. Sémantique utile (pour ne pas re-chercher)

Latch (input_boolean.victron_grid_hysteresis_latch) : « c'est l'automate qui a allumé EDF et il défend cet état ». Reprise en main manuelle : stratégie stop + hystérésis OFF + latch OFF.
Fenêtres EVCS (helpers HA, corrigées/vérifiées le 09/07) : night_hc 01:24→07:24 (HC réelles), morning_solar 07:30→11:00, midday_hc_or_solar 12:24→14:24 (HC réelles), evening_high_soc 17:00→20:30, sinon outside_window. L'Auto Charge Manager utilisait des fenêtres codées en dur légèrement fausses (01:30-07:15 / 12:25-14:25) — alignées sur 01:24-07:24 / 12:24-14:24 le 09/07.
Seuils hystérésis réseau (HA, valeurs réelles) : ON ≤ 20 %, OFF ≥ 30 %, min_on 25 min.
Cibles nuit : hard floor 22 % ; cible matin selon forecast : ≥18 kWh→35 %, ≥10→55 %, sinon 85 %. nightSessionActive = fenêtre nuit && véhicule branché (⚠️ pas besoin de charge active).
Statut borne 6 = branchée en attente de démarrage (« Inconnu (6) » sur le dashboard).
Labels FR dans source_mode : Réseau forcé, Réseau HC autorisé, Assistance batterie nuit, Bloqué, Solaire, Potentiel solaire — l'hystérésis matche ces labels.

6. Méthode de travail validée (à réutiliser)

Backup : GET /api/v1/workflows/<id> → modified/*_backup_<stamp>.json.
Patch des jsCode par remplacement exact (script node), node --check sur chaque node.
Dry-run local de la chaîne complète : snapshot réel via POST /api/template HA, exécution séquentielle des 5 nodes avec shim $input, horloge simulable en surchargeant global.Date (voir session du 09/07).
PUT /api/v1/workflows/<id> (⚠️ filtrer settings : seuls executionOrder/timezone/save*/executionTimeout/errorWorkflow sont acceptés).
Vérification live : helpers HA 40-70 s après.

7. Backlog / Point du 10/07 au réveil

Vérifier la nuit de test P2+P4 (fenêtre HC 01:24→07:24, forecast fort → cible 35 %) :
- takeover engagé quand SOC ≤ 35 → EDF ON continu (pas de créneaux) ;
- input_text.victron_charge_mode = evcs_takeover_recover puis evcs_takeover_hold ;
- sensor.victron_max_charge_current_setting = 2 pendant le hold (batterie tenue ~35 %) ;
- 07:24 : fin de fenêtre → EDF coupé (turn_off_recovered), ACM repasse en profil jour. Historique utile : switch.edf_general_ok_switch, sensor.victron_battery_soc, input_text.victron_charge_mode entre 01:00 et 08:00.
Cause de l'extinction du Synology (DSM → Centre des journaux) + réflexion SPOF : le fail-safe physique actuel est « EDF ON + charge batterie » quand le NAS meurt.
Baisser input_number.victron_evcs_soc_start_min 94 → 90 (aligner avec P3) si souhaité.
Sécuriser : auth Bearer sur les 5 MCP Server Triggers n8n + révoquer/déplacer le jeton HA.
À investiguer : « conditions de démarrage nuit batterie non réunies » quand la batterie suffit pour la nuit (conditions de départ battery_assist_night).
Optionnel : brancher un keepalive/republish Venus automatique après mqtt.reload (cf. note maintenance §3).

8. Historique des sessions

12/06/2026 : analyse blocage outside_window, déploiement afternoon_probe (V2.6), fix clignotement EDF (edf_general_ok_on conditionné au sourceMode).
09/07/2026 (nuit) : incident EDF nocturne analysé (root cause complète), MCP option 1 en place, P1 (hystérésis robuste + entité stratégie), P2 (anti-créneaux nuit), P3 (provocation PV).
09/07/2026 (journée/soir) : incident Synology (NAS éteint → EDF ON toute la nuit, batterie 96 %), firmware borne 2.08 (fantôme résolu), dashboard EDF Urgence + boost 28 A, P4 (maintien SOC au forecast pendant takeover, via Auto Charge Manager), P5 (plafond EDF ON configurable), fenêtres HC corrigées (01:24-07:24 / 12:24-14:24), maintenance erreurs (save error executions, prise garage conditionnelle, 33 templates MQTT durcis).
12/07/2026 : P6 (override abondance du plancher SOC midi — PV fort + batterie en charge ⇒ démarrage dès SOC 40) ; validation en réel à 12:43, charge Jeep engagée.
17/07/2026 (après-midi) : Session de débogage majeure — résolution d'un enchaînement de bugs bloquants empêchant la charge solaire de la Jeep :

Bug 1 — Typo critique dans DECISION_ENGINEV2 :
- Ligne ~333 : noDemandnightSessionNeedsClearScoreOff (variable inexistante) au lieu de noDemandScoreOff
- Conséquence : evcsVehicleNoDemandSemantic restait false même quand la voiture était pleine
- Le filtre "véhicule plein/pause" ne fonctionnait jamais → blocage du système
Bug 2 — Artefacts de corruption dans WINDOWS_SOURCEV2 :
- 3 occurrences de tool_f6d3316d2001k4aAfEjbKGNUX2 (résidu de copier-coller ou debug)
- Provoquaient des erreurs is not defined à l'exécution
- Workflow en ERROR continu depuis 14:49
Bug 3 — Session nuit jamais clearée :
- input_boolean.victron_evcs_night_session_active restait on depuis 23:24 la veille
- Même après la fenêtre HC (01:24-07:24), le profil restait night_hc → battery_assist_night
- En plein jour avec grand soleil, le système pensait être en "assistance batterie nuit"
- Clearé manuellement à 14:45
Bug 4 — EDF rebranché automatiquement en journée :
- Condition edf_general_ok_on déclenchée dès sourceMode = grid_forced ou grid_hc_allowed
- Même en plein jour avec du soleil, EDF se rebranchait si le workflow passait en ces modes
- Correction : ajout de context.profile === 'night_hc' pour ne rebrancher que la nuit
Configuration ajustée :
- battery_discharge_soft_a : 0A (au lieu de -8A) — permet le démarrage sans décharge batterie
- battery_neutral_band_a : 0A (au lieu de -2A) — tolérance nulle
- soc_start_min : 80% (au lieu de 94%) — seuil de démarrage plus réaliste
- night_target_soc : 70% (au lieu de 85%) — laisse plus de marge pour le PV
Mode sonde activé :
- probe_enabled : ON — permet le démarrage à 6A pour "provoquer" la production PV
- Particulièrement utile en autoconsommation sans injection où le PV ne produit que si chargé
Résultat :
- Workflow réparé et fonctionnel
- Jeep en charge à 17A avec le soleil (16:58)
- EDF OFF (ne se rebranche que la nuit)
- Système 100% auto en auto_solar_plus
- DeliveryRatio à 99.9% — charge stable et efficace
À noter : Le courant de sonde (probeCurrentA) est codé en dur dans le workflow n8n (nœud SETUP/PARAMS), pas dans un helper HA. Pour le changer de 6A à 10A, modifier directement dans l'interface n8n. Mais le workflow augmente automatiquement le courant (17A atteints), donc ce n'est pas critique.

⚙️ CONFIG LOCALE — Qwen3.6-35B sur DGX Spark (≠ gros modèle cloud)

⚠️ Cette config est CALIBRÉE pour le modèle LOCAL Qwen3.6-35B-A3B (3B actifs, contexte limité). NE PAS appliquer telle quelle à un gros modèle cloud (FABLE/Claude), qui n'a besoin ni du bornage strict ni du découpage par nœud.

Infra (validée le 16/07/2026)

DGX Spark = 10.10.10.8, endpoint vLLM unique sur port 8000.
UN SEUL modèle à la fois (contrainte NVRAM 1 Spark) → swap via scripts :
- use-code : docker compose down (VL) + sparkrun run qwen3.6-35b sur :8000
- use-vl : sparkrun stop --all + docker compose up (Qwen3-VL, vision)
Recette : @official/qwen3.6-35b-a3b-fp8-mtp-vllm --tp 1 --port 8000 --gpu-mem 0.8 --served-model-name qwen3.6-35b (MTP + flashinfer + tool-parser qwen3_coder déjà inclus dans la recette).
Qwen3-VL (docker /opt/vllm) réservé à l'analyse de captures d'écran.

opencode.json (poste Ubuntu, PAS la Spark)

baseURL: http://10.10.10.8:8000/v1, apiKey "EMPTY".
Modèle "qwen3.6-35b" : options { temperature: 0.15, reasoningEffort: "none" }, cost tout à 0 (sinon compteur fantôme FABLE), limit context 65536.
permission.bash : "curl *": "deny", "wget *": "deny" (bloque hallucinations HTTP).
Les 6 MCP (n8n-mcp, ha-get-state, ha-set-helper, grid-set-state, victron-set-charge-limits, pv-get-forecast) : NE JAMAIS toucher ce bloc.

RÈGLES DE TRAVAIL spécifiques au local (dans AGENTS.md)

Contexte trop petit pour un workflow entier (~357K = ~102K tokens > 65K). => JAMAIS charger le workflow complet. UN nœud / UNE tâche à la fois.
n8n-mcp_get_workflow renvoie le workflow entier => opencode l'écrit dans ~/.local/share/opencode/tool-output/tool_* (tronqué). Le fichier commence par "Retrieved workflow: " AVANT le JSON => json.load ÉCHOUE. Extraction validée : grep -n '"name":"NOEUD"' puis sed -n 'X,Yp'. (ripgrep/rg N'EST PAS installé sur la Spark, utiliser grep.)
reasoningEffort none coupe le thinking (le tag /no_think en tête de chat NE marche pas : opencode l'intercepte comme slash-command).
Skill n8n installée dans .opencode/skills/ — surveiller les compactions.

PÉRIMÈTRE (le plus important)

LOCAL Qwen3.6 = tâches CIBLÉES : lire 1 nœud, repérer une faille logique, patch simple, dry-run. Rapide, gratuit, fiable SI bien borné.
CLOUD (FABLE/gros modèle) = refontes multi-nœuds, analyse d'un workflow ENTIER, orchestration MCP longue. Ne pas forcer le local dessus (il boucle).

🧩 SKILLS n8n — validées le 16/07/2026 (Qwen3.6 local, PAS gros modèle)

⚠️ Config calibrée pour Qwen3.6-35B-A3B local (contexte 65K). Les skills aident au tool-calling n8n. Sur gros modèle cloud, elles sont facultatives.

Installation

Dépôt : github.com/viliamvolosv/n8n-opencode-skill
Emplacement OBLIGATOIRE : .opencode/skills//SKILL.md (dossier "skills" PLURIEL ; le repo clone dans un sous-dossier "skill" SINGULIER → il FAUT remonter : mv n8n-opencode-skill/skill/* .)
opencode doit être lancé DEPUIS le projet : cd /mnt/projects/EVCS/EVCS && opencode (sinon .opencode/skills/ n'est pas découvert → skills invisibles).
Chargement PROGRESSIF : au repos les 8 skills ne coûtent que ~12K tokens (18%). Le SKILL.md complet (~16K) ne se charge QUE si la skill est invoquée.

Skills ACTIVES (5, validées par test réel sur DECISION_ENGINEV2)

n8n-mcp-tools-expert → récup config nœud via MCP (fiabilise les 6 MCP)
n8n-code-javascript → analyse/patch du jsCode (vars in/out, utilitaires)
n8n-expression-syntax → vérif syntaxe {{ }}
n8n-validation-expert → refs de nœuds, cohérence types, conditions
n8n-node-configuration → conformité params/mode/position

Skills DÉSACTIVÉES (déplacées dans .opencode/skills-off/)

customize-opencode (méta, hors sujet EVCS)
n8n-code-python (on fait du JS)
n8n-workflow-patterns (exige le workflow ENTIER → risque contexte) → réactivables en les remettant dans skills/ , ou à réserver au cloud.

Résultat du test de validation (5 skills, DECISION_ENGINEV2)

Les 5 skills invoquées et nommées correctement, analyse d'ingénieur juste (16 vars, 7 derived, 22 conditions, pipeline complet reconstitué).
UNE SEULE compaction (pic 88% au parsing du workflow 357K, reprise propre).
2 AttributeError Python transitoires (structure connexions n8n) → auto-corrigés.
Coût : $0.00.

RÈGLE contexte associée (dans AGENTS.md)

Analyse pipeline multi-nœuds : grep -n "name"/"jsCode" + sed sur la plage, JAMAIS le workflow JSON entier en mémoire Python. Traite 1 nœud, résume, libère.
Le fichier tool-output commence par "Retrieved workflow: " AVANT le JSON → parade validée : json.loads(text[text.index('{'):]).

PÉRIMÈTRE (rappel)

Local Qwen3.6 + skills = analyse ciblée 1 nœud, validation, patch simple. ✅
Cloud (FABLE/gros modèle) = refonte multi-nœuds massive, workflow entier.

9. Session du 18/07/2026 (matin)

Corrections documentation (MANUEL_COMPLET.md)

outside_window : décrit comme "Mode probe (sonde) pour relancer le PV si besoin" (pas bloquant)
Cloud Debt & Probe : nouvelle section 11.4 complète avec explication dette nuageuse, mode probe 10A, bypass en auto_solar_plus / force_charge_now
Stratégies : clarifié force_grid_now = préservation batterie (SOC<22% → recover 35%/50%/75%) vs force_charge_now = secours manuel
Heure de départ : nouvelle section 11.5 "Logique Heure de départ (Night EVCS)"

Modification workflow

probeCurrentA : augmenté de 6A à 10A dans le nœud INPUT_PARSE (fallback)
Rationale : 6A trop faible pour "provoquer" la production PV, 10A plus efficace

Versionnage Git

Export du workflow dans workflows/evcs-surplus-controller-v2.6.json
Commit & push effectués

10. Session du 04/08/2026 (matin) — Fix grid HC 1h30 + libération takeover

Problèmes诊断qués

Charge HC ne démarre pas à 1h30 : Le grid ne se mettait pas en route à l'ouverture de la fenêtre HC
Grid ne rend pas la main après charge : EDF restait ON après la fin de charge (SOC 71% < 90%)

Root Causes identifiées

gridAllowedBySoc (BATTERY_CLOUD_LOCKS) : autorise le grid seulement si soc <= 35% ou forceGridRequested. En profile night_hc avec SOC > 35%, le grid était bloqué.
nightTakeoverLatched (WINDOWS_SOURCEV2) : reste latché tant que soc < 90% (hardcodé). Pas de condition "véhicule chargé" → le takeover ne se libérait jamais.

Corrections appliquées

Fix 1: `gridAllowedBySoc` — Autoriser le grid en profile night_hc

Node: BATTERY_CLOUD_LOCKS

// AVANT:
const gridAllowedBySoc = parsed.soc <= 35 || strategy.forceGridRequested;

// APRÈS:
const gridAllowedBySoc =
  strategy.forceGridRequested ||
  context.profile === 'night_hc' ||
  parsed.soc <= 35;

Fix 2: `nightTakeoverLatched` — Libérer si charge terminée

Node: WINDOWS_SOURCEV2

// AVANT:
const nightTakeoverLatched =
  nightSessionActive &&
  nightTakeoverPrev &&
  parsed.soc < NIGHT_TAKEOVER_RELEASE_SOC_PCT;

// APRÈS:
const vehicleChargeCompleted =
  !parsed.evcsChargingSwitchOn &&
  parsed.soc >= 50;
const nightTakeoverLatched =
  nightSessionActive &&
  nightTakeoverPrev &&
  (
    parsed.soc < NIGHT_TAKEOVER_RELEASE_SOC_PCT ||
    vehicleChargeCompleted
  );

Méthode de déploiement

MCP n8n-mcp_update_workflow : Erreur 1003 (request/body must NOT have additional properties) — bug du MCP
Bypass : Script tools/n8n-rest-update-test.mjs créé, utilise REST API n8n directement avec token
PUT réussi avec body minimal : {name, nodes, connections, settings, staticData}
Settings doit être minimal : {"executionOrder":"v1","callerPolicy":"workflowsFromSameOwner"}

Backup

backup-workflow-ATswvGfG4KJUls0K-1785849621547.json

Vérification

Les 2 patches sont dans le workflow en production
À surveiller : prochaine nuit HC (01:24-07:24) pour valider le comportement

Document mis à jour le : 04/08/2026 (~10:00) — Fix gridAllowedBySoc + nightTakeoverLatched via REST API État live à la clôture : Workflow patché, à tester en conditions réelles

11. Session du 07/08/2026 — P7 : Charge HC nuit automatique (VW hybride) + outillage push

Problème (nuits du 05-07/08, observé sur l'historique HA)

VW hybride branchée le soir + stratégie auto_solar_plus → aucune charge en HC. 01:24 : idle_wait_conditions / « Conditions de démarrage nuit batterie non réunies » (SOC 53 %, target=trigger=35 %). L'utilisateur devait intervenir manuellement (force_charge_now, ou BOOST EDF 28A à 05:50 le 07/08).

Root causes

battery_assist_night ne démarre jamais : batteryAssistNightStartOk exige batteryCurrentA >= profileBatteryDischargeFloorA (= battery_discharge_soft_a = 0 A). La nuit, la maison tire sur la batterie (~ −14 A) → condition impossible. → le système attendait que le SOC dérive jusqu'au trigger 35 % (des heures) avant le grid. (= backlog §7.5 « conditions de démarrage nuit batterie non réunies », résolu.)
allow_grid_hc_night (toggle « Réseau HC nuit ») était décoratif : parsé dans INPUT_PARSE (params.allowGridHcNight) mais utilisé nulle part (contrairement à allowGridHcMidday).

Fix P7 (déployé 07/08 ~15:45, dry-run 7 scénarios validés)

Dans WINDOWS_SOURCEV2 et BATTERY_CLOUD_LOCKS (logique nuit dupliquée) :

const nightGridHcPreferred =
  nightSessionActive &&        // fenêtre HC nuit + véhicule branché
  params.allowGridHcNight;     // toggle "Réseau HC nuit" ON

batteryAssistAllowed : ajout && !nightGridHcPreferred
nightGridTakeoverNeeded : ajout nightGridHcPreferred || dans le OR

Effet : dès l'ouverture de la fenêtre HC (01:24) avec véhicule branché, nightPreferredSourceMode = grid_hc_allowed (ou grid_forced si SOC < cible matin) → edf_general_ok_on allume EDF → takeover helper ON → ACM evcs_takeover_hold (batterie tenue 2 A) → gridStartOk → start_grid_hc_min_current puis step-up.

Toggle « Réseau HC nuit » OFF → comportement historique (battery assist) intact.
Jour / pas de véhicule / force_charge_now : aucun changement (dry-run vérifié).
Garde-fous intacts : hard floor 22 %, recovery urgent, latch anti-créneaux P2, P4/P5.

Outillage (résout le blocage minimax « impossible de pousser dans n8n »)

tools/n8n-pull.mjs <id> <fichier> : GET workflow → JSON local (clé API lue automatiquement dans ~/.config/opencode/opencode.json).
tools/n8n-push.mjs <fichier> [id] : PUT REST (body minimal validé 04/08) avec backup serveur auto pré-push (modified/prepush-*.json) et node --check sur chaque jsCode (abandon si erreur de syntaxe).
tools/patch-20260807-night-hc-grid.mjs : le patch P7 (remplacements exacts, rejoue-able).
tools/dryrun-20260807-night-hc.mjs : harnais dry-run WINDOWS→BCL avec snapshot simulé.
Cycle git : commit backup AVANT (1debfe3) → patch → push → commit APRÈS. Rollback : git checkout 1debfe3 -- workflows/evcs-surplus-controller-v2.6.json && node tools/n8n-push.mjs workflows/evcs-surplus-controller-v2.6.json.

À surveiller (prochaine nuit HC 01:24→07:24, VW branchée)

01:24-01:25 : source_mode → Réseau HC autorisé, EDF ON, takeover helper ON ;
start_grid_hc_min_current → montée en courant (plafond EDF ON = helper 20 A / boost 28 A) ;
ACM en evcs_takeover_hold (batterie ~2 A, SOC stable) ;
07:24 : fin de fenêtre → EDF OFF, retour profil jour.

Document mis à jour le : 07/08/2026 (~15:50) — P7 charge HC nuit auto + tools n8n-pull/n8n-push

12. Session du 07/08/2026 (soir) — R1 : Déduplication du moteur nuit

Contexte

Refactor n°1 du plan de maintenabilité (conseil validé avec l'utilisateur) : le moteur nuit complet (~161 lignes : nightSessionActive, batteryAssistAllowed, nightGridTakeoverNeeded, nightPreferredSourceMode, cibles/triggers, latch...) était calculé DEUX FOIS, dans WINDOWS_SOURCEV2 ET BATTERY_CLOUD_LOCKS. Chaque patch nuit devait être appliqué 2× (P2, fix 04/08, P7) → risque de divergence silencieuse entre sourceMode (WINDOWS) et conditions (BCL).

Fix R1 (déployé 07/08 ~19:03, A/B validé)

WINDOWS_SOURCEV2 = unique calculateur. Reprend les 4 éléments que seul BCL calculait : nightSessionStartMs, nightSessionNeedsCapture version stricte (critère startMs inclus), batteryRecoveryAllowedNow, batteryTargetReached. Export nightEvcsPreview étendu (+ nightTakeoverLatched, nightGridHcPreferred).
BATTERY_CLOUD_LOCKS consomme prev.nightEvcsPreview (bloc de 161 lignes remplacé par ~50 lignes de lecture avec fallbacks sûrs : preview absent → session inactive / 'blocked'). −1,7K chars.
Le shape de l'export nightEvcs de BCL (consommé par DECISION_ENGINEV2 et HA_SERVICE_CALLS_OUTPUT) est strictement inchangé.
RÈGLE DÉSORMAIS : toute évolution de la logique nuit se fait UNIQUEMENT dans WINDOWS_SOURCEV2. BCL ne contient plus aucune logique nuit.

Validation A/B (tools/ab-20260807-r1.mjs)

Pipeline complet WINDOWS→BCL exécuté avant (git HEAD) / après (patché) sur les 7 scénarios golden + 2 cas limites (capture session history vide, clear résiduel).
Sorties BCL strictement identiques (nightEvcs, conditions, safeguards, context).
Fallback preview absent : pas de crash, retombe en 'blocked'.
Piège rencontré : Date.now() dans le harnais → faux diffs de quelques ms ; corrigé en construisant le snapshot une fois puis clone JSON par exécution.

Outillage ajouté

tools/patch-20260807-r1-dedup-night.mjs : le refactor (rejouable).
tools/ab-20260807-r1.mjs : harnais A/B git HEAD vs working tree — réutilisable pour tout futur refactor (modèle pour R3, la suite de tests golden).

Prochaines étapes du plan validé

R3 : suite de tests golden (~15 scénarios, exécutée avant chaque push).
R2 : git source de vérité (src/nodes/*.js + assemblage dans n8n-push.mjs).
Puis agent IA planificateur en mode ombre (jamais dans la boucle 30 s).

Document mis à jour le : 07/08/2026 (~19:10) — R1 déployé, comportement inchangé (A/B), production stable

13. Session du 07/08/2026 (soir) — R3 : Suite de tests golden

Ce qui existe désormais (`tests/golden/`)

run.mjs : exécute le VRAI code des nodes en chaîne complète (INPUT_PARSE → WINDOWS_SOURCEV2 → BATTERY_CLOUD_LOCKS → DECISION_ENGINEV2 → HA_SERVICE_CALLS_OUTPUT) dans une sandbox vm avec horloge simulée (Date épinglée par scénario) sur un snapshot HA réel modifié par overrides.
fixture-snapshot.json : snapshot production capturé depuis l'exécution n8n 975833 (173 champs, re-capturable via tools/fetch-snapshot-fixture.mjs).
scenarios.mjs : 16 scénarios avec attendus FIGÉS après revue manuelle : 6 nuit HC (P7 ON/OFF, sous-cible, hard floor, sans véhicule, EDF ON→start), 4 solaire (matin fort, matin nuageux, abondance P6, provocation P3), garde SOC midi HC, force_grid, force_charge nuit, stop, overload, débranché.

Usage

node tests/golden/run.mjs → 16/16 ✅ ou liste des diffs + exit 1
--print : affiche les résumés obtenus (pour autoriser une évolution)
--json : sortie machine (utilisée pour figer les attendus)
--only=<motif> : filtre par id de scénario

Intégration au déploiement (le point clé)

tools/n8n-push.mjs exécute la suite AVANT tout PUT du workflow EVCS : golden rouge = rien n'est poussé. Échappatoire consciente : --skip-golden. Évolution volontaire du comportement → mettre à jour les attendus dans scenarios.mjs DANS LE MÊME COMMIT que le patch.

Validation par mutation

P7 volontairement cassé (nightGridHcPreferred = false) → la suite détecte 2 échecs avec diffs précis (sourceMode, takeover, EDF) et bloque le push ; restauration → 16/16. Le filet fonctionne.

Résumé testé par scénario

profile, sourceMode, state, decision, desiredCharging, currentA, takeoverNeeded, action EDF ON, service helper takeover.

Notes de comportement figées (découvertes en écrivant les attendus)

SOC 20 la nuit avec maison sur batterie (−14 A) → battery_current_hard_stop (bande lt25 : hard −8 A) + demande réseau simultanée. Protection cohérente.
force_charge_now la nuit (toggle HC ON) → start_manual_local_min_current ET takeover helper ON (session nuit active) : EDF peut venir en renfort. Voulu.
Garde SOC>35 midi : sourceMode grid_hc_allowed mais idle_wait_conditions (le grid HC midi ne s'active que SOC ≤ 35) — comportement épinglé par le test.

Prochaines étapes du plan

R2 : git source de vérité (src/nodes/*.js + assemblage dans n8n-push).
Agent IA planificateur en mode ombre (après R2).
Enrichir la suite au fil des incidents : chaque bug corrigé = +1 scénario.

Document mis à jour le : 07/08/2026 (~19:20) — R3 en place, 16/16, push bloquant

14. Session du 07/08/2026 (soir) — P8 : Libération EDF quand le véhicule est plein

Spécification utilisateur

La nuit : charge dès 01:24 (P7) ✓, puis quand la charge est finie → EDF OFF, sauf si la batterie solaire est sous le seuil (alors EDF reste pour la recharger).

Bugs découverts en traçant la spec

Fix 04/08 logiquement inversé : (soc < 90 || vehicleChargeCompleted) GARDAIT le latch takeover après la charge au lieu de le libérer. Jamais corrigé en réalité.
P7 ne relâchait pas : nightGridHcPreferred restait vrai tant que véhicule branché → l'EVCS redemandait EDF ON toutes les 30 s jusqu'à 07:24.
Signal "voiture pleine" instable : le VehicleDemandFilter retombe à false dès que le relais s'ouvre (session désarmée) → impossible de s'appuyer dessus seul.

Solution : mémoire AUTO-ENTRETENUE via l'état surplus (P8)

Chaîne (nouveau champ snapshot prev_surplus_state ← input_text.victron_evcs_surplus_state) :

charge → VDF détecte voiture pleine → state 'vehicle_full_or_paused'
cycle N+1 : WINDOWS voit ce state → vehicleChargeCompleted=true
          → DECISION émet 'night_session_done_idle'
cycles suivants : 'night_session_done_idle' s'auto-entretient
fin : débranchement (state vehicle_not_connected) ou fin de fenêtre 07:24

Effets quand vehicleChargeCompleted :

latch libéré (fix inversion 04/08 : soc < 90 && !completed)
préférence P7 relâchée ; sourceMode nuit → 'blocked' (zéro tentative de charge)
SOC > cible matin : takeover helper OFF → hystérésis coupe EDF (turn_off_recovered)
SOC ≤ cible : takeover helper ON → hystérésis maintient EDF (override) + ACM recharge la batterie à la cible → puis relâche. ⚠️ Le nom 'night_session_done_idle' ne doit matcher AUCUN pattern no-demand de l'hystérésis (full_or_paused / not_requesting_power / charge_complete / no_demand) — c'est ce qui permet à l'override batterie-basse de fonctionner. NE PAS RENOMMER sans vérifier.

Nœuds modifiés (tools/patch-20260807-p8-release-full.mjs, rejouable)

Snapshot template : +prev_surplus_state
WINDOWS_SOURCEV2 : vehicleChargeCompleted collant, latch corrigé, P7 conditionné, preferred 'blocked' si plein, export preview
BATTERY_CLOUD_LOCKS : passthrough du flag dans nightEvcs
DECISION_ENGINEV2 : branche 'night_session_done_idle' (avant sourceMode blocked)

Validation

3 nouveaux scénarios golden (19 au total) : transition vehicle_full→done_idle (takeover turn_off), auto-entretien, batterie basse (takeover turn_on maintenu).
Les 16 scénarios existants inchangés (aucune régression).
Push via pipeline bloquant (golden 19/19), production stable.

Comportement attendu cette nuit (VW branchée, checklist complète)

01:24-01:25 : grid_hc_allowed → EDF ON → charge 6 A puis montée (P7)
VW pleine : vehicle_full_or_paused → night_session_done_idle → takeover OFF → EDF coupé par l'hystérésis ≤ 1 min après (si min_on 25 écoulé et SOC ≥ 30)
Batterie sous cible matin (35 été) : EDF maintenu + recharge ACM jusqu'à cible
07:24 : fin de fenêtre → retour profil jour

15. Session du 07/08/2026 (soir) — R2 : Git = source de vérité du code des nodes

Nouveau layout

src/nodes/ = SOURCE DE VÉRITÉ : INPUT_PARSE.js, WINDOWS_SOURCEV2.js, BATTERY_CLOUD_LOCKS.js, DECISION_ENGINEV2.js, HA_SERVICE_CALLS_OUTPUT.js, BUILD_ACTIONS.js, HA_SNAPSHOT_TEMPLATE.json.tpl.
workflows/evcs-surplus-controller-v2.6.json = artefact déployable, reconstruit automatiquement depuis src/ à chaque push (src GAGNE toujours).
tools/lib-node-map.mjs (cartographie), tools/n8n-extract.mjs (JSON→src, uniquement pour resynchroniser après une édition UI n8n — à éviter), tools/n8n-build.mjs [--check] (src→JSON / vérif synchro).
archive/ : toutes les copies historiques (decoupesurplus/, WINDOWS/, BATTERY/, DECISION/, HYSTERESIS/, EVCSV2.2.json, surplus.js...) — copies mortes, dérivées.
.gitignore : backup-workflow-.json + modified/prepush-.json (rollbacks locaux).

WORKFLOW DE MODIFICATION DÉSORMAIS (règle inscrite dans AGENTS.md)

éditer src/nodes/<NODE>.js
node tools/n8n-push.mjs workflows/evcs-surplus-controller-v2.6.json
   → build src→JSON → node --check → GOLDEN 19/19 (bloquant) → backup serveur → PUT
git commit (src + json + scénarios si évolution voulue) && git push

JAMAIS d'édition directe du JSON ou de l'UI n8n (écrasée au prochain push).

Validations effectuées

Extract/build idempotents (extract → build → --check : zéro diff).
Test mutation : édition src → build injecte 1 node → restauration git+extract OK.
Pipeline complet de push exécuté en réel : build (no-op) → golden 19/19 → PUT OK.
Nota : tailles ls ≠ longueur de code (octets UTF-8 vs caractères, accents FR).

Plan de maintenabilité : état

R1 ✅ déduplication moteur nuit (07/08)
R3 ✅ suite golden 19 scénarios bloquante (07/08)
R2 ✅ git source de vérité + build/push (07/08)
Suivant : agent IA planificateur en MODE OMBRE (jamais dans la boucle 30 s) — helpers advisor_*, validation bornée des sorties, kill-switch, cf. HANDOFF §13/§14.

16. Session du 07/08/2026 (nuit) — Agent IA planificateur en MODE OMBRE

Ce qui tourne désormais

Workflow n8n "EVCS Advisor Shadow V1" (id tdfInZns7cqo8fU2, actif, 15 min) :

Schedule 15min → HA Snapshot compact (template Jinja {{ {...} | tojson }})
→ BUILD_PROMPT (kill-switch input_boolean.evcs_advisor_enabled, prompt FR ~4K chars)
→ IF_ENABLED → LLM_LOCAL_MODELS (GET 10.10.10.8:8000/v1/models, 5s)
→ LLM_LOCAL (modèle DYNAMIQUE = celui chargé sur la Spark, max_tokens 6000)
→ IF_LOCAL_OK → sinon LLM_CLOUD (OpenRouter anthropic/claude-haiku-4.5,
  credential chiffré "OpenRouter Advisor" id eOM9xofDHT0KMoeY — clé JAMAIS dans git)
→ VALIDATE_PARSE (strip <think>, JSON strict, enums+bornes, invalide = REJET)
→ BUILD_HA_CALLS (helpers advisor_* + divergence + compteurs + logbook)
→ Execute HA Service

GARANTIE MODE OMBRE (structurelle, testée)

BUILD_HA_CALLS n'écrit QUE vers input_text/input_number.evcs_advisor_* et logbook. Le test tests/advisor/run.mjs ÉCHOUE si une écriture sort de ce périmètre (16 tests : kill-switch, réponses valides/hors-bornes/non-JSON/ /offline, périmètre ombre, compteurs accord/divergence). Suite intégrée au push : n8n-push.mjs workflows/evcs-advisor-shadow-v1.json.

Helpers HA (package NFS /mnt/ARCH3/docker/HA/packages/evcs_advisor_shadow.yaml)

evcs_advisor_enabled (kill-switch) · advisor_strategy · advisor_night_target_soc (22-90) · advisor_current_max_a (6-28) · advisor_ev_charge_tonight · advisor_reason · advisor_status (ok/invalid/llm_offline) · advisor_divergence · advisor_last_run · advisor_model · advisor_agree_count / advisor_diverge_count. Carte dashboard « 🤖 Conseiller IA (ombre) » ajoutée à evcs_master.yaml (backup dans SAVE/).

Première recommandation réelle (07/08 22:40, via qwen3-vl local)

auto_solar_plus | cible 35% | charge VE cette nuit: oui | confiance 90% | « Prévision solaire forte (40.7 kWh), cible SOC matin basse adaptée. Véhicule chargé en HC avec réseau EDF. » → accord avec le réel (et avec P7/P8 !).

Pièges rencontrés (pour mémoire)

Template /api/template DOIT être du Jinja : {{ { ... } | tojson }} — sans wrapper, HA renvoie le texte brut non rendu.
Modèle local = qwen3-vl Thinking : max_tokens 2500 → JSON tronqué par le raisonnement → rejeté proprement (invalid: JSON non terminé). Fix : 6000. (La validation stricte a fait exactement son travail dès le 1er run réel.)
MCP activate_workflow → erreur 415 : activer via REST POST .../activate body {}.
n8n-push : le fallback d'id par défaut (EVCS) était DANGEREUX avec un 2e workflow → supprimé, l'id vient du champ id du JSON ou de l'argument.

Outillage multi-workflows (extension R2)

lib-node-map.mjs : WORKFLOWS[] (evcs + advisor) · build/extract/push acceptent un fichier cible · n8n-create.mjs (POST création) · gen-advisor-workflow.mjs (squelette advisor rejouable, credentials/ids inclus).

Note LLM local (analyse du 07/08, décision : statu quo surveillé)

qwen3-vl-Thinking "fait le job" mais est sous-optimal pour l'advisor : variante Thinking (raisonnement non désactivable, 40-60 s/run, risque marginal de JSON tronqué — rejeté proprement par la validation). Le bon modèle local est qwen3.6-35b quand il est chargé (use-code). Option prête si les compteurs se dégradent (décision utilisateur : ne rien changer pour l'instant) : routage intelligent = 1 IF après LLM_LOCAL_MODELS (local seulement si l'id du modèle chargé n'est pas vl/thinking, sinon cloud direct) + éventuellement cloud moins cher (gemini-2.5-flash-lite ~1€/mois vs haiku-4.5 ~9€/mois plein temps). Implémentation ~30 min, tests advisor inchangés.

Phase 3 — critères de bascule (dans 2-3 semaines d'observation)

Taux d'accord stratégie ≥ 80% (compteurs agree/diverge sur la carte) ;
Zéro sortie invalide NON rejetée (advisor_status) ;
Divergences analysées = soit l'agent a raison (améliorer les règles), soit il a tort (améliorer le prompt) — les deux font progresser le système. → Alors premier câblage réel LIMITÉ : night_target_soc uniquement, derrière un nouveau toggle advisor_apply_night_target, le reste inchangé.

17. Session du 08/08/2026 — Incident rebond EDF nuit 07-08/08 : fixes A/B/C/D

Incident (captures HA analysées, faits dans docs/vision-notes.md)

P7 a chargé la VW dès 01:24 ✓ (session 1h32m). Ensuite :

Fin de charge détectée très tardivement (~04:15 au lieu de ~02:56) ;
Rebond EDF ON/OFF période ~10 min autour de SOC=35 (= cible matin) + flapping ACM Charging/passthru 2-4 s (03:58→04:16) ;
Débranchement VW (04:17) → takeover bien relâché mais EDF maintenu (hold_on_min_runtime 25 min) → arrêt manuel utilisateur 04:25 (stopped_user).

Root causes

A — point dégénéré SOC==cible (WINDOWS_SOURCEV2) : engage takeover soc <= cible, release soc > cible, recovery ACM soc < cible (strict), et l'ACM recharge PILE à la cible → aucune position stable, oscillation.
B — snapshot incomplet : evcs_night_session_start_soc/_at jamais relus (absents du template) → nightSessionNeedsCapture vrai à CHAQUE cycle → "Night Session Start At" réécrit toutes les 30 s toute la nuit (visible logs), budget décharge nuit faussé (start SOC glissant).
C — hystérésis grid : pas de coupure anticipée au débranchement (min_on 25 min s'applique même véhicule parti et SOC ≥ seuil OFF).
D — détection fin de charge fragile : VDF armé uniquement session pleinement active ; stop par garde (ex battery_current_hard_stop) → filtre désarmé → 'vehicle_full_or_paused' inatteignable pendant longtemps.

Fixes déployés (production 08/08 ~14:00, golden 23/23)

Fix A (WINDOWS_SOURCEV2 + BCL passthrough + DECISION) : nouvel état auto-entretenu night_recovery_done_idle émis quand vehicleChargeCompleted && SOC ≥ cible. Takeover relâché DÉFINITIVEMENT ; ré-engagement uniquement si SOC ≤ cible − 2 (bande NIGHT_RECOVERY_REARM_BAND_PCT). ⚠ Le nom ne matche aucun pattern no-demand de l'hystérésis (comme done_idle). Structure takeover : completed ? !nightRecoveryDone : (trigger || urgent || latch).
Fix B (HA_SNAPSHOT_TEMPLATE) : +evcs_night_session_start_soc, +evcs_night_session_start_at (helpers input_text existants, vérifiés via MCP).
Fix C (workflow hystérésis 7iIlu7LLTW7TZA8o, patch tools/patch-20260808-c-unplug-cut.mjs rejouable) : nouvel état turn_off_vehicle_unplugged = véhicule débranché (es=vehicle_not_connected)
- latch ON + grid ON + pas d'override + SOC ≥ seuil OFF → coupure immédiate (bypass min_on) + notification. Dry-run 4 cas validé (incident/SOC bas/ takeover ON/recovery_done) AVANT push. Le fichier local du workflow est désormais suivi : workflows/victron-grid-hysteresis-v1.json.
Fix D (WINDOWS_SOURCEV2) : evcs_status_raw == 3 (Victron "charged") vaut fin de charge immédiate, sans attendre le VDF.

Golden : 19 → 23 scénarios

2 attendus mis à jour (transition/auto-entretien : SOC ≥ cible → état night_recovery_done_idle désormais) ;
4 nouveaux : night-recovery-atteinte-soc-cible (LE cas du rebond), night-recovery-done-bande-collante (34 % dans la bande), night-recovery-rearm-sous-bande (32 % → ré-engagement), night-vw-statut-charged (Fix D).
Piège outillage : tests/golden/run.mjs exécute le JSON BUILDÉ (workflows/*.json), pas src/ → toujours node tools/n8n-build.mjs avant un run golden manuel (n8n-push le fait automatiquement).

Documentation

MANUEL_COMPLET.md §11.6 : GRAFCET complet du cycle nuit (G1 EVCS / G2 hystérésis) + états surplus fin de nuit + résumé incident.
docs/vision-notes.md : OCR/faits des 9 captures de l'incident.

À surveiller (prochaine nuit HC, VW branchée)

Fin de charge : passage à vehicle_full_or_paused OU night_recovery_done_idle rapide (Fix D si la VW publie le statut 3) ;
SOC à la cible → UNE coupure EDF, puis plus aucun ON/OFF (sauf SOC ≤ cible−2) ;
"Night Session Start At" écrit UNE fois en début de session (Fix B) ;
Débranchement → EDF OFF ≤ 1 min (turn_off_vehicle_unplugged, Fix C).

Document mis à jour le : 08/08/2026 (~14:15) — fixes A/B/C/D déployés, golden 23/23

18. Session du 09/08/2026 — Incident nuit 08-09/08 : le rebond est revenu par un AUTRE chemin (Fix E)

Incident (captures HA, VW branchée, HC, VW pleine vers ~03:00)

Fix A/D du 08/08 ont bien fonctionné CÔTÉ WINDOWS (status 3 → completed → takeover Désactivé, source blocked). MAIS l'état EVCS observé était hold_min_run_source_lost / stop_source_lost — jamais night_recovery_done_idle. Cycles ~30 min de 03:00 à 05:40 : EDF ON (2531 W réseau, SOC 51 % > cible 35) → arrêt urgence utilisateur 05:43 (EDF URGENCE OFF + stratégie stop) → débranchement.

Root cause (ordre des branches DECISION)

Status 3 arrive PENDANT la session armée (relais fermé, chg=1/perm=1/l=1).
WINDOWS → sourceMode 'blocked' (Fix D) ; mais dans DECISION la branche session ACTIVE traite 'blocked' comme « source perdue » : hold_min_run_source_lost (25 min de session zombie !) puis stop_source_lost. La branche P8 (état collant) est dans la chaîne NON-active → jamais atteinte.
Au stop, le relais s'ouvre → le statut EVCS RETOMBE (3 → 1/6, même piège que le VDF documenté en P8) → completed=false → re-P7 → takeover ON 1 cycle → edf_general_ok_on rallume EDF + restart → status 3 → goto 2. Rebond ~30 min.
L'hystérésis adoptait l'EDF ON du cycle de flap puis hold_on_min_runtime 25 min (ov=0/eg=0 ensuite, mais latch pris) → EDF ON quasi permanent.

Fix E (déployé 09/08 ~06:25, golden 25/25)

DECISION : nouvelle PREMIÈRE branche du bloc session-active (avant VDF) : night_hc && vehicleChargeCompleted && !force* → setOff immédiat avec l'état collant (night_recovery_done_idle si SOC ≥ cible, sinon night_session_done_idle), decision stop_vehicle_full_or_paused. → l'état collant est écrit AU PREMIER cycle où status=3, relais encore fermé ; les retombées de statut ensuite sont sans effet (prev state dans la liste).
WINDOWS : garde puissance sur Fix D (status==3 && evcsAcPowerW <= 300 W) pour ne jamais latcher sur un glitch en pleine charge.
Hystérésis (patch tools/patch-20260809-e2-recovery-done-cut.mjs) : turn_off_recovery_done = es=night_recovery_done_idle + pas d'override + SOC ≥ seuil OFF → coupure EDF immédiate (bypass min_on 25). Sûr car l'état est collant (le takeover ne peut pas revenir, sauf SOC ≤ cible−2 → override). Dry-run 5 cas validé avant push.

Golden : 23 → 25

night-charged-en-session-active : status 3 en session ARMÉE → arrêt propre
- latch immédiat (LE chemin de l'incident) ;
night-flap-statut-apres-latch : relais ouvert, statut retombé à 1, prev=night_recovery_done_idle → collant, aucun re-P7/EDF.

Comportement attendu au REBRANCHEMENT d'une VW pleine en HC

Session nuit → P7 → EDF ON → tentative de charge (inévitable : le système ne peut pas savoir que la VW est pleine sans fermer le relais) ;
VW refuse (0 W, status 3) → ≤ 1 min : night_recovery_done_idle collant, takeover OFF, session stoppée proprement ;
Hystérésis : turn_off_recovery_done → EDF OFF ≤ 1 min (plus de min_on 25) ;
Plus RIEN jusqu'au débranchement / fin de fenêtre (flaps de statut ignorés). Total attendu : EDF ON ~2-3 min UNE seule fois, puis silence.

Document mis à jour le : 09/08/2026 (~06:35) — Fix E déployé (EVCS + hystérésis), golden 25/25

19. Session du 09/08/2026 (suite) — Fix F : la mémoire "charge terminée" est prioritaire sur les gardes

Test de rebranchement utilisateur (~06:33, VW rebranchée en HC)

✅ Fix E validé en réel : 06:51:00 night_recovery_done_idle latché, 06:51:03 turn_off_recovery_done → EDF coupé immédiatement (bypass min_on).
❌ 06:53-06:56 : la VW a relancé une charge (status 2) qui, EDF OFF, tirait sur la batterie (−47 A) → garde mustStopHard → état battery_current_hard_stop ÉCRIT PAR-DESSUS le collant dans le helper → completed perdu → re-P7 → EDF rallumé (hold_on_evcs_override, re-min_on 25). → Le collant ne survivait à AUCUN état émis par une branche plus prioritaire.

Fix F (déployé 09/08 ~07:00, golden 26/26)

DECISION : nouvelle branche dans la cascade PRINCIPALE, entre vehicle_not_connected et mustStopHard : night_hc && vehicleChargeCompleted && !force* → setOff avec l'état collant (recovery_done/done_idle), mustStop si la borne est encore armée. → l'état collant est réécrit à CHAQUE cycle tant que VW branchée + fenêtre, il survit aux micro-charges/gardes. Aucune perte de protection (le setOff coupe chg/perm/latch comme un hard stop).
La branche Fix E interne (session active) supprimée : remplacée par la branche haute. La branche P8 historique (chaîne non-active) reste en filet.
Golden 26 : night-hard-stop-necrase-pas-done (micro-charge −60 A sur batterie avec prev=recovery_done → l'état reste recovery_done, stop ferme).

Leçon d'architecture (pour le futur)

La "mémoire" portée par input_text.victron_evcs_surplus_state est fragile : tout état émis l'écrase. Fix F la protège en réécrivant chaque cycle, mais la solution PROPRE à terme est un helper dédié (input_boolean victron_evcs_night_charge_done, package YAML + reload HA) si un nouveau cas d'écrasement apparaît.

Relecture de la nuit 08-09/08 (après coup)

La VW n'a pris que 5 kWh cette nuit, morcelés par les stops zombies (§18) : elle n'était probablement PAS pleine. Les "micro-charges" du matin étaient de vraies reprises. À 07:00 (post-Fix F) : charging_step_up_grid_hc = charge HC nominale jusqu'à la fin de fenêtre 07:24. Le collant ne se posera que sur un VRAI signal de fin (VDF no-demand ou status 3) — et tiendra désormais.

Document mis à jour le : 09/08/2026 (~07:05) — Fix F déployé, golden 26/26

20. Session du 09/08/2026 — PREMIER CÂBLAGE RÉEL de l'advisor : cible SOC matin

Décision utilisateur

Météo Bretagne au beau fixe (47-58 kWh/j prévus) = conditions idéales pour tester le câblage avec risque minimal. Périmètre STRICTEMENT limité au plan §16 : night_target_soc uniquement, derrière un toggle, rollback 1 clic.

Ce qui est câblé

batteryMorningTargetPct (WINDOWS_SOURCEV2) suit input_number.evcs_advisor_night_target_soc SI ET SEULEMENT SI :

input_boolean.evcs_advisor_apply_night_target = ON (nouveau toggle, initial OFF, package evcs_advisor_shadow.yaml + carte dashboard) ;
input_text.evcs_advisor_status = 'ok' (exact) ;
recommandation fraîche ≤ 120 min (parse DD/MM HH:mm de advisor_last_run, année courante, garde passage d'année — parseAdvisorRunToMs INPUT_PARSE) ;
valeur clampée [max(22, hard floor), 90]. Sinon → règles forecast historiques (batteryMorningTargetRulePct), aucun changement de comportement. Le toggle OFF = état d'origine.

Chaîne technique

Snapshot : +advisor_apply_night_target, +advisor_night_target_soc, +advisor_status, +advisor_last_run (states() d'une entité absente → 'unknown' → toggle vu OFF → sûr AVANT le reload HA).
INPUT_PARSE : params.advisorApplyNightTarget / advisorNightTargetSocPct / advisorStatusOk / advisorLastRunMs.
WINDOWS : override borné + export advisorNightTargetApplied + batteryMorningTargetRulePct (preview) ; BCL passthrough ; DECISION : la reason affiche target=X% (ADVISOR) quand appliqué → visible logbook/carte.
Impact aval automatique : gridTakeoverTriggerPct, grid_forced vs hc_allowed, recovery post-charge, bande anti-rebond — tous dérivés de la cible.

Golden 26 → 29

night-advisor-target-applique : SOC 30, advisor 22 ON/ok/frais → grid_hc_allowed (au lieu de grid_forced par la règle 35) ;
night-advisor-target-stale : > 120 min → fallback règles (grid_forced) ;
night-advisor-toggle-off : toggle OFF → règles inchangées.

Sécurités NON modifiées

Hard floor 22 %, hysteresis grid ON ≤ 20 %, recovery urgent départ, latch anti-créneaux, collant fin de charge (Fix A/E2/F). L'advisor ne peut RIEN piloter d'autre (VALIDATE_PARSE borne night_target_soc 22-90 côté advisor, clamp identique côté contrôleur).

Rollback (3 niveaux)

Toggle « APPLIQUER cible SOC matin » OFF → effet au cycle suivant (30 s) ;
Kill-switch advisor OFF → plus de runs → fraîcheur > 120 min → fallback auto en ≤ 2 h même si le toggle reste ON ;
git revert du commit + node tools/n8n-push.mjs workflows/evcs-surplus-controller-v2.6.json.

Surveillance (2-3 nuits)

Carte Conseiller IA : « Cible SOC matin (agent) » vs « (réel) » doivent converger quand le toggle est ON ;
Logbook « Victron EVCS - Reason » la nuit : target=X% (ADVISOR) ;
Le matin : SOC batterie au lever du soleil ≈ cible advisor, remontée solaire OK ;
Si SOC matin < 22 % ou EDF nuit anormal → toggle OFF + capture + analyse.

Action utilisateur requise après ce déploiement

Recharger HA pour créer le toggle : Outils développeur → YAML → « ENTRÉES BOOLÉENNES (input_boolean) » Recharger (ou redémarrage HA), puis activer le toggle sur la carte Conseiller IA (dashboard EVCS Master rechargé).

Document mis à jour le : 09/08/2026 (~07:35) — câblage advisor night_target déployé (toggle OFF par défaut), golden 29/29

21. Session du 09/08/2026 — P9 : charge réseau avant départ + sélecteur véhicule VW/JEEP

Contexte clarifié par l'utilisateur (IMPORTANT pour comprendre les incidents)

DEUX véhicules alternent sur la borne :

VW (hybride) : départ ~08:50, ne publie PAS franchement "charged" (statut 3 rare/fugace) → détection fin de charge = VDF surtout ;
JEEP : départ ~06:30, publie "charged" franchement. Relecture des incidents : nuit 08-09/08 = JEEP (rebonds §18) ; matin 09/08 = VW déjà pleine (chargée la veille en solaire) rebranchée à la place de la JEEP. L'heure de départ unique (08:50) était un réglage VW ; la JEEP part à 06:30 (dans la fenêtre HC → couverte par la mécanique nuit existante).

Nouveaux helpers (package /mnt/ARCH3/docker/HA/packages/victron_evcs_vehicles.yaml)

input_select.victron_evcs_vehicle (VW/JEEP, défaut VW) — à sélectionner au branchement. NB : l'ancien input_select.victron_evcs_target_vehicle (None/Jeep/Zero, créé UI) n'était câblé nulle part → retiré de la carte, remplacé par le nouveau. À supprimer un jour via l'UI.
input_datetime.victron_evcs_departure_time_jeep (06:30). L'existant victron_evcs_departure_time (08:50) devient l'heure VW.
input_boolean.victron_evcs_allow_grid_departure_urgent (toggle P9, OFF). Carte "Paramètres utilisateur" (evcs_master.yaml) mise à jour. ⚠ RELOAD HA requis (input_boolean + input_datetime + input_select).

P9 (golden 33/33, déployé 09/08 ~08:27)

INPUT_PARSE : departureTimeMin suit le véhicule sélectionné (JEEP → departure_time_jeep, fallback VW) ; impacte aussi departurePriorityActive et batteryRecoveryUrgent nuit (donc la JEEP à 06:30 est mieux servie).
WINDOWS : fenêtre departureWindowActive = toggle ON + véhicule branché + HORS fenêtre HC + départ dans ≤ 120 min. Si charge non terminée → departureUrgentActive → sourceMode grid_hc_allowed (prend le pas sur blocked/solar_potential/hybrid_probe, JAMAIS sur solar_only ni stop/force*). Fin de charge (VDF vehicle_full_or_paused relu, ou statut 3) → departureChargeDone → sourceMode blocked + état collant.
BCL : gridAllowedBySoc inclut departureUrgentActive (sinon SOC>35 bloquait).
DECISION : branche collante departure_done_idle (même principe que Fix F, au-dessus des gardes, mustStop si borne armée).
HA_SERVICE_CALLS : helper takeover tenu ON pendant departureUrgentActive (override hystérésis + maintien batterie ACM pendant la charge pré-départ).
Hystérésis (patch tools/patch-20260809-p9-departure-cut.mjs) : coupure immédiate E2 étendue à departure_done_idle.

Golden 29 → 33

p9-depart-vw-grid (fenêtre active, SOC 45 > 35 → réseau quand même) · p9-depart-jeep-passe (sélecteur : départ JEEP passé → rien) · p9-done-idle-collant · p9-toggle-off (comportement historique).

Mode d'emploi utilisateur

Recharger HA (YAML : input_boolean, input_datetime, input_select) ;
Sur la carte : sélectionner le véhicule au branchement (VW ou JEEP) ;
Activer « ⚡ Réseau avant départ (P9) » ;
La JEEP profite de sa vraie heure 06:30 dès cette nuit (recovery urgent nuit) ; la VW aura sa fenêtre 06:50-08:50 hors HC si sous-chargée. Rollback : toggle P9 OFF (30 s) ; sélecteur sans effet si P9 OFF (sauf heure de départ pour la priorité/urgence nuit — voulu).

Document mis à jour le : 09/08/2026 (~08:35) — P9 + sélecteur véhicule déployés, golden 33/33

22. Session du 09/08/2026 — P10 : mémoire "véhicule plein" en journée

Incident (captures utilisateur 09:49-09:57)

VW pleine rebranchée ~07:00. À 09:49, PV fort (5,5 kW) → le surplus solaire lance une tentative (morning_solar, solar_only) : 6 A commandés, 0 W pris, VRM affiche "Charged". Sans mémoire jour, le cycle se répète toutes les ~15 min TOUTE la journée (VDF stop → block → re-start). Zéro coût énergie (solaire, EDF OFF) mais usure relais borne/VW + bruit. Les états collants P8/P9 étaient scopés nuit / fenêtre départ.

Fix P10 (déployé 09/08 10:04, golden 36/36, validé live à 10:04:30)

WINDOWS : dayVehicleFullIdle collant = véhicule branché + hors fenêtre HC
- (prev ∈ {day_vehicle_full_idle, vehicle_full_or_paused, night_recovery_done_idle, night_session_done_idle, departure_done_idle} OU statut 3 ≤ 300 W). sourceMode → 'blocked' (y compris face à solar_only : charger un véhicule plein ne sert à rien).
HÉRITAGES bidirectionnels : le jour hérite des états done de la nuit (07:24 → aucune re-tentative matinale) ; la nuit hérite du jour (vehicleChargeCompleted inclut day_vehicle_full_idle → pas de tentative 01:24 si resté branché plein).
DECISION : branche collante 'day_vehicle_full_idle' au-dessus des gardes (principe Fix F), stop propre si session armée.
Libération : DÉBRANCHEMENT (vehicle_not_connected) — ou échappatoires force_charge_now / force_grid_now (testé golden).
Hystérésis : nom sans pattern no-demand ✓, aucun changement nécessaire (EDF pas impliqué dans ce chemin).

Golden 33 → 36

day-vw-pleine-statut3 (session armée 0 W statut 3 → collant) · day-full-heritage-nuit (prev=night_recovery_done_idle → pas de solaire) · day-full-echappatoire-force-charge (force_charge_now relance).

Validation live

10:04:14 PUT → 10:04:30 : day_vehicle_full_idle latché sur la VW pleine en cours de tentative ; statut retombé à 6 (relais ouvert) sans relance.

Cycle de vie complet d'un véhicule branché (résumé)

branché → tentatives légitimes (nuit P7 / jour solaire / P9 départ)
        → plein détecté (statut 3 ou VDF)
        → collant : night_*_done_idle / departure_done_idle / day_vehicle_full_idle
          (héritages entre périodes, réécrit chaque cycle au-dessus des gardes)
        → DÉBRANCHEMENT = seule remise à zéro (+ force_* en échappatoire)

Document mis à jour le : 09/08/2026 (~10:10) — P10 déployé et validé live, golden 36/36

23. Session du 12/08/2026 — P11 : reset du collant au changement de véhicule

Incident (nuit 12/08, captures utilisateur)

JEEP branchée 01:24, chargée en HC (cible 35% ADVISOR), fin de charge franche → état collant night_recovery_done_idle. Utilisateur débranche la JEEP et branche la VW à sa place. L'état collant a SURVÉCU (le collant n'était remis à zéro que par vehicle_not_connected, non vu de façon franche lors du swap) → la VW était bloquée « charge véhicule terminée » alors que c'était celle de la JEEP. La VW (déchargée) ne chargeait pas.

Cause de conception

Tous les états collants "plein" (P8 night_, P9 departure_, P10 day_*) se libéraient UNIQUEMENT au débranchement (vehicle_not_connected). Un remplacement de véhicule rapide (ou un statut EVCS qui ne repasse pas franchement "déconnecté") laissait le collant en place → nouveau véhicule bloqué.

Fix P11 (déployé 12/08 05:00, golden 39/39, validé live à 05:00:30)

Signal fiable : sensor.victron_evcs_charging_time repart de 0 à CHAQUE nouvelle connexion physique.

Snapshot : +evcs_charging_time ; INPUT_PARSE : parseChargingTimeToSec ("1h 49m 53s"/"8m 27s"/"0s" → secondes), parsed.evcsChargingTimeSec.
WINDOWS : sessionFresh = véhicule branché ET charging_time ≤ 90 s. Neutralise vehicleChargeCompleted, dayVehicleFullIdle, departureChargeDone ET evcsStatusCharged (statut 3 résiduel ignoré le temps que la borne renégocie) → le système RETESTE le véhicule neuf.
Export sessionFresh (traçabilité).

Golden 36 → 39

p11-changement-vehicule-nuit (prev=night_recovery_done_idle + charging_time 15s → night_wait_grid_takeover, retest) · p11-changement-vehicule-jour (day_vehicle_full_idle + 20s → solaire repart) · p11-session-etablie-reste-collant (charging_time 2h05 → reste collant, pas de reset abusif).

Validation live

05:00:00 PUT → 05:00:30 : la VW est passée de night_recovery_done_idle (bloqué) à night_wait_grid_takeover / source « Réseau HC autorisé ».

Récapitulatif des remises à zéro du collant "plein"

DÉBRANCHEMENT (vehicle_not_connected) ;
CHANGEMENT DE VÉHICULE / nouvelle connexion (charging_time ≤ 90 s, P11) ;
force_charge_now / force_grid_now (échappatoires manuelles).

26. Session du 27/08/2026 — L'oscillateur du takeover nuit, et deux acteurs non lus

L'oscillateur (corrigé, golden 40 → 42, déployé 08:32)

Nuit du 26-27/08, Jeep pleine restée branchée, aucun besoin de charge : trois sessions EDF (04:24→05:16, 05:31→06:50, 07:05→07:30), 2,5 kWh importés un matin annoncé à 43 kWh de solaire. La nuit du 20-21/08 en comptait six. Le helper night_grid_takeover_needed précède chaque bascule du contacteur de 3 s : la cause est entièrement dans le moteur de nuit EVCS, pas dans l'hystérésis (grid_soc_on/grid_soc_off valent toujours 20/30, jamais approchés).

Cause, dans WINDOWS_SOURCEV2.js :

gridTakeoverTriggerPct = max(plancher 22, cible 35) = 35   → engage si SOC <= 35
nightRecoveryDone      : SOC >= 35                          → relâche
NIGHT_RECOVERY_REARM_BAND_PCT = 2                           → réengage à 33

Engagement et relâchement sur le même nombre, la bande de 2 points du Fix A ne faisant que retarder le réarmement. Or 2 points de SOC ≈ 0,34 kWh ≈ 31 min à la charge nocturne (~650 W, parfaitement plate) : ce n'est pas une hystérésis, c'est la période d'une horloge. C'est le propriétaire qui a mis le doigt dessus en observant que le phénomène était « super stable car pas de variation de consommation » — la platitude de la charge est ce qui rend le cycle régulier.

Correctif : la recovery batterie post-charge est UNE SEULE passe par session de nuit (nightRecoveryDone = ... || nightRecoveryDonePrev, sans bande). C'était déjà l'intention affichée du Fix A (« relâché DÉFINITIVEMENT »). Aucun seuil de ré-engagement n'est ajouté : batteryBelowHardFloor reste un terme indépendant de nightGridTakeoverNeeded, et l'hystérésis garde sa bande 20/30. Le vrai critère de ré-engagement est un budget d'énergie restant à couvrir — il appartient au bilan énergétique, pas à une constante de plus ici.

Golden : night-recovery-rearm-sous-bande (qui épinglait l'oscillateur) devient night-recovery-done-pas-de-reengagement ; +night-oscillateur-nuit-2627 (le relevé exact de la nuit) ; +night-recovery-done-plancher-dur (le filet de sécurité doit rester : SOC 21 → ré-engagement). Preuve par mutation : bande restaurée → échec du nouveau scénario ; retirée → 42/42.

D'où venait le 35 %, et pourquoi ce n'est pas une réserve

batteryMorningTargetPct vient des règles de prévision (≥ 18 kWh → 35 %, ≥ 10 → 55 %, sinon 85 %). C'est une optimisation économique — « demain il fera beau, la batterie peut descendre » — et non une réserve de sécurité, ce que le propriétaire croyait. Point de conception qui en découle : une réserve contre la perte du réseau ne peut pas être constituée avec le réseau ; elle se charge sur le solaire et se décide le soir. Voir §27 (à écrire) pour la réserve d'orage.

Acteur non lu n°1 — les charges programmées de l'ESS (IMPORTANT)

Le GX a trois fenêtres de charge réseau programmées, actives tous les jours, que rien dans nos workflows ne lit :

#	Départ	Durée	Cible SOC	Actif
0	01:35	365 min (→ 07:40)	45 %	on
1	07:30	298 min (→ 12:28)	45 %	on
2	12:24	120 min (→ 14:24)	55 %	on
3	14:24	120 min	85 %	off
4	23:08	60 min	50 %	off

Entités : switch.gx_device_ess_batterylife_schedule_charge_N_enabled, time..._start, number..._duration, number..._soc. sensor.gx_device_ess_batterylife_state = self_consumption hors réseau. Le GX veut donc 45 % la nuit quand EDF est présent, quand notre cible dit 35 % : deux automates avec deux consignes différentes sur la même batterie.

Origine (donnée par le propriétaire) et décision du 27/08 : ces trois fenêtres étaient un contournement manuel, posé d'abord quand le système n'arrivait plus à tenir un seuil de 20 %, puis réutilisé l'hiver pour garantir un minimum de charge en heures creuses et éviter de rallumer EDF en heures pleines. Inutiles l'été. Les cinq programmations sont désormais désactivées (vérifié : ..._charge_0..4_enabled = off). Le contrôleur EVCS est le seul propriétaire de la décision réseau.

⚠️ Le besoin qu'elles couvraient l'hiver reste entier. Il doit être repris par le bilan énergétique, pas par une reprogrammation manuelle — voir la règle saisonnière ci-dessous.

Règle saisonnière de la cible du matin (propriétaire, 27/08)

« 20 % ou 35 % minimum c'est bien l'été mais l'hiver c'est idiot, ça va plutôt être 80 % le matin ». Le raisonnement est en heure solaire : en été 9 h locales valent 7 h TU, en hiver 10 h locales valent 9 h TU, soit ~2 h de consommation supplémentaires à tenir sur batterie avant le relais du solaire, et une montée hivernale plus lente et plus basse.

Conséquence : la cible du matin ne doit être ni une constante ni un choix entre trois paliers. Elle se déduit de l'heure réelle du croisement production/consommation du lendemain et de l'énergie à couvrir d'ici là — ce que le bilan sait déjà calculer. C'est le chantier qui remplace à la fois les paliers 35/55/85 et les charges programmées de l'ESS.

Acteur non lu n°2 — l'export d'excédent PV

switch.gx_device_dc_coupled_pv_feed_in_excess = off · switch.gx_device_ac_coupled_pv_feed_in_excess = off · ess_max_feed_in_power = −1. Cohérent avec « sans injection », à confirmer comme voulu.

Ce qui n'est PAS démontré : le bridage du MPPT par la présence d'EDF

Tentative de preuve sur la seule fenêtre EDF-ON diurne conservée en base (21/08, 07:24→08:07) : PV moyenne 91 W (max 218) contre 907 W (max 1464) sur les 43 min suivantes, EDF coupé, à consommation identique (668 vs 637 W). Écart spectaculaire — mais l'enveloppe solaire passe elle-même de 0,17 kWh à 07 h à 1,03 kWh à 08 h, soit un facteur 6 qui explique l'essentiel. La mesure est donc confondue par le lever du soleil et ne prouve rien. Ne pas décider d'une mise à jour firmware sur cette base. Test propre à faire : fermer EDF 10 min en milieu de journée, batterie non pleine, et comparer.

Test contrôlé EDF↔MPPT du 27/08 10:47-10:56 (relevé : `docs/mesures/20260827-test-edf-mppt.log`)

Protocole : 2 min de référence, hystérésis désactivée, contacteur EDF fermé 5 min, puis restauration complète (EDF ouvert, latch remis à zéro, hystérésis réactivée) et 2 min d'observation. Échantillon toutes les 15 s de PV, courant batterie, conso, import réseau, limite DVCC et mode ACM. Conditions : SOC 71 %, batterie absorbant +129 A, DVCC 130 A — donc MPPT avec un preneur.

Ce que le test établit :

La limite DVCC est restée à 130 A d'un bout à l'autre et le mode ACM à day_pv_boost. Le bridage éventuel ne vient donc PAS de l'Auto Charge Manager — hypothèse écartée.
Aucun bridage du MPPT observé dans ces conditions : PV moyenne 3260 W pendant la fenêtre EDF ON contre 2568 W après la coupure. Le solaire déclinait de lui-même (la référence est passée de 7708 à 4460 W en 105 s AVANT toute action — passage nuageux). La comparaison avant/pendant est donc inexploitable ; seule pendant/après l'est, et elle ne montre pas de bridage.
Découverte non cherchée, celle-là sans ambiguïté : EDF fermé fait importer du réseau pour charger la batterie, en rampe continue 0 → 983 → 2139 → 3335 → 4113 W en 3 min 30, alors que la consommation maison n'était que de ~880 W. Preuve directe : à la coupure, le courant batterie s'effondre de 104,6 A à 25,7 A en 15 s — ~80 A (≈ 4 kW) venaient donc du réseau, pas du soleil. Les cinq programmations ESS étaient déjà désactivées depuis ~10 min : ce n'est pas elles. Le propriétaire de cet ordre reste à identifier (minimum SOC de l'ESS n'est pas exposé côté HA).

Ce que le test N'établit PAS. Le propriétaire dispose de plusieurs mois d'observation concordante d'un bridage du MPPT par la présence d'EDF. Ce test ne le contredit pas : il ne reproduit pas sa condition. Avec la batterie à 71-75 % absorbant 130 A, le MPPT a toujours eu un preneur, donc rien ne pouvait le censurer — c'est exactement l'équation de censure PV_mesurée = min(ressource, conso + absorption batterie). Le cas à tester est batterie pleine ou quasi pleine (SOC ≥ 90 %) avec EDF fermé : là, le réseau sert les charges, la batterie ne peut plus absorber, et la PV n'a plus aucun débouché. Test à refaire dans ces conditions, 3 min suffisent.

Conséquence immédiate, indépendante de la question du bridage : chaque minute d'EDF fermé coûte de l'énergie réseau qui part dans la batterie à plusieurs kW, sans que personne ne l'ait demandé. C'est l'explication mécanique des nuits où la batterie finit à 96 % sur réseau (incident du 09/07), et un argument de plus pour la « session réseau unique et dimensionnée ».

Aucune mise à jour firmware n'est justifiée par ces mesures.

PREUVE (27/08 11:38-11:51) : la présence d'EDF substitue le réseau au solaire

Relevé : docs/mesures/20260827-test-edf-mppt-alterne.log. Protocole alterné OFF 3 min / ON 3 min / OFF 3 min / ON 3 min, échantillon 15 s, avec cette fois la tension batterie et l'état des chargeurs MPPT (sensor.*_mppt_operation_mode, *_pv_tracker_solar_N_operation_mode) — des capteurs qu'aucun workflow ne lisait et qui disent explicitement si un chargeur cherche son point de puissance maximale (mppt_active) ou se retient (voltage_current_limited).

Phase	PV moyen	Réseau	Conso
OFF_1	3 858 W	0	2 223 W
ON_1 (établi)	1 112 W	2 287 W	2 258 W
OFF_2	4 025 W	0	2 226 W
ON_2 (établi)	1 043 W	2 717 W	2 590 W
FIN (OFF)	4 358 W	0	2 249 W

Transitions : bascule ~75-90 s après la fermeture du contacteur, retour en ~32 s après l'ouverture, quatre fois de suite. DVCC constant (110 A / 51,2 V), SOC 86→88, batterie loin de la saturation. La PV moyenne est plus HAUTE à la fin du test qu'au début (4 358 contre 3 858) : aucune tendance météo ne peut expliquer les creux. L'hypothèse « nuages » du test précédent est morte.

Perte : ~2 900 W, soit 73 % de la production, reprise par le réseau au watt près, à consommation inchangée. Ce n'est PAS la censure normale par manque de preneur (il y avait 2 250 W de charges et une batterie autorisée à 110 A, que le solaire alimentait intégralement 90 s plus tôt) : le réseau ne comble pas un déficit, il prend la place. Résidu pendant les phases ON remarquablement constant (~1 040 W), ce qui ressemble à un plancher et non à une réduction proportionnelle.

Cadrage donné par le propriétaire, à respecter : le bridage quand la batterie se remplit — et même avant, pour limiter le courant de charge — est le comportement NORMAL d'une installation en autoconsommation sans injection, il le connaît, ce n'est pas le sujet. L'anomalie est la substitution ci-dessus, apparue depuis le passage des deux MultiPlus II en maître/esclave (parallèle), avec plusieurs mois de recul.

Piste (configuration avant firmware) : un système parallèle ayant perdu son comportement ESS retombe en passthrough + chargeur — le réseau alimente les charges et charge la batterie, le solaire ne faisant plus que compléter, ce qui est exactement le symptôme. À vérifier côté VEConfigure/console GX, non visible depuis HA : (1) assistant ESS présent et identiquement configuré sur les deux unités ; (2) point de consigne réseau (l'import se cale exactement sur les charges) ; (3) affectation du compteur réseau après passage en parallèle.

Conséquence chiffrée pour l'autonomie : chaque heure de contacteur fermé coûte ~2,3 kW de solaire gratuit remplacé par du payant, et cela quel que soit le niveau de la batterie — à cumuler avec l'import de ~4 kW vers la batterie observé au test de 10:47. Le dimensionnement des batteries prévu cet hiver doit se faire APRÈS ce correctif, sous peine de dimensionner sur une installation qui perd les trois quarts de sa production dès que le réseau est présent.

Réserve d'orage (déployé 27/08 12:04, mode ombre, tests 42/42)

Besoin : les coupures réseau d'orage sont fréquentes sur ce site, et le propriétaire veut garder de quoi tenir jusqu'au retour du solaire.

Point de départ, souvent mal posé : une coupure n'arrête PAS l'installation. Le solaire et la batterie continuent, seul le filet de secours disparaît. La question n'est donc pas « combien stocker pour survivre » mais « la batterie traverse-t-elle la prochaine fenêtre de déficit SANS réseau ». C'est exactement la couverture prudente (p80) que le bilan calcule déjà : aucune constante nouvelle. Le profil prudent est le bon choix ici précisément parce qu'une coupure retire la possibilité de rattraper une sous-estimation.

Chaîne : HA_SNAPSHOT_TEMPLATE lit la vigilance sans connaître la commune (states.sensor | selectattr('entity_id','search','_weather_alert')) → PREPARE_BALANCE passe-plat → BALANCE calcule le bloc storm → BUILD_HA_CALLS publie 5 helpers evcs_balance_storm_*.

Fenêtre retenue : en déficit, celle qu'on traverse (couverture prudente) ; en surplus, la prochaine (nextDeficit) — car à 15 h la réponse « rien à couvrir » est exacte et inutile, le risque étant la nuit qui vient.

Seuil d'activation : vigilance orange, c'est-à-dire l'échelle officielle de Météo-France (vert/jaune/orange/rouge) et non un nombre choisi ici.

Helpers (package evcs_energy_balance.yaml, sauvegarde *.bak.20260827, rechargés et vérifiés) : evcs_balance_storm_level · _storm_active · _storm_reserve_kwh · _storm_reserve_soc (borné à 100 pour la plage de l'entrée) · _storm_reason.

Tests 38 → 42. Deux résultats notables figés :

24/08 06:43, SOC 21 % : réserve 2,42 kWh (SOC 38,1 %) → manque 2,57 kWh pour tenir la matinée sans réseau ;
24/08 15:30, SOC 95 %, vigilance rouge : la fenêtre qui compte devient celle de 19 h, 12,77 kWh, SOC requis 107,1 % — même pleine, la batterie actuelle ne passe pas la nuit sans réseau. Valeur volontairement NON écrêtée : c'est le signal de dimensionnement pour l'achat de batteries de cet hiver.

Garantie mode ombre étendue : le fixture synthétique BALANCE_OK de scenarios-shadow.mjs ne contenait pas storm, donc les nouvelles écritures n'étaient PAS couvertes par le test de périmètre. Corrigé, plus une assertion explicite wroteStorm: 5. Preuve par mutation : une écriture détournée vers input_boolean.victron_evcs_night_grid_takeover_needed fait échouer la suite (outOfScope la nomme).

RESTE À FAIRE — action utilisateur : l'intégration Météo-France n'est pas installée (HA n'a que met / Met.no). Elle est gratuite, sans clé d'API, intégrée au cœur de HA. Le flux de configuration a été testé par API : il réclame un nom de commune et refuse les coordonnées ({"city":"empty"} sur 48.7732657 / -3.5187179) — donc à ajouter par l'interface, ou à me donner la commune. Tant qu'elle est absente, le bilan publie indisponible, active reste faux, et la réserve est quand même chiffrée : rien ne casse.

Historique HA plus court que configuré

configuration.yaml déclare purge_keep_days: 90, mais l'historique brut s'arrête au 20/08 (~7 jours) : testé vide au 01/06, 29/07, 10/08, 17/08 ; 1 point au 20/08, 7 au 24/08. Base recréée, ou purge qui ne respecte pas la consigne — à investiguer. Les statistiques long terme (horaires, conservées indéfiniment) sont un stock distinct et probablement intactes.

Diagnostic en attente de vérification (Qwen, 22/08)

Voici mon analyse et plan de correction : Diagnostic Le bug est dans HA_SERVICE_CALLS_OUTPUT.js:987-996 : edf_general_ok_on: { execute: ['grid_forced', 'grid_hc_allowed'].includes(context.sourceMode) && !parsed.gridAvailable, ... } Il n'existe pas de edf_general_ok_off. Le workflow ne coupe JAMAIS activement EDF. Il ne fait que le rallumer quand sourceMode est grid ET que le réseau n'est pas encore disponible. Quand sourceMode revient à solar_only/blocked, le switch reste ON dans l'état qu'il avait. Conséquence : après la fenêtre HC nocturne (~06:00), EDF reste allumé. La présence du réseau bloque la production PV (Victron plafonne à ~100 W). Le débranchement du véhicule résout parce que c'est le seul mécanisme qui coupe physiquement le switch. Plan de correction Fichier : src/nodes/HA_SERVICE_CALLS_OUTPUT.js Ajouter un call edf_general_ok_off juste après edf_general_ok_on (ligne 996) : edf_general_ok_off: { execute: !['grid_forced', 'grid_hc_allowed'].includes(context.sourceMode) && parsed.gridAvailable &parsed.evcsVehicle

Verdict (Claude, 22/08) : diagnostic ÉCARTÉ, voir §24 ci-dessous. Le symptôme est correctement identifié (EDF ne se coupe jamais activement après la fenêtre HC) mais la cause et le correctif proposés sont faux : le bug n'est pas dans HA_SERVICE_CALLS_OUTPUT.js (qui n'a jamais eu vocation à couper EDF — la coupure est le rôle exclusif du workflow séparé "Victron - Battery / Grid Hysteresis Fix V1"), et ajouter un edf_general_ok_off côté EVCS créerait un deuxième écrivain non coordonné sur switch.edf_general_ok_switch (courses 30s/1min entre les deux workflows, le hysteresis reprenant la main au cycle suivant via son propre latchIsOn et rallumant probablement EDF quand même). Le vrai bug et son correctif (Fix G, côté hystérésis) sont documentés en §24.

Document mis à jour le : 22/08/2026 (~18:00) — Fix G déployé (hystérésis), diagnostic Qwen écarté, golden-hysteresis 7/7

24. Session du 22/08/2026 — Fix G : coupure EDF quand l'override EVCS disparaît mi-session (hystérésis)

Incident (nuit 21-22/08)

Le takeover nuit (P7) a correctement rechargé la batterie à ~35 % via EDF. Quand la fenêtre HC s'est fermée (~06:00-07:24) avec le véhicule encore branché en session active (pas encore flag "charge terminée"), EDF est resté allumé — le réseau a plafonné le MPPT Victron à ~100 W, privant la maison de 600-4000 W de solaire disponible (elle tirait ~1000 W d'EDF). Seul le débranchement du véhicule a libéré EDF (2179 W de PV immédiatement après).

Root cause

Côté EVCS (WINDOWS_SOURCEV2.js/DECISION_ENGINEV2.js) : pas le bug. Chaque cycle, nightSessionActive et tout le moteur nuit sont activement recalculés à false/'blocked' dès la fermeture de fenêtre — helper night_grid_takeover_needed passe à off et source_mode à 'Bloqué' correctement et immédiatement, même mi-session. MAIS les deux branches "collantes" de fin de session (Fix F, exige profile === 'night_hc' ; P10 day_vehicle_full_idle, exige que le surplus_state précédent soit déjà un pattern "terminé") ne se déclenchent PAS sur le cycle exact où la fenêtre se ferme mi-session non-terminée. Le système retombe sur des états génériques transitoires (stop_source_lost puis idle_wait_source).

Côté Grid Hysteresis (workflows/victron-grid-hysteresis-v1.json, node "Compute Grid Hysteresis") : c'est là le bug. Les règles de coupure immédiate existantes (Fix C turn_off_vehicle_unplugged, Fix E2 turn_off_recovery_done) ne matchent que des noms exacts de surplus_state (vehicle_not_connected, night_recovery_done_idle, departure_done_idle) — aucune ne matche stop_source_lost/idle_wait_source (ni day_vehicle_full_idle lui-même). Sans matche, le code retombe sur la boucle générique qui maintient EDF jusqu'au seuil statique grid_soc_off (35 %, input_number.victron_grid_soc_off), totalement découplé de la cible dynamique de l'EVCS — potentiellement des heures, d'autant qu'EDF-ON lui-même bride la recharge solaire organique.

Fix G (déployé 22/08 ~18:00, golden-hysteresis 7/7)

Au lieu d'ajouter encore un nom d'état à une liste blanche fragile, nouvelle règle générique dans "Compute Grid Hysteresis", basée sur evcsGridOverride (déjà fiable) plutôt que sur le nom de surplus_state — couvre donc aussi automatiquement tout futur nom d'état non énuméré :

if (
  !forcedCut && latchIsOn && gridIsOn &&
  !evcsGridOverride &&
  soc > gridSocOn &&              // 22%, PAS gridSocOff 35% — protège le cas
                                   // indépendant "SOC bas" qui doit tenir
                                   // jusqu'à gridSocOff
  evcsSourceModeLooksValid        // garde anti-glitch (lecture HA vide/
                                   // unavailable/unknown → pas d'action)
) {
  desiredGrid = 'off'; desiredLatch = 'off';
  state = 'turn_off_evcs_override_released';
  forcedCut = true;
}

Coupure immédiate, bypass min_on (25 min), comme Fix C/E2. Décision validée avec l'utilisateur : vitesse de libération prioritaire sur le risque résiduel (un glitch de lecture HA sur un seul cycle pourrait causer une coupure/ rallumage isolé, auto-diagnosticable dans le logbook — pas de chatter soutenu car il faudrait une lecture fausse à chaque cycle).

Nouvelle suite de tests : `tests/golden-hysteresis/` (7 scénarios, première

suite pour ce workflow — 0 → 7) g-incident-gap-mid-session/g-incident-gap-idle-wait-source (les deux noms d'état zombies de l'incident, min_on non écoulé) · g-incident-replay-hc-boundary (rejeu complet, min_on déjà écoulé aussi — prouve que ce n'est pas seulement un bypass min_on) · g-baseline-low-soc-no-override (garde non-régression : SOC bas indépendant doit continuer à tenir) · g-regression-fixc-unplugged / g-regression-fixe2-recovery-done (Fix C/E2 toujours prioritaires, pas absorbés par Fix G) · g-glitch-guard-unavailable (garde anti-glitch). Lancée AVANT patch : 3 échecs (les scénarios d'incident, stuck sur hold_on_min_runtime/hold_on_until_soc_off) + 4 succès (gardes déjà bonnes) — confirme que le harnais détecte vraiment le bug. Après patch : 7/7. Câblée dans tools/n8n-push.mjs (nouveau isHysteresisWorkflow), bloquante au push comme les 2 autres workflows.

Outillage

tools/patch-20260822-g-override-released-cut.mjs (rejouable, même patron que patch-20260809-e2-recovery-done-cut.mjs) · tests/golden-hysteresis/{fixture-snapshot.json,run.mjs,scenarios.mjs}.

Déploiement

node tools/n8n-push.mjs workflows/victron-grid-hysteresis-v1.json → backup serveur auto (modified/prepush-7iIlu7LLTW7TZA8o-*.json) → syntaxe OK → golden-hysteresis 7/7 → PUT OK. grid_min_on_minutes réel vérifié via MCP ha-get-state avant de figer le fixture : 25 (pas le fallback 45 du code).

Hors périmètre (volontairement)

Aucun changement côté src/nodes/* (EVCS V2.6) — le fix est entièrement côté hystérésis. Amélioration cosmétique future possible, non incluse ici : remplacer les noms zombies stop_source_lost/idle_wait_source par un état de transition dédié pour la lisibilité dashboard/logbook.

À surveiller (prochaine fermeture de fenêtre HC avec véhicule encore

branché mi-session)

Logbook doit montrer turn_off_evcs_override_released peu après la fermeture de fenêtre si le véhicule n'est pas encore flag "terminé" ;
La PV doit remonter (MPPT non-plafonné) immédiatement après ;
Aucune coupure/rallumage répété (turn_off_evcs_override_released suivi de près par turn_on_evcs_override répétitivement) — signe d'un glitch de lecture HA à investiguer si observé.

*Document mis à jour le : 22/08/2026 (~18:05) — Fix G déployé et validé (syntaxe + golden-hysteresis 7/7 + PUT OK), à confirmer en conditions réelles à la prochaine fermeture de fenêtre HC mi-session

25. Session du 24/08/2026 — Fix G retiré + diagnostic des deux oscillateurs

Fix G retiré de la production (déployé 24/08 12:18, golden-hysteresis 7/7)

Fix G (§24) a produit en production un yoyo EDF de 2-4 min la nuit du 23-24/08, véhicule débranché : coupure à SOC 21 % (Fix G, bypass min_on) puis rallumage à SOC 20 % (branche hold_on_low_soc, bypass cooldown), MPPT qui flappe à chaque bascule. Logbook : turn_off_evcs_override_released 06:43:03 → hold_on_low_soc 06:45:03 → turn_on_low_soc_cooldown_bypassed 06:52:03.

Erreur de conception : le garde soc > gridSocOn ne protégeait que l'INSTANT de l'engagement sur SOC bas (soc <= 20), pas la PHASE DE REMONTÉE 20 → 30 qui est 100 % de la durée de vie de ce cas. Fix G a donc remplacé l'hystérésis 20/30 par une hystérésis 20/20,1.

Erreur de test : le fixture tests/golden-hysteresis/ portait grid_soc_on: "22" / grid_soc_off: "35" — les valeurs de repli du code, pas la production (vérifiée via MCP : 20 / 30, inchangées depuis le 07/08). Et le scénario de non-régression g-baseline-low-soc-no-override utilisait SOC 18 %, c'est-à-dire le seul point que Fix G épargnait. → Règle : figer un fixture de test sur des valeurs lues en live via MCP, jamais sur les fallbacks du code.

Retrait : tools/patch-20260824-revert-g.mjs (rejouable) — le jsCode résultant est byte-identique à la version pré-Fix-G (commit 0419c74), vérifié. Suite réécrite (7 scénarios, seuils réels 20/30) avec les garde-fous manquants h-recovery-band-no-cut-21 / -25 : la remontée batterie sur réseau ne doit JAMAIS être interrompue avant grid_soc_off. Test de mutation : Fix G réappliqué → 4/7 échecs, retiré → 7/7. Le filet attrape désormais la régression.

Diagnostic : deux oscillateurs, même pathologie

Détail complet dans docs/MANUEL_COMPLET.md §11.8. Résumé :

A — Yoyo EDF. Le problème de fond n'est pas le réglage de grid_soc_off mais le fait qu'il n'a aucun sens physique : le 24/08, la PV ne couvre la conso maison qu'à partir de ~09:00 (0,07 → 0,63 → 2,74 kWh/h contre 0,75 kWh/h de conso). Couper EDF à 06:43 à 21 % rend le yoyo inévitable quels que soient les seuils. Le workflow hystérésis lit 25 champs et aucune prévision solaire. Cible : session réseau unique dimensionnée jusqu'au croisement PV/conso, arbitrée par le conseiller IA. NB : mesurer la vraie capacité PV impose de couper EDF (sinon le MPPT est bridé et on ne voit rien).

B — Oscillation charge EVCS en plein soleil (24/08 12:25 → 12:28). Ce n'est PAS une limite 5 kVA (aucun ve_bus_overload depuis le 20/08, ac_loads_max_safe_w = 9000, AC-out L1 à 5335 W sans overload, plafond calculé ~20 A) et pas non plus une bande morte batterie trop étroite : le courant batterie était à +127 A au moment de l'arrêt. Les deux atténuations que j'avais d'abord proposées (battery_discharge_soft_a à −12 A, battery_neutral_band_a à 3-5 A) n'avaient donc aucun effet sur ce cas — l'utilisateur l'a signalé, à raison, avant que je les applique.

Cause réelle : inversion du plancher de démarrage et du plancher de maintien. À 12:24:00 le profil bascule vers midday_hc_or_solar ; avec SOC 58 % le plancher de démarrage vaut min(midday_soc_min 75, abondance P6 40) = 40 et le plancher de maintien max(soc_stop_min 29, 75-15) = 60. Le système a le droit de DÉMARRER ce qu'il n'a pas le droit de MAINTENIR → cycle limite à la période de min_run_minutes (3 min) sur toute la bande [40 %, 60 %], et ~2,6 kW de PV écrêtés à chaque creux (PV 10,24 kW → 7,64 kW quand la borne s'arrête).

Décisions de conception validées avec l'utilisateur

La conso se lit, elle ne se devine pas ; filtrage numérique dynamique des pointes (improbables la nuit hors charge EVCS ; pas de moyenne quand aucun véhicule n'est branché).
SOC : lissage pour les décisions de confort, valeur instantanée conservée pour la sécurité (le risque prime).
Les seuils fixes doivent devenir dynamiques (saison, prévision) et être arbitrés par le conseiller IA : « un automatisme c'est trop rigide pour traiter tous ces cas tordus ». Ne plus empiler de branches codées en dur.
Exploiter les messages d'état réels du Victron et de la borne au lieu de s'auto-limiter à l'aveugle sur un proxy.

Correctif déployé 24/08 12:45 — invariant maintien <= démarrage

src/nodes/BATTERY_CLOUD_LOCKS.js, deux volets indissociables :

effectiveSocHoldFloor = min(règle du profil, plancher de démarrage effectif) — on ne peut plus être autorisé à démarrer ce qu'on n'est pas autorisé à maintenir. Sans abondance, comportement inchangé.
L'abondance P6 se PROUVE au démarrage (solarAbundanceStart : pvAvg >= 4000 ET batterie >= +20 A) mais se MAINTIENT en charge (solarAbundanceHold : pvAvg >= 4000 ET batterie >= 0). Sans ce dédoublement, la charge du véhicule détourne le surplus, fait tomber le courant batterie sous +20 A et détruit sa propre condition d'autorisation — l'oscillation reviendrait dès que le PV n'est que moyennement fort.

Golden 39 → 40 : midday-inversion-start-hold (relevé VRM du 24/08 12:25 : PV 10,24 kW, charges 3815 W dont EVCS 3502 W, batterie +127 A, SOC 58 %). Preuve par mutation : code d'avant → stop / « Conditions de maintien perdues » ; après → charging_step_up_battery à 19 A. Les 39 scénarios existants inchangés.

Leçon transverse : trois oscillateurs identifiés le même jour (Fix G, abondance P6 auto-destructrice, inversion démarrage/maintien) — même pathologie à chaque fois, des seuils empilés par couches successives, chacun raisonnable isolément, dont personne ne vérifie la cohérence d'ensemble. D'où le chantier du bilan énergétique partagé plutôt qu'un garde de plus.

Document mis à jour le : 24/08/2026 (~12:50) — Fix G retiré (golden-hysteresis 7/7, seuils réels 20/30), inversion démarrage/maintien corrigée (golden 40/40), diagnostic des deux oscillateurs

27. Session du 30/08/2026 — Deux propriétaires GX de la décision réseau, jamais lus

Le propriétaire demandait une procédure détaillée avant d'intervenir sur les deux MultiPlus-II en parallèle (piste VEConfigure de la §26). Les lectures préalables côté GX déplacent la priorité : il est probable qu'aucune intervention VEConfigure ne soit nécessaire.

Procédure complète : docs/PROCEDURE_ESS_PARALLELE.md.

Trouvaille 1 — Consigne de puissance réseau à 4200 W (défaut : 50 W)

number.gx_device_ac_power_setpoint = 4200 W, miroir per-phase number.airtria_mpii_v1_ac_power_setpoint_l1 = 4200 W. C'est le Grid setpoint ESS (/Settings/CGwacs/AcPowerSetPoint) : la puissance que le système s'efforce en permanence de prélever sur le réseau quand AC-IN est présent.

L'ESS régulant la puissance au point de raccordement, le seul levier pour faire place à cet import quand maison et batterie sont déjà servies est de brider les MPPT via DVCC. C'est le mécanisme exact de la substitution prouvée le 27/08, et l'explication du résidu constant (~1040 W).

Les deux campagnes se réconcilient arithmétiquement :

10:47, SOC 71 %, conso 877 W → import monte à 4113 W ≈ consigne ;
11:38, SOC 86 %, batterie en absorption n'acceptant que ~1070 W → conso 2258 + batterie 1070 − PV 1043 = 2285 W contre 2287 W mesurés.

Valeur inchangée sur tout l'historique disponible (7 j) ; user_id: null sur le dernier changement = simple recréation d'entité au redémarrage HA du 24/08. Aucun code du dépôt n'écrit cette entité (grep). Hypothèse la plus probable : ancien contournement manuel, même famille que les charges programmées ESS désactivées le 27/08. À confirmer sur l'écran du GX avant de conclure — ne pas se fier au seul nom de l'entité HA.

Correction proposée : 50 W (défaut Victron, légèrement positif pour ne jamais injecter). Réversible en dix secondes, sans VEConfigure.

Trouvaille 2 — SOC minimal ESS à 40 %, au-dessus de notre cible de nuit

number.gx_device_ess_min_soc_limit = 40 %, sensor.gx_device_active_soc_limit = 40 % (BatteryLife ne fait donc pas dériver la limite au-dessus).

Sous 40 %, l'ESS recharge la batterie sur le réseau de sa propre initiative. Ce n'est pas théorique : sensor.gx_device_ess_batterylife_state passe à recharge les 29/08 04:08 et 30/08 01:21, précédé de soc_below_battery_life_dynamic_soc_limit.

Or le contrôleur vise 35 % le matin en été : le nôtre relâche à 35, le GX reprend à 40. Troisième automate contradictoire sur la même batterie, après les charges programmées. Arbitrage à rendre avec le propriétaire — piste préférée : laisser ce plancher comme filet de sécurité bas (~20 %) et confier la vraie cible au bilan énergétique. Rien changé sans son accord.

Trouvaille 3 — L'assistant ESS tourne, aucune erreur VE.Bus

États BatteryLife vivants et cohérents → la boucle ESS fonctionne, elle n'est pas absente. Toutes les alarmes VE.Bus à no_alarm, aucune erreur d'installation. L'hypothèse « assistant perdu ou dépareillé entre les deux unités après le passage en parallèle » est affaiblie sans être éliminée (un assistant présent mais mal paramétré ne lève aucune alarme) — d'où le maintien de la partie VEConfigure en seconde intention dans la procédure.

Méthode retenue dans la procédure

Étapes classées par risque croissant : lectures gratuites → réglages GX réversibles → rejeu du protocole alterné du 27/08 comme critère objectif → VEConfigure seulement en cas d'échec, avec sauvegarde .rvms obligatoire, une correction à la fois, et interdiction absolue de relancer le VE.Bus System Configurator. Firmware : toujours pas justifié par les mesures, et à ne pas mêler au diagnostic.

Document mis à jour le : 30/08/2026 — consigne réseau 4200 W et SOC minimal ESS 40 % identifiés comme propriétaires non lus de la décision réseau ; procédure d'intervention rédigée

28. Session du 31/08/2026 — La substitution ne se reproduit plus (batterie preneuse). Cas « batterie pleine » encore ouvert

Première vérification de la correction de la consigne réseau (4200 → 50 W, §27), sur une nuit complète puis deux campagnes alternées.

La nuit 30-31/08 : l'import colle à la consommation

Une seule session réseau, switch.edf_general_ok_switch ON à 05:04:10 (hystérésis, SOC 21 ≤ seuil 20) et OFF à 10:08:04 (SOC 30 ≥ seuil OFF). Aucun rebond, aucun créneau.

heure	import réseau	conso maison	courant batterie
05:15	780 W	732 W	0 A
06:30	507 W	477 W	−1 A
07:45	781 W	751 W	+4 A

À comparer au test du 27/08 10:47 où, pour 877 W de consommation, l'import montait en rampe jusqu'à 4113 W pour gaver la batterie. Le comportement a disparu. Détail de la fermeture : de 05:04 à 05:13 l'import est resté à 24-56 W (la consigne) pendant que la batterie continuait de servir la maison à −15 A ; à 05:14, SOC atteignant le plancher ESS de 20 %, l'ESS a basculé — import = charge maison, batterie à 0 A, SOC plat à 20 % jusqu'à 08:00. Manuel.

Le matin : réseau présent, production libre

De 08:40 à la coupure de 10:08, contacteur toujours fermé :

heure	PV	import	conso	I batterie
08:45	1 303 W	18 W	1 109 W	+2 A
09:25	3 425 W	39 W	805 W	+50 A
10:05	5 244 W	47 W	952 W	+83 A

sensor.mppt_450_200_hq2449yr9pt_mppt_operation_mode est resté mppt_active sur toute la fenêtre : le chargeur déclare lui-même chercher son point de puissance maximale pendant que le réseau est présent.

Campagnes alternées (`tools/test-edf-alterne.mjs`)

Journaux : docs/mesures/20260831-1043-test-edf-alterne.log (phases 180 s) et 20260831-1101-test-edf-alterne.log (phases 240 s).

Transitions exploitables, chaque phase fermée contre ses voisines ouvertes :

phase	PV fermée	PV voisines ouvertes	écart	trackers bridés
10:47 ON_1	7 168 W	7 131 W	+0,5 %	2,7/7 (DVCC, I=124 A)
11:13 ON_2	7 920 W (max 8 759)	7 002 W	+13,1 %	4,5/7 (DVCC, I=125 A)

Le 27/08, la même manœuvre faisait tomber la PV de 3 885 à 1 045 W en 90 s avec six trackers sur sept en voltage_current_limited. La substitution ne se reproduit plus à batterie preneuse. Le bridage résiduel observé est le bridage NORMAL : il apparaît quand le courant batterie approche la limite DVCC (125 sur 130 A) et il s'accompagne d'un import réseau nul — critère de discrimination utilisable : bridage normal ⇒ import nul ; bridage anormal ⇒ l'import remplace la production.

Mécanisme identifié : un transitoire de reprise, qui retombe à la consigne

À chaque fermeture du contacteur, le réseau reprend d'un coup toute la charge de la maison et la totalité du solaire bascule vers la batterie. Bilan vérifié au watt près (10:48:15 : PV 7222 + grid 2120 − conso 2249 = 7093 W contre 7107 W de charge batterie mesurée). Puis l'import décroît jusqu'à la consigne :

campagne	import à la fermeture	après ~2 min 15
11:05 ON_1	1 985 W	25 W, stable
11:13 ON_2	2 600 W	52 W puis −41 W

Coût ≈ 50-60 Wh par fermeture. Avec l'ancienne consigne à 4200 W, cette reprise n'avait aucune raison de redescendre : elle se stabilisait sur « le réseau alimente tout, on bride le solaire pour faire de la place ». C'est vraisemblablement le même mécanisme, dont la correction de consigne a rétabli l'extinction. Corollaire : chaque fermeture coûte, ce qui plaide pour une session réseau unique et dimensionnée plutôt que des créneaux répétés. Note : aucun transitoire à la fermeture de 05:04 (PV nulle) — il n'y a rien à rediriger quand il n'y a pas de solaire.

CE QUI N'EST TOUJOURS PAS TESTÉ — batterie pleine (à faire)

Tout ce qui précède s'est mesuré à SOC 40-54 %, batterie absorbant 60 à 125 A. Le propriétaire maintient, sur plusieurs mois d'observation, que le cas décisif est batterie pleine : plus de tampon, donc le solaire qui alimentait la maison n'a plus de destination quand le réseau la reprend. Discrimination attendue, contacteur fermé, maison ~2 kW, SOC ≥ 90 % :

observation	conclusion
PV ≈ conso (~2 kW), import ≈ 50 W	corrigé — écrêtage normal, le solaire sert la maison
PV ≈ 0-1 kW, import ≈ conso	non corrigé — éviction ; VEConfigure (§27, `docs/PROCEDURE_ESS_PARALLELE.md` étape 1)

Le 27/08 à 11:38, SOC 86-88 %, batterie n'acceptant plus que ~1 kW, on avait PV 1043 W pour une maison à 2258 W et un import de 2287 W : le solaire SOUS la consommation et le réseau AU-DESSUS. C'est le point le plus proche du cas décisif dont on dispose, et il est du mauvais côté. Trois minutes de protocole alterné à SOC ≥ 90 suffiront à trancher.

Outillage ajouté

tools/test-edf-alterne.mjs — protocole alterné OFF/ON/OFF/ON/OFF, phases et pas d'échantillonnage paramétrables. Mesure PV, tension et courant batterie, conso, import, SOC, limite DVCC, présence physique AC-IN et le mode des 7 chargeurs solaires. Désactive l'hystérésis pendant le test et restaure tout à la fin, sur Ctrl-C et sur erreur. Journal horodaté dans docs/mesures/.
tools/analyse-test-alterne.mjs — résumé par phase et verdict.

Deux pièges d'instrumentation corrigés en cours de route, à ne pas réintroduire :

Garde météo. Les phases OUVERTES voient toutes la même ressource : si elles divergent entre elles (33 % et 42 % sur les deux campagnes du 31/08), la moyenne ON contre OFF est ininterprétable. L'outil refuse désormais de conclure dans ce cas et compare chaque phase fermée à ses voisines immédiates. C'est ce piège qui avait pollué le premier test du 27/08. Contrôle interne utile : si la PV chute AVANT l'apparition de l'import, ce sont des nuages (cas de la phase ON_2 du 31/08 10:53, chute 6995 → 3607 W avec l'import encore à zéro).
Biais du parseur. La lecture des modes MPPT était ancrée sur MPPT , ce qui faisait tomber en silence toute ligne dont le PREMIER tracker était bridé — précisément les échantillons à mesurer — et biaisait le résultat vers « aucun bridage ». Le bloc de modes est le dernier champ : l'ancrer sur edf on|off, jamais sur le mot MPPT.

Signal indépendant : la jauge de SOC s'effondre en bas d'échelle

Entre 04:00 et 04:20, le SOC est passé de 30 à 22 % alors que la batterie ne débitait que ~11 A (≈ 550 W), tension stable à 49 V. Huit points sur un parc de ~15 kWh représentent 1,2 kWh, soit plus de deux heures à ce débit — pas vingt minutes. La jauge ne mesure plus, elle réestime. Comportement classique d'un parc vieillissant près du genou de décharge, cohérent avec le module en panne connu (7 modules actifs sur 8, cf. MANUEL §0). Conséquence : tous les seuils des deux workflows (20, 30, 22, 35) sont exprimés dans une grandeur non linéaire en bas d'échelle. À verser au chantier du bilan énergétique ; ne pas « corriger » par un seuil de plus.

LE CAS DÉCISIF, TESTÉ — batterie pleine (campagne 12:58, SOC 90-92 %)

Journal : docs/mesures/20260831-1319-test-edf-alterne.log. Conditions de départ exactement celles que le propriétaire désignait : SOC 90 %, courant batterie +22,8 A, DVCC retombée à 80 A, production déjà écrêtée à 3 691 W (2 301 W de maison + ~1,1 kW de batterie) alors que la même installation produisait 9 112 W le matin. Plus de tampon.

Le phénomène qu'il décrit se produit — et il se résorbe. ON_2, le cas le plus net :

heure	PV	import	conso
13:11:57	2 663 W	0	1 899 W
13:12:12	559 W	1 777 W	1 886 W
13:12:57	1 405 W	1 136 W	1 877 W
13:13:27	1 912 W	683 W	1 891 W
13:14:27	3 008 W	258 W	2 362 W
13:14:42	3 158 W	112 W	2 373 W

Effondrement de 79 % en un seul pas de mesure, simultané à l'apparition de l'import (et non avant, contrairement aux passages nuageux du matin : le critère de discrimination fonctionne). Puis récupération en miroir, watt pour watt, sur ~2 min 30 : l'import redescend à 112 W et la production revient à 3 158 W, au-dessus de son niveau d'avant fermeture. Même séquence en ON_1 (3 369 → 1 890 W avec import 2 083 W, retour à 3 315 W avec import 8 W).

Une fois le transitoire exclu (165 s), l'état établi ne montre aucune substitution : −7,0 % et +2,0 % contre les phases ouvertes voisines, import résiduel 443 et 479 W et toujours décroissant. Les phases ouvertes déclinent d'elles-mêmes (3 505 → 2 808 → 2 488 W, milieu d'après-midi), ce qui explique le −7 %.

Conclusion. L'observation de plusieurs mois du propriétaire est exacte : à batterie pleine, fermer le contacteur tue la production. Ce qui était faux, c'est la permanence. Le mécanisme est le même transitoire de reprise qu'à batterie preneuse — le réseau reprend la maison, le solaire cherche une destination — sauf que sans tampon la seule variable d'ajustement est le bridage des MPPT, donc l'effet devient spectaculaire au lieu d'être invisible. Avec l'ancienne consigne à 4200 W, ce transitoire n'avait aucune raison de se terminer : le régulateur ne pouvait atteindre sa cible qu'en maintenant le solaire bridé. C'est l'explication complète de « pas de grid sinon le solaire ne sert à rien », et la correction de consigne y met fin.

Coût par fermeture du contacteur, à batterie pleine : ~50 Wh d'import transitoire plus ~100 Wh de production perdue pendant les 2 min 30 de bridage, soit environ 150 Wh. À batterie preneuse, seulement les ~50 Wh. C'est l'argument chiffré en faveur d'une session réseau unique et dimensionnée plutôt que de créneaux répétés : chaque ouverture-fermeture se paie, et se paie trois fois plus cher quand la batterie est pleine.

Ce qui reste vrai et inchangé : à batterie pleine et régime établi, la production est écrêtée à la consommation (6 à 7 trackers sur 7 en voltage_current_limited dans TOUTES les phases, ouvertes comme fermées). C'est le bridage normal d'une installation sans injection, il ne dépend pas du réseau, et il ne doit pas être confondu avec l'éviction.

Aucune intervention VEConfigure ni firmware n'est justifiée par ces mesures. L'étape 1 de docs/PROCEDURE_ESS_PARALLELE.md reste en réserve, sans objet actuel.

Document mis à jour le : 31/08/2026 (~13:30) — cas batterie pleine testé : l'effondrement existe mais dure 2 min 30 et se résorbe entierement ; la substitution permanente est morte avec la consigne a 4200 W ; ni VEConfigure ni firmware justifies

29. Session du 31/08/2026 (suite) — Fenêtre d'établissement du réseau

Le défaut

Mesure du 31/08 (§28) : à la fermeture du contacteur, le réseau reprend d'un coup toute la charge de la maison et le solaire bascule vers la batterie — ou se fait brider s'il n'y a plus de tampon (2 663 → 559 W). L'import redescend ensuite à la consigne en ~150 s, deux fois mesuré (1 985 → 25 W, 2 600 → 52 W).

Pendant cette phase, PV, import et courant batterie ne décrivent aucun régime permanent. Or la boucle EVCS tourne toutes les 30 s : elle y prend cinq décisions. Pire, INPUT_PARSE lit pv_power_10m_avg_w, une moyenne glissante de dix minutes : un creux de 2,5 kW pendant 2 min 30 la tire d'environ 600 W et l'effet persiste une dizaine de minutes après le retour à la normale. Les seuils de démarrage et de maintien solaire se jouent dans cette plage.

Boucle de rattrapage qui en résulte : réseau présent → le système lit « plus de soleil » → il conclut qu'il a besoin du réseau → il le garde. La conclusion confirme sa prémisse. Quatrième oscillateur, même famille que les trois du 24/08.

Le correctif

Aucun seuil nouveau : le système publiait déjà l'information et personne ne la lisait — l'horodatage de la dernière transition du réseau.

Gabarit snapshot : acin1_last_changed_ts, grid_switch_last_changed_ts (as_timestamp(...last_changed, 0), avec garde is not none pour une entité absente), plus grid_settle_seconds (helper optionnel input_number.evcs_grid_settle_seconds ; absent → 180 s). ⚠️ Un commentaire Jinja {# #} est interdit à l'intérieur de l'expression {{ {...} | tojson }} : TemplateSyntaxError: unexpected char '#'.
INPUT_PARSE : parsed.gridTransitionAgeSec = âge de la plus récente des deux transitions (AC-IN physique et contacteur). Horodatage absent ou nul → Infinity → aucune fenêtre, comportement historique. On ne devine jamais une transition qu'on n'a pas observée. params.gridSettleSeconds borné [0,900].
WINDOWS_SOURCEV2 : derived.gridSettling = gridAvailable && age < seuil.
BATTERY_CLOUD_LOCKS : pendant la fenêtre, rawSolarStartOk est faux (on ne démarre pas sur des mesures fausses), les deux termes de mesure de rawSolarHoldOk (plancher de décharge, seuil PV) sont neutralisés (on ne laisse pas une charge en cours s'arrêter à cause d'elles), probeFailedNow est suspendu (le réseau masque la production, la sonde n'échoue pas) et solarShouldStepUp est bloqué. Les step-down ne sont pas bridés : c'est la direction sûre.
HA_SERVICE_CALLS_OUTPUT : trace ETABLISSEMENT reseau Xs/Ys dans la raison, sinon une lecture du logbook pendant le transitoire donne l'impression que le système décide n'importe quoi — alors qu'il décide de ne pas décider.

ASYMÉTRIE VOULUE (le point à ne pas casser)

La fenêtre ne s'ouvre qu'à l'arrivée du réseau. À sa disparition, les onduleurs reprennent instantanément toute la charge : les gardes doivent agir plus vite, jamais moins vite. gridSettling exige donc parsed.gridAvailable.

De même, la fenêtre suspend le confort, jamais le risque : commonSafety*, planchers SOC, surcharge et arrêt dur batterie restent évalués normalement — application directe de la règle « lissage pour le confort, instantané pour la sécurité ».

Golden 42 → 48

Chaque cas est apparié à son contrefactuel hors fenêtre ; sans cet appariement le test ne prouverait rien (première rédaction : les trois scénarios donnaient le même résultat, le maintien passant par la tolérance nuageuse).

scénario	attendu
`etablissement-maintien-charge` (30 s, PV 600 W, batt −15 A)	`charging_step_down_battery` 14 A — continue
`etablissement-termine-arret-normal` (400 s, idem)	`stop_conditions_lost`
`etablissement-securite-non-suspendue` (30 s, batt −40 A)	`battery_current_hard_stop`
`etablissement-ouverture-aucune-fenetre` (réseau disparu 30 s)	`stop_conditions_lost`
`etablissement-pas-de-demarrage` (30 s, PV 4,5 kW)	`idle_wait_conditions`
`etablissement-demarrage-hors-fenetre` (400 s, idem)	`start_min_current`

Les 42 scénarios existants sont inchangés : leur fixture ne porte pas les horodatages, donc Infinity → aucune fenêtre. Le repli est sûr par construction.

Preuve par mutation : gridSettling = false → échec des deux scénarios qui testent le correctif (maintien-charge, pas-de-demarrage), les quatre autres restant verts puisqu'ils n'en dépendent pas. Restauration → 48/48.

Suite prévue (ordre convenu avec le propriétaire)

✅ fenêtre d'établissement ;
séquence d'ouverture — baisser la consigne de la borne avant d'ouvrir le contacteur, jamais après. Aujourd'hui l'hystérésis ouvre et le contrôleur EVCS l'apprend jusqu'à 30 s plus tard, pendant lesquelles les deux MultiPlus portent la voiture au courant majoré (jusqu'à 28 A en boost) plus la maison : c'est le mécanisme du W-105 déjà consigné ;
priorité solaire pour la voiture à batterie pleine (coût marginal nul : 6-7 trackers sur 7 bridés = ressource refusée) et interdiction de fermer le contacteur pour charger une voiture en journée batterie pleine (~150 Wh).

Document mis à jour le : 31/08/2026 (~18:20) — fenêtre d'établissement déployée dans src/, golden 48/48, PUT n8n en attente de validation

115 KiB Raw Blame History Unescape Escape

HANDOFF.md — EVCS / Grid Hysteresis — État au 09/07/2026

1. Contexte Projet

2. Architecture Data-Flow

3. Patchs déployés le 09/07/2026 (session opencode)

P1 — Grid Hysteresis (déployé, vérifié)

P2 — EVCS V2.6 : continuité takeover nuit / anti-créneaux (déployé, vérifié en réel)

P3 — EVCS V2.6 : provocation PV batteries pleines (déployé, dry-run complet)

P4 — Maintien SOC adapté au forecast pendant le takeover nuit (déployé 09/07 après-midi)

Autres réalisations du 09/07 (après-midi)

P5 — Plafond courant EVCS configurable quand EDF est ON (déployé 09/07 soir)

P6 — Override « abondance » du plancher SOC de démarrage (déployé 12/07 midi)

Maintenance du 09/07 soir (analyse des messages d'erreurs)

4. Root Cause de l'incident « EDF ON à 48 % sans charge Jeep » (nuit 08→09/07)

5. Sémantique utile (pour ne pas re-chercher)

6. Méthode de travail validée (à réutiliser)

7. Backlog / Point du 10/07 au réveil

8. Historique des sessions

⚙️ CONFIG LOCALE — Qwen3.6-35B sur DGX Spark (≠ gros modèle cloud)

Infra (validée le 16/07/2026)

opencode.json (poste Ubuntu, PAS la Spark)

RÈGLES DE TRAVAIL spécifiques au local (dans AGENTS.md)

PÉRIMÈTRE (le plus important)

🧩 SKILLS n8n — validées le 16/07/2026 (Qwen3.6 local, PAS gros modèle)

Installation

Skills ACTIVES (5, validées par test réel sur DECISION_ENGINEV2)

Skills DÉSACTIVÉES (déplacées dans .opencode/skills-off/)

Résultat du test de validation (5 skills, DECISION_ENGINEV2)

RÈGLE contexte associée (dans AGENTS.md)

PÉRIMÈTRE (rappel)

9. Session du 18/07/2026 (matin)

Corrections documentation (MANUEL_COMPLET.md)

Modification workflow

Versionnage Git

10. Session du 04/08/2026 (matin) — Fix grid HC 1h30 + libération takeover

Problèmes诊断qués

Root Causes identifiées

Corrections appliquées

Fix 1: gridAllowedBySoc — Autoriser le grid en profile night_hc

Fix 2: nightTakeoverLatched — Libérer si charge terminée

Méthode de déploiement

Backup

Vérification

11. Session du 07/08/2026 — P7 : Charge HC nuit automatique (VW hybride) + outillage push

Problème (nuits du 05-07/08, observé sur l'historique HA)

Root causes

Fix P7 (déployé 07/08 ~15:45, dry-run 7 scénarios validés)

Outillage (résout le blocage minimax « impossible de pousser dans n8n »)

À surveiller (prochaine nuit HC 01:24→07:24, VW branchée)

12. Session du 07/08/2026 (soir) — R1 : Déduplication du moteur nuit

Contexte

Fix R1 (déployé 07/08 ~19:03, A/B validé)

Validation A/B (tools/ab-20260807-r1.mjs)

Outillage ajouté

Prochaines étapes du plan validé

13. Session du 07/08/2026 (soir) — R3 : Suite de tests golden

Ce qui existe désormais (tests/golden/)

Usage

Intégration au déploiement (le point clé)

Validation par mutation

Résumé testé par scénario

Notes de comportement figées (découvertes en écrivant les attendus)

Prochaines étapes du plan

14. Session du 07/08/2026 (soir) — P8 : Libération EDF quand le véhicule est plein

Spécification utilisateur

Bugs découverts en traçant la spec

Solution : mémoire AUTO-ENTRETENUE via l'état surplus (P8)

Nœuds modifiés (tools/patch-20260807-p8-release-full.mjs, rejouable)

Validation

Comportement attendu cette nuit (VW branchée, checklist complète)

15. Session du 07/08/2026 (soir) — R2 : Git = source de vérité du code des nodes

Nouveau layout

WORKFLOW DE MODIFICATION DÉSORMAIS (règle inscrite dans AGENTS.md)

Validations effectuées

Plan de maintenabilité : état

16. Session du 07/08/2026 (nuit) — Agent IA planificateur en MODE OMBRE

Ce qui tourne désormais

GARANTIE MODE OMBRE (structurelle, testée)

Helpers HA (package NFS /mnt/ARCH3/docker/HA/packages/evcs_advisor_shadow.yaml)

Première recommandation réelle (07/08 22:40, via qwen3-vl local)

115 KiB

Raw Blame History

Fix 1: `gridAllowedBySoc` — Autoriser le grid en profile night_hc

Fix 2: `nightTakeoverLatched` — Libérer si charge terminée

Ce qui existe désormais (`tests/golden/`)

Test contrôlé EDF↔MPPT du 27/08 10:47-10:56 (relevé : `docs/mesures/20260827-test-edf-mppt.log`)

Nouvelle suite de tests : `tests/golden-hysteresis/` (7 scénarios, première