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`.*