OpenEMS für §14a EnWG: Der vollständige Entwickler-Leitfaden

Das Inkrafttreten des §14a EnWG am 01.01.2024 verpflichtet Betreiber steuerbarer Verbrauchseinrichtungen wie Wärmepumpen, Wallboxen und Batteriespeicher zur Teilnahme an der netzdienlichen Steuerung. OpenEMS bietet mit seiner modularen OSGi-Architektur eine hervorragende Basis für die Umsetzung dieser Anforderungen – allerdings existieren noch Lücken, die Entwickler schließen müssen. Dieser Artikel zeigt, wie OpenEMS-Systeme §14a-konform erweitert werden können, vom einfachen Wärmepumpen-Setup bis zum komplexen Multi-Device-Management mit Priorisierung und Compliance-Reporting.

Warum OpenEMS die ideale Plattform für §14a-Projekte ist

Die Bundesnetzagentur hat mit der Festlegung BK6-22-300 klare technische Vorgaben für steuerbare Verbrauchseinrichtungen definiert. Der Gesetzgeber fordert, dass Netzbetreiber die Leistungsaufnahme von Anlagen mit mehr als 4,2 kW Anschlussleistung auf maximal 4,2 kW (bzw. 40% bei Anlagen über 11 kW) begrenzen können. Die Steuerung erfolgt künftig über Smart Meter Gateways mit FNN-Steuerboxen – ein Ökosystem, das flexible Software-Schnittstellen benötigt.

OpenEMS bringt drei Kernstärken mit, die es zur natürlichen Wahl für §14a-Projekte machen:

Der bereits vorhandene Controller.Ess.Limiter14a zeigt, dass die OpenEMS-Community die regulatorischen Anforderungen ernst nimmt. Dieser Controller reduziert bei Netzbetreiber-Aufforderung die Wirkleistung auf -4.200 W – exakt die gesetzlich garantierte Mindestbezugsleistung.

OpenEMS Grundarchitektur für §14a-Anwendungen

Das Dreischicht-Modell verstehen

OpenEMS folgt einer klaren Trennung zwischen Feldebene, Steuerungsebene und Cloud-Services:

┌─────────────────────────────────────────────────────────────────────────────┐
│                              BACKEND LAYER                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │
│  │   OpenEMS    │  │   Tariff-    │  │   Weather    │  │  CLS-Mgmt    │    │
│  │   Backend    │  │   Provider   │  │   Forecast   │  │   System     │    │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘    │
└─────────┼─────────────────┼─────────────────┼─────────────────┼────────────┘
          │ WebSocket       │ REST            │ REST            │ (zukünftig)
          ▼                 ▼                 ▼                 ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                        OPENEMS EDGE (Industrial PC/RPi)                     │
│  ┌────────────────────────────────────────────────────────────────────┐    │
│  │                         SCHEDULER                                  │    │
│  │  Priority 1: Limiter14a ──► Priority 2: PeakShaving ──► ...       │    │
│  └────────────────────────────────────────────────────────────────────┘    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐       │
│  │ ESS Controller│ │ EVCS Controller│ │ HeatPump Ctrl│ │ Limiter14a  │       │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘       │
│         │                │                │                │               │
│  ┌──────┴──────────────────┴──────────────────┴──────────────┴──────┐       │
│  │                     COMMUNICATION BRIDGES                         │       │
│  │   Modbus TCP  │  Modbus RTU  │  REST  │  WebSocket  │  OCPP     │       │
│  └───────────────────────────────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────────────────────────┘
          │              │              │              │
          ▼              ▼              ▼              ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                             DEVICE LAYER                                    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │ Batterie-   │  │  Wallbox    │  │ Wärmepumpe  │  │Smart Meter  │        │
│  │ speicher    │  │  (OCPP)     │  │  (SG Ready) │  │  Gateway    │        │
│  └─────────────┘  └─────────────┘  └─────────────┘  └─────────────┘        │
└─────────────────────────────────────────────────────────────────────────────┘

Scheduler und Prioritätenkette

Das Herzstück der §14a-Integration ist das Verständnis des OpenEMS-Schedulers. Controller werden sequenziell in definierter Priorität ausgeführt, wobei später ausgeführte Controller frühere Werte nicht überschreiben können. Die zentrale Ess.Power-Komponente verwaltet alle Leistungsanforderungen über ein lineares Gleichungssystem.

Für §14a-Konformität empfiehlt sich folgende Prioritätenkonfiguration:

