d2163ffc88
Plusieurs scans successifs, aucun changement — l inventaire reste a 4 modules et 400 Ah. La capture au bandeau bleu a ete prise PENDANT un scan : il s est donc bien declenche et n a rien trouve de plus. Ce que ca elimine : l inventaire simplement perime. Le Cerbo redemande et le BMS agrege lui repond quatre. Le probleme n est pas cote Cerbo mais dans ce que le hub lui presente — ce qui promeut l etape 3, la seule qui demande si le pack 2 est joignable du tout par ce chemin. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj
192 lines
10 KiB
Markdown
192 lines
10 KiB
Markdown
# 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.
|