Capacity tariff peak shaving — effekttariff (SE) / capaciteitstarief (BE)

Node-RED
, ,
1

Hi everyone,

I’ve been working on a Node-RED node for managing capacity-based grid tariffs, and it’s reached a point where I’d love to get more people testing it. Just to set expectations upfront: this is a work in progress, results are not guaranteed, and you should treat it as experimental.

The problem

Several European countries have already or going to introduce capacity tariffs that charge you based on how high your peak consumption is, not just how much energy you use overall. If your MultiPlus briefly draws 8 kW because the EV charger and the oven are running at the same time, that spike can cost you significantly more on your grid bill for the rest of the month.

  • Sweden (effekttariff): your grid fee is based on the average of your 2–3 highest hourly consumption values each month, typically measured on weekdays during winter (Nov–Mar)

  • Belgium (capaciteitstarief): based on the single highest 15-minute interval per month, with a 12-month rolling average — so one badly-timed EV charge can follow you for a year

The good news: a Victron system with a battery can actively shave those peaks, as long as something tells it what the current limit should be.

The goal of this node is to keep future peaks from passing already recorded ones.

What this node does

node-red-contrib-effekttariff is a Node-RED node that:

  • Tracks your consumption peaks throughout the month

  • Calculates a current limit (in Amps) to stay below your developing peak average

  • Outputs that limit directly to your MultiPlus via Ac/In/1/CurrentLimit

  • Optionally manages battery charging to ensure the battery is ready before peak hours

  • Exposes a status object and chart data for dashboard visualisation

It goes through a learning phase at the start of each month while it records enough peaks to set a meaningful target. During that time it runs conservatively.

Current status and limitations

This is genuinely a work in progress. Specifically:

  • It has been running on a small number of test sites for a few weeks

  • Simulation results look promising, but real-world savings will vary — consumption patterns, battery sizing, response times, and your specific grid company’s rules all matter

  • No warranty, no guaranteed savings, use at your own risk

If you do try it and something doesn’t behave as expected, please open an issue on GitHub — that feedback is exactly what will make this better.

Future direction

Like Dynamic ESS, this starts as a Node-RED project so the logic can be developed and validated in the open, with real installations. Whether it eventually ends up with a native implementation on the GX or integrated into VRM is something we can think about once the approach is proven — there is no timeline for that.

Getting started

Open Node-RED, go to Menu → Manage palette → Install, and search for node-red-contrib-effekttariff. Hit install, and wait a bit. Once installed, look for the Effekttariff node in the palette.

An example flow looks like this:

image
image1926×1102 268 KB

GitHub: https://github.com/dirkjanfaber/node-red-contrib-effekttariff

Simulation reports (to see what the algorithm does before connecting it to anything real):

https://raw.githack.com/dirkjanfaber/node-red-contrib-effekttariff/main/docs/simulations/index.html

Happy to answer questions, and very curious to hear from anyone running a Swedish or Belgian tariff who wants to give it a try.

2 Likes
Time-variable grid fees ("hourly peak shaving"?)
2

Small correction it’s not Belgium but Flanders (dutch speaking part off Belgium) in Wallonia there is a different system (3 timeframes with different gridcost).

3

Good point. I’ll adjust that. Though as far as I understand this is coming from EU regulations, so probably the French part of Belgium will also get this in one form or the other.
This is typically something that each country interprets and implements in its own way.

4

Indeed rules should be all over Europe the same but logic.

The current system we have in Flanders is not really a good system. Goal off a capacity tarifs should be flatten the gridload. With extra cost when there is a peak demand and lower cost when there is low demand. The ideal system would be 3 different measurements depending on time off the day + reduction when injecting at peak time. This can help to make te gridload more stable spread over 24h and would reduce the need off extra infrastructure to cover the higher and higher peak loads.

5

This is how I’ve been doing it for a while with ESS and Node-Red:
At 22:00, when cheap rate start, I set the Grid Setpoint to 2100W to charge the battery. Once SoC is reached, I disable charging until 7:00.

As you can see in this graph, the power consumption from the grid is a flat line. When the household needs more power at night than 2100W, the battery kicks in.

The capacity has never exceeded 2100W.

setpoint ESS
setpoint ESS710×417 22.2 KB

6

Just for my understanding, in an ESS situation where the whole house can run of your batteries,
wouldn’t this be something what could be acomplished by limiting the allowed grid load?
But this setting (and the ruling in general btw?) limits the possibility to help the grid in solar abundance periods??
What kind of period of peak load would be allowed? seconds? minutes?

7

In my situation, when the load is higher than solar plus battery, there is no way to limit the grid. Power has to come from somewhere.

8

It is the total off the 15min that is counted.

For example max peak load is 2.5KwH (this is the min that is charged) then your total gridload may never exceed 2.5/4 in a 15min timeframe.

To archive this you can limit gridcharge to max 2500W (gridsetpoint).

If you consume directly from grid (because this is cheaper then the battery for example) case inverter off then you need to keep eye on the delta from grid between start off the current 15min & the actual timing. If you reach 90% of this 2,5/4 then kick in the inverter with gridsetpoint 0.

9

@Marnix Good question. A fixed grid setpoint or current limit can prevent peaks, but it’s a blunt instrument: if you set it conservatively enough to always stay safe, you’re leaving available capacity on the table every hour of the month. What this node does differently is track your actual peak history throughout the month and adjust the limit dynamically. Early in the month when you have few recorded peaks it’s more permissive; as you approach your peak count it tightens. It also knows which hours and months count toward the tariff for your specific provider, so it relaxes completely outside those windows. For Belgium the measurement is indeed 15-minute quarter-hour intervals, as Stefan explained.

@Diederik That’s a solid approach and for many setups a fixed setpoint is exactly the right level of complexity. The node is essentially automating the same idea but adapting to what’s actually happened so far this month, rather than requiring you to pick a fixed number upfront. If you’ve already had two high peaks, it will limit more aggressively to protect the third. If you’ve had a quiet month, it gives you more room. It also handles the battery side - calculating how much charge is needed before peak hours start and ramping down charging once peaks begin.

For anyone who wants to look under the hood before committing to running it: the simulation reports show how the algorithm behaves across a range of scenarios. Feedback and issues on GitHub are very welcome. And thanks for the feedback and active discussion already.

2 Likes
10

I love that this is being done, i’ve seen a lot of self built solutions appear in the years capacity tariff exists, lets hope DESS surpasses them all.

For customers in Belgium just limiting the AC-in is currently the only solution without tinkering and like you said a blunt instrument. It also requires manual adjustment sometimes.

Some issues/wishes from solutions i’ve seen in the past;

-A peak shaving solution for a single inverter in a 3 phase grid.

-Supporting multiple methods of lowering the grid load, for example throttle heating/ev charger or switch of non essential loads through relay outputs/mqtt.

-Load planning; when the HEMS plans a load (charge EV, charge battery) it not only looks at the electricity price but also at the expected load in that timeframe and adjusts if necessary.

I will try to install it on my home system (never used node-red), send me a message if you want the VRM id.

Again, thanks for implementing this.

11

I installed the node and it seems to work, i will keep an eye on it.

One thing i noticed (and i may be wrong) is that the node tracks the average load of the last 15 minutes. In Belgium with capaciteitstarief energy is counted in 15 minute blocks starting at 15 minute intervals within the hour, so for example always 9.00h-9.15h-9.30h-9.45h-10.00h. The “kwartierpiek” is not a running average and never starts at for example 9.12h. The 24 hours in a day are essentially divided into 96 blocks.

12

Interesting. I will test this on a 3 phase Multiplus II 3000VA system in Flanders. What I’ve noticed already:

When setting the peak limit to 2.5kW (shouldn’t this be called maximum instead of minimum?), the current limit is set to 2500 / (3 x voltage) which equals 3.6A in my case. When consuming 2300W (10A) on 1 phase and nothing on other phases, then this is still below the limit. But the battery will unnecessary kick in wasting precious capacity. I do not see the current limit dynamically changing.

I would expect that the current limit for each 15 min period starts at a high limit or breaker limit and as soon as the average power for that 15 min period is exceeding the peak limit, then it will gradually lower to keep the average grid power at that level (= 2500W).

13

Great initiative and thanks for the explanation@Dirk-Jan Faber, I’ve just watched a video of Harold Halewijn in which he told that this same ‘capaciteits tarief’ will be in effect for Netherlands too in 2028? (Might not be axactly the same). So the function will probably be needed more in the near future. I’m in progress of installing a Victron whole house solution.

14

The good news: a Victron system with a battery can actively shave those peaks, as long as something tells it what the current limit should be.

How does it currently go about this?

Yes, if you have a 1 phase system you just set the peak for peak shaving to a few Amps that fit your typicall load (e.g. I? have a 44kWh car battery that needs to be charged overnight twice a week in 11 hours, so I have set my peak to 22A which at average of 230V gets me close enough and that would work for me)

But how would one accomplish the same in a 3 phase system?

the peak shaving featur works in Amps per phase, and in Belgium the peak is calculated as sum of phases.

How does someone set its peak to be 4.5kW over 3 phases by limiting individual phases? I can’t set it to 22 per phase anymore because that could give me a total possible peak of over 15kW

I calso can’t set it to 7A because that wouldnt let me just run my one phase heat pump without pulling from the battery whilst possible exporting over the other 2 phases.

So how do people set peak shaving in a 3 phase system here? Any hints would be appreciated.

15

I’m also trying to find the best way for peak shaving in Belgium. The method used in this node works, but is not optimal. It is only optimal if power consumption is equal on all 3 phases. In all other cases the battery will unnecessary kick in. The method used in this node is probably the best way for 3 phase systems and that is calculating the average power value. Whats missing here is the correct control of the current limit.

I’m now working on a function node based on the code found in this effekttariff node that controls the current limit based on the average power value for each ‘kwartier’.

  • When the average power is < then the peak limit which would be 2500W in my case, then no AC in current limit is set.
  • When average power >= peak limit then the AC in current limit will be set to peak limit / (3 x 230V).

This way you can still consume high power in a short period without the battery starting to peak shave.

16

15-minute fixed blocks (@mac)

The node uses fixed clock-aligned blocks (0:00, 0:15, 0:30, 0:45), matching exactly how Fluvius measures - not a rolling window. The documentation was unclear on this; it’s been clarified in the node’s help text as of v0.2.3.

Three-phase systems - how to set it up (@cbr, @DannyDG)

The capaciteitstarief is measured as total power across all phases combined by the digital meter - not per phase. So you feed the node the total grid power (sum of all three phases in Watts) as you would on a single-phase setup.

The node then outputs a per-phase current limit that the Victron ESS applies equally to all phases. For balanced loads this works fine. For unbalanced loads (one phase carrying most of the load), the per-phase limit can trigger unnecessary battery discharge even when total consumption is safely below the threshold.

v0.2.3 adds a Threshold-based limiting option (Electrical section in the node config) to address this - the current limit is only applied once the running average of the current 15-minute block actually reaches the peak threshold. This is essentially what DannyDG was building with a function node. For three-phase Flanders setups with unbalanced loads I’d recommend enabling it.

Netherlands (@Leeu4702)

The Dutch kWmaxgewogen tariff (2028) is on the radar. The proposed architecture is similar to the Belgian capaciteitstarief but with time-of-use weighting across five time blocks. Implementation is tracked but blocked until ACM finalises the exact block hours - expected end of 2026. I’ll update the node and documentation once that’s confirmed.

1 Like