What a dedication dognose!
So many parameters to include for getting things steered the way you want.
Also the interference from the BMS that restricts with CCL could lead to feed-in the grid and not getting things like planned.
1 Like
And again: it dumped PV to the grid instead of battery:
This is so fustrating! It happened exactly at 12:00 and fed nearly 500W to the grid, final strategy was SCHEDULED_CHARGE_SUPPRESS_FEEDIN at that time and battery was charged with 270W instead of possible 770W:
DESS Final Strategy meaning of plot colors not printed in the graph:
Cyan = IDLE_MAINTAIN_TARGET_SOC
Purple = SELFCONSUME_ACCEPT_CHARGE
=> I hope this gives you some insight @dognose
That is strange, but will review that.
As said, the SCHEDULED_CHARGE_SUPPRESS_FEEDIN basically does just tell the system, that there is a feedin restriction enabled (the goal is to have any feedin beeing surpressed and turned into battery charge - which apparently does not happen on your system.)
I will check the current code and see if there may be an issue with the underlaying implementation at that time.
3 Likes
I could imagine that itâs not calculating the total energy balance correctly, e.g. because of a wrong sign for one of the phases.
Please notice that on L1 my inverter is not connected before the Multiplus, i.e. at AC_in, but after it, i.e. at AC_out1. So the PV power from that inverter is passing the Multiplus (including itâs internal âcritical loadsâ current sensor) before itâs being measured by the grid meter.
Edit: it happened again today with exactly same symptoms and I was able to take a screenshot in VRM that shows the power on each phase (thatâs something I do not have in my Homeassistant records). So Iâm not sure anymore if itâs related at all to the fact that I have 2 PV inverters on 2 different phases.
Exactly at 11:00 SCHEDULED_CHARGE_SUPPRESS_FEEDIN kicked in and it started to feed more and more energy to the grid with a big bump around 11:20 which is shortly before I noticed it and disabled DESS.
Starting with beta v3.60~47 the hack is no longer compatible.
But majority of changes are now included in the beta 
5 Likes
Reading the Changelog for v3.60~47 I have a suspicion that a lot of your work has been officially integrated in VenusOS
Obvious question: will The Hack receive further development (in parallel to the features integrated natively in VenusOS) or will it just be integrated in VenusOS and disappear as an external mod/hack ?
I updated yesterday to the latest beta (3.60~48), but today saw some unexpected (non-)charging..
From noon it started selling to the grid, whereas the battery was only at 43%. super annoying.
Could you give me your your site-id?
The numeric one in the VRM url?
Will have a look at what happened there.
Iâve checked that. The System did everything smooth as ârequestedâ by the schedule.
Why the schedule requested a battery-idle from 12 to 15 ⌠I would need to check with the dev of the scheduler. Canât see any reason for that.
Today I did some reconfiguring and added a MP2 to the setup so I have more capacity to charge the battery from solar (I have more PV than a single MP2-3000 can handle).
Iâll monitor it for the coming days to see if there are strange behavious / unexpected export to the grid.
1 Like
Did anyone yet test v3.55 of Cerbo GX? Is the Feed in still a problem or does @dognose Hack still work?
Hack still works on v3.55 !
Only VenusOS v3.60~47 and higher are incompatible with the Hack.
1 Like
I have a question about DESS trying to reach MIN SOC at the end of the day.
I can see that in com.victronenergy.settings is /Settings/DynamicESS/MinSOC that I have set to 30% in my case. But all the calculations still target ESS Min SOC at the end of the day, that I have set to 15%.
The problem is that I again tried âGreen Modeâ with the hack and if DESS is selling to 15% in 01:00 at night then with my consumtion around 1kw per hour, the system is below 15% in the morning.
If it would honor that setting DynamicESS/MinSOC then I do not mind that it wants to sell battery to 30% so that tomorrows PV will fit there
Hi,
There is no com.victronenergy.settings/.../DynamicEss/MinSoc Setting. The value exposed in com.victronenergy.system/.../DynamicEss/MinSoc is just a dump of the EssMinSoc and not read, even if modified externally.
So, the System is using the regular MinSoc Setting.
What you could do (Some users do this through Node-Red): When reaching the SoC Value, bellow which you donât want to sell anymore, change the Mode from Trade to Green. Then DESS will stop selling and favor self-consumption.
However, I think the Trade Schedule should account for whether it makes sence to really sell down to min soc, or keep a bunch of energy to avoid more expensive purchases.
But the individual Strategy is highly system / price dependent and sometimes it requires very deep maths to figure out, DESS has actually created the most economical roadmap based on available predictions.
Iâm actually using green mode and not trade mode.
So it is mystery for me why it try to sell all.
My max day production is 70kwh, I usually use 25-35kwh in 24h and my battery is 80kwh.
So for the next day PV to fit in the battery it must not sell to 15% (my case min soc for ESS). Selling to 30% is suffient
Here is image from few days back when I allowed dess to sell to grid.
Iâm not sure if in Green mode & Hack applied the system is even supposed to be selling from battery to grid.
Right, the hack shouldnât do that anyway. (Didnât implement a discharge2grid logic)
But that ofc. doesnât impact that DESS (Remote-Site) creates a schedule planing to do that.
If you have variing Feedin prices (high at evening / night), then also greenmode will schedule to sell excess battery to the grid - but only as much as it estimates to be unneeded.
Therefore, if you want the schedule to reflect in itâs soc-prediction what really will happen, you can add a 24/7 bat2grid restriction, then the schedule will not assume any bat2grid that at the end (due to the hack) wonât happen anyway.
If you have variing Feedin prices (high at evening / night), then also greenmode will schedule to sell excess battery to the grid - but only as much as it estimates to be unneeded.
This is not correct, I allowed sales to grid and DESS generated that at 20:00 it should sell to grid.
But if you look at my graph, then tomorrows PV will fit without this Bat2Grid sell.
And why it thinks that I do not need that 1,32kwh of energy?
Here is DESS today graph.
Ok if I understand correctly then tomorrow it sells because next day prices is not available and if these are not available itâs default logic is to reach 15% (aka min soc in my case).
It seems that DESS has rethought itself and now wantâs to sell ~8kwh to the grid.
I do not thik that this is the energy my system does not need, If it sells that then there might be situation that battery goes under 15% in somewhere in the night and it starts to buy from grid.
Ok DESS does think that it will go to 15% and then there is PV. But again still why go to 15% at all when tomorrows PV will fit to the battery without selling???
