executeAction écrêtait le haut avec master->maxIntensity() mais le bas avec un
littéral 6.0. Une borne déclarant un minimum de 8 A aurait donc reçu une consigne
de 7 A écrite telle quelle : au-dessus du littéral, en dessous de ce que la borne
honore. L'asymétrie datait de l'écriture initiale — la lecture du registre 0x0BD1
existait déjà, elle n'était simplement pas utilisée là.
Les deux extrémités passent maintenant par courantMinimalEffectif() /
courantMaximalEffectif(), qui retiennent la PLUS CONTRAIGNANTE des deux sources :
la borne peut être plus exigeante que l'IEC 61851, jamais moins — une lecture
aberrante à 0 ne doit pas ouvrir la voie à une consigne de 3 A. La borne haute est
refermée sur la basse pour la même raison : RegMaxIntensity dépend de la version de
firmware, et un intervalle inversé ferait échouer setStateMinMaxValues.
Le même couple sert aux DEUX usages, et c'est le point : ce qui est publié comme
min/max du state (lu par le curseur de l'app et par
EvCharger::maxChargingCurrentMinValue() côté moteur) et ce qui est écrêté à
l'écriture. Les faire diverger donnerait un curseur qui propose une valeur que
l'action transforme en pause — une commande sans effet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
d526a1eaae