EVCS/docs/PROCEDURE_ESS_PARALLELE.md

# 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 |
|---|---|---|---|---|
| 30/08 21:46 | Consigne réseau GX | 4200 W | **50 W** | à faire (plein soleil) |
| 30/08 ~21:55 | Limite de charge (% de CCL) — *paramètre obsolète* | 95 % | **100 %** | remis au défaut |
| 30/08 ~21:55 | Limite de décharge (% de DCL) — *paramètre obsolète* | 20 % | **100 %** | remis au défaut |
| 30/08 22:0x | SOC minimal ESS | 40 % | **20 %** | ⚠ limite *active* encore à 40 % (BatteryLife) |
| | (VEConfigure, si nécessaire) | | | non entamé |

### Note sur l'épisode « paramètres obsolètes » (30/08)

Les lignes « Limite de charge/décharge de la batterie (% de CCL / % de DCL) »
de l'écran ESS ne sont **pas des limites de SOC** : ce sont des pourcentages des
courants que la batterie déclare accepter et fournir (*Charge/Discharge Current
Limit*). Portées à 95 % / 20 %, elles auraient plafonné la décharge à 20 % de
150 A = **30 A ≈ 1,5 kW**, là où la maison avait tiré 73,7 A le soir même et
108 A dans l'après-midi. Réseau ouvert — le régime habituel ici — la batterie
n'aurait plus pu servir la maison ; réseau fermé, l'écart serait revenu au
réseau, soit exactement la substitution qu'on cherche à supprimer.
Victron les range lui-même sous « Paramètres obsolètes » : DVCC (`forced_on`
avec une batterie managée en CAN-bus) en est le vrai propriétaire.
**Valeur correcte : 100 % / 100 %.**

### Note sur le SOC minimal et BatteryLife (30/08)

`MinimumSocLimit` a été ramené de 40 % à **20 %**, pour en faire un filet de
sécurité bas cohérent avec les seuils du contrôleur (plancher dur 22 %,
hystérésis réseau ON à 20 %) au lieu d'un concurrent de la cible du matin
(35 % en été).

⚠️ **La limite qui agit réellement n'a pas suivi immédiatement** :
`sensor.gx_device_active_soc_limit` reste à 40 %. Avec BatteryLife actif, le GX
maintient une limite *dynamique* propre, qui monte de 5 % quand la batterie
passe sous elle et ne redescend que de 5 % par jour de charge complète.
L'historique le montre sans ambiguïté : 40 → 45 chaque nuit, 45 → 40 chaque
jour, jamais en dessous de 40, sept jours durant.

Deux options :
1. **attendre** : la limite descendra 40 → 35 → 30 → 25 → 20 au rythme d'un
   palier par journée de charge complète, soit environ quatre jours ;
2. **basculer le mode ESS** sur « Optimisé (sans BatteryLife) » depuis l'écran
   GX (ligne *Mode*, au-dessus de *État BatteryLife*) : la limite active devient
   alors immédiatement égale au minimum réglé.

L'option 2 est la plus cohérente avec la direction du projet — une limite
dynamique cachée que rien ne lit est précisément le type d'acteur non lu qu'on
est en train d'éliminer.

**Retenue et appliquée le 30/08 au soir** (mode ESS → « Optimisé sans
BatteryLife », depuis l'écran GX : le mode n'est PAS exposé à Home Assistant).
Vérification immédiate :

```
sensor.gx_device_active_soc_limit    : 40 %  →  20 %                    ✔
sensor.gx_device_ess_batterylife_state : self_consumption
                                       → self_consumption_soc_above_min  ✔
```

⚠️ Faux ami à connaître : `select.gx_device_dess_mode` (options
`off/auto_vrm/buy/sell/node_red`) n'est PAS le mode ESS — c'est le *Dynamic
ESS*, piloté par les prix de l'électricité. Il doit rester sur `off`.

---

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