Shaper not working anymore with release v5.0.2

[zerodur12]

I have install the release v5.0.2 on a EVSE with 8.2.3.T2 firmware and Shaper does charge current according to my real time house load,
for exemple the maximum power load is set to 8400W:

but the real power load is 9428W. The Shaper set up the charge current to 31,68A for this load which is to high. Charge current decrease only a little with the power load it look like there is a wrong scaling factor in the shaper charge current regulation
If I go back to previous recommanded release v4.2.2 everything work fine exemple:

For comparison release v5.0.2 versus v4.2.2 for the Shaper
You find below the graphic of the recorded shaper charge current regulation, EvSE power usage and house power load. From 22:00 to 22:16 the EVSE was working with release v5.0.2 and after 22:24 the EVSE was working with release v4.2.2

there no current regulation with release v5.0.2 and power load is not limited to 8400W
and after 22:24 the EVSE Shaper is working well with release v4.2.2 with a good current regulation

[zerodur12]

I have investigate a bit more the Shaper troubleshooting with release v5.0.2.
I have re-install release v5.0.2 and test again the Shaper
after the installation the shaper work again, exemple:

But I can reproduce the Shaper troubleshooting by changing the value of the maximum load power for exemple by setting from 8400W to 6000W while the EVSE is charging:

in that case the shaper is stuck to the previous value and it does'nt take into account the new value (or it taking into account after a long periode of time). To be sure that the new value is taking into account I need to stop the charge and/or restart the v5.0.2 firmware.
In the case case you are charging with the Shaper working and you want to increase the value of the maximum load power, there is no problem the value is taken into account and the Shaper increase the charging current to reach the new maximum load power

[prlm86]

I'm experiencing the same problem. I went into the shaper code, and I found this added code on v5.0.2:

if (livepwr > max_pwr) { livepwr = max_pwr; }

In my view, this makes that whenever "Live Power" passes over "Max Power", "Max Current" will result in the same value (evse.getAmps()), so nothing will change.

edit: add mention to @KipK for visibility.

[zerodur12]

I look into the shaper code also and like @prlm86, I don't understand the need to force livepwr = max_pwr in case livepwr > max_pwr in the shaper code

It seems this change was introduce with the merge New InputFilter class by @KipK in #590

[linuxkidd]

I'm having a similar issue, but mine isn't going to equal livepwr, it's going much higher, dangerously so..

At the time of enabling shaper, my EVSE was set to maximum of 40 amps, with a manual limit of 10 amps. Clearly, 45.78 A is no where near the right value.

[zerodur12]

@linuxkidd from my understanding what you show in your screen capture seems to be normal for me.
45.78 A is the free max current available. it is compute in current_shaper.cpp code by max_cur = ((max_pwr - livepwr) / evse.getVoltage()) + evse.getAmps()
this doesn't mean it is the one that will be use if you start charging your car. the real charching current will be limited by the smallest value between manual limit and free max current.
in your case with a power load of 935W, 9600W of Max power allowed no car charging ( evse current =0) and 190V of evse voltage
45.78 A ~= (9600-935)/ 190 +0

The problem I experience is current_shaper.cpp code in line 177 have introduce in the v5.0.2 (if compare with v4.2.2) the saturation of livepwr to max_pwr if livepwr >max_pwr just before computing _max_cur

By doing that it kills the shapper current regulation in case of livepwr > max_pwr.
deleting the line 177, 178 in the shaper code will solve the problem from my point of view

mention to @KipK for visibility.

[linuxkidd]

I think I figured out my issue.. at least, it's much more stable / predictable now.

I was feeding the power being used for all loads except the EVSE load. Once I adjusted my MQTT publish logic to add the EVSE power with the other loads, and thus, send the total power, it seems to behave much better.

Unsure if this is helpful to others in this thread.

A few suggestions for this:

1. Document that the Live power load MQTT Topic value is expected to be total power, inclusive of EVSE power.
2. Set a logic test in code that if the value published to Live power load MQTT Topic is a certain percentage lower than the EVSE's known power level, disable charging and throw an error for the Shaper.
   • I say a 'percentage' lower because there would need to be allowance for difference in measurement accuracy from the EVSE to whatever is providing the MQTT value.
3. Additionally, there should be a check that the resulting calculated current limit should never exceed the configured max current for the EVSE - lack of this can result in unsafe overload conditions.

[danpadure]

I have the same problem. Tested with multiple values
for example in the screenshot:
max power allowed 3000W
Load 7947W
Free: 31.46A

Somehow the Smoothed Current seems correct

[zerodur12]

@danpadure from my point of view to solve this wrong behavior line 177 to 179 has to be remove from current_shaper.cpp code
I try to test that but up to now I have been able to have a setup to compile the code on my Windows environnent (see #708)
so if someboddy is able to recompile the release v5.0.2 with line 177 to 179 remove from current_shaper.cpp code i'm ready to test this change.
mention to @jeremypoulter for visibility.

[jeremypoulter]

Before making any changes I would like to get some testing setup similar to that for the divert, so if we can start to collect some CSV files of the input data along with the expected response that would be great

[danpadure]

Sure Jeremy. What should I do?

[jeremypoulter]

Basically if you can log the feed data, eg using EmonCMS and then attach a CSV or a day or so to this issue I can use that to create test cases.

[zerodur12]

There is one test for witch there is no specific input data needed: setup the "Max power allowed" to a value that will be reach by the grid when charging a car for exemple set Max power allowed to 4000W. start charging, verify that the live power from the grid reach 4000W. Then change during the charge Max power allowed to 3000W the expected response is a decrease of the charging current such that the live power from the grid should decrease to 3000W. Today it is the case with 4.2.2 firmware but the 5.0.2 will be stuck arround 4000W for the live power and dont reach the new target

[danpadure]

Basically if you can log the feed data, eg using EmonCMS and then attach a CSV or a day or so to this issue I can use that to create test cases.

I can, but which inputs should I log, there are 73 of them :)
I already log a few like: amp, voltage, pilot, grid_ie

[jeremypoulter]

Just the one you use for the shaper.

[danpadure]

this is crazy. I started running the test, logging a lot of feeds for you
it started as usual, disregarding max allowed power.
after ~15 min suddenly shaper started working properly
I even changed max allowed power during testing, and shaper executed and ajusted power
you will see in the logs, but I have no explanation other than the house changed it's power usage but not much. I was not even paying attention, only noticed in mqtt explorer that I was running - it show a brief history

[danpadure]

Just the one you use for the shaper.
Attaching the CSV. NULL values at start are because they were not yet recorded as feeds
I had set max 28A, and shaper had max 5000W
Until 2023-12-11 22:06:00 openevse ran at pretty much max Amps, then it starts throttle-ing down
Then you can see how I kept changing the openevse:shaper_max_pwr to 4000 then to 6000 and the shaper followed it

graph.csv

[zerodur12]

@jeremypoulter
I have perform a record of shaper working with release 4.2.2 and release v5.0.2
from 17-Dec-2023 13:25:00 to 17-Dec-2023 14:45:00 the shaper run with release 4.2.2
Every thing work as expected I have change the value of the shaper_max_power from 8400 W to 6400W end the live power follow the change.
After 17-Dec-2023 14:45:00 the shaper run with release v5.0.2
and as expected whatever the value of live power the shaper power is suck to the initial value of 8400 W

You will find attach the CSV file of this reccord containing in colum:
TimeStamp;Live_Power;EVSE_Current_power;Shaper_Max_Power;Charging_Current;Current_Capacity;FirmWare
data_shaper_cvs.csv

[monfiston]

hello
I also have the same problem as you, the load shedding function does not work, it does not reduce the power
have you taken into account the problems reported here?
When will they be resolved?

media.mp4

[graememk]

I tested this, tonight, I also can replicate on v 5.0.2, Huzzah esp32.

(My connection can support 16kW+ but set to 10kW for testing.)

I did clone the repository, and comment out the livepwr = max_pwr;
Done a build and tested, Its working as expected again.
If the livepwr value ever got above the max_pwr value, it will never see any more load happening on the connection

eg max is set at 8000, livepwr is 10000,
It then sets livepwr to 8000, Never sees the increase in demand.

[danpadure]

so the solution is to comment a line?
@jeremypoulter check it and maybe implement it in the next version?

[graememk]

Possibly, I don't know the reason why it was put there initially as it could be there to fix something else.

[jeremypoulter]

It would be good to get some comment from @KipK, but I would tend to agree that those lines can be removed. In the meantime I will setup the testing to see what impact removing has. In the meantime I have created a draft PR with the lines removed.

Test builds can be downloaded from #784, click on one of the actions at the bottom of the PR then on the summary, the binaries can be downloaded from there. At time of writing this is https://github.com/OpenEVSE/openevse_esp32_firmware/actions/runs/7467645640?pr=784 but that link may not be the latest if any additional changes are added.

[KipK]

I now get why It fails with the saturation, livepwr contains evse loads, so saturation should remove it from calculation. Anyway as there's no issues with negative values, let's remove it

[jeremypoulter]

Thanks for checking