Yes, that is exact what is supposed to happen: TargetSoc == 100% and MaxIdleSoc == 100% means, the system will “follow” the idle plan, despite consumption occuring.
Set a lower MaxIdleSoc, then it will switch to “Selfconsume_soc_high” and consume from battery, ignoring the 100% requested by vrm.
I’m using ~ 60% Max Idle Soc currently, because I know that 60% soc would be sufficent, to have enough energy until the next day - so I don’t want to idle the battery at anything above 60% but rather have regular ESS Mode (charge / discharge based on production / consumption)
Just note, that this will also “break” the periodic charge to 100%, if there isn’t enough solar to achieve that.
I’ve been reading here for some time and find the development extremely interesting. I know nothing about programming, so please forgive me. What I keep asking myself is, isn’t it actually a reaction to symptoms and not a solution to the actual problem? What leads to malfunctions/deviations from the schedule? Unforeseen changes to the forecasts or are we disagreeing on that? So it would actually make sense to work on these forecasts, wouldn’t it? Which is probably mainly a Victron problem. I don’t think the solar forecast is a bad solution in general, but it could be better. The consumption forecast could certainly be based on more factors. Nevertheless, I have the utmost respect for the work you do.
You are absolutely right, the calculated schedule is always smart with regards to the forecast - but the forecasts are sometimes very off, leading to differences beeing punished to the grid (either feedin or pull).
Yet, the original implementation on the device side is relying on the schedule too heavily.
No matter how precice a hourly forecast would be - it can’t predict solar ups and downs that happen on a per-minute base or faster.
So, having a 100% correct prediction of 3 kWh solar in the hour, resulting in a 3000 Watt charge rate, may be prone to (extreme example) the following:
first 30 minutes, you have 6000 watt solar - but the battery is charging 3000, feeding in 3000.
Second 30 minutes, you have 0 solar overhead, just covering consumption, Battery will now pull the still missing 1.5 kWh from grid.
So, goal will be achieved: 3 kWh charged - but also 1.5 feed in and 1.5 grid pull.
Therefore I think that - beside any good schedule - the local system needs to react to local conditions in order to get the most out of it.
The above exagerated example would have been avoided, if the system just noticed that it could charge more than 3000 watts - then it would have reached target soc, when solar overhead drops to 0, and can do half an hour nothing, reaching 3 kWh charged with 0 feedin and 0 gridpull.
Its basically like vrm beeing the controller in an airport tower - any advices are most likely good with regards to the overall picture - but this doesn’t mean the pilot shouldn’t watch out for bad weather, other planes or even tiny birds
Finally - this is something everyone needs to accept - acting based on a forecast will lead to wrong results every now and then, even if all decissions made sence at the time they were made.
OK… then as a pure “zero feeder” I am not so aware of the problem. A high/higher PV production leads to energy being shifted to one of the wall boxes or the heat pump. As a result, my consumption forecast is always a little higher than what we need as a minimum for the coming night. A lower PV production is also not a big problem because the consumption forecast is always a little too high. The electric cars usually have a time window of 3-4 days to recharge and the heat pump goes back to the minimum. For me there are currently no problems at all. I will continue to monitor
You sir, just made my day. You are right, with a 0-Feedin, that cannot happen, the system has to consume or charge.
And that means - to fix this issue happening - I don’t need to manually calculate a optimized charge rate - i could simply “lie” to the system, saying “hey, desired charge rate is 3kW - but we have a 0-Feedin restriction enabled” (as long as soc < 95% or sth - or to be more precice: as long as pv surplus < charge current limit of the battery)
By the way, I was still thinking about your analogy regarding air traffic control and pilots. In relation to this, I have a co-pilot. DESS as air traffic control, the MP2 as pilot and my own load control, which switches on the WB and heat pump when PV production is high, as a co-pilot for regional influences.
Unfortunately not. It’s not distinguishable from any other “charge to 100% request”.
However I don’t know, if there would be any other charge to 100% request at all. Most likely only for Trade-Mode
So, eventually that could be modified, so that you can basically opt to selfconsume at 70% - and if a 100% schedule is coming in - well, then could switch to 100% effective target soc again.
Today I observed the problem you described for the first time. Reloading because the target SOC was not reached. This led to reloading at a higher cost than necessary. 2 hours later would have been a better/cheaper option. If I have understood Dognose’s “hack” correctly, it simply suppresses this behavior under certain conditions. Which is certainly an approach. Wouldn’t it be even better if the schedule/target SOC was recalculated before the end of the hour, thus creating the opportunity to cover underproduction in a cheaper way. It may be that I am thinking too simply.
Yes, that one is not yet part of the public available hack.
(“Lower charge rate, while more solar available during scheduled charge by vrm”)
The reason here is that your soc is < targetsoc - hence as of now the system is accepting that it HAS TO CHARGE (“SCHEDULED_CHARGE”) according to the calculated charge rate, eventually accepting grid-pull - but your solar then does exceed the calculated charge rate, so overhead is feed in.
I’ve modified this on my system already, pretending a “0-Feedin-Restriction” is enabled when this situation occurs, to force the system to charge more - but still awaiting the situtation to happen again, so I can validate, everything works as expected, and make sure that there are no undesired side effects.
Discovered this here as well, but didn’t have the chance to validate my changes until today:
:
