Grid current limiting in DIVERT_MODE_NORMAL

[Stef-Sijben]

At least in the Netherlands, but probably also other places, it is fairly common to have grid connections with rather low current limits on the main breakers, e.g. single phase 35A or 40A or 3 phase 25A for the whole household. If there are other significant loads present, this means that the EVSE would have to be set to a low pilot current in order to avoid tripping the main breaker for the house.
Some commercial EVSEs support a "load balancing" mode, where they monitor the grid current and dynamically adjust the EVSE current to not exceed the limit. I would like to suggest adding this feature to OpenEVSE as well.

This is quite similar to the existing eco divert mode and the changes implemented in #54, but there are a few differences:

• This would always be active, also (especially) when not in eco mode.
• This would be based on the grid I/E information, but instead of aiming for 0 import, you want to keep the imported grid current below a configurable limit.
• This limit needs stricter enforcement: If you exceed it for too long (on the order of seconds, depending on how much it is exceeded?), the house is left without power.
• Because of the previous point and related to Feature Request: Loss of MQTT connection disables EVSE #59, I would suggest that the EVSE enters a "safe" state when no message has been received on the grid I/E topic for a certain amount of time. The safe state could be a low current limit or completely disabling charging until information becomes available again.
• The maximum current allocated to the EVSE should still not exceed the configured value. E.g. house has 40A main fuse, EVSE is on a 32A circuit. Then we should never go over 32A pilot current, even when more is available from the grid.

[Stef-Sijben]

I've been working on this in my own branch at Stef-Sijben/ESP32_WiFi_V3.x@d8d1ba2, which is based on @jeremypoulter's divert_mode_off branch. It seems to work quite nicely with the characteristics mentioned above.

Only the interaction with the timer and/or pausing charge is still an issue. When the timer is configured and grid current limiting is active, they will get in a fight about the correct EVSE state. Outside the selected interval, the timer wants to go to sleep, while the diversion code wakes it up again, causing the state to oscillate all the time. Similarly, when the user pauses the charge, it starts back up right away.
I'm wondering whether these do play nice with the parent branch when in eco mode?
Anyway, I'm thinking maybe the timer should get a different role in this new context. I think it should specify when we transition between eco and normal mode, and perhaps add a force sleep/pause divert mode as well to fix the pause button.

The protection against relay cycling is also changed. Previously, when a charge started, it could not be stopped by the divert code until a specified time had elapsed. This would not be safe when the available grid current is less than the minimum, so we go to sleep immediately when less than 6A is available. Instead, when the divert code decides to go to sleep it cannot come back out of sleep for a fixed amount of time. Which version is preferred in eco mode is debatable, but I decided for simplicity to keep it the same in both scenarios.

Also still missing is configurability, all parameters are currently hardcoded. The main parameters are

• max grid current (0 to disable limit),
• grid I/E message timeout period (0 to disable timeout),
• possibly safe mode current (0 to go to sleep, >0 just sets that current).
  These would need to be stored/read in EEPROM and configurable through the web interface.

[jeremypoulter]

Thanks for this, my gut feeling is that a lot of this can be covered by the work I am currently doing on the PV divert, let me finish that up then we can see what is missing

[Zuikkis]

* This limit needs stricter enforcement: If you exceed it for too long (on the order of seconds, depending on how much it is exceeded?), the house is left without power.

I'd like to comment on this one. It's not really all that strict. Fuses are very slow.

Most household circuit breakers are C type. As you can see, for 1second they allow 5-10 times the rated current, that is 125-250A for 25A fuse..

Even if you look in the 4000 sec range (3600s=1hour), the fuse should allow 1.1-1.4 times the rated current, and that's average current for one hour..

So, I think for most cases it's enough to just have configurable max limit. Set that to 20A for 25A main fuses and it's very unlikely to blow a fuse..

Though, if this is easy to add, why not. :)

[jeremypoulter]

@Stef-Sijben We have merged the divert changes to master now, can you give it a test? There are some advanced options that should allow you to configure to suit this usecase

[Stef-Sijben]

@jeremypoulter Thank you, this is already a big step forward, but it's not quite there, unless I'm missing something. I think a few things should still be added to fully achieve this:

