ESS Settings:
DESS Settings:
In other words, a pretty common ESS system. I looked at your data, and those grid exports were “commanded” by the control loop. This usually means there is a charging limit imposed somewhere, so to prevent the PV inverter power on the output from going into the battery, it has to send it to the grid.
The only issue, for me, is that nothing changed in Venus 3.70 related to how this works. We only made peak shaving fixes, and only when Self Consumption from battery is set to “output loads only”. There was one other fix, related to peak shaving while actively charging (eg, Keep Batteries Charged), but that is also not what your system is doing at this point.
So the only explanation I can see, is that something limited charge current at the time. This is unfortunately not logged to VRM, and you don’t have remote support on, so I was limited in what I could do.
Has it been tested with nodered disabled?
Hi Izak,
Yes it is indeed inspired by that chip 
Thank you for taking the time to look into it. I am positive that the charge voltage was 56.5V at the time of the screenshots and nothing else was preventing charge. I repeated the test on 27/2 as you can see in the next post. First screenshot 10:24 is on V3.70, rolled back to V3.67 at 10:25 and the second screenshot at 10:26 is on V3.67. For that test nothing besides the update/rollback was adjusted.
As for why the user defined voltage is nessecary (but please ignore this paragraph because it is not relevant to the issue and has been deactivated during testing): I am indeed setting a charge voltage of 54.8V from nodered once the battery is full (which it was not during testing). I deliberately omitted those details so as not to obscure the story (and because, of course, that would be the first thing people would point to). I disabled the necessary nodes for the test, and even turned off DVCC completely, but all with the same result. The reason for this user defined voltage is to allow transfer of DC PV power over the DC bus when the battery is full (and i am using that excess to heat a boiler on the AC side). My battery’s BMS is not lowering CVL when full, it only sets CCL to 0. As the MP uses this CVL voltage (56.5V) as ‘DC bus transfer voltage’, the battery is pushed into a OVP situation which we ofc do not want. So if the BMS decides the battery is full (which it determines based on pack/cell voltage), it recalibrates the SoC to 100 and sets the CCL to 0. I am setting the CVL tot 54.8V (which is a nice ‘absorption’ voltage for my battery) in nodered when CCL drops to 0. Aditionally i limit the charge current above 90% SoC to 40A so the battery is not pushed too hard in the final charge section. Excess power goes to a boiler thru an external PID loop. This workaround works perfect, but it would still be nice to have it embedded in fw for situations where the battery does not dynamically adjust CVL when full (eg. provide a ‘DC transfer voltage’ parameter which is used by the MP to transfer power at over the DC bus once the battery is full).
Today we will have excess solar, i have disabled all output nodes in nodered and updated to V3.70 at 9:33. At the moment the system behaves as expected (only thing i see is that the Grid power is fluctuating way more than before, but it does stay around the set 0W). When the solar input rises later today the issue should pop up. I will report back with the exact time of rollback later today. That way you will have more (and more relevant) data to look at.
Please let me know if there is anything else i can test on this setup.
The system is already exporting power to the grid for no obvious reason. I have also turned off the circuit breaker to the boiler as that would muddy the data (PID setpoint for the boiler is -100W so he would be taking the power)
Yes, I saw that, but I also noticed that this was not the reason for the limit, so that was not what I was referring to. A current limit of some sort would be what I would expect, for example, the DVCC maximum charge current setting. I see nothing like that coming from the battery. You seem fairly technical, so your input here is greatly appreciated.
I don’t think the peak shaving limits would be to blame. Those would not cause less charge to go into the battery, rather, it would cause more charge to go into the battery in some cases, in order to keep within the limits.
OK great, please turn on remote support, and I will take a look.
I have turned remote support on
Update from my side:
When I deactivate peakshaving, ESS is working fine. Also when I go back to V3.67, ESS works fine.
As lower the peakshaving import current, as higher the excess, see pictures below. From 20A and higher ESS is working fine.
I can confirm, peakshaving deactivated (good, 0W):
Peakshaving 40A (good, 0W):
Peakshaving 10A (not good, exporting. I really need it to be working at this level because we have capacity based rates):
Sorry for changing these paramaters during remote support I have only: Disabled PS > set 40A limit > back to 10A as it was.
Hi @555 and also @Pigmaster ,
I found the line of code causing the issue. I took the liberty of installing a version with this line reverted on both your systems, and you should see that it is now working correctly. This has however also unfixed a bug that prevents you from overriding peak shaving with a very large setpoint, so just don’t do that for now.
Thanks for reporting, I know where to look now.
Looks good indeed. Thanks for the quick response!
Thank you very much appreciated. System is working as intended now.
