The controller on the EVCS in offgrid mode seems to increment in 1A increments at a cycle time of 15 seconds. This leads to battery cycling that is unnecessary, and curtailment of solar power. Below is a ~3hour chart of the BESS charge rate that swings from >3kW to <4kW, a range of >7kW whilst my ability to charge the EV is only 6.5kW.
But it gets worse, on the upswings, the Multi curtails my AC inverter and DC chargers, so that doesn’t even show the real picture:
If a cloud comes over and the solar production drops from 6.5kW to 1200W, the EVCS controller would have a 6 minute response time, one can see from the image above that there’s only 3 minutes between curtailment events, as notified to me as “over frequency” in my notifications.
In the second half of the top chart, there’s a 1.65kW load that gets switched off below 3400W and switched back on above 3400W, so again it doesn’t show the real picture.
Can we please reduce the cycle time on the controller?
Can we please increase the increment value from 1A to 2 or 3 if the delta is greater than 4?
Today’s clouds weren’t even that bad, they were slowly moving, and not that grey, I’ve previously experience 95% swings in as little as a second.
Can we please be nicer to my battery?
…and i’m working on a node red implementation of a model predictive controller.
So the logic goes:
- if the frequency is above 50.2Hz, the the BESS charge setpoint is set to -500W, to allow the multi to bring down the frequency and the PV inverter to stop curtailing
- Dynamic setpoints to enable the car charger to be switched on in the morning, and allow the BESS to charge to 99%
- 2 second delay on the EV charger input to the calculate function to accomodate slightly for the deadtime between setting EV charger output and the car to ramp to the new output, the dynamic controller steps help it to not overshoot:
- dynamic steps in controller output depending on the BESS charge rate, to allow increments of 3A over 2200W, 2A between 1300W and 2200W, 1A at other times.
- there’s a 2A deadband around the setpoint due to being only able to increment in integers, so this provides a healthy stop on the controller helping it to hone in on the setpoint.
So far this responds really well to clouds, and injected 1650W disturbances.
Troughs of BESS discharge have been reduced in half by watts, and reduced in duration by a factor of 4-5, Peaks have been reduced by more than half and reduced in duration by a factor of 4-5.
Let me know if anyone wants the flow?
PS, I can’t code my way out of a bucket, but I do know what I want, so thanks to Grok for doing the coding for me.
Trends to follow when I get some clouds.
So below is the control
Few patchy clouds at the start, and some bigger ones at the end.
Disturbances include a 500W pump starting and stopping regularly, other than that just clouds.
Variation to positive was limited to 520W, and disturbances to the downside peaked at 1100W, a 6 fold reduction from the auto controller to the upside and almost 4 fold reduction to the downside. Duration of disturbances were also significantly reduced.
The two lines at +/- 1A are the deadband of the controller. During this time the setpoint of the controller was -70W as the battery was at 98%
Before
After:
And solar production for context over the same time period:
I converted the chart to watts, so it’s directly comparable to the first trend plot at the top of the page, the time period is a bit longer.
Got some more serious clouds later, as you can see by the dips going a bit deeper, I added a node to turn off the charger when we run out of sun, you can see that there’s insufficient sun from just after 15:50, where it dips permanently below the deadband, and you can also clearly see the pump kicking in at that point.
I also added a feature for it to stop calculating if the charger is off, so it doesn’t keep calculating all night, because offgrid.
I got rid of the delay on the calculation input, and put in a calculation rate limit, so it sees raw data, but does nothing with it until it is supposed to.
And I added dynamic calculation cycles, so it works faster the further from setpoint. There’s sufficient deadband to catch any over shoot, which has been at most 1A.
I trialled using the EVCS power and converting to amps, but my EVCS power is a guess at best, so that led to some weird outputs whilst close to setpoint, so I went back to the original and I now average them, since the EVCS Amps is only a confirmation of the setpoint, not how many A the car is pulling, whilst the EVCS power is what the car is pulling. Need some more run hours to perfect this.
New Flow:
