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.