EVCS/docs/PROTOCOLE_LVHUB_CERBO.md

Pourquoi le Cerbo ne voit qu'un pack sur deux — protocole de tests

Rédigé le 14/09/2026, après l'incident de 16:24.

Le fait à expliquer

Le LV-Hub reconnaît les deux packs — LED 2 verte et trois bips, qui sont son accusé de réception. Le Cerbo, relié à ce hub, n'en énumère qu'un.

nombre_de_modules_en_ligne  =   4          (attendu : 9)
capacite_installee          = 400 Ah       (attendu : 650 = 4 x 100 + 5 x 50)

Ce qui est déjà mesuré — à ne pas refaire

fait	mesure
Pack 2 porte bien du courant	14/09 20:14 : les quatre US5000 débitent −24 A au total, le Cerbo annonce −41 A au parc. Les 17 A d'écart sont le pack 2.
Les deux chaînes s'ignorent	Console sur pack 1 → 4 modules puis Absent. Console sur pack 2 → 5 modules puis Absent. Aucune n'énumère l'autre.
Deux familles, deux générations	Pack 1 : US5000, 48V/100AH, firmware B69.26.0.0, fabriqués 26-27/03/2026. Pack 2 : US2000C, 48V/50AH, firmware B69.13.0.0 et B69.13.2.0.
Le Cerbo passe par le pack 1	Débrancher le pack 1 → le Cerbo ne voit plus rien du tout (constaté par le propriétaire).
Pack 2 seul sur le hub a échoué	Batterie 0 et hub au rouge (constaté par le propriétaire).
Les deux packs sont sains	75 cellules du pack 2 à SOHCount 0 / Normal, compteurs 0-1. Pack 1 neuf, aucune alarme.
L'inventaire a changé le 13/09 à 21:35:09	Événement isolé — ce n'est pas un redémarrage de Home Assistant, dont le dernier gros pic date du 06/09 14:21.

Ce que les captures de la console GX ajoutent (14/09 au soir)

observation	pourquoi ça compte
Un seul appareil Pylontech est listé dans Configuration Système → Batteries : AIRTRIA 8 US2000C. L'autre entrée est AIRTRIA MP2, le moniteur du MultiPlus.	Le hub ne présente pas deux BMS au Cerbo mais un seul, agrégé. Le problème n'est donc pas « le Cerbo ignore un appareil » : c'est cet appareil unique qui n'annonce que quatre modules.
Le nom porte « 8 US2000C »	Ce device a été créé quand le parc comptait huit modules. Le nom a survécu à l'évolution du parc, pas l'inventaire.
Moniteur de batterie = Automatic, sélection retenue = le BMS Pylontech	Une sélection manuelle existe. À ne PAS toucher avant l'étape 4 : le BMS est le bon choix, c'est lui qui protège les cellules.
Capacité installée / disponible = 400 Ah / 0,0 Ah	La capacité disponible à zéro est anormale et n'a jamais été expliquée. À relever à chaque étape : si elle se remplit après un rescan, c'est le signe que l'inventaire s'est rafraîchi.
Les deux moniteurs donnent des courants différents — BMS −56,9 A, MP2 −37,1 A	Confirme que les deux mesurent à des points différents. Ne pas les comparer comme s'ils devaient coïncider.
Le GX tourne en Venus OS Large, avec Node-RED accessible	Moyen de lire ou d'agir directement sur le GX si les étapes 1 à 3 ne suffisent pas. Non utilisé pour l'instant.

⚠️ Le courant mesuré au parc n'est PAS un indicateur d'énumération. Le Cerbo lit le shunt, donc tout le parc, y compris ce que son BMS n'énumère pas. Les seuls critères valables sont nombre_de_modules_en_ligne et capacite_installee.

Règles de sécurité — tirées de l'incident du 14/09

1. FERMER EDF AVANT TOUTE MANŒUVRE, et le laisser fermé jusqu'au retour à l'état initial. Couper la communication du BMS arrête la gestion batterie, donc l'onduleur, donc la maison : le 14/09 à 16:24 elle est restée dans le noir 72 secondes, le temps qu'une automatisation referme le réseau. Avec EDF déjà fermé, la maison passe en direct et ne voit rien.
2. De jour, batterie ni pleine ni basse (SOC 40-80 %). Pleine, on ne peut rien lire sur la charge ; basse, on n'a pas de marge.
3. Une manœuvre à la fois, avec un relevé avant et après. Deux changements simultanés ne prouvent rien — c'est la leçon du premier test EDF du 27/08, confondu par un passage nuageux.
4. Éclairer la baie. Le propriétaire l'a dit lui-même : l'incident vient d'une fiche débranchée de nuit.
5. Retour à l'état initial garanti à la fin de chaque étape, même si l'étape échoue.

