I’m starting a new topic now, because the old one became a bit confusing.
First of all: I have installed the smartshunt in the meantime, it has been running for 6 days, nothing has changed.
I also work in green mode, the way this mode works should be familiar.
Almost every morning, energy is drawn from the grid as the system tries by all means to meet the SOC target.
See the following example from just now:
At 10:00 a.m., the target SOC of the forecast jumps to 86%, the battery SOC is 61%. Now the battery starts charging with 2 kWh, the missing energy that the PV system does not supply is drawn from the grid. I turned on the stove for testing, nothing changes, the missing energy is drawn from the grid, the battery is charged in any case with 2 kW, from the grid.
I just want to know from Victron whether this is intentional or whether this could be a faulty configuration on my system.
In my opinion, in this case, the energy should come from the battery and the forecast should be postponed. It really doesn’t matter whether the battery SOC of 100% is reached at 11, 12 or 13 o’clock.
That is a commonly appearing behaviour. Either it is a (ongoing) Issue, or DESS is smarter than we are
Today, I was having the same Issue as well - but when looking at the current values, WHEN this is happening, it starts to make certain sence - just the DESS Graph does not outline the detail behind:
What DESS in Fact is doing in my case: Using the DC-Connected Charger to already charge the battery, using the AC-tied inverter + grid to sustain the loads.
The graph in VRM however considers this a “Grid2Bat” as in your case.
VRM is basically thinking: Consumption = PV, so we have that 479 from grid going in the battery.
With regards to current grid prices, it may indeed be “optimal” to use a certain amount from Grid NOW to directly power AC-loads, over having additional DC-AC conversion losses and later on add another round of losses, when doing Grid2Bat / AC-DC again to charge the battery later.
So, even if DESS is showing Grid2Bat in the graph - it is in Fact Solar2Bat and Grid2Consumption that is going on.
However, there is a second, older issue, that DESS is working with a “hourly target-soc” - and if that soc is not reached by the hour, it will do “something” to achieve the soc, like charging from grid. Thought this was resolved, but in the past days, there have been many posts, starting to report exactly this behaviour again, see for example:
I understood your explanation, but I don’t agree with it. In my case, PV was easily enough to supply the load, but the battery was still charged to reach the target Soc. I don’t really care whether it’s a mains to the battery or a mains to the load. That’s just for statistics.
It would have been right to have no supply from the grid at all, that would have been quite simple, simply charging less battery, lowering the forecast and thus the SOC target.
But using your available DC-PV to supply the AC Loads over charging the battery would have “lowered” the absolute gain by probably 15-20% due to required DC-AC conversion.
And at the end of the day you still need a certain amount of energy IN the battery. If you then have to compensate that (later) through a lossy AC-DC conversion, you are spending 30-40% more energy throughout the day compared to minimizing conversion losses and utilizing the Grid for “AC” loads earlier.
But this all stands and falls with proper “forecasts”. If you have enough solar later that you would even need to feed in - then the plan/schedule/forecast wasn’t accurate.
I absolutely agree that my first thought also was: “Why is it pulling from grid, over stopping charging and 100% covering the loads?”
Even if I have 5% more conversion losses from DC to AC, it is still better in this case to empty the battery first instead of drawing power from the grid.
To see who is right (DESS or you) we would have to await the end of the day.
If you reach 100% SoC and feedin - DESS more likely made the wrong decission.
If you don’t reach 100% SoC - DESS made the right thing by minimizing the overall required amount of Energy during the day by keeping conversion losses to a minimum.
It’s more than 5% losses, for sure. If you have MQTT / SSH Access, you can lookup the value DESS is assuming for your system, under: settings/0/DynamicEss/SystemEfficency For me, it is assuming 10% losses currently.
And this value would be off “twice” when doing DC-AC and AC-DC conversions that could be avoided.
I currently have 100% SOC at 12 o’clock every day and the battery almost always lasts through the night. Therefore, the forecast could have been easily postponed.
When you reach 100%, then you are right. Then the system should have concluded that it “is not necessary to grid-pull” by now. (Which I was discussing a few times with victron officials, but without receiving a proper statement if this would be fixed).
As it stands DESS has the possibility to postpone it’s soc-schedule - but it is unclear (to me) when and why it will do that - and when it will stick to plan. (Also there is no way to configurative take influence on this)
There are also user-topics that DESS will feedin available pv-power, when the target soc is reached to early - which is also irrational. So, lowering the DESS-forecast values (if that takes impact at all) would most likely result in this behaviour taking place.
And once again the same problem, DESS charges the battery from the grid, although the forecast says that 100% SOC will be achieved. This is now the 6th day in a row where this happens.
I can’t understand that and switch off DESS except for an explanation from Victron.
Hi @BuBu . Together with a colleague we’ve been looking into this. While knowing what the cause is, it wasn’t easy to come up with a solution that doesn’t just work for systems like yours, but won’t hurt other systems out there.
We are quite sure that we found a solution that covers that. At the moment we are working on implementing it, which should be ready later today. We will initially deploy the fix on a limit set of systems (including yours), before releasing it for the other users.
Thank you for your patience and I’ll post here as soon as it has been deployed.
