Le hub reconnait les deux groupes — LED verte et trois bips, son accuse de reception — mais le Cerbo n en enumere qu un : 4 modules et 400 Ah la ou le parc en compte 9 et 650. Le releve de reference apporte le fait qui manquait : a 20:14 les quatre US5000 debitent 24 A au total pendant que le Cerbo annonce 41 A au parc. Les 17 A d ecart sont le pack 2, qui porte donc bien du courant sans etre enumere. Le courant mesure au shunt n est pas un indicateur d enumeration — seuls nombre_de_modules_en_ligne et capacite_installee le sont. Quatre etapes par risque croissant, la premiere ne touchant a aucun cable : un redemarrage du Cerbo, l inventaire ayant deja change une fois le 13/09 a 21:35, evenement isole verifie comme n etant pas un redemarrage de Home Assistant. Regle de securite tiree de l incident d aujourd hui : fermer EDF AVANT toute manoeuvre. Couper la communication du BMS arrete la gestion batterie, donc l onduleur, donc la maison — 72 secondes dans le noir a 16:24. EDF deja ferme, la maison passe en direct et ne voit rien. L etape 4 renvoie a la documentation constructeur et n avance aucune theorie de cablage : sur du materiel batterie je ne raisonne pas de memoire. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
7.1 KiB
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. |
⚠️ 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
- 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.
- 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.
- 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.
- Éclairer la baie. Le propriétaire l'a dit lui-même : l'incident vient d'une fiche débranchée de nuit.
- 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 — Forcer une ré-énumération, sans toucher au câblage
La moins risquée, et à faire en premier. L'inventaire a changé une fois, le 13/09 à 21:35 : le Cerbo ré-inventorie donc à l'occasion. Peut-être n'a-t-il simplement jamais rescanné depuis que les deux packs sont en place.
- Fermer EDF, relevé « avant ».
- Redémarrer le Cerbo (interface GX → Paramètres → Général → Redémarrer). Ne PAS toucher aux modules ni aux câbles.
- Attendre le retour complet, relevé « après ».
| résultat | conclusion |
|---|---|
| 9 modules / 650 Ah | c'était un inventaire périmé. Terminé. |
| toujours 4 / 400 | le Cerbo rescanne et ne retient qu'un groupe → étape 2 |
Retour arrière : aucun, rien n'a été modifié.
É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.