openevse_esp32_firmware
openevse_esp32_firmware copied to clipboard
OpenEVSE
Solar Divert not using smoothed current
My hybrid inverter has a very hard time with super fast decreases in current so when I graphed pilot, available current and smoothed current, it is obvious the pilot does not follow smoothed current and jumps up and down very fast. Looking at the code, smoothed current doesn't seem to be used.
https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/b8d1addc4fcf47c51b1c559e5a10d9c0f382bfff/src/divert.cpp#L218
This is the expected behaviour, and the graph you posted shows exactly why. The smothered current is only used to start/stop the charge, as that can cause damage to the EVSE and the vehicle if done rapidly, but changing the rate once charging has started is not damaging so we react to the actual current to reduce the amount of imported energy.
Also I am not sure I understand the relation to the inverter, the current is coming out of the inverter irrespective of if the EVSE is in operation or not, it will either go to the vehicle or to the grid right?
Unfortunately, that’s not how some inverters with batteries work. There are complex control loops that control how much power is exported or if battery should be used to offset the load in the house (peak shaving). When there is a huge decrease in energy like dropping from 24A to 6A, the inverter has to absorb all that power that is being pushed by solar panels so it tries to dump the energy into the batteries. When you have full batteries, that can be especially bad. This is further exasterbated when grid is down and running off-grid with batteries, the control loop can’t cope with big surges in demand and negative demand so it would be best to use the smoothed curve to adjust the change in pilot.
Interesting, is this not a case of updating the OpenEVSE data faster then? I would have thought that having the EVSE track the available solar closer would be better for that case? Or are you saying it would be better to have a smoother load on the inverter and discharge the battery? We could possibly add an option to do this but generally this is not what people would want.
I thought the whole point to the smoothing parameters was to control how closely the curve follows the actual current. I set up a fast increase but slow delay. Wouldn’t someone that wanted to follow closely set up the parameters accordingly?
I theory, following solar exactly makes sense but because of sensing and delays to mqtt, it is hard to follow exactly the instantaneous production so it will be a lot harder on the electronics.
Also, if solar is strictly coming from a solar only grid tie inverter, it will always push the maximum amount of power without much of a control algorithm but with these new hybrid inverters with batteries, it depends on settings, limits for export set and battery capacity, it starts to manage the MPPT power, AC coupled solar power and zero export features. Having the ability to to slow down characteristics of the EVSE load is beneficial for everyone.
If I simply make that one line change and compile the bin file using platformio, do I need to mess with and upload any of the GUI elements? I can do that pretty easily.
I just realized the whole code for divert has been reworked so the image above is for 4.2.2 and not current top of tree.
So I changed the following lines to get it to use smoothing:
The problem I have now is that I can not use a smoothing attack of less than 1 sec. Even at 1s, the smoothing is pretty slow from the graph below. The part where I've circled this is when I changed both attack and decay to 0.9s. Seem like the default values of 20 would be way too slow no?
I may have answered my own question. Currently running for a while to see how the smooth curve performs.
After adjusting the two lines of code and setting the minimum tau constant to 1, I am able to tweak the smoothed current response. Awesome!
@goldserve : what are you using for your smoothing attack and decay settings now with the new version ? Are the changes still required ?
@jeremypoulter : as an alternative, would it be possible to have a min stop time, so that the charge rate of the vehicule can be adjusted more closely to the solar excess with lower attack and decay durations, and after that, control the minimum stop time and minimum charge time so that the contactor does not start too often ?
@goldserve : what are you using for your smoothing attack and decay settings now with the new version ? Are the changes still required ?
With the two changes above, I am using attack of 1 second and decay of 3. Let me know if anyone wants more graphs to look at but it’s been working great.
@goldserve : what are you using for your smoothing attack and decay settings now with the new version ? Are the changes still required ?
With the two changes above, I am using attack of 1 second and decay of 3. Let me know if anyone wants more graphs to look at but it’s been working great.
But these settings can trigger a charge to stop and another one to start a few seconds later right ? So it does not help reduce the wear of the contactor ? Or you have implemented something to prevent a charge from starting after another one within a minimal duration ?
@goldserve : what are you using for your smoothing attack and decay settings now with the new version ? Are the changes still required ?
With the two changes above, I am using attack of 1 second and decay of 3. Let me know if anyone wants more graphs to look at but it’s been working great.
But these settings can trigger a charge to stop and another one to start a few seconds later right ? So it does not help reduce the wear of the contactor ? Or you have implemented something to prevent a charge from starting after another one within a minimal duration ?
I thought there is a minimum charge time in the settings of 600 seconds which would prevent the wear you are talking about.
@goldserve : what are you using for your smoothing attack and decay settings now with the new version ? Are the changes still required ?
With the two changes above, I am using attack of 1 second and decay of 3. Let me know if anyone wants more graphs to look at but it’s been working great.
But these settings can trigger a charge to stop and another one to start a few seconds later right ? So it does not help reduce the wear of the contactor ? Or you have implemented something to prevent a charge from starting after another one within a minimal duration ?
I thought there is a minimum charge time in the settings of 600 seconds which would prevent the wear you are talking about.
The minimum charge time tells the minimal duration to stay in charge when a charge has started.
But there is no minimum "sleep" time as far as I know, which would be the minimal duration to sleep after a charge has stopped, before allowing a new one to restart.
I am not too concerned about stopping and then starting again after a few seconds because that rarely happens in practice. Having the minimum time on will help with total number of cycles and stop to start is just one cycle.
Ok.... I will try decrease the decay and do some testing today. Thamks!