PP_AUTO_AMPACITY should set absolute maximum charge for a single session

[glynhudson]

PP_AUTO_AMPACITY works well to set the correct max charge rate for the non-tethered cable in use. However, once a cable is connected or a charge is active it's then possible for a user to override this maximum by setting the current manually. For obvious reasons this should not be possible. How difficult would it be to make the max current set by PP_AUTO_AMPACITY the absolute maximum current for that session.

Update: After further testing it was found that the openevse does currently revert to the previous max charge setting when the cable in unplugged. Only the issue above remains.

Currently when a cable is unplugged is unplugged the display shows the pilot setting from the last cable to be used. e.g. if a 20A cable was used for the last charging session the display will show 20A when the cable is unplugged. This could be misleading for the next users of the station who understandably would think that this stations is only capable of 20A. While in fact when a 32A cable is plugged in the EVSE then increases the pilot to 32A.

[lincomatic]

The current setting on the front panel is for configuration of the EVSE, so I don't think that should be limited per session.
Via RAPI, the $SC command has an option for the setting to be volatile, or to be saved to EEPROM.
When the V (volatile) flag isn't specified, it's saved to EEPROM, and this is not supposed to be a per-session configuration value.

The only place I agree that maybe we should set a limit based on PP would be for $SC with the V (volatile) flag

[glynhudson]

Sure I understand that $SC is for configuration of the max current value. But don't you think that if a cable of XX capacity has been detected by PP than the max permissible current while this cable is connected should be XX even if $SC is used to try to set a higher current than XX?

[lincomatic]

Actually, now that I think about it, there are issues with the management of temporary (volatile) changes to max ampacity.

$SC can override over temperature throttling or any other volatile changes to the max ampacity.
Also, I think the PP code overrides over temperature throttling. I need to fix that. The EVSE knows when it's in over temperature, so it can try not to override that, but the over temperature code isn't currently aware of volatile changes in ampacity due to $SC or PP, so if an over temperature event happens, it goes back to the non-volatile max ampacity.
Ugh. Have to spend some time to really think through how to properly manage non-volatile max ampacity. It's considerably more intricate than it at first appears. And we might run out of code space trying to fix this.

[glynhudson]

Mmm yeah good point. I guess to be on the safe side we should always air on the side of caution and limit the charge rate to the lowest value E.g PP, over temperature should always take priority as the max current rate over $SC.

[lincomatic]

We have only 1240 bytes of code space left, after the latest fixes, unfortunately. I am having doubts that we will be able to fit this in, but I will try

[lincomatic]

I was able to fit in the fixes. It is difficult for me to test it. Please test and report back.. again, code is in test branch.

1. don't let $SC with V raise ampacity above PP max ampacity
2. when in over temperature event, don't let $SC with V raise ampacity.. can only lower it

[lincomatic]

changed the code.. doesn't check for V.. always applies:

1. don't let $SC raise ampacity above PP max ampacity
2. when in over temperature event, don't let $SC raise ampacity.. can only lower it

in D5.0.0 in development branch