• Have a configurable import limit that is applied in normal charge mode. So in eco mode we try to balance import and export as it is now. In normal mode, the divert calculations stay active when this limit is configured. Then the goal is to maximise charge current without exceeding the limit.
• As noted by @Zuikkis, there is some margin to exceed the rated current for a while, but I still think there should be a timeout when we stop receiving updates. The updates are sent across a potentially unreliable network and any component involved might fail for an extended period of time. If this happens at an unfortunate time this could leave us in the situation where the limit is exceeded long enough to blow the fuse. And I don't think it's good practice to rely on the fuse characteristics anyway, I think it still wears out the fuse over time.
  I think the easiest option is to just stop charging when divert mode is active (eco or normal) and no recent information is available, but a configurable "safe current" could be added.

I can put together a pull request to add these features.

[glynhudson]

@Stef-Sijben active load management would be a great feature to implement on the OpenEVSE. We would welcome a pull request.

An MQTT feed for Grid Import can already be defined as part of the solar PV divert feature. It makes total sense to also use it be able to set a grid limit.

I agree, as a fail-safe if the grid limit feature is active the charge should pause (or at least drop to a low level) if no MQTT data is received. As mentioned in #59

[jeremypoulter]

#69 is also related, we could add an option to drive the heartbeat from data received from the MQTT server. This does however need the EVSE controller to have that feature in the firmware.

[Stef-Sijben]

I'm making good progress on this, see Stef-Sijben:gridCurrentLimit. I think it is working correctly now, including configuration of the new settings through the web interface, as long as the delay timer is disabled.
With the timer enabled, the divert code and the timer both try to set what they think is the correct state, so the state keeps oscillating between waiting and EV connected.

However, I was looking at how the current master resolves the interaction between eco mode and timer. As far as I can see the divert code uses the divert_active variable to avoid putting the EVSE to sleep when the charge was not started by the divert code (i.e. it was started by the timer). This is fine when the timer is used at night, but in some scenarios I believe this would go wrong:

• During the day, eco mode is active at low current, timer becomes activated. Now the charge would continue at the low current, not the boost as it should be.
• Same scenario, but the sun is going down, so at some point the smoothed current drops below the minimum. Now divert_active == true, so the EVSE is put to sleep. Probably the timer will wake it again, at the maximum current this time, but before that time the behaviour is not as it should be.
• The other way around: Eco mode is sleeping, timer activates. Then the sun rises and at some point eco mode takes over and reduces the current. Because the charge was not started by the diversion code, it will also not stop the charge after the timer has expired and the available current goes down. Although in this case the timer might stop the charge when the window ends and then eco mode picks up from there.

Am I still missing something here or is this indeed the current behaviour?
I think in order to correctly have current diversion and the delay timer interact, the divert code must know when the timer is active and change its behaviour accordingly. The current implementation is an approximation that is sometimes equivalent, but not always, as described above. So this is potentially a bug in 3.2.0, shall I create a new issue for that?

With the more complicated behaviour of the grid current limiting, I don't see how this could be resolved without correct information about whether the timer is currently active.

So then I see two options to get the information:

• The RAPI protocol is extended so we can ask the EVSE if the timer is currently active (meaning inside the configured interval).
• We read the timer settings from the EVSE and work out on the WiFi module whether we are inside the configured interval. Probably simpler because it doesn't need an update for OpenEVSE and RAPI, but having two sources of truth is always a bit risky.

[jeremypoulter]