// Hohe Priorität (werden zuerst ausgeführt)
1. Controller.Ess.Limiter14a        // §14a Netzbetreiber-Steuerung
2. Controller.Ess.EmergencyReserve  // Notstromreserve
3. Controller.Ess.LimitTotalDischarge // Mindest-SoC

// Mittlere Priorität
4. Controller.Ess.PeakShaving       // Lastspitzenkappung
5. Controller.Ess.GridOptimizedCharge // Prognosebasiertes Laden

// Niedrige Priorität
6. Controller.Ess.Balancing         // Eigenverbrauchsoptimierung
7. Controller.Ess.TimeOfUseTariff   // Tarifoptimierung

Szenario 1: Einfache Wärmepumpen-Steuerung

Technische Ausgangslage

Eine Wärmepumpe mit 9 kW Anschlussleistung soll §14a-konform gesteuert werden. Der Netzbetreiber kann die Leistung auf 4,2 kW begrenzen. Die Wärmepumpe unterstützt den SG Ready-Standard mit zwei Relais-Kontakten.

SG Ready Betriebszustände nach BWP-Regularien 3.0

OpenEMS-Konfiguration

Der Io.SgReady.HeatPump-Controller wird wie folgt konfiguriert:

{
  "id": "ctrlHeatPump0",
  "alias": "Wärmepumpe SG Ready",
  "factoryId": "Controller.Io.HeatPump.SgReady",
  "properties": {
    "outputChannel1": "io0/Relay1",
    "outputChannel2": "io0/Relay2",
    "mode": "AUTOMATIC",
    "minimumSwitchingTime": 60,
    "status1PowerThreshold": -1500,
    "status3PowerThreshold": 2000,
    "status4PowerThreshold": 5000
  }
}

§14a-Integration implementieren

Da der SG Ready-Controller keine direkte §14a-Schnittstelle bietet, muss ein Wrapper-Controller entwickelt werden:

@Component(name = "Controller.HeatPump.Limiter14a")
@Designate(ocd = Config.class, factory = true)
public class HeatPumpLimiter14aImpl extends AbstractOpenemsComponent 
    implements Controller, OpenemsComponent {

    @Reference
    private ComponentManager componentManager;
    
    private String sgReadyControllerId;
    private Channel<Boolean> gridLimitActiveChannel;
    
    @Override
    public void run() throws OpenemsNamedException {
        // §14a Signal vom Netzbetreiber prüfen
        boolean gridLimitActive = this.gridLimitActiveChannel.value().orElse(false);
        
        if (gridLimitActive) {
            // Betriebszustand 1 erzwingen (EVU-Sperre)
            forceSgReadyState(SgReadyState.LOCK);
            logComplianceEvent("14a_LIMIT_ACTIVE", 4200);
        } else {
            // Normale Steuerung durch SG Ready Controller
            releaseSgReadyControl();
        }
    }
    
    private void logComplianceEvent(String eventType, int powerLimit) {
        // Compliance-Logging für Netzbetreiber-Nachweis
        ComplianceLogger.log(Instant.now(), eventType, powerLimit, 
            getCurrentPowerConsumption());
    }
}

Wichtige Designentscheidung: Mindestversorgung garantieren

Der §14a fordert, dass Wärmepumpen auch bei Dimmung funktionsfähig bleiben. Die 4,2 kW Mindestleistung muss garantiert werden:

// Leistungsbegrenzung mit Mindestgarantie
int calculateAllowedPower(int requestedPower, boolean gridLimitActive) {
    if (!gridLimitActive) {
        return requestedPower;
    }
    // Mindestens 4,2 kW oder 40% bei Anlagen >11 kW
    int minimumPower = (ratedPower > 11000) ? (int)(ratedPower * 0.4) : 4200;
    return Math.min(requestedPower, minimumPower);
}

Szenario 2: Wärmepumpe + Batteriespeicher

Architekturübersicht

Die Kombination aus Wärmepumpe und Batteriespeicher ermöglicht intelligente Lastverschiebung. Bei einem §14a-Steuerungssignal kann der Speicher Energie bereitstellen, während die Wärmepumpe gedrosselt wird.

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   FNN-STB /     │────►│    OpenEMS      │────►│   Wärmepumpe    │
│   Steuerbox     │     │    Edge         │     │   (SG Ready)    │
└─────────────────┘     │  ┌───────────┐  │     └─────────────────┘
                        │  │Limiter14a │  │
                        │  │PeakShaving│  │     ┌─────────────────┐
                        │  │Balancing  │  │────►│  Batterie-      │
                        │  └───────────┘  │     │  speicher       │
                        └─────────────────┘     │  (Modbus TCP)   │
                                                └─────────────────┘

