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
2bb3ff570b