Relevé avant et après chaque étape :

node tools/releve-parc-batterie.mjs "etape N - avant" --console /dev/ttyUSB0
node tools/releve-parc-batterie.mjs "etape N - apres" --console /dev/ttyUSB0

Lecture seule, journal horodaté dans docs/mesures/.

---

Étape 1 — « Détecter à nouveau la batterie », le rescan ciblé

La moins risquée de toutes, et à faire en premier. La page de l'appareil porte un bouton « Détecter à nouveau la batterie » (Paramètres → Appareils → AIRTRIA 8 US2000C, en bas). Il annonce lui-même jusqu'à 30 secondes pendant lesquelles le nom peut être incorrect. C'est exactement l'outil qu'il faut : un rafraîchissement de l'inventaire, sans redémarrage et sans toucher un câble.

L'hypothèse qu'il teste est sérieuse : le device s'appelle encore « 8 US2000C », un inventaire qui n'existe plus. Et l'inventaire a bel et bien changé une fois, le 13/09 à 21:35:09 — événement isolé, vérifié comme n'étant pas un redémarrage de Home Assistant.

• Fermer EDF, relevé « avant ».
• Appuyer sur Détecter à nouveau la batterie, attendre le retour du nom.
• Relevé « après ».

résultat	conclusion
9 modules / 650 Ah	c'était un inventaire périmé. Terminé.
le nom change mais toujours 4 / 400	le rescan marche et ne trouve qu'un groupe → étape 1bis
rien ne bouge	le rescan n'a pas eu lieu → étape 1bis

Retour arrière : aucun, rien n'a été modifié.

❌ FAIT LE 14/09 AU SOIR — SANS EFFET

Le propriétaire a lancé plusieurs scans successifs. Aucun changement : l'inventaire reste à 4 modules et 400 Ah. Ses mots : « il s'en cogne totalement ». La capture portant le bandeau bleu « Détecter à nouveau la batterie peut prendre jusqu'à 30 secondes » a justement été prise pendant un scan — donc le scan s'est bien déclenché, et il n'a rien trouvé de plus.

Ce que ça élimine : l'hypothèse de l'inventaire simplement périmé. Le Cerbo REDEMANDE, et le BMS agrégé lui répond quatre modules. Le problème n'est donc pas côté Cerbo mais dans ce que le hub lui présente.

Ce que ça renforce : l'étape 3 devient la plus informative des trois restantes, puisqu'elle demande si le pack 2 est joignable du tout par ce chemin. L'étape 1bis garde son sens — un redémarrage reprend aussi l'initialisation du port, pas seulement l'inventaire — mais elle devient peu probable.

Étape 1bis — Redémarrer le Cerbo

Si le rescan ciblé n'a rien donné, le redémarrage complet reprend toute la détection depuis le début.

• EDF toujours fermé, relevé « avant ».
• GX → Paramètres → Général → Redémarrer. Ne PAS toucher aux câbles.
• Attendre le retour complet, relevé « après ».

Même grille de lecture qu'à l'étape 1. Si l'inventaire reste à 4 / 400 → étape 2.

Étape 2 — Inverser l'ordre de mise sous tension

Sur une chaîne Pylontech, l'ordre d'allumage détermine qui prend le rôle de maître et comment les adresses se distribuent. Si le pack 1 s'annonce toujours en premier, il est plausible qu'il « prenne la place ».

• Fermer EDF, relevé « avant ».
• Éteindre les deux packs. Rallumer le pack 2 d'abord, attendre sa stabilisation et les bips du hub, puis le pack 1.
• Relevé « après ».

résultat	conclusion
9 modules / 650 Ah	l'ordre était la cause. À consigner comme procédure de remise en service.
5 modules / 250 Ah	le Cerbo suit le premier allumé — il ne sait pas fusionner les deux groupes → étape 3
toujours 4 / 400	l'ordre n'y est pour rien → étape 3

Retour arrière : rallumer dans l'ordre d'origine.

Étape 3 — Le pack 2 seul, pour savoir si le Cerbo sait lui parler

Question précise : le Cerbo est-il capable de dialoguer avec des US2000C dans cette installation, ou seulement avec les US5000 ?

• Fermer EDF, relevé « avant ».
• Déconnecter le pack 1 du hub, laisser le pack 2 seul, comme le pack 1 l'est aujourd'hui (même type de liaison, même port).
• Relevé « après », puis tout remettre.