Konfiguration des ESS-Clusters

OpenEMS unterstützt die Kombination mehrerer Energiespeichersysteme über den Ess.Cluster-Controller:

{
  "id": "essCluster0",
  "factoryId": "Ess.Cluster",
  "properties": {
    "ess.ids": ["ess0", "ess1"]
  }
}

Peak Shaving für Netzentgeltoptimierung

Der Controller.Ess.PeakShaving ist essentiell für die Nutzung von Modul 2 (60% Netzentgeltreduzierung):

{
  "id": "ctrlPeakShaving0",
  "factoryId": "Controller.Ess.PeakShaving",
  "properties": {
    "ess.id": "ess0",
    "meter.id": "meter0",
    "peakShavingPower": 4200,
    "rechargePower": -3000
  }
}

§14a-konforme Priorisierungslogik

Bei aktivem Netzbetreiber-Signal müssen Wärmepumpe und Speicher koordiniert werden:

public class CombinedLimiter14aController extends AbstractOpenemsComponent 
    implements Controller {

    private static final int GRID_LIMIT_POWER = 4200; // Watt
    
    @Override
    public void run() throws OpenemsNamedException {
        boolean gridLimitActive = isGridLimitSignalActive();
        
        if (gridLimitActive) {
            // 1. Wärmepumpe auf Minimalbetrieb
            setHeatPumpMode(SgReadyState.LOCK);
            
            // 2. Batterie: Entladen zur Netzentlastung ermöglichen
            int currentGridPower = meter.getActivePower().get();
            int excessPower = currentGridPower - GRID_LIMIT_POWER;
            
            if (excessPower > 0 && battery.getSoc().get() > MIN_SOC) {
                // Batterie entladen, um Netzlast zu reduzieren
                battery.setActivePowerEquals(excessPower);
            }
            
            // 3. Compliance-Logging
            logEvent("14a_COMBINED_LIMIT", currentGridPower, GRID_LIMIT_POWER);
        }
    }
}

Wichtiger Hinweis: Gleichzeitigkeitsfaktor bei EMS-Steuerung

Die BNetzA erlaubt bei EMS-Steuerung die Anwendung eines Gleichzeitigkeitsfaktors. Wenn mehrere Verbraucher über ein EMS koordiniert werden, muss nicht jeder einzelne auf 4,2 kW begrenzt werden, sondern nur die Summe am Netzanschlusspunkt.

Szenario 3: Komplettes System (WP + Speicher + Wallbox)

Systemarchitektur

Das vollständige §14a-konforme System integriert alle steuerbaren Verbrauchseinrichtungen:

┌─────────────────────────────────────────────────────────────────────────────┐
│                           NETZBETREIBER-EBENE                               │
│  ┌─────────────────┐     ┌─────────────────┐                                │
│  │  CLS-Backend    │────►│   Smart Meter   │                                │
│  │  Netzbetreiber  │     │   Gateway       │                                │
│  └─────────────────┘     └────────┬────────┘                                │
└───────────────────────────────────┼─────────────────────────────────────────┘
                                    │ CLS-Schnittstelle
                                    ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                           STEUERBOX-EBENE                                   │
│  ┌─────────────────────────────────────────────────────────────────────┐   │
│  │                    FNN-Steuerbox (EEBUS / IEC 61850)                │   │
│  └──────────────────────────────────┬──────────────────────────────────┘   │
└─────────────────────────────────────┼───────────────────────────────────────┘
                                      │ EEBUS/Modbus
                                      ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                        OPENEMS EDGE                                         │
│  ┌────────────────────────────────────────────────────────────────────┐    │
│  │                    §14a ORCHESTRATOR                                │    │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐ │    │
│  │  │ Grid Signal  │  │ Load         │  │ Priority Manager         │ │    │
│  │  │ Handler      │  │ Calculator   │  │ (WP > Batt > EVCS)       │ │    │
│  │  └──────────────┘  └──────────────┘  └──────────────────────────┘ │    │
│  └────────────────────────────────────────────────────────────────────┘    │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐       │
│  │ ESS         │  │ EVCS        │  │ HeatPump    │  │ Compliance  │       │
│  │ Controller  │  │ Controller  │  │ Controller  │  │ Logger      │       │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘  └─────────────┘       │
└─────────┼────────────────┼────────────────┼─────────────────────────────────┘
          │ Modbus         │ OCPP           │ SG Ready
          ▼                ▼                ▼
