There is a good discussion ongoing on the topic of time-variable grid fees here. Status is (as I understand it) that Victron is working on implementing time-variable costs in the DESS. But I think that my question is slightly different:
We will get something similar to time-variable grid fees in 2026. The grid fees (meaning kr / kWh) will stay the same during the day, but there’s an additional fee for the average of three peak kWh/h readings each month. If I, for example, during three different hours this month pulled 4, 5, and 6 kWh from the grid (and less during all other hours), I would pay 5 * 45 kr in addition to the grid fees. This peak-fee is independent of the total energy used during the month.
In 2026, this fee will become time-variable and will be about 130 kr per peak kWh/h during weekdays and 0 kr during nights and weekends. This means I can save quite some money by avoiding high-consumption hours. I am therefore looking for a way to limit the total energy pulled from the grid each hour. This is not exactly the same as the peak shaving implemented in the ESS, as that limits the short-time power, not the hourly energy. Of course peak-shaving will limit the hourly energy as well, but I’m happy to allow higher peak power drawn under short periods.
It’s more a smearing out of the energy pulled from the grid that I’m after. If I by 12:40 notice that I’ve only pulled 0.5 kWh, but I’m averaging 2 kWh this month (or have set the 2 kWh target by some other heuristic), I can charge the battery during the remaining 20 minutes. Likewise, if I’ve pulled 2.1 kWh from the grid and it’s only 13:30, I would like to discharge the battery for the next 30 minutes instead of using the grid. Of course, making smart decisions becomes more complicated in combination quarterly energy prices.
Does anyone have an idea where I can even start? We have a 3-phase MP-II ESS setup with a 10 kWh battery, a Cerbo GX. I use HomeAssistant and I’m not unfamiliar with programming but I haven’t used Node.Red.
We are already running evaluations for different strategies for this kind of tarrifs. (And checking if DESS would be a suitable tool to handle this)
As to my understanding, the “key” would be to keep the accumulated grid-pull per hour to a “minimum” to keep that fees low, right?
So, my first attempt would be the following:
Use regular ESS
Set a desired Grid-Setpoint of for example 2000W (24/7)
Your battery will charge continuously with the remaining energy, if consumption is bellow that value.
Configure Peak-Shaving to match this 2000W
Thus, whenever your consumption exceeds 2000W, Energy will be taken from the battery to “shave the peak” - and as soon as that consumption spike is over, the battery will continuously recharge for the next peak.
Over time, you could adjust this value to something that is suitable for your system. In theory, you achieved the “optimal, minimum continuous grid load” , when your battery never hits 100% and when it never hits minsoc.
if it hits 100% → You could lower the 24/7 setpoint.
if it hits minsoc → You can’t stockpile enough to cover your peaks, you need to accept a “higher grid pull” during peak times to make the battery last long enough.
And with a very little node-red you could even adjust the setpoint based on time, because nightly the impact on final costs is “halfed” (So, you could allow a 4000W continuous grid-pull there, yielding the same average-costs as allowing 2000W during the day)
For a 10 kWh Battery, you are probably more in the situation that you have to see, “how high” a minimum grid-pull during peak-times needs to be, to be able to cover Xh of increased loads. for instance, if you frequently encounter 5000W for 4h, your battery can compensate roughly 2.5 kWh per hour - so you would need to have a continuous grid-draw of 2500W to achieve that, else your 4th hour will spike to 5000W grid pull.
Thanks a lot for your response! You’re of course right about the time-variable costs and the DESS is handling that part well for me.
Yes exactly. The challenge is keeping the accumulated hourly grid-pull low during certain times (e.g. weekdays 07:00 - 20:00 1 nov - 31 march), all while functioning as a ‘normal’ ESS with solar prognosis and variable electricity costs at all times. I get billed extra for the average of three highest cumulated hourly grid-pulls each month.
That is exactly right - but I would want the system to also take into account solar prediction and time-variable electricity costs.
Here’s what I’ve been testing since my previous post in October, similar to what you proposed.
I use the DESS
The grid point is permanently set to 30 W. I tried manually adjusting it, but in my experience that interfered too much with the DESS. I’d have to take into account tomorrow’s solar forecast (and lower the grid point when expecting solar) and quarterly electricity prices (often unnecessary to keep the grid point at 3 kW during peak electricity prices). The DESS handles those parts better than me.
Based on experience I set the peak shaving at 1/24th of the expected daily grid-pull (plus some margin), e.g. 3.5 kW in the winter for our house that needs around 70 kWh on a cold day. That worked fairly well during predictable conditions in the winter (high consumption around the clock, no solar).
Now that the sun is coming out, the expected daily grid-pull is harder to predict.
Anyway, I think that this might be the exact solution I am looking for, as long at it nicely integrates with the DESS. I’ll test and report back!
Thanks again for your help!
Edit: Maybe useful background: We pay one company for the transfer of electricity - the ones running the network. These are the ones charging the grid fees I’m trying to optimise here. We pay a different company for the energy we use, at prices varying on a 15-minute basis. This part is well handled by the DESS.