résultat	conclusion
5 modules / 250 Ah	le Cerbo sait parler aux deux, séparément. Le problème est la COMBINAISON → étape 4
rien du tout	le pack 2 n'est pas joignable par ce chemin — problème de liaison ou de port, indépendant du mélange

⚠️ Sur cette étape la maison tourne sur cinq US2000 seuls, EDF fermé. Courte, et ne pas la faire en pleine cuisson.

Étape 4 — Documentation constructeur, avant toute reconfiguration

Si l'étape 3 montre que chacun fonctionne seul mais pas ensemble, alors la question est celle du mélange US5000 / US2000C sur un même LV-Hub, et de la différence de firmware (B69.26 contre B69.13).

⚠️ Ne rien reconfigurer avant d'avoir lu la documentation Pylontech sur ce point précis. C'est un cas que le constructeur traite explicitement, et je ne raisonnerai pas de mémoire sur du câblage batterie. Les éléments à chercher, dans cet ordre : règles de mélange de modèles dans un même groupe et sur un même hub ; adressage et rôle maître par port du hub ; compatibilité des versions de firmware entre groupes ; et la procédure officielle de mise en service d'un hub à deux groupes.

Une mise à jour de firmware du pack 2 vers la génération du pack 1 est une piste possible mais pas démontrée, et elle se décide sur la documentation, pas sur une déduction. Si elle est retenue : sauvegarde des relevés avant, un module à la fois, et jamais pendant que la maison dépend de la batterie.

---

Ce que le protocole ne cherche PAS à faire

• Remettre en cause les 180 A. Les neuf modules sont sains et le courant se répartit physiquement sur tous — moins de 14 A par équivalent US2000. Le BMS garde la main, et il a démontré le 05/09 une réaction en cinq secondes.
• Réparer quoi que ce soit dans l'urgence. L'installation fonctionne : le pack 2 fournit son courant, tous les modules sont sains, aucune alarme.

Le seul vrai coût de la situation actuelle est que la protection cellule visible depuis Home Assistant ne couvre que quatre modules sur neuf. C'est ce qui justifie de comprendre, pas de se précipiter.

---

Nuit du 18-19/09/2026 — le detail batterie est mort depuis le 15/09, PAS a cause des packs

Ce que la nuit a etabli (a ne pas re-tester)

Le proprietaire voulait faire reconnaitre les 9 modules en passant le pack US2000C (5 modules) en maitre a la place du pack US5000 (4 modules). Trois configurations essayees, toutes lues en direct sur le bus MQTT du GX (battery/512) ET sur la console serie :

configuration	3 bips ?	BMS vu par le Cerbo	trames de BASE	trames ETENDUES
US2000C maitre → hub → Cerbo	non, jamais	oui (agrege)	ok	null
US5000 maitre → direct Cerbo (hub retire)	—	AUCUN — retombe sur vebus/MP2	—	—
US5000 maitre → hub → Cerbo (config du 12/09)	oui	oui (agrege)	ok	null

• trames de base = SOC, tension, courant, temperature, limites charge/ decharge (250/250 A), toutes les alarmes de base (no_alarm). Elles passent : le BMS protege le parc.
• trames etendues = System/NrOfModulesOnline, InstalledCapacity, Capacity, FirmwareVersion, Serial, System/MinCellVoltage/MaxCellVoltage et leurs IDs, le diagnostic par module. Toutes null dans les deux configs qui ont un BMS.

Les trois conclusions dures

1. Le detail etait deja mort le 15/09, avant toute manip de packs. Le §69 du HANDOFF l'avait mesure : 26 entites figees depuis le redemarrage HA du 15/09 05:09. Le « 4 modules / 400 Ah » que le Cerbo affichait etait une valeur figee et fausse (le dernier inventaire d'avant le 15/09, jamais rafraichi). Le renommage du device + la MAJ du Cerbo faits cette nuit ont vide ce cache : on est passe de fige-faux a null-honnete. Ce n'est pas une regression, c'est la verite qui remonte.

2. Inverser le maitre ne pouvait rien reparer. Le defaut est anterieur de deux jours et ne depend pas de l'ordre des groupes : US2000C via hub et US5000 via hub donnent le meme symptome au watt pres. Les 9 modules sont sains des deux cotes (console : ecarts 1-2 mV).

3. Le coupable est le hub / l'agregation, pas les groupes ni le Cerbo. Le hub presente au Cerbo un seul BMS agrege (une seule unit en console) et ne lui transmet que les trames de base. Le Cerbo, mis a jour cette nuit, n'y change rien.

Le mystere des 3 bips — resolu

