AutoSetCurrentCapacity() should set a max current capacity not actual charge current.
KipK opened this issue · comments
PP_AUTO_AMPACITY fw have problems with wifi module. When a charge is started by the wifi module, and a charge current value has been set previously ( so wifi module sent an $SC command ) , AUTO_AMPACITY fw will check AutoSetCurrentCapacity() and set a new charge current value, overriding previous one. Charger then starts it charge at full amp capacity instead of setted value.
This cause problem with Divert mode and Shaper and any automation using settable charge current.
This is also a security issue as it can override the main circuit braker depending of house load.
AutoSetCurrentCapacity() should set a new Soft_Max_Capacity variable to not interfere.
This should solve #155 and some other issues pointed on OpenEvse Wifi git
Here is an extension proposal:
Add a new bool auto_amp_check , initialized to false
Add a new RAPI cmd to call auto_set_cuttent_capacity() and get the result
Then this simple algo should fit:
-esp: check ampacity rapi cmd
-evse: send back to esp ampacity . Set new var auto_amp_ok to true
-esp: receive ampacity, set max_current_soft to ampacity, send back charge_current to evse
--esp: send state change
-evse: change state to active , don't do auto_ampacity check if auto_amp_ok = true
- evse: set auto_amp_ok = false at vehicle disconnection.
No I don't think that is correct, the safety features should remain on the EVSE module and not depend on the WiFi module in any way. We need to ideally only change the current if it is set to a value greater than the new value, and also event it to the ESP32.
I don't propose a change in safety, just reporting back the info to wifi firmware.
For now ESP has no idea of what's going on on this point with the consequencies we knows .
Not doing the auto amp at start because it has been done few sec before is not really a change in the way it is.
Evse will still set it's current value according to the auto amp check, but ESP will be able to set it's own security feature ( as max_current is for ) , and set back the amps if < max_current.
Actually you totally can send a claim at 32A and set the evse accordingly, even if it has a 16A cable plugged in. I think the actual way is more problematic
Simple way of fixing blindly would be to set the charge capacity after ampacity check only if it's < previously settled one
But that still would be good to have the ampacity value on wifi and display it on the set current slider as max value.
On what I've proposed the evse module still works like before. But if there's a wifi module and it has already asked for the ampacity, just don't execute it again at state change.
Can someone point me to a spec on PP auto ampacity and explain the use case? We don't have this functionality in the US. When I coded it years ago, I did it under the assumption that EVs which implemented it weren't capable of reading the ampacity from the pilot PWM. Otherwise, I really don't understand the use case, except perhaps for load balancing purposes across multiple connected EVSEs
In Europe AC charger must be non tethered. User provide the cable.
But there's different cables, some are rated for 16Amps cable others 32amps, other less/more, so the check is made to read the resistance embedded in the cable..
I'll check to find you some doc.
from https://www.iqlaad.com/knowledge-base/proximity-pilot/
Current Limitation (Type 2 only)
The function of current limiting applies only to Type 2 plugs. The reason is that Type 2 plugs are both on vehicle side as on charger side. This is a main difference from the Type 1 plug which only has a vehicle side plug. While in Europe, the charger side has a type 2 plug, in North America and Japan, the cable is always attached to the charger making integral part of the Electric Vehicle Supply Equipment (EVSE). This implies that the current capacity of the cable is compatible with the charger. For a cable that is not part of the EVSE, the cable can have conductor thickness which is not enough to carry the maximum current the EV can draw and thus overheating the cable resulting in dangerous situations.
The resistor value in the type 2 plug indicates the conductor size of the cable. The conductor size determines the maximum current the cable can handle. The following values apply:
Resistor | Conductor size | Maximum Current
-- | -- | --
100 Ohm | 10 mm2 | 64 Ampère
220 Ohm | 6 mm2 | 32 Ampère
680 Ohm | 2.5 mm2 | 16 Ampère
1500 Ohm | 1.5 mm2 | 10 Ampère
Thanks for the information. It makes a lot more sense now.
I just pushed changes to new branch for you to test (I can't test this, since I don't have a Type 2 setup)
https://github.com/lincomatic/open_evse/tree/ppauto
It will only change the current capacity if it's current higher than what the cable is capable of.
In STATE B/C, $GC will return the soft limit of the cable if it is lower than the normal max. otherwise, it will just return the normal max
Thanks for this. I'm out for 10 days, will test when back.
seems good here 👍
@lincomatic Can you merge it now it has been tested ? Thanks for this.
Reopening this issue to get attention, sorry for that.
@lincomatic please can you merge pp_branch?
Openevse git wants to stay in sync with your master and it's an important fix. ( Even if we mitigated it on wifi module side )
Thanks
Sorry it took so long. I didn't notice the notification from github. I merged it yesterday. Let me know if it works as expected. Thanks.