┌─────────────────┐  ┌─────────────┐  ┌─────────────┐
│ Batteriespeicher│  │  Wallbox    │  │ Wärmepumpe  │
│ (z.B. BYD)      │  │  (z.B. KEBA)│  │             │
└─────────────────┘  └─────────────┘  └─────────────┘

EVCS-Integration über OCPP

OpenEMS unterstützt Wallboxen primär über OCPP (Open Charge Point Protocol):

{
  "id": "evcs0",
  "factoryId": "Evcs.Ocpp.Abl",
  "properties": {
    "ocpp.id": "ABL_WALLBOX_001",
    "minHwPower": 4140,
    "maxHwPower": 22000
  }
}

Der EVCS-Controller für PV-Überschussladen:

{
  "id": "ctrlEvcs0",
  "factoryId": "Controller.Evcs",
  "properties": {
    "evcs.id": "evcs0",
    "enabledCharging": true,
    "chargeMode": "EXCESS_POWER",
    "priority": "CAR",
    "defaultChargeMinPower": 4200
  }
}

§14a-Priorisierungsalgorithmus für Multi-Device-Systeme

Der Kernalgorithmus verteilt die verfügbare Leistung bei Netzengpässen:

public class MultiDeviceLimiter14a extends AbstractOpenemsComponent {

    // Priorisierung gemäß §14a-Anforderungen
    enum DevicePriority {
        HEAT_PUMP_HEATING(1, 4200),    // Höchste Priorität: Raumwärme
        BATTERY_DISCHARGE(2, -10000),  // Batterie entladen zur Entlastung
        WALLBOX(3, 4140),              // 6A dreiphasig = Minimum
        HEAT_PUMP_HOTWATER(4, 0);      // Warmwasser verschiebbar
        
        final int priority;
        final int minPower;
        
        DevicePriority(int priority, int minPower) {
            this.priority = priority;
            this.minPower = minPower;
        }
    }

    @Override
    public void run() throws OpenemsNamedException {
        if (!isGridLimitActive()) {
            return; // Keine Begrenzung aktiv
        }
        
        int availablePower = GRID_LIMIT_TOTAL; // 4200 W
        int currentGridPower = meter.getActivePower().get();
        
        // Batterie-Entladung zur Netzentlastung
        if (battery.getSoc().get() > MIN_SOC) {
            int dischargePotential = Math.min(
                battery.getMaxDischargePower().get(),
                currentGridPower - availablePower
            );
            if (dischargePotential > 0) {
                battery.setActivePowerEquals(dischargePotential);
                availablePower += dischargePotential;
            }
        }
        
        // Lastverteilung nach Priorität
        allocatePowerByPriority(availablePower);
    }
    
    private void allocatePowerByPriority(int availablePower) {
        int remaining = availablePower;
        
        // 1. Wärmepumpe Heizung (garantierte Mindestleistung)
        int hpPower = Math.min(remaining, heatPump.getCurrentDemand());
        hpPower = Math.max(hpPower, DevicePriority.HEAT_PUMP_HEATING.minPower);
        setHeatPumpPower(hpPower);
        remaining -= hpPower;
        
        // 2. Wallbox (falls Fahrzeug angeschlossen)
        if (remaining > 0 && evcs.isVehicleConnected()) {
            int evPower = Math.min(remaining, evcs.getMaxPower());
            evPower = Math.max(evPower, DevicePriority.WALLBOX.minPower);
            setWallboxPower(evPower);
            remaining -= evPower;
        }
        
        // 3. Warmwasser (nur wenn übrig)
        if (remaining > 0) {
            setHotWaterMode(true);
        } else {
            setHotWaterMode(false);
        }
    }
}

EVCS-Cluster für mehrere Wallboxen

Bei mehreren Ladepunkten koordiniert der Evcs.Cluster:

{
  "id": "evcsCluster0",
  "factoryId": "Evcs.Cluster.PeakShaving",
  "properties": {
    "evcs.ids": ["evcs0", "evcs1", "evcs2"],
    "hardwarePowerLimitPerPhase": 7360,
    "priority": "BY_ARRIVAL_TIME"
  }
}

Identifizierte Lücken in OpenEMS für §14a-Konformität

