Epic: §14a Dimming - overview of current capabilities and roadmap

[andig]

For a long time, evcc has supported load management and specifically §14a compliance for wall boxes. This epic extends and replaces https://github.com/evcc-io/evcc/issues/23912 with the current state of affairs.

Currently supported scope

1. Loadpoints/ chargers with current control are regulated according to load management limit (i.e. global §14a restrictions are applied via load management)
2. Some Loadpoints/ chargers only accept power hints or general "boost" hints. These are currently not controlled according to §14a since load management only puts them into "normal", but not into "dimmed" operations mode.
3. A further exception to 2. is that generic SGReady chargers and any charger supporting dimming via it's setmode implementation is dimmed when mounted into a loadpoint.
4. During dimming, we're also stopping battery grid charging (https://github.com/evcc-io/evcc/pull/24150)

How this works

Dimming via DSO is globally applied via eebus or relay hems which operate an lpc circuit. The lpc circuit wraps the user-defined root circuit and hence applies to all connected devices. For this reason, users must not, atm, define a custom lpc circuit (https://github.com/evcc-io/evcc/pull/24882). The user configures the individual minimum power via the maxPower property of the relay HEMS (see BK6-22-300 dated 27 November 2023) or the power restriction is communicated dynamically via EEBus HEMS by the grid operator without any further local configuration.

What's not supported (yet)

Limitations we currently have and that we propose to work on cover:

• [x] support dimming for additional meters that are not mounted into a loadpoint (specifically ext/aux). This is proposed in https://github.com/evcc-io/evcc/issues/24074 with a sample implementation for EEBus "meter" devices in https://github.com/evcc-io/evcc/pull/24595). We still need to add actually dimming the meter when grid connection point is dimmed.
• [x] support this Dimmer interface for more meters. We already have an sgready-relay custom charger that extends the older sgready-boost which this capability in https://github.com/evcc-io/evcc/pull/24704.
• [ ] Dimming is unconditional in that it affects all devices (except for case 1. above). It should be up to the user to determine which devices fall under §14a regime (this was originally covered under https://github.com/evcc-io/evcc/issues/15239).
• [ ] Take dimming limits into account. Except for 1. all devices are unconditionally dimmed. This is only necessary when the dimming circuit is actually overloaded.
• [ ] Jump prediction: What will happen in extreme cases when dimming or boost mode is activated/deactivated? The device-specific power profile (except for case 1. devices) is unknown. In order to make better use of the available power budget and to be able to respond to changing load situations without exceeding the total power budget, knowledge of the maximum values that actually occur in the dimmed and boosted states is required.

Open points

• Should dimming ~~and boosting~~ (also) be available depending on tariffs?
• Documentation of the current status

[meierchen006]

Hello, Let's hope that at some point we'll also get control boxes that can pass all this on.

[spasdev]

On the open point above : Should dimming and boosting (also) be available depending on tariffs In my point of view this capability is really very important for everyone having dynamic tariffs. At the end of the day dynamic tariffs are just another way of keeping the network in balance.

[andig]

Let's not get confused: dimming is a DSO topic. It is not related to tariffs. Loadmanagement in contrast may be. Boosting already is subject to tariffs/ smart charging. Nothing new there.

That said: OT for this discussion.

[spasdev]

I don't understand the logic. Boost (consuming more when tariff is low) is ok for tariff but Dim (consuming less when tariff is high) is not ok? Dynamic tariff is a soft way for DSO to pass the information. I don't think it's OT.

[andig]

I suggest to read up on §14 EnWG. It has nothing to do with tariffs.

[CiNcH83]

I have a question regarding § 14a and the home battery and I hope it fits in here without being OT...

I can see that the battery remains in the unknown mode after evcc has started up. I wonder whether there is a transition to normal when being dimmed via § 14a? I can't find the respective transition in the code, only the one from charge to hold. So is the battery out of the box supposed not to charge from the grid?

[andig]

Dimming will atm replace charge with hold. If not charged by evcc it won‘t be affected (unless we can actually read that mode from the battery which we cannot generally). I think that‘s worth documenting.

[typxxi]

Not every (home) battery is part of §14a cause our 2 batteries are simply counted as 2 non §14a batteries due to a phyhsical limitation of 3000 Watt charging and discharging by the single phase Growatt SPH inverters which is limiting to 3 kW no matter which model (SPH 3000 - SPH 4600 in germany and even SPH 6000 for other countries). If you should check the specs of the newest edition they claim to charge and discharge 4000W but that is phantasy and simply a lie. We have 3 inverters from 3 years and each of those is able to charge with 3 kW max (and for a short period of time and only sometimes 3300 W). We have tried each and every combination with a JK BMS in Growatt protocol canbus mode, but also with a genuine Growatt LV battery: 3000 W per battery / inverter

Hence these are not part of the §14a dimming regulations and hence we do not like this "feature / function" mentioned above:

During dimming, we're also stopping battery grid charging (https://github.com/evcc-io/evcc/pull/24150)

Not sure if there will be a work around but in general we would like to stay with all of our batteries , inverters, wallboxes and heatpump under evcc as the future heart. Unfortunatelly we still struggle from time to time but that is another topic that does not belong here.

Or maybe I misunderstood that line "during dimming we are stopping battery grid charging". We rely on that cause we charge our batteries with octopus go each night from midnight to roughly 5 am with 3 kW max while the kWh price is reduced to 14 cent for now instead of 28 cent, but with §14a we would get a refund of 10 cent for every kWh used from 0 am to 6 am from the grid operator Westnetz . Right now we have not §14a implemented, but we are preparing for that.

Hence we got even a 2nd identical Wallbox Pulsar Plus, to run the first one under evcc as OCCP server and the 2nd one with octopus energy OCCP server and "outside" evcc when the "proxy solution" that had been discussed somewhere was not on the table. THANKS A LOT.

[CiNcH83]

Hence these are not part of the §14a dimming regulations and hence we do not like this "feature / function" mentioned above:

IIRC, it has already been mentioned somewhere that in the future, also batteries (or meters in general) will have to be added to the lpc circuit in order for § 14a to take effect. So if you don't add it, nothing will happen.

[andig]

Hence these are not part of the §14a dimming regulations and hence we do not like this "feature / function" mentioned above:

@typxxi not sure if we is pluralis majestatis or else, but I trust you‘ve noticed the second open point above regarding selection of §14a devices. If so- repeating that it‘s open does not move the discussion forward imho. Thank you.

[VolkerK62]

Currently, the limit does not take the current PV generation into account. Will this be changed?

[andig]

Currently, the limit does not take the current PV generation into account.

What exactly does this observation (?) refer to?

If you mean

Take dimming limits into account. Except for 1. all devices are unconditionally dimmed. This is only necessary when the dimming circuit is actually overloaded.

Then thats a) not universally true and b) already mentioned ;)

