Protocole LVHUB : la nuit du 18-19/09 - detail batterie mort depuis le 15/09, pas a cause des packs

Consigne les trois configs testees (lues en MQTT direct + console), les trois
conclusions dures (detail deja mort le 15/09 ; inverser le maitre n'agit pas ;
coupable = hub/agregation), la resolution du mystere des 3 bips (chainage
inter-groupes seulement en sens US5000-tete), et la config a garder.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GwpFpy2aQ2rJok6tNQSbVj

docs/PROTOCOLE_LVHUB_CERBO.md

@@ -189,3 +189,93 @@ la fois, et jamais pendant que la maison dépend de la batterie.
 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.*