Die Analyse der OpenEMS-Architektur offenbart mehrere kritische Lücken für eine vollständige §14a-Implementierung:

Fehlende Kernfunktionen

EEBUS: Die größte Lücke

Die VDE-AR-E 2829-6-1 definiert EEBUS als Standard-Kommunikationsprotokoll zwischen FNN-Steuerbox und steuerbaren Verbrauchseinrichtungen. OpenEMS bietet keine native Implementierung. Verfügbare Alternativen sind:

• enbility.net (eebus-go): Go-Implementierung, kann via HTTP-Bridge integriert werden
• jEEBus (Fraunhofer/OpenMUC): Java-Stack, theoretisch OSGi-kompatibel
• OpenEEBUS (NIBE): Neue Open-Source-Initiative, noch in Entwicklung

Fehlende Netzbetreiber-Schnittstellen

Die Kommunikation mit dem Netzbetreiber-Backend (CLS-Management-System) fehlt vollständig:

Soll-Zustand:
CLS-Backend ──► SMGW ──► Steuerbox ──► OpenEMS ──► SteuVE

Ist-Zustand OpenEMS:
                                    ??? ──► OpenEMS ──► SteuVE

Unzureichendes Compliance-Logging

Der §14a fordert Nachweispflichten. OpenEMS protokolliert Steuerungsereignisse nicht in einem für Netzbetreiber nutzbaren Format:

// Erforderliche Datenpunkte für §14a-Compliance
public class ComplianceDataPoint {
    Instant timestamp;           // Sekundengenau
    String eventType;            // LIMIT_ACTIVE, LIMIT_RELEASED
    int gridLimitPower;          // Angeforderte Begrenzung
    int actualPower;             // Tatsächliche Leistung
    Duration duration;           // Dauer der Maßnahme
    List<String> affectedDevices; // Betroffene SteuVE
}

Lösungsvorschläge und Erweiterungen

1. EEBUS-Bridge-Bundle entwickeln

Eine pragmatische Lösung ist ein OSGi-Bundle, das eebus-go als Subprozess startet und über HTTP kommuniziert:

@Component(name = "Bridge.Eebus")
public class EebusBridgeImpl extends AbstractOpenemsComponent 
    implements Bridge, OpenemsComponent {

    private Process eebusProcess;
    private HttpClient httpClient;
    
    @Activate
    void activate(Config config) {
        // eebus-go als Subprocess starten
        ProcessBuilder pb = new ProcessBuilder(
            config.eebusGoPath(), 
            "--config", config.configPath()
        );
        eebusProcess = pb.start();
        httpClient = HttpClient.newHttpClient();
    }
    
    public void sendGridLimitSignal(int powerLimit) {
        // EEBUS SPINE Nachricht via HTTP-API
        String json = String.format(
            "{\"feature\":\"LoadControl\",\"function\":\"LimitWrite\",\"value\":%d}", 
            powerLimit
        );
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("http://localhost:4712/api/v1/limit"))
            .POST(HttpRequest.BodyPublishers.ofString(json))
            .build();
        httpClient.send(request, HttpResponse.BodyHandlers.ofString());
    }
}

2. Compliance-Logger implementieren

Ein dediziertes Bundle für §14a-Nachweise:

@Component(name = "Controller.Compliance.Logger14a")
public class ComplianceLogger14aImpl extends AbstractOpenemsComponent {

    private InfluxDBClient influxDB;
    
    @Override
    public void run() throws OpenemsNamedException {
        // Alle §14a-relevanten Events erfassen
        Point point = Point.measurement("compliance_14a")
            .time(Instant.now(), WritePrecision.S)
            .addTag("event_type", getEventType())
            .addField("grid_power", meter.getActivePower().get())
            .addField("limit_power", getCurrentLimit())
            .addField("soc", ess.getSoc().get())
            .addField("hp_power", heatPump.getPower().orElse(0))
            .addField("evcs_power", evcs.getChargePower().orElse(0));
        
        influxDB.getWriteApiBlocking().writePoint(point);
    }
}

3. FNN-Steuerbox-Simulator für Entwicklung

Für die Entwicklung ohne echte Hardware:

@Component(name = "Simulator.FnnSteuerbox")
public class FnnSteuerboxSimulator extends AbstractOpenemsComponent {

    private Channel<Integer> gridLimitChannel;
    
    @Reference
    private WebsocketServer websocket;
    