[hybe2022]

Ist das wirklich so umgesetzt? Das die Batterie nicht mehr entlädt, wenn der Bezug eingeschränkt wurde ist fatal. Dadurch bekommt man unter Umständen Netzbezug, obwohl die eigene Batterie diesen ausgleichen könnte. Dies ist für den Nutzer problematisch, da er eventuell und nachts zu 100% für Bezug bezahlen muss, obwohl er seinen tagsüber eingespeicherten Strom nutzen könnte. Noch dazu ist es auch fürs Grid kontraproduktiv, da man gerade Bezug zum Schutz des Netzes vermeiden will, das blockieren der Einladung der Batterie allerdings dazu führt/führen kann... Ich hoffe das ist nicht so umgesetzt.

Auch das komplette blockieren der Ladung ist nicht gewollt:

1. Darf man tagsüber den PV Überschuss einspeichern.
2. Darf man auch beim Dimmen mindestens 4,2kW bei Direktsteuerung unter Relais aus dem Netz + Hausverbrauch ziehen oder bei EMS Pmin + Hausverbrauch abzüglich der PV Produktion
3. Wenn der Speicher keine sVE nach 14a ist, dann darf/muss er niemals gesperrt werden
4. Entladen wird genau wie PV Erzeugung von Pmin abgezogen

Der Speicher müsste also auch explizit dem Circuit lpc zugeordnet werden, falls dieser überhaupt eine sVE nach 14a ist. Entladen darf niemals gesperrt werden und das Laden nur über 4,2kW aus dem Netz oder über Pmin aus dem Netz minus PV Erzeugung.

Berechnung von Pmin siehe Excel Sheet unter:

www.zveh.de/die-e-handwerke/e-handwerke-und-netzanschluss/umsetzung-paragraph-14a-enwg.html

[premultiply]

There are three battery modes implemented:

• normal
• hold
• charge

Which fits best?

[andig]

@hybe2022 for sake of courtsey, please stay in English.

[hybe2022]