Yes that looks like a good summary of the current situation, however there is a 3rd resolution, and the one we are probably going to go for. That is to move the timer code to the WiFi module. This will then allow us to do things like 7 day schedule, move the demand shaper to the WiFi module, etc. Not totally sure when this will be done however :(

[Zuikkis]

This actually became an issue for me as well. I now own a Tesla Model S which can charge with three phases each at 16A.. I modified my OpenEVSE box to three phases.

My house only has 3x25A main fuses, but what's worse than that, the garage only has 3x16A. In addition to Tesla I have three other electric cars, which each have (non-OpenEVSE) single phase chargers at about 2000W each (8-9 amps). They are all connected to different phase, so they don't disturb each other.

If only Tesla is charging, I can use full 3x16A for it. If any other car is charging, Tesla must be limited to about 7A to keep the total per phase under 16A.

But instead of modifying OpenEVSE code, I figured that I can just modify the MQTT grid import/export feed to control the ECO mode charging.

I was already using a custom program to create the MQTT grid feed for OpenEVSE. Something like that is needed for three phase anyway, to inspect all three phases and choose the highest value to pass to OpenEVSE, because OpenEVSE only understands single phase.

Now I have a button in Domoticz home automation that selects "solar charge" or "quick charge". If quick charge is selected, I simply subtract 3680W (16A 230V) from the grid values, before passing to OpenEVSE! That way OpenEVSE will limit the current so that total grid import stays at max 16A per phase.

My solar plant is also on the roof of that same garage. If there is solar power available and I start "quick charge", it will actually charge at solar power + 11kW from grid.. In that case the current can be much higher than 16A and not blow a fuse.

[wilcovh]

I would really like to see the grid limit implemented on another level as via the solar. I can do it via solar but it then disables the timer. I would like to be able to run the charging at the 4 hours cheap energy I have but more also needs to load. while the car can use the load available and ramp up when the hotwater and buffer tank loading has finished.

[wrightwells]

In the UK too the paperwork for the DNO needs to show grid limiting to 60% of the total property fuse. Or it requires a visit to determine load. With the increase of car charging installs there is a 8 week waiting list.

I’m doing it in Node-Red but the sparky wanted to see it in the app of the EVSE for him to sign it off as having grid limiting.
Although this also needs to be linked with the feature to stop charging if connection to the CT source aka the mqtt broker is unavailable.

[jeremypoulter]

@wrightwells That is interesting would like to see the exact requirements around this. I would have thought that this is just a static setting and does not have to be dynamic as the main house fuse is fixed? If static then this can be done as a write once operation via RAPI (for now) or via the GUI, if you want to be able to change later.

[wrightwells]

it can be static but to gain the full UK 32amps the calculation of the house demand is based on a percentage usage of the circuits in the property.

All EV charger installations need to inform the DNO but the deciding question is:

Maximum Demand less than 13.8kVA per phase OR the premises is CT metered OR the premises load is limited to below the known cut-out fuse rating

This is the form that needs to be completed
https://www.energynetworks.org/assets/images/Resource%20library/Single-Electric-Vehicle-Charge-Point-and-Heat-Pump-Installation-Application-Form.docx

[jeremypoulter]

So I think an OpenEVSE would normally be installed under the 3rd clause, for example my instillation is installed on a 32A circuit and the OpenEVSE is setup with a max current of 32A. Am I missing something?

Not that I am trying to say that this feature is not needed, just trying to guage if we need to increase the priority of implantation.

@glynhudson can you clarify more?

[wrightwells]

It’s the maximum load of the property not the circuit as in your example.

Asking the question to the DNO directly, they said that if the maximum demand of the property (calculated by the electrician) is above 60amps and not load limited then it is not just a notification to the DNO but you need to apply to them before connection.

The EV charger specific question is
Premises MD ≤13.8 kVA per phase OR where CT metered: Maximum AC output of EV charge points ≤30% of the Maximum Import Capacity.

Depending on the layout of the consumer unit i.e number of circuits and breakers. You need to take the calculation of the diversity of the circuits which gives a theoretical maximum demand. If this is over 60amps it appears that it needs to be CT metered to just be a notification to the DNO.

It will not be an issue getting the approval , just the time for the paperwork and possible visit.

The stupid thing is that my consumer unit was setup with 16 breakers , so the diversity calculation takes me over the 100amp main fuse, although I have a CT clamp monitoring our use over the last 3years and we have never go over 25amps.
A 8 bedroom mansion with pool , hot tub and ensuit showers would have the same 100amp main fuse and the consumer unit diversity calculation could be very similar but they may be close to that 100amps but definitely over the 60amps.

[wrightwells]

This looks like chargers installed in the UK after June will need to be ‘smart’ but doesn’t explicitly say grid limiting just : “it is able to respond to signals” , “increasing or decreasing the rate of electricity flowing through the charge pointl

https://www.gov.uk/government/news/government-funded-electric-car-chargepoints-to-be-smart-by-july-2019

https://www.legislation.gov.uk/uksi/2021/1467/contents/made

[jeremypoulter]

Some initial work towards this has been done as part of #382