    @Activate
    void activate() {
        // Websocket für manuelle Steuerung
        websocket.onMessage("/steuerbox/limit", (msg) -> {
            int limit = Integer.parseInt(msg);
            gridLimitChannel.setNextValue(limit);
            logInfo("Simuliertes §14a-Signal: " + limit + " W");
        });
    }
}

4. Erweiterung des Limiter14a-Controllers

Der vorhandene Controller sollte um Reporting und flexible Limits erweitert werden:

// Erweitertes Interface für Limiter14a
public interface Limiter14aExtended extends Controller {
    
    // Dynamisches Limit statt fester 4200 W
    void setDynamicPowerLimit(int limitWatts);
    
    // Priorisierung über mehrere SteuVE
    void setPriorityDevices(List<String> deviceIds);
    
    // Reporting-Callbacks
    void setReportingCallback(Consumer<ComplianceEvent> callback);
    
    // Statistiken
    Duration getTotalLimitDuration();
    int getLimitEventCount();
}

Best Practices und Ausblick

Architektur-Empfehlungen für neue Projekte

Entwickler, die §14a-konforme Systeme mit OpenEMS bauen, sollten folgende Patterns beachten:

Separation of Concerns: Jeder Controller sollte genau eine Aufgabe erfüllen (KISS-Prinzip). Ein §14aOrchestrator koordiniert die spezialisierten Controller.

Event-Driven Design: Nutzen Sie den OpenEMS-Event-Bus für lose Kopplung:

// Publisher
eventAdmin.postEvent(new Event("openems/grid/limit/active", 
    Map.of("limit", 4200, "timestamp", Instant.now())));

// Subscriber
@EventHandler
public void handleGridLimit(Event event) {
    int limit = (int) event.getProperty("limit");
    activateLimitMode(limit);
}

Fail-Safe-First: Bei Kommunikationsverlust zur Steuerbox muss das System in einen sicheren Zustand wechseln:

@Override
public void handleCommunicationLoss() {
    // Watchdog: Nach 60s ohne Signal → Normalbetrieb
    // ABER: Letzte bekannte Limits respektieren
    if (lastSignalAge() > Duration.ofSeconds(60)) {
        if (lastKnownLimitActive) {
            maintainSafeLimit(); // Vorsichtsmodus
        } else {
            resumeNormalOperation();
        }
    }
}

Technologie-Stack für Produktionssysteme

Roadmap: Was kommt 2025-2026?

Die §14a-Landschaft entwickelt sich weiter. Entwickler sollten folgende Meilensteine im Blick behalten:

• 01.04.2025: Start von Modul 3 (zeitvariable Netzentgelte) – erfordert iMSys-Integration
• 2025: BSI-Zertifizierung weiterer FNN-Steuerboxen – mehr Auswahl bei der Hardware
• 2025/2026: EEBUS 2.0 mit erweitertem Funktionsumfang erwartet
• 31.12.2028: Ende der Übergangsfrist für Bestandsanlagen – alle Systeme müssen migriert sein

Fazit: OpenEMS als Entwicklungsplattform

OpenEMS bietet mit seiner modularen Architektur und dem vorhandenen §14a-Controller eine solide Basis für die Entwicklung netzdienlicher Energiemanagementsysteme. Die identifizierten Lücken – insbesondere die fehlende EEBUS-Integration und das CLS-Interface – sind mit überschaubarem Aufwand zu schließen.

Für Entwickler, die in diesem Bereich arbeiten, empfiehlt sich folgende Vorgehensweise:

1. Kurzfristig: Nutzung der vorhandenen Controller mit manueller Triggering-Logik
2. Mittelfristig: Integration von eebus-go als Bridge-Bundle
3. Langfristig: Beitrag zur OpenEMS-Community für native EEBUS/CLS-Unterstützung

Die Energiewende erfordert intelligente Systeme, die Netzstabilität und Verbraucherinteressen ausbalancieren. OpenEMS bietet das technische Fundament – die §14a-Konformität liegt in der Hand der Entwickler-Community.

Weiterführende Ressourcen

• OpenEMS Dokumentation
• BNetzA Festlegung BK6-22-300
• EEBUS Initiative
• evcc - Open Source Ladelösung
• §14a EnWG Grundlagen auf Enerchy

Haben Sie Fragen zur Implementierung von §14a-konformen Systemen mit OpenEMS? Kontaktieren Sie uns für technische Beratung oder nutzen Sie unseren KI-Assistenten für spezifische Fragen zur Energiewirtschaft.