There are three battery modes implemented:

• normal
• hold
• charge

Which fits best?

Currently none. It has to be normal mode, but maxchargepower should be set to 4.2kW in case of relay/direct control and higher value configured or to Pmin which needs to be dynamically calculated... and that only in case the battery is configured as lpc as for all none 14a batteries charging should not be restricted at all.

[mucki12]

I would also say that, of the three available modes, the normal mode would be the most suitable. I’m not yet participating in 14a, but I still haven’t understood why the battery should necessarily be set to hold mode, which automatically causes grid consumption and prevents the use of any available energy stored in the battery.

Of course, one could argue that the battery was intended to be charged precisely because of low grid prices, and therefore the hold mode would fit well with those low grid prices. However, it could also happen that the grid price rises significantly in the meantime, and due to 14a throttling, the battery remains in hold mode even though it (perhaps) could then provide cheaper energy.

[andig]

Ist das wirklich so umgesetzt?

Before we're all getting excited and worked up: what exactly?! I'd appreciate if the statement (that I assume this refers to) is read carefully:

During dimming, we're also stopping battery grid charging

In this moment, grid is cheap (for whatever reason) and user wants to consume grid. By putting battery on hold he can do that without violating §14a. Having the battery support locally (i.e. normal mode) it not regulated by §14a in contrast. In other words: we're complying with user choice.

Of course, one could argue that the battery was intended to be charged precisely because of low grid prices, and therefore the hold mode would fit well with those low grid prices.

Exactly

However, it could also happen that the grid price rises significantly in the meantime, and due to 14a throttling, the battery remains in hold mode even though it (perhaps) could then provide cheaper energy.

Many things can happen. Does this speculation help with anything or lead anywhere particular? If things do happen, the battery would no longer be in hold mode.

[andig]

That said: since this issue is about current status, feel free to open new issue with a specific request what to change and how. The discussion does not belong here.

Thank you.

[hybe2022]

During dimming, we're also stopping battery grid charging

In this moment, grid is cheap (for whatever reason) and user wants to consume grid. By putting battery on hold he can do that without violating §14a. Having the battery support locally (i.e. normal mode) it not regulated by §14a in contrast. In other words: we're complying with user choice.

Usually I expect it will be dimmed when there is a high use of electric energy. During high usage usually the price is high and not low, which means I want to use my energy stored within the battery. If the price would be low I would like to maybe charge the battery, but not block charging which has nothing to do with 14a. 14a means dimming/reduction, but not blocking.

In this moment, grid is cheap (for whatever reason) and user wants to consume grid. By putting battery on hold he can do that without violating §14a. Having the battery support locally (i.e. normal mode) it not regulated by §14a in contrast. In other words: we're complying with user choice.

Of course, one could argue that the battery was intended to be charged precisely because of low grid prices, and therefore the hold mode would fit well with those low grid prices.

Exactly

To use low prices and also charge the battery in that case to benefit from low prices is a good feature, but if that comes together with dimming it would be currently blocked. No charging with up to 4.2kW at all. So that is against that arguement. Nor there is any relation between dimming and low prices, as most likely it is the other way round. Blocking discharge during dimming is completely against what our power provider want to have. Reduce grid consumption due to overload...

The thing is dimming is one thing and charging depending on low prices another thing. Dimming should never block discharging (there could be a feature use grid instead of battery depending on low prices) and only reduce consumption/charging, but not block it.

[roethigj]

power restriction is communicated dynamically via EEBus HEMS by the grid operator without any further local configuration.

I don’t think that’s correct. The grid operator cannot communicate a limitation for the entire grid connection point, because they only know the number and power of the controllable devices (SteuVE) that they are allowed to control. They do not know the rest of the household consumption, which they are not allowed to control. This also follows from BK6-22-300:

4.5.2 Für alle steuerbaren Verbrauchseinrichtungen, die gemäß Ziffer 4.4.b. (Steuerung mittels EMS) angesteuert werden, ist die Mindestleistung unter Berücksichtigung eines angemessenen Gleichzeitigkeitsfaktors zu ermitteln....

Der Betreiber ist berechtigt, den insgesamt gewährten Sollwert für den maximalen netzwirksamen Leistungsbezug über das Energie-Management-System nach eigener Maßgabe einzusetzen.

To be clear: Der Betreiber - the operator - is the HEMS operator, not the grid operator. Therefore, at the grid connection point the following must always apply:

Pmin total = Phouse + Pmin SteuVE.