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