Le proprietaire n'obtient les 3 bips (tous les groupes en ligne) qu'avec les US5000 en tete, jamais avec les US2000C en tete, et jamais avec deux cables bleus (un par groupe vers le hub). La seule combinaison qui donne les 3 bips : maitre US5000 → cable bleu → LV-Hub, et cable GRIS entre pack 1 et pack 2. La console confirme pourquoi : depuis un maitre, pwr n'enumere que sa propre chaine (5 modules cote US2000C, 4 cote US5000) et voit l'autre groupe Absent. Le chainage inter-groupes ne fonctionne, dans cette installation, que dans le sens US5000-tete. C'est un fait de cablage, pas un choix — a respecter.

Console du hub (branchee cette nuit, pour memoire)

help du LV-Hub liste : bat info pwr unit sysinfo getpwr datalist data log soh stat time cmdquit + les t* de test et updata/login (INTERDITS). Sortir par cmdquit avant de debrancher. Brancher la console fait redemarrer le hub (horloge retombee a 2000-01-01). ⚠️ En mode console, getpwr/sysinfo affichent SysError, Max Chg/Dsg Curr 0, coupure 396800 mV — ce sont probablement des artefacts du mode console, pas l'etat reel (meme piege que le 05/09). Ne pas conclure a une panne du hub sur ces valeurs. Le seul fait solide de la console hub : il ne voit qu'une seule unite agregee, ce qui confirme qu'il fusionne les deux groupes.

Etat retabli en fin de nuit (config a garder)

US5000 maitre → cable bleu → hub → Cerbo, cable gris pack 1 ↔ pack 2. 3 bips, LED STATUS verte, LED 2 verte. BMS actif, SOC reel, protection OK. EDF rendu a l'automatique, strategie auto_solar_plus, releve serie relance sur le pack 2. Le detail cellules cote HA reste perdu ; il est couvert par le releve serie automatique (deploy/releve-cellules/, les 5 US2000C).

Ce qui reste a instruire — A FROID, pas la nuit

Pourquoi le hub a cesse d'emettre les trames etendues vers le ~15/09. Pistes, sur la documentation constructeur et non de memoire :

• un firmware du LV-Hub (verifier version et disponibilite d'une MAJ) ;
• l'effet de la MAJ Venus OS du 18/09 sur le decodage des trames Pylontech agregees (deux variables ont bouge le meme soir — MAJ Cerbo ET manips packs) ;
• le format de trame etendu attendu par le Cerbo quand la source est un hub agrege plutot qu'un BMS unique. ⚠️ Ne PAS relancer d'essais d'inversion de maitre : la nuit a montre que ce levier n'agit pas sur ce symptome.

Redige le 19/09/2026 vers 01:45.

Complement de la meme nuit (~02:00) — reset hub ET sequence complete refaite : sans effet

Apres la premiere serie, le proprietaire a tente deux leviers de plus, EDF ferme et force a chaque fois :

1. reset du hub seul (sans toucher aux packs) → trames etendues toujours null, base intacte (SOC 77, 250/250 A) ;
2. sequence complete de mise en service refaite (extinction totale, 3 bips, DIP, cable bleu en dernier, hub allume) → identique, trames etendues null.

Bilan : six leviers independants, aucun ne ramene les trames etendues. rescan Cerbo · redemarrage Cerbo · MAJ firmware Cerbo · inversion du maitre · reset hub · sequence complete. Le levier materiel est epuise ; le refaire ne changera pas le verdict.

Ce que ca designe : le driver Venos can-bus-bms, pas le hub materiel

Le GX declare Mgmt/ProcessName = can-bus-bms, ProcessVersion = v0.71, ProductId 45065 / Pylontech battery. Il cree tous les topics etendus (NrOfModulesOnline, Capacity, MinCellVoltage…) mais avec value: null : son decodeur les ATTEND et ne les RECOIT jamais. Et §69 a date la mort de ces trames au redemarrage HA du 15/09 05:09 — un redemarrage HA ne touche pas le hub materiel. La cause est donc dans la couche logicielle Venus (driver can-bus-bms, ou un etat/reglage bascule le 15/09, ou la MAJ Venus du 18/09), pas dans le hub ni dans l'ordre des packs.

Prochaine piste, A FROID et sur doc : version du driver can-bus-bms de Venus et son changelog autour du 15/09 ; existence d'un reglage GX « BMS agrege par hub » ; et l'effet de la MAJ Venos du 18/09. Ne plus toucher au materiel batterie pour ce symptome — c'est demontre inutile.

Complete le 19/09/2026 vers 02:00. Service retabli : US5000 maitre / 3 bips, EDF auto, strategie auto_solar_plus, SOC 77 reel, releve serie actif sur pack 2.