d526a1eaae
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>