Émis après le lot C, tout constaté sur .75 (plugin 1.15.2+etm15), rien corrigé côté moteur.
L'app s'est arrangée pour ne pas mentir en attendant.
1. Les compteurs cumulés d'Energy.GetPowerBalance sont CORROMPUS : totalReturn 9,1e+33,
totalAcquisition 7,5e+33, totalConsumption -1,6e+33 — alors que totalProduction est sain
et que les états du Thing compteur sont tous plausibles (1429 / 87,9 kWh). Ce n'est donc
pas le compteur qui ment, c'est l'accumulation au-dessus.
2. Renommer une charge ne parvient jamais à l'adaptateur : updateSoftConfig() ne porte que
priority et needs, donc le journal de la box garde l'ancien libellé jusqu'à la prochaine
reconstruction — trompeur en mise en service.
3. relays[] est comparé PAR INDEX dans sameHardware() : un simple réordonnancement
reconstruit la charge (contacts ouverts, verrous réarmés). Question de conception ouverte —
le routeur dérive toutes les combinaisons, l'ordre ne change rien au routage.
4. Les paliers dérivés ne sont publiés nulle part (powerLevels vide, télémétrie limitée à
maxStageW/stageW). L'app les dérive pour l'affichage : deux implémentations de la même
combinatoire, et c'est l'app qui aura tort si elles divergent.
5. minCurrent n'existe dans aucun champ de ChargingInfo alors que ChargingModeEcoWithMinCurrent
est publié : le mode se choisit, son paramètre non.
6. Pas de compteur dédié par charge. L'app affiche le bloc grisé, dérivé du schéma — il
s'activera seul le jour où le champ existera.
7. L'avertissement LM-200 attend typeAppareil : keyé sur domain il crierait sur des
installations correctes.
Plus la liste de ce sur quoi l'app s'appuie désormais et qu'il ne faut pas casser.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HajXLUczEyZd22JeewRfff
