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

Node-RED
, ,
21

A very good initiative for the Belgian capacity tariff, which I fully support. That is also why I am actively testing the Node-RED node.

However, for Belgium the Node-RED node is not working properly. I already submitted a bug report two weeks ago, and I hope the issues will be fixed soon.

The bugs are that for the Belgian profile, off-peak hours (00:00–07:00) are still being applied, and there is an invalid “24” selection in Peak Hours.

As a result, the battery can charge at full power during off-peak hours.

22

Just to let you know that I am still developing on the project. But due to other priorities I can’t commit too much time to it right now.

Still trying to get an update out this week, but no promisses.

23

If true capacity tariff peak shaving is wanted an option to “charge battery in daytime when batteries are below %SOC” could be beneficial.

If you have more battery capacity than daily consumption the current “charge batteries once during off-peak” will suffice, but like me I have installed 15kWh and consume between 10-20kWh. And on most days I will have some solar to keep me charged, but during the worst winter weeks I might run into issues. I do note that a lot of it could be fixed with an additional battery.

An intermediate full charge during the day would cost me 15 kWh x 0,35€/kWh x 0,2 (conversion losses)= 1€, but one 15 min peak in the evening would cost me 4x80€/kW peak per year = 27€/month. And this is considering night/day tariff, if you have dynamic and cost is lower during it will rapidly be more economic to have an intermediate charge during the day than having a peak in the evening.

I was actually thinking about something along these lines:

  • 0-15% SOC: Reserved for off-grid mode (as per current ESS design)
  • 15-30% SOC: Reserved for peak shaving only, grid setpoint should be set to XX% of current peak limit.
    • If there is a big consumption: battery will shave off only until current max peak (I.E shave a 7kW consumption to 3,5kW and not to 0W).
    • If there is no big consumption: battery will recharge and will allow for future peak shaving.
  • 30-100% SOC: As per current design, grid setpoint 0W
24

During the winter weeks, I charge my battery overnight during the cheap hours to a certain level.

25

Hi, finally got some time to look into this and happy to help clarify each of these.

1. Input without a grid meter

A functional grid meter is required for the node to work — it needs real-time grid power to accumulate interval averages. If you don’t have a Victron-supported meter, the cleanest approach is to use the Virtual Grid Meter available from node-red-contrib-victron. You can feed that virtual meter from whatever source you do have (P1 DSMR, a CT clamp via MQTT, etc.) and then read it back with the standard Venus system grid node.

2. Output wiring — ESS power setpoint vs Grid set-point

Output 1 of the node (the current limit) should always connect to Ac/In/1/CurrentLimit on the MultiPlus — that is the hard AC input current cap and is what the node is designed for. The /Settings/CGwacs/AcPowerSetPoint (Grid set-point) is a separate path used in some examples for the battery charge rate side. Don’t use the ESS power setpoint as a substitute for the current limit; they control different things.

3. Max Charge Rate vs monthly peak

It would charge at 2000W, not 3000W. Ac/In/1/CurrentLimit (Output 1) is the hard cap on total grid consumption — the MultiPlus cannot draw more than that from the grid regardless of what the charge rate is set to. If the peak target works out to 2000W (≈8.7A at 230V), that 8.7A limit applies to everything coming from the grid: house loads plus battery charging combined. The charge rate (Output 3) is advisory to the internal charger and is simply overridden by the AC input limit if the two conflict.

One thing worth knowing: the battery management feature was primarily designed for Sweden, where there are clear off-peak hours to charge in. In Belgium mode (peakHoursStart=0, peakHoursEnd=24), all hours are considered peak hours, so the battery charging logic keeps the charger in hold mode around the clock. The current limit (Output 1) is the active mechanism for Belgium.

4. ESS vs DESS

Both work. I am running a test in Sweden on one site with Dynamic ESS alongside the node without issues. For ESS without DESS, Optimised (without BatteryLife) is recommended — BatteryLife can override SOC targets in ways that conflict with the node’s pre-peak charging strategy.

5. Battery balancing

Balancing is a nightly top-up cycle to keep cells in balance. The settings are: socThreshold (start balancing if SOC exceeds this, default 95%), targetSoc (charge to this, default 100%), holdHours (stay at target SOC for this many hours, default 2), and a time window (startTime/endTime, default 00:00–06:00). It runs at most once per window per night.

6. Consumption forecasting

Forecasting controls how the battery’s daily discharge budget is spread across expected peak periods. forecastSource can be none (off, default), time-based (fixed morning/evening windows from config), historical (learned from your own hourly data over time), or external (a forecast object from msg.forecast or global context). For a new install, none or time-based is the easiest starting point.

26

Thanks for the detailed write-up. Your approach of using the DSMR quarter-hour average as input — and predicting the final interval value by combining the reported running average with current instantaneous power — is exactly the right way to do this for Fluvius users with a P1 port. The quarter-hour average (1-0:1.4.0) and monthly peak (1-0:1.6.0) fields are Fluvius-specific extensions to the DSMR spec; they’re not present on Dutch or other meters, so this would be a Flanders-specific input mode rather than a general one. Still very much worth doing for that audience.

I’ve opened a GitHub issue to track this: Belgium/Flanders: support Fluvius P1 DSMR as input source · Issue #18 · dirkjanfaber/node-red-contrib-effekttariff · GitHub. If you do get around to building the Node-RED side of it I’d be very happy to incorporate it.

27

Version 0.2.6 is out — mostly a Flanders bug fix release. Two issues have been fixed:

  • Midnight bug — the Flanders profile incorrectly treated midnight–07:00 as off-peak, which could cause battery charging to accelerate unexpectedly overnight. Root cause was a falsy-zero parsing error (parseInt("0") || 7 evaluating to 7 instead of 0); it now correctly treats all 24 hours as peak hours.

  • Peak Hours End rejected 24 — the node editor capped the field at 23, making the Belgium preset technically invalid. Fixed.

