From 457f4c8727d1818c37049fb11bcb1abc5153e644 Mon Sep 17 00:00:00 2001 From: Tallagrand Thierry Date: Sun, 30 Aug 2026 21:41:46 +0200 Subject: [PATCH] Consigne reseau a 4200 W : le proprietaire non lu de la substitution EDF MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Le symptome prouve le 27/08 (73 % de la production solaire remplacee par du reseau des que le contacteur se ferme) trouve une explication complete cote GX, sans toucher aux onduleurs. number.gx_device_ac_power_setpoint vaut 4200 W la ou le defaut Victron est 50 W. C'est le Grid setpoint de l'ESS : la puissance que le systeme s'efforce en permanence de prelever sur le reseau. L'ESS regulant la puissance au point de raccordement, son seul levier pour faire place a cet import quand la maison et la batterie sont deja servies est de brider les MPPT via DVCC. Les deux campagnes du 27/08 se reconcilient arithmetiquement : a 10:47 l'import monte a 4113 W, soit la consigne ; a 11:38 la batterie en absorption n'accepte que ~1070 W et conso 2258 + batterie 1070 - PV 1043 = 2285 W contre 2287 mesures. Le residu constant de ~1040 W etait la signature d'un plancher, pas d'une reduction proportionnelle. Seconde trouvaille : le SOC minimal de l'ESS est a 40 %, au-dessus de la cible de 35 % du controleur. Le GX recharge donc sur le reseau de sa propre initiative des que le controleur relache — etat `recharge` observe les 29 et 30/08. Troisieme automate contradictoire sur la meme batterie apres les charges programmees. Arbitrage laisse au proprietaire. L'assistant ESS tourne et aucune alarme VE.Bus n'est levee : l'hypothese d'un assistant perdu au passage en parallele est affaiblie, pas eliminee. La partie VEConfigure reste donc en seconde intention dans la procedure, avec sauvegarde obligatoire et interdiction de relancer le System Configurator. Aucun reglage n'est modifie ici : ce commit ne contient que le diagnostic et la procedure. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01KKzkkVTG6KXnGXFFC7X9XJ --- HANDOFF.md | 69 +++++++++ docs/PROCEDURE_ESS_PARALLELE.md | 248 ++++++++++++++++++++++++++++++++ 2 files changed, 317 insertions(+) create mode 100644 docs/PROCEDURE_ESS_PARALLELE.md diff --git a/HANDOFF.md b/HANDOFF.md index 910f67e..b3c3b34 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -1601,3 +1601,72 @@ 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* diff --git a/docs/PROCEDURE_ESS_PARALLELE.md b/docs/PROCEDURE_ESS_PARALLELE.md new file mode 100644 index 0000000..0088a29 --- /dev/null +++ b/docs/PROCEDURE_ESS_PARALLELE.md @@ -0,0 +1,248 @@ +# Procédure — corriger la substitution EDF↔solaire sur les 2 MultiPlus-II en parallèle + +> Rédigé le 30/08/2026, avant intervention. À suivre dans l'ordre : les étapes +> sont classées par **risque croissant**, et il est très possible que tout soit +> réglé avant d'arriver à VEConfigure. +> +> Rappel du symptôme à corriger (prouvé le 27/08, protocole alterné +> `docs/mesures/20260827-test-edf-mppt-alterne.log`) : dès que le contacteur EDF +> se ferme, la production solaire tombe de ~3 900 W à ~1 050 W et le réseau +> reprend la charge au watt près, à consommation inchangée. Quatre fois de +> suite, transitions en 75-90 s. Perte : **73 % de la production**. + +--- + +## Étape 0 — Trois lectures gratuites (à faire AVANT tout le reste) + +Aucune de ces trois vérifications ne touche à VEConfigure. Deux d'entre elles +sont des réglages du GX, modifiables depuis l'écran ou la console à distance, +réversibles en dix secondes. + +### 0.1 — La consigne de puissance réseau est à 4200 W (défaut Victron : 50 W) + +**C'est le suspect numéro un.** Relevé le 30/08 dans Home Assistant : + +``` +number.gx_device_ac_power_setpoint = 4200 W (défaut : 50 W) +number.airtria_mpii_v1_ac_power_setpoint_l1 = 4200 W +``` + +C'est le paramètre ESS *Grid setpoint* (`/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. À 4200 W, on ne demande pas au système de +s'équilibrer sur le solaire : on lui demande d'importer 4,2 kW. + +Et comme l'ESS régule *la puissance au point de raccordement*, il n'a qu'un +levier pour faire de la place à cet import quand les puits (maison + batterie) +sont déjà servis : **brider les chargeurs solaires via DVCC**. D'où la +substitution, et d'où le résidu remarquablement constant. + +Les deux campagnes de mesure se réconcilient exactement avec cette hypothèse : + +| Test | Conso | PV pendant EDF ON | Réseau | Vérification | +|---|---:|---:|---:|---| +| 27/08 10:47, SOC 71 % | 877 W | — | monte à **4113 W** | ≈ la consigne 4200 W, le surplus part en batterie (le courant batterie s'effondre de 104,6 → 25,7 A à la coupure) | +| 27/08 11:38, SOC 86 % | 2258 W | 1043 W | 2287 W | batterie en absorption, elle n'accepte plus que ~1070 W : `2258 + 1070 − 1043 = 2285` ✔ | + +Dans le second cas la consigne de 4200 W n'est pas atteignable (la batterie +sature), mais le système fait tout ce qu'il peut dans cette direction — et ce +« tout ce qu'il peut » consiste précisément à effacer le solaire. + +**Vérification (aucun risque)** — console GX / Remote Console : +`Paramètres → ESS → Point de consigne réseau`. Confirmer qu'il affiche bien +4200 W. *Ne pas conclure sur le seul nom de l'entité HA : il faut le voir à +l'écran du GX.* + +**Correction** : ramener à **50 W**. Valeur par défaut Victron, légèrement +positive pour garantir qu'on n'injecte jamais — ce qui est exactement le +régime voulu ici. +- soit sur le GX : même menu ; +- soit depuis HA : `number.gx_device_ac_power_setpoint` → 50. + +**Noter la valeur d'origine (4200) avant de changer.** Retour arrière = remettre +4200. + +⚠️ Il est très probable que ce 4200 soit un ancien contournement manuel, de la +même famille que les trois charges programmées de l'ESS désactivées le 27/08 — +mises en place à l'époque où le système ne tenait plus ses seuils. À confirmer +de mémoire avant de supposer qu'il s'agit d'un accident. + +### 0.2 — Le SOC minimal de l'ESS est à 40 %, au-dessus de notre cible de nuit + +``` +number.gx_device_ess_min_soc_limit = 40 % +sensor.gx_device_active_soc_limit = 40.0 % +``` + +En dessous de 40 %, l'ESS **recharge la batterie sur le réseau de sa propre +initiative**, sans rien demander à personne. Ce n'est pas une hypothèse : +l'historique montre l'état `recharge` deux nuits sur les sept derniers jours +(29/08 04:08, 30/08 01:21), précédé à chaque fois de +`soc_below_battery_life_dynamic_soc_limit`. + +Or notre contrôleur vise **35 %** le matin en été. **Deux automates avec deux +consignes contradictoires sur la même batterie** : le nôtre relâche à 35, le GX +reprend à 40. C'est le même cas de figure que les charges programmées. + +Ce n'est pas la cause de la substitution (les deux tests étaient à SOC 71 % et +86 %), mais c'est une source d'import réseau non commandé qu'il faut trancher. + +**Décision à prendre** (pas d'urgence, pas de risque) : soit descendre ce +plancher sous la cible du contrôleur, soit — plus cohérent avec la direction du +projet — le laisser comme **filet de sécurité bas** (par exemple 20 %) et +laisser le bilan énergétique piloter la vraie cible. À arbitrer ensemble ; +je ne le change pas sans votre accord. + +### 0.3 — L'assistant ESS tourne bien, et il n'y a aucune erreur VE.Bus + +Deux indices concordants, relevés le 30/08 : +- `sensor.gx_device_ess_batterylife_state` produit des états vivants et + cohérents (`self_consumption`, `self_consumption_soc_exceeds_85`, `recharge`) — + la boucle de régulation ESS **tourne**, elle n'est pas absente ; +- toutes les alarmes VE.Bus sont à `no_alarm`, aucune erreur d'installation + n'est signalée. + +**Conséquence** : l'hypothèse « l'assistant ESS a été perdu ou dépareillé entre +les deux unités lors du passage en parallèle » est **affaiblie** — sans être +éliminée, car un assistant présent mais mal paramétré ne lève aucune alarme. +C'est ce qui justifie de garder la partie VEConfigure ci-dessous en réserve, +mais **en seconde intention**. + +### 0.4 — Le test de validation (30 minutes, à faire après 0.1) + +Ne pas se fier à une impression. Rejouer **exactement** le protocole alterné du +27/08, qui a déjà fait ses preuves : + +- OFF 3 min / ON 3 min / OFF 3 min / ON 3 min, échantillon toutes les 15 s ; +- grandeurs relevées : PV, courant **et tension** batterie, conso, import + réseau, limite DVCC, mode ACM, modes de fonctionnement des MPPT. +- Conditions : plein soleil, batterie **non pleine** (SOC < 80 % de préférence), + et de quoi consommer (chauffe-eau en marche par exemple). + +Critère de réussite, sans ambiguïté possible : **la PV ne bouge pas d'une phase +à l'autre**, et le réseau reste proche de zéro pendant les phases ON. + +L'alternance est indispensable : elle interdit à une dérive météo de se faire +passer pour un effet, ce qui avait ruiné la première campagne du 27/08 à 10:47. + +Je peux relancer ce test dès que vous me dites que le setpoint est corrigé. + +--- + +## Étape 1 — VEConfigure, seulement si l'étape 0 n'a pas suffi + +### 1.1 — Ce qu'il ne faut surtout PAS faire + +1. **Ne jamais relancer le VE.Bus System Configurator.** C'est l'outil qui + déclare le nombre d'unités et les phases. Le relancer **efface la + configuration des deux onduleurs** et impose de tout refaire. On vient + modifier des réglages, on ne reconstruit pas le système. +2. **Ne pas mettre à jour le firmware dans la foulée.** Voir §2. +3. **Ne pas travailler sans sauvegarde préalable** (§1.3). +4. **Ne pas enchaîner plusieurs corrections.** Une modification, une + vérification, puis la suivante — sinon on ne saura pas laquelle a agi. + +### 1.2 — Matériel et accès : deux chemins possibles + +**Chemin A — Remote VEConfigure via VRM (recommandé, pas de câble)** +- Prérequis : le GX est en ligne sur VRM, et la **communication bidirectionnelle** + est activée (VRM → Paramètres de l'installation). +- VRM → votre installation → *Liste des appareils* → **Remote VEConfigure**. +- « Télécharger le fichier de réglages » : VRM interroge le GX, qui lit **les + deux unités** et produit un fichier de configuration **système** (extension + `.rvms` pour un système multi-unités, `.rvsc` pour une unité seule). +- Ce fichier s'ouvre dans **VEConfigure3** (Windows — paquet *VE Configuration + Tools*, téléchargeable gratuitement sur le site Victron). Un sélecteur permet + de passer de l'unité maître à l'unité parallèle. +- Puis « Envoyer et appliquer le fichier de réglages ». + +**Chemin B — Câble MK3-USB (si VRM n'est pas accessible)** +- Interface **MK3-USB** branchée sur un port VE.Bus (RJ45) de **l'onduleur + maître** ; VEConfigure3 détecte le système complet, pas une unité isolée. + +⚠️ **Dans les deux cas, l'écriture des réglages provoque un redémarrage bref du +VE.Bus** : les charges de la maison sont coupées quelques secondes. À faire à un +moment où c'est acceptable, et surtout **pas** pendant une charge de véhicule. + +### 1.3 — Sauvegarde (obligatoire, avant toute écriture) + +1. Télécharger le fichier de réglages **et le conserver tel quel**, sans + l'ouvrir en écriture : c'est le point de retour. +2. Le nommer explicitement, par exemple + `SAVE_CONFIG/vebus-parallele-AVANT-20260830.rvms`, et le mettre à l'abri + **hors du GX et hors du NAS** (le Synology est déjà un point unique de + défaillance connu du projet). +3. Photographier ou noter, depuis la console GX : point de consigne réseau, + SOC minimal, mode ESS, limite de courant d'entrée CA. Ces valeurs-là ne sont + pas dans le fichier VEConfigure — elles vivent dans le GX. + +### 1.4 — Inspection en lecture seule (rien ne s'écrit à cette étape) + +Ouvrir le fichier dans VEConfigure3 et **relever**, pour **chacune des deux +unités** (basculer avec le sélecteur d'appareil) : + +| Onglet | Point à vérifier | Ce qu'on cherche | +|---|---|---| +| **Assistants** | Liste des assistants installés | **ESS présent sur les DEUX unités**, même version. Un assistant présent sur le maître seul est la panne classique après un passage en parallèle. | +| **Assistants → ESS** (rejouer l'assistant en lecture) | « Y a-t-il un compteur réseau ? » | Doit correspondre à la réalité. Si l'assistant croit qu'un compteur externe existe alors qu'il n'y en a pas (ou qu'il a été désaffecté lors du passage en parallèle), la boucle de régulation lit une puissance réseau fausse et se comporte exactement comme observé. | +| **Assistants → ESS** | Type de batterie / tensions / *sustain* | Cohérence avec les Pylontech pilotées en CAN-bus. | +| **Grid** | Code réseau / pays | Un code réseau réinitialisé après reconstruction du parallèle peut imposer des comportements non voulus. | +| **Inverter** | PowerAssist, limite de courant d'entrée CA | Doit être cohérent entre les deux unités. | +| **Virtual switch** | Doit être **désactivé** | L'assistant ESS et le *virtual switch* sont incompatibles. | +| **Charger** | Tensions de charge | Largement outrepassé par DVCC avec une batterie managée — à noter, pas à corriger en priorité. | + +**Toute divergence entre les deux unités est un résultat en soi** : la noter +avant de toucher à quoi que ce soit. + +### 1.5 — Corrections, une seule à la fois + +Ordre recommandé, du plus probable au moins probable : +1. assistant ESS manquant ou dépareillé entre les deux unités ; +2. réponse « compteur réseau » de l'assistant ESS incohérente avec l'installation ; +3. limite de courant d'entrée CA / PowerAssist incohérentes. + +Après **chaque** écriture : attendre le retour du VE.Bus, vérifier que les +alarmes restent à `no_alarm`, puis **rejouer le test §0.4**. Si le comportement +ne change pas, revenir au fichier de sauvegarde avant d'essayer la correction +suivante — on ne veut pas empiler des modifications non concluantes. + +### 1.6 — Retour arrière + +Renvoyer le fichier `…-AVANT-20260830.rvms` par le même chemin (VRM ou MK3), +et restaurer à la main les réglages GX notés en §1.3. C'est pour cela qu'il faut +les avoir notés : ils ne sont pas dans le fichier. + +--- + +## Étape 2 — Mise à jour du firmware : à ne pas faire maintenant + +Si « mise à jour » désignait le **firmware** des MultiPlus-II, la réponse reste +celle du 27/08 : **aucune des mesures effectuées ne justifie une mise à jour**. +Les raisons de ne pas la faire dans le même mouvement : + +- sur un système en parallèle, **les deux unités doivent porter exactement le + même firmware** ; une divergence casse le parallèle ; +- une mise à jour firmware peut réinitialiser des réglages et **imposer de + refaire la configuration du système** — c'est précisément l'opération à + risque qu'on cherche à éviter ; +- on ne diagnostique pas deux variables à la fois : si l'étape 0 corrige le + symptôme, une mise à jour n'aura servi qu'à brouiller la piste. + +Si elle devient nécessaire un jour, elle se fait **avec accès physique aux +onduleurs**, jamais à distance, et après la sauvegarde du §1.3. + +--- + +## Journal d'intervention (à remplir au fur et à mesure) + +| Date/heure | Action | Valeur avant | Valeur après | Résultat du test §0.4 | +|---|---|---|---|---| +| | Consigne réseau GX | 4200 W | | | +| | SOC minimal ESS | 40 % | | | +| | (VEConfigure, si nécessaire) | | | | + +--- + +*Document créé le 30/08/2026. Relevés HA à l'appui : consigne 4200 W et SOC +minimal 40 % lus le 30/08 ; historique `recharge` des 29 et 30/08 ; alarmes +VE.Bus toutes à `no_alarm`.*