2bb3ff570b
Constaté au banc à 14:41:58 : l'avertissement « has a model 160 but no StCha/StDisCha block » a été émis une fois, au démarrage, sur une machine dont les deux blocs existent et dont le currentPower a ensuite suivi la batterie correctement en charge, en décharge et au repos. Cause. libnymea-sunspec crée les blocs répétés d'un modèle depuis `initFinished`, émis pendant la PREMIÈRE lecture, juste avant `blockUpdated`. Sur ce premier signal les blocs existent mais n'ont jamais été remplis : tous les `IDStr` sont vides, rien ne se classe, et `hasBatteryBlocks()` répond faux. Cette réponse est exacte et hors sujet — la question n'était pas « pas de batterie » mais « pas encore lu ». Ce que le faux positif coûtait. Ce n'est pas du bruit : le README dit à l'exploitation de chercher cette ligne EN PREMIER pour distinguer une batterie cassée d'une batterie non mesurable. Une ligne qui sort à chaque démarrage sain ne distingue plus rien, et le diagnostic que ce lot venait d'installer était mort-né. Les deux questions sont maintenant posées séparément : `blocksAreIdentified()` avant `hasBatteryBlocks()`. Sans identification, on se tait et on attend le tour suivant — `readBlockData()` passe à chaque rafraîchissement de toute façon. Le garde en double au moment du binding disparaît aussi : les deux updaters se gardent eux-mêmes, un seul endroit à tenir à jour plutôt que deux qui peuvent diverger. Deux tests figent la distinction, dont un sur le cas où l'avertissement DOIT sortir — un GEN24 sans batterie, lu, identifié, sans bloc batterie. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y3gzsuwENJfJtvuNDT3xGn