# 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.