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.