Also added a warning in the editor when the Flanders profile is selected with battery management enabled, since all hours are peak hours and the off-peak charging logic has no window to operate in.

28
  1. Clear
  2. Clear
  3. Clear, future development using cost-aware logic would solve this for Flanders (see my post on 2nd of April for more ideas)
  4. Clear
  5. Clear, probably also not working for Flanders anymore due to battery logic being disabled. Doing this daily might not be required for LFP batteries? Possibly a “mandatory balancing every XX days bypassing socThreshold requirement” similar to “battery balancing in DESS” may be necessary?
  6. Is this actually operation in 0.2.5 or 0.2.6? Because in github lib/forecasting.js is blanc/placeholder

If you need a system to perform live testing let me know.

29

This prevents me from using it with DESS (in belgium/flanders) as it limits grid import and export. Capacity tariff is only on import. The limit also throws DESS off as it cant export at the power thats set in the DESS settings.

30

Does this have a lower limit? Our utility offers a rate plan with preferential pricing if we maintain less than 2kW of demand during peak hours. The Victron docs are a little confusing… it says the inverter/charger units have minimum input current limits, though Venus allows me to set it to whatever value I want (below the thresholds specified in the docs)

31

var watt = msg.payload.active_power_w;

// Negatieve waarden (injectie) afkappen naar 0

if (watt < 0) {
watt = 0;
}

msg.payload = watt;
return msg;

ik heb dit tussen de node en de data die aankomt van mijn homewizard p1 meter. zo toont hij geen negatieve waarde aan de node en blokkeerd hij geen injectie

32

I’ve finally had some time to write the nodered flow. I’ve sent it on GitHub.

33

Thanks @SB10. I am searching for some time to look into it again, but this will certainly help.

34

Two releases since the last update:

0.2.6 - Flanders bug fixes:

  • Midnight bug: the Flanders profile incorrectly treated midnight-07:00 as off-peak, which could cause battery charging to accelerate unexpectedly overnight. Root cause was a falsy-zero parsing error (parseInt("0") || 7 evaluating to 7 instead of 0); it now correctly treats all 24 hours as peak hours.

  • Peak Hours End rejected 24: the node editor capped the field at 23, making the Belgium preset technically invalid. Fixed.

  • Added a warning in the editor when the Flanders profile is selected with battery management enabled, since all hours are peak hours and the off-peak charging logic has no window to operate in.

0.2.7 - New effekttariff P1 node:

  • Adapter for Fluvius smart meters (P1 port). The Fluvius meter exposes OBIS 1-0:1.4.0 (current quarter-hour demand) and 1-0:1.6.0 (monthly peak), the exact values used for billing, which are absent from standard Dutch DSMR meters. This node normalises those values to Watts and feeds them directly into the effekttariff node in Belgium mode, so the node tracks the official billing value rather than computing its own accumulation.

  • Supports SB10’s semicolon-separated ESPHome/MQTT format (P_now;P15;Pmax_month;U_grid) and configurable individual message properties.

  • Wire as: P1 source (MQTT / ESPHome) → effekttariff P1 → effekttariff (Belgium preset)

Update through the Node-RED palette manager (once that has the cache updated).

35

Good news: this is now shipped in 0.2.7. The new effekttariff P1 node does exactly what you described. It reads 1-0:1.4.0 (quarter-hour demand) and 1-0:1.6.0 (monthly peak) from the P1 port and normalises them to Watts for the effekttariff node. Your semicolon format (P_now;P15;Pmax_month;U_grid) is supported out of the box.

Wire it as: P1 source → effekttariff P1 → effekttariff (Belgium preset)

An example flow is included in the package under examples/fluvius-p1-belgium.json.

36

Hello,

I tried to install the modules but didn’t succeed…

Directly in Node-Red :

2026-08-14T20:43:32.747Z Installer : node-red-contrib-effekttariff 0.2.7

2026-08-14T20:43:33.530Z npm install --no-audit --no-update-notifier --no-fund --save --save-prefix=~ --omit=dev --engine-strict node-red-contrib-effekttariff@0.2.7
2026-08-14T20:44:30.321Z rc=null

On the GX with SSH :

root@nanopi:~# npm install node-red-contrib-effekttariff
⠇Killed
root@nanopi:~#

For information, i’m installing it on My gx (Multiplus II GX) version 3.75.

@dfaber Any idea ?

Nicolas

37

i succeeded to install it but had to do it manually, without dependencies.

38

Sorry for not responding earlier to this. When you posted this I was on vacation and forgot about it when I returned. Installation is typically done via the palette manager in Node-RED itself.

image
image1992×1158 180 KB

If you do it by hand via ssh, the risk is big that it will install the packages as user root, not as user node-red. That will give you issues when updating later on (and can be solved by, in the ssh session chown-ing the files: chown -R nodered:nodered /data/home/nodered/.node-red/node_modules)

39

The effekttariff-node calculates the quarter-hour peak very accurately, even though I use the vm-3p75ct. I get exactly the same values as Fluvius.
Furthermore, I’ve written my own code for when ESS reaches its minimum SOC (which happens more often in winter). The minimum SOC in ESS is temporarily lowered if my quarter-hour peak exceeds the peak/value limit I’ve set.

Cheers!
B.

40

Hi,

Thanks for this impementation.

Maybe stupid question, on 3x400V+N with only 1 multiplus on F1, will this node work?

Because when going over total power limit, setting max amps to 0 will not be enough because only influence on F1 where multiplus is, will have to tell multiplus to discharge even more so total power goes down? Best Regards, Dominiek