Das Fraunhofer-Institut für Solare Energiesysteme ISE, die FENECON GmbH und der OpenEMS Association e. V. entwickeln gemeinsam eine Open-Source-Referenzimplementierung für Energiemanagementsysteme (EMS), die eine sichere und interoperable Kommunikation zwischen Messsystem, Steuerung und dezentralen Energieanlagen ermöglicht. Diese Lösung legt die Grundlage für sichere Stromnetze und den wirtschaftlich optimalen Betrieb von Erzeugern, Speichern und Stromverbrauchern. Die Integration einer am Fraunhofer ISE entwickelten Bibliothek für Kommunikationsprotokolle in das quelloffene Energiemanagementsystem OpenEMS soll die Digitalisierung des Energiesystems vorantreiben.

Der Umbau des Energiesystems hin zu 100 Prozent erneuerbaren Energien geht mit einem stark wachsenden Anteil dezentraler Energieressourcen – wie Photovoltaikanlagen, Batteriespeicher und Wärmepumpen – einher. Um Stromerzeugung und -verbrauch so abzustimmen, dass Stromnetze sicher betrieben und Anlagen wirtschaftlich optimal genutzt werden können, ist eine sichere, resiliente und interoperable Kommunikationsinfrastruktur unabdingbar.

Mit dem intelligenten Messsystem iMSys und der FNN-Steuerbox steht bereits eine cybersichere Infrastruktur bereit, über die Steuerbefehle des Netzbetreibers an die Kundenanlage übertragen werden können. Für die Kommunikation zwischen Steuerbox und Energiemanagementsystem können verschiedene Kommunikationsprotokolle wie KNX oder EEBus zum Einsatz kommen. Diese regeln die Vernetzung von energietechnischen Anlagen (Wallbox, Wärmepumpe, Stromspeicher, Wechselrichter, Energiemanagementsystem) im Gebäude. Besonders relevant sind dabei die Anwendungsfälle »Limitation of Power Consumption« (LPC, Limitierung des Stromverbrauchs eines Gebäudes oder einzelner Geräte) und »Limitation of Power Production« (LPP, Limitierung der Einspeiseleistung von eigenständigen Stromerzeugern). Diese werden bei Notfall-Steuereingriffen nach § 14a EnWG und § 9 EEG durch den Verteilnetzbetreiber angewandt.

Die praktische Umsetzung dieser Kommunikationskette stellt Hersteller und Entwickler von EMS-Lösungen jedoch vor erhebliche technische Hürden: die Komplexität des Kommunikationsstandards und der iMSys-Infrastruktur sowie fehlende Referenzimplementierungen erschweren die breite Markteinführung interoperabler Lösungen. Genau hier setzen die gemeinsamen Arbeiten von Fraunhofer ISE, FENECON und der OpenEMS Association e. V. an.

 jEEBus trifft OpenEMS – eine offene Referenzplattform für die Energiewende

Das Fraunhofer ISE entwickelt seit Jahren die Open-Source-Bibliothek jEEBus für das Kommunikationsprotokoll EEBus. Die Kernkomponenten jEEBus.SHIP (Transport- und Kommunikationsschicht), jEEBus.SPINE (Daten- und Informationsschicht) sowie die Anwendungsfälle LPC und LPP stehen nun als Quellcode auf der öffentlichen Software-Entwicklungsplattform GitHub frei zur Verfügung. 

»Wir wollen komplexe Kommunikationsstandards durch Open-Source-Lösungen einfach nutzbar machen und gemeinsam mit der Branche Lösungen entwickeln, die die Digitalisierung des Energiesystems vorantreiben«, erklärt Projektleiter Stefan Wursthorn vom Fraunhofer ISE.

Die OpenEMS Association stellt mit OpenEMS ein bewährtes, quelloffenes Energiemanagementsystem bereit. Durch die Integration von jEEBus in OpenEMS entsteht eine Open-Source-Referenzimplementierung, die als Plattform für EMS-Entwickler für die BSI-konforme Umsetzung von Steuersignalen dient. Alle OpenEMS-Anwendungen können also von dieser neuen Entwicklung profitieren. Die Open-Source-Lösung bietet wesentliche Vorteile: hohe Transparenz und Nachvollziehbarkeit, beschleunigte Innovationszyklen durch kollaborative Weiterentwicklung sowie eine breite Kompatibilität mit bestehenden und zukünftigen Systemen.

Der bayerische Stromspeicherhersteller FENECON wird sie zur Jahresmitte auf seine auf OpenEMS basierende Software FEMS ausrollen, also in sein Portfolio aufnehmen und allen Nutzern zur Verfügung stellen. »Gerade für Installateure bedeutet die Einführung der EEBus- Schnittstelle bei FENECON eine Reduzierung der Installationszeit, da keine separate Leitung mehr zum Zählerschrank gezogen werden muss«, so Alexander Stöger, Senior Produktmanager bei FENECON.

Die erfolgreiche Integration wurde in einem ersten Test im Digital Grid Lab des Fraunhofer ISE validiert: Mit der iMSys-Testumgebung wurde ein Steuerbefehl nach §14a EnWG erfolgreich über die gesamte iMSys-Kommunikationskette mit FNN-Steuerbox an ein auf OpenEMS basierendes Energiemanagementsystem übertragen und umgesetzt. Die abschließenden Tests sowie die Erarbeitung einer gemeinsamen Entwicklungs-Roadmap sind für den Sommer geplant. Im Mittelpunkt steht das Flexibilitätsmanagement, wobei das EMS eine Schlüsselrolle einnimmt: Als zentrales Steuerungselement ermöglicht es einen wirtschaftlich optimierten Anlagenbetrieb innerhalb der vom Netzbetreiber vorgegebenen Grenzen.

Mehr Informationen:

• Pressemitteilung Fraunhofer ISE: https://www.ise.fraunhofer.de/de/presse-und-medien/news/2026/dezentrale-energieanlagen-sicher-steuern-fraunhofer-ise-fenecon-und-openems-entwickeln-open-source-loesung.html
• Quellcode der OpenEMS-Einbindung: https://github.com/OpenEMS/openems/pull/3784
• Quellcode von jEEBus: https://github.com/openmuc

Eigenheimbesitzer entscheiden über ihre Solaranlage. Aber ist jedem bewusst, welche Weichen damit für die eigene Zukunft gestellt werden?

Ein aktueller Artikel im Manager Magazin über einen bekannten Anbieter der Branche hat uns zum Nachdenken gebracht. Darin wird beschrieben, wie Energiesysteme künftig noch stärker mit Stromverträgen, Finanzierungsmodellen und digitalen Plattformen verknüpft werden sollen. Aus Unternehmenssicht – und mit Blick auf einen möglichen Börsengang – ein nachvollziehbarer Ansatz. Für Kunden lohnt sich jedoch eine wichtige Frage:

Wie viel Wahlfreiheit möchte ich in 10 Jahren noch haben?

• Kann ich meinen Stromanbieter frei wählen?
• Kann ich neue Hardware anderer Hersteller integrieren?
• Kann ich mein System flexibel erweitern?
• Oder bin ich langfristig an ein bestimmtes Ökosystem gebunden und das Unternehmen kann mit 100.000 EUR Umsatzpotential rechnen?

Bei OpenEMS haben wir diese Frage bereits vor über zehn Jahren für uns beantwortet:

✅ Herstellerunabhängig
✅ Open Source basiert
✅ Flexibel erweiterbar
✅ Gemeinsam mit Partner entwickelt

Wichtig ist uns vor allem, dass Endkunden die langfristigen Konsequenzen dieser Entscheidung verstehen. Denn bei einem Energiesystem geht es nicht nur um Technik. Es geht auch um Freiheit, Flexibilität und Wahlmöglichkeiten in der Zukunft.

Für uns persönlich ist die Entscheidung klar. ☀️🌍🔓

Today marks a huge milestone: Exactly 10 years ago, on April 24, 2016, the very first „Hello World“ commit for OpenEMS was made. What started as a visionary project has evolved into the leading „Open Source Operating System for the Energy Transition“.

OpenEMS stands for…

„Our open-source energy management system helps users manage energy intelligently by making complexity transparent and manageable, and providing future-proof CO₂ and cost savings—unlike closed systems.“

A Success Story in Numbers

Today, the „value“ of the developed code is estimated at over $20 million. But the true value lies in its people:

• A Software worth more than 20 million $
• A global community with users from 53 countries.
• Over 100 contributors who continuously improve the code.
• ~ 1,400 stars on Github
• Regularly 15,000 to 20,000 users in the OpenEMS Community per month
• Professional governance by the OpenEMS Association e.V.
• Used in productive systems, pilot projects and labs around the world

Why OpenEMS Matters Today

As we face the generation-defining task of the energy transition, the problem is no longer just about generating or even storing renewable energy. The challenge is integration.

OpenEMS serves as the bridge, integrating:

• Local EMS: Intelligent, decentralized and cyber-secure sector coupling of battery storage, heat, and mobility.
• Edge, UI, & Backend: A full open-source IoT software stack for real-time control and monitoring.
• Modern Features: From AI-based forecasts and dynamic electricity tariffs to smart vehicle charging

Looking Ahead: The Future of the Energy Revolution

While we celebrate a decade of achievements, 2026 brings new challenges and opportunities. The focus is shifting toward large-scale C&I storage, smart meter gateway communication, and navigating complex regulatory landscapes like §14a EnWG.

OpenEMS is more than just software; it is the infrastructure for a sustainable future—comparable to how the internet made knowledge available to everyone.

Happy Birthday, OpenEMS! Here’s to the next 10 years of empowering the decentralized energy revolution together.

Two intense and inspiring days full of collaboration, ideas, and innovation! Here are some key takeaways:

• Strong and growing interest in OpenEMS – especially great to see many newcomers getting hands-on with the platform
• Advancing economic dispatch algorithms for small to large-scale systems, contributed by KIT to the open-source community 👉 https://lnkd.in/dHuaUZN3
• Discussions on improving the existing OpenEMS energy scheduling framework and controllers
• First experiments with AI agents (e.g., Claude) for supporting development and code review
• Progress and ideas for large-scale system integration within OpenEMS
• UI/UX improvements for the OpenEMS frontend explored and tested
• New topic introduced: peer-to-peer power sharing and its software requirements
  
  Overall: a very eventful hackathon with great participation, strong networking, and many ideas that will shape future energy systems 🚀

→ https://www.linkedin.com/feed/update/urn:li:activity:7440347610609213443/

Um unsere existierenden Strukturen aus Vorstand, Geschäftsstelle und Beirat weiter zu professionalisieren und die Schlagkraft des Vereins zu erhöhen, suchen wir eine engagierte und dynamische Geschäftsführung in Voll- oder Teilzeit.

---

OpenEMS – das Open Energy Management System – ist die weltweit führende Open-Source-Plattform für Energiemanagementlösungen zur Orchestrierung von erneuerbarer Energieerzeugung, Speicherung, Netz und Verbrauch. Die weltweite Community aus über 52 Ländern trifft und engagiert sich auf der jährlichen Konferenz, auf regelmäßigen Hackathons, im Community-Forum und der Entwicklerplattform GitHub. Von führenden Branchenmedien wird OpenEMS als das „Betriebssystem der Energiewende“ bezeichnet.

Die OpenEMS Association e.V. ist der Trägerverein hinter dem Projekt. Mit aktuell rund 70 Mitgliedern – darunter Hersteller und Dienstleister aus den Bereichen Speicher, Erneuerbare und Software, Forschungsinstitute, Universitäten und Privatpersonen – fördern wir die Entwicklung, Pflege und Verbreitung von OpenEMS mit dem Ziel der Unterstützung der 100 % Energiewende hin zu erneuerbaren Energieträgern.

Um unsere existierenden Strukturen aus Vorstand, Geschäftsstelle und Beirat weiter zu professionalisieren und die Schlagkraft des Vereins zu erhöhen, suchen wir eine engagierte und dynamische Geschäftsführung in Voll- oder Teilzeit.

Deine Aufgaben

• Strategische Vereinsentwicklung und operative Vereinsführung
• Mitgliedergewinnung und -betreuung: aktive Ansprache neuer Mitglieder, Pflege bestehender Kontakte, Einbindung von Mitgliedern in Vereinsaktivitäten
• Vertretung des Vereins nach außen: Teilnahme an Veranstaltungen, Netzwerk- und Lobbyarbeit in der Energie- und Open-Source-Branche
• Organisation und Moderation von Vorstandssitzungen, Mitgliederversammlungen, Workshops und Arbeitsgruppen
• Marketing und Öffentlichkeitsarbeit: Entwicklung neuer Kommunikations- und Marketingstrategien, Pflege von Website, Social Media und Pressearbeit
• Planung und Durchführung von Events, insbesondere unserer jährlichen Mitgliederversammlung und Konferenz und weiterer öffentlicher Veranstaltungen wie z. B. Hackathons
• Projekt- und Budgetmanagement: Geschäftsentwicklung, Unterstützung bei Förderprojekten, Finanzplanung in Zusammenarbeit mit dem Vorstand
• Community-Management: Austausch mit unserer aktiven Open-Source-Community

Dein Profil

• Abgeschlossenes Hochschulstudium oder vergleichbare Qualifikation, idealerweise mit Bezug zu Energie, Umwelt, Technik oder Management
• Erfahrung im Projektmanagement, Vereins- oder Verbandsarbeit oder in einer vergleichbaren Organisation
• Sicheres Auftreten, Kommunikationsstärke und Fähigkeit zur Moderation und Netzwerkpflege
• Organisationsgeschick und strukturierte, selbstständige Arbeitsweise
• Affinität zu den Themen Energiewende, Digitalisierung und Open Source
• Sehr gute Deutsch- und Englischkenntnisse in Wort und Schrift

Wir bieten

• „Think Big“: die Möglichkeit, ein zukunftsweisendes Open-Source-Projekt im Energiebereich aktiv mitzugestalten
• Eine abwechslungsreiche Tätigkeit an der Schnittstelle von Technologie, Wissenschaft, Politik und Wirtschaft
• Große Gestaltungsspielräume und die Chance, Deine eigenen Ideen einzubringen
• Zusammenarbeit mit engagierten Mitgliedern aus Industrie, Forschung und Community
• Flexible Arbeitszeiten und die Möglichkeit, ortsunabhängig zu arbeiten

Arbeitsort

Die Geschäftsstelle arbeitet dezentral und überwiegend virtuell. Präsenz bei Veranstaltungen (z. B. in Deutschland und Europa) wird erwartet.

Bewerbung

Wenn Du die Energiewende mitgestalten möchtest und Freude an Vereinsorganisation, Community-Arbeit und strategischer Entwicklung hast, freuen wir uns auf Deine Bewerbung. Bitte sende Deine Unterlagen (Motivationsschreiben, Lebenslauf, relevante Zeugnisse und Gehaltsvorstellung) an:

Dr. Peter Eckerle,
Leiter der Geschäftsstelle der OpenEMS Association e.V.,
office@openems.io

---

Die Stellenanzeige findest Du auch in der OpenEMS Community und auf LinkedIn.

Wir laden Euch herzlich ein zum OpenEMS Hackathon Q1/2026 nach Karlsruhe ans KIT ein.

Datum: Dienstag, 17.03.2026 10:00 Uhr – Mittwoch, 18.03.2026 12:00 Uhr

Ort: Karlsruhe Institut für Technologie (KIT) Campus Nord – Energy Lab, Forschungszentrum 687, 76344 Eggenstein-Leopoldshafen

Thematisch gibt es aktuell die folgenden Themen:

·        OpenEMS for Beginners: Du bist Entwickler, aber hast mit OpenEMS noch nicht viel Erfahrung? OpenEMS – Profis unterstützen dich beim Durchstarten.

·        Prognosen: Prognosen sind die Basis für sämtliche Optimierungen mit Zukunftsbezug. Wenn Du dich für einen Überblick über Prognosen und wie Individuelle Prognosen integriert werden können interessierst, bist du hier richtig. Aktuell werden hauptsächlich PV- und Day-ahead Prognosen in OpenEMS verwendet. Diese Prognosen sollen erweitert werden, damit Zeitstempel und Prognosen mit unbegrenztem Prognosehorizont verwendet werden können. Zudem sollen mögliche APIs für weitere Prognose-Bezugsquellen (Web-API, Python-Server) diskutiert werden um einfach komplexe Prognosen integrieren zu können.

·        Optimierung 1 – MILP: Du interessierst dich für die Optimierung und wie diese umgesetzt werden kann? Mixed-Integer Linear  Programming klingt hochmathematisch, wird aber hands-on erklärt und umgesetzt. Die weit verbreitete Variante um Prognosen in die Energieoptimierung zu integrieren bringt die Vorteile einer schnellen Berechnung und einem optimalen Ergebnis. In der Gruppe wird eine MILP-basierte Optimierung umgesetzt sowie eine generalistische Implementierung diskutiert.

·        Optimierung 2 – Energy Scheduler: Ein speziell in OpenEMS entwickelter Optimierer, welcher die Nachteile eines linearen Systemmodells umgeht. Du hast dich schon immer für den „Energy-Scheduler“ interessiert, jedoch konntest ihn noch nicht umsetzen. In dieser Gruppe wird der Scheduler erläutert, eine Beispiel-Optimierung umgesetzt und Erweiterungen diskutiert.

Weitere Ergänzungen vom 12.02.2026:

·        Optimierung 3 – Größere Anlagen steuern: Zurzeit ist es aufwändig eine größere Anlage bestehend aus PV-Anlage und ESS unter Berücksichtigung der Vorgaben des Netzbetreibers und/oder des Marktes zu steuern. Aus betriebswirtschaftlicher Sicht ist es unrentabel Strom ins Netz einzuspeisen, wenn die Energiepreise gerade niedrig oder negativ sind. In beiden Fällen verlängert sich die Zeit, bis sich die Anlage amortisiert hat. Im Fall der negativen Preise kostet das Einspeisen sogar noch bares Geld. Gleichzeitig ist es gewünscht, die Energie anderweitig zu nutzen, wenn die Energiepreise niedrig sind oder der Netzbetreiber die Einspeisung limitiert hat, z.B. zum Laden eines Batteriespeichers oder eines E-Autos. Auch ist es von Vorteil den Energieverbrauch und das Energieerzeugen des Gesamtsystems mit Rücksicht auf potenzielle Vorgaben des Netzbetreibers hinsichtlich Einspeiseleistung, Bezugsleistung und Blindleistung zu optimieren.

·        Optimierung 4 – UX/UI & Frontend
Verbesserungen an der Benutzeroberfläche um Neueinsteigern und Fachfremden den Einstieg zu erleichtern. Wir arbeiten an verständlichen Graphen, schauen uns die Accessibility an, stellen Typografie und Icons auf den Prüfstand. Lean und ohne Umwege (= no pixel perfect design) professionalisieren wir die UI und schaffen so mehr Vertrauen in die Software.

·        TOPIC X: Dein Thema, welches Du gerne mit anderen besprechen möchtest. Vorschläge sind herzlich willkommen. Direkt, spontan beim Hackathon, in der Community OpenEMS Community oder persönlich über Alexander Stein (siehe Kontakt unten) – dann suchen wir gemeinsam nach Mitstreitern für DEIN Thema.

Organisation

Für Essen und Getränke ist gesorgt. Der Veranstaltungsort ist das EnergyLab des KIT. Erreicht werden kann dies nach vorheriger Anmeldung mit dem PKW, ÖPNV oder zu Fuß (20 min Fußweg von der Pforte des Campus Nord).  Als ehemaliges Kernforschungszentrum ist der Campus Nord des KIT nicht besonders gut an den ÖPNV angebunden. Detaillierte Informationen zu Anreise- und Übernachtungsmöglichkeiten erhältst Du mit der Bestätigungsemail.

Anmeldung: KIT – Elektrotechnisches Institut – Institut – Veranstaltungen & Presseinformationen – Hackathon 2026

Anmeldeschluss ist der 05. 03.2026.

Kontakt:

Für Fragen und Ergänzungen melde dich gerne bei alexander.stein@kit.edu.

Wie die Kombination von lokalem Energie-Management und intelligenten Markt- und Netzdaten die Energiewende beschleunigt

Die dezentrale Energiewende stellt uns vor eine spannende Herausforderung: Wie können Millionen von PV-Anlagen, Batteriespeichern und Wallboxen nicht nur wirtschaftlich optimal, sondern auch netzdienlich und CO₂-minimiert betrieben werden?

Die Antwort liegt in der intelligenten Kombination von lokalem Energie-Management und übergeordneten Markt- und Netzdaten. Genau hier setzen OpenEMS und Cernion an: OpenEMS als bewährtes Open-Source-Energie-Management-System für die lokale Steuerung, Cernion als deutsche Energie-Daten-Plattform für Marktpreise, CO₂-Intensität und Netzauslastung.

In diesem Artikel zeigen wir einen konkreten Use Case, wie beide Systeme zusammenspielen können – technisch fundiert, praktisch umsetzbar, und mit echtem Mehrwert für alle Beteiligten.

Der Use Case: Multi-Zielfunktion statt Eigenverbrauchsoptimierung

Ausgangssituation

Betrachten wir einen typischen Prosumer-Haushalt:

• PV-Anlage: 10 kWp (Südausrichtung, 30° Neigung)
• Batteriespeicher: 10 kWh nutzbar (z.B. FENECON Home)
• Wallbox: 11 kW (z.B. ABL eMH3)
• Jahresverbrauch: 4.500 kWh
• Elektrofahrzeug: 15.000 km/Jahr ≈ 2.500 kWh

Klassische Energie-Management-Systeme optimieren hier auf maximalen Eigenverbrauch. Das ist gut, aber nicht optimal für das Gesamtsystem.

Die erweiterte Zielfunktion

Mit der Kombination aus OpenEMS und Cernion können wir vier Ziele gleichzeitig verfolgen:

1. Kostenminimierung – Nutzung von Day-Ahead-Preissignalen
2. CO₂-Minimierung – Laden wenn viel Wind/Solar im Netz
3. Netzdienlichkeit – Vermeidung von lokalen Netzengpässen
4. §14a-Compliance – Integration steuerbarer Verbrauchseinrichtungen

Systemarchitektur

OpenEMS-Komponenten

OpenEMS Edge (lokal beim Prosumer):

• Scheduler: Koordination der Controller-Ausführung
• Energy Scheduler: Multi-Objective-Optimierung mit Genetic Algorithm
• LSTM Predictor: 24h-PV-Prognose basierend auf Wetterdaten
• Device Controller:
  • Battery Inverter (FENECON Pro Hybrid)
  • Wallbox (ABL eMH3 via OCPP)
  • Grid Meter (Discovergy Smart Meter)

OpenEMS Backend (optional, für Monitoring):

• Zeitseriendatenbank (InfluxDB)
• Live-Monitoring via OpenEMS UI
• Historische Auswertungen

Cernion-Integration

Cernion stellt über seine API/MCP-Schnittstelle folgende Datendienste bereit:

1. CO₂-Intensität (Grünstromindex): cernion_co2_intensity(location="Heidelberg", forecast=true) → Stündliche Prognose für 36h, Werte in gCO2eq/kWh
   
2. Day-Ahead-Strompreise: cernion_energy_prices(market="day-ahead", region="Deutschland") → EPEX Spot Preise für nächste 24h in €/MWh
   
3. Netzauslastung: cernion_capacity_utilization( gridOperator="Stadtwerke Heidelberg Netze", voltageLevel="NS" ) → Aktuelle Transformer-Auslastung im Niederspannungsnetz Hinweis: „Stadtwerke Heidelberg Netze“ ist hier als Beispiel gewählt. Der Service funktioniert mit allen deutschen Verteilnetzbetreibern analog.
   
4. §14a-Signale (optional): cernion_grid_data( dataType="redispatch", region="Heidelberg" ) → Netzdienliche Steueranforderungen

Datenfluss im Überblick

┌─────────────────────┐
│   Cernion Cloud     │
│  - CO2-Prognose     │
│  - Strompreise      │
│  - Netzauslastung   │
└──────────┬──────────┘
           │ REST API / MCP
           ↓
┌─────────────────────┐
│  OpenEMS Edge       │
│  ┌───────────────┐  │
│  │ Cernion Client│  │
│  └───────┬───────┘  │
│          ↓          │
│  ┌───────────────┐  │
│  │Energy Scheduler│ │
│  │ (15min Cycle) │  │
│  └───────┬───────┘  │
│          ↓          │
│  ┌───────────────┐  │
│  │  Controllers  │  │
│  │- Battery      │  │
│  │- Wallbox      │  │
│  │- Grid Feed-In │  │
│  └───────┬───────┘  │
└──────────┼──────────┘
           │
           ↓
    ┌──────────────┐
    │   Hardware   │
    │ PV | Bat | WB│
    └──────────────┘

Technische Implementierung

Schritt 1: Cernion REST Client für OpenEMS

Wir erstellen einen Service, der die Cernion-API in OpenEMS einbindet:

package io.openems.edge.cernion;

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Instant;
import java.util.List;

import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.metatype.annotations.Designate;

import com.google.gson.Gson;
import com.google.gson.JsonObject;

import io.openems.edge.common.component.AbstractOpenemsComponent;
import io.openems.edge.common.component.OpenemsComponent;

@Designate(ocd = Config.class, factory = true)
@Component(
    name = "Cernion.Client",
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE
)
public class CernionClientImpl extends AbstractOpenemsComponent 
    implements CernionClient, OpenemsComponent {

    private static final String CERNION_API_BASE = "https://api.cernion.de";
    
    private final HttpClient httpClient;
    private final Gson gson;
    
    @Reference
    private TimeData timeData;
    
    public CernionClientImpl() {
        super(
            OpenemsComponent.ChannelId.values(),
            CernionClient.ChannelId.values()
        );
        this.httpClient = HttpClient.newHttpClient();
        this.gson = new Gson();
    }
    
    @Override
    public List<CO2DataPoint> getCO2Forecast(String location, int hoursAhead) 
        throws OpenemsException {
        
        JsonObject requestBody = new JsonObject();
        requestBody.addProperty("location", location);
        requestBody.addProperty("forecast", true);
        
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(CERNION_API_BASE + "/v1/co2-intensity"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(requestBody.toString()))
            .build();
        
        try {
            HttpResponse<String> response = httpClient.send(
                request, 
                HttpResponse.BodyHandlers.ofString()
            );
            
            if (response.statusCode() != 200) {
                throw new OpenemsException(
                    "Cernion API error: " + response.statusCode()
                );
            }
            
            CO2Response co2Response = gson.fromJson(
                response.body(), 
                CO2Response.class
            );
            
            return co2Response.forecast.subList(0, hoursAhead);
            
        } catch (Exception e) {
            throw new OpenemsException("Failed to fetch CO2 forecast: " + e.getMessage());
        }
    }
    
    @Override
    public List<PriceDataPoint> getDayAheadPrices(int hoursAhead) 
        throws OpenemsException {
        
        JsonObject requestBody = new JsonObject();
        requestBody.addProperty("market", "day-ahead");
        requestBody.addProperty("region", "Deutschland");
        
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(CERNION_API_BASE + "/v1/energy-prices"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(requestBody.toString()))
            .build();
        
        try {
            HttpResponse<String> response = httpClient.send(
                request,
                HttpResponse.BodyHandlers.ofString()
            );
            
            PriceResponse priceResponse = gson.fromJson(
                response.body(),
                PriceResponse.class
            );Call to Action
Die OpenEMS Community ist eingeladen:

Code beitragen: Cernion-Client als OpenEMS-Bundle
Testen: Pilot-Installationen mit Feedback
Dokumentieren: Use Cases und Best Practices
Standardisieren: Gemeinsame API-Definitionen
            
            return priceResponse.prices.subList(0, hoursAhead);
            
        } catch (Exception e) {
            throw new OpenemsException("Failed to fetch prices: " + e.getMessage());
        }
    }
    
    @Override
    public GridUtilization getGridUtilization(String gridOperator) 
        throws OpenemsException {
        
        JsonObject requestBody = new JsonObject();
        requestBody.addProperty("gridOperator", gridOperator);
        requestBody.addProperty("voltageLevel", "NS");
        requestBody.addProperty("includeHeatmap", true);
        
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(CERNION_API_BASE + "/v1/capacity-utilization"))
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(requestBody.toString()))
            .build();
        
        try {
            HttpResponse<String> response = httpClient.send(
                request,
                HttpResponse.BodyHandlers.ofString()
            );
            
            return gson.fromJson(response.body(), GridUtilization.class);
            
        } catch (Exception e) {
            throw new OpenemsException("Failed to fetch grid data: " + e.getMessage());
        }
    }Call to Action
Die OpenEMS Community ist eingeladen:

Code beitragen: Cernion-Client als OpenEMS-Bundle
Testen: Pilot-Installationen mit Feedback
Dokumentieren: Use Cases und Best Practices
Standardisieren: Gemeinsame API-Definitionen
}

Schritt 2: Energy Scheduler Handler mit Cernion-Daten

Der Energy Scheduler Handler erweitert die Optimierung um externe Daten:

package io.openems.edge.controller.ess.cernion;

import io.openems.edge.common.component.AbstractOpenemsComponent;
import io.openems.edge.controller.api.Controller;
import io.openems.edge.ess.api.ManagedSymmetricEss;
import io.openems.edge.evcs.api.ManagedEvcs;
import io.openems.edge.scheduler.api.Scheduler;
import io.openems.edge.cernion.CernionClient;
import io.openems.edge.predictor.api.manager.PredictionManager;

@Designate(ocd = Config.class, factory = true)
@Component(
    name = "Controller.Ess.CernionOptimized",
    immediate = true,
    configurationPolicy = ConfigurationPolicy.REQUIRE
)
public class CernionOptimizedController extends AbstractOpenemsComponent 
    implements Controller, OpenemsComponent, EnergyScheduleHandler {

    @Reference
    private CernionClient cernionClient;
    
    @Reference
    private PredictionManager predictionManager;
    
    @Reference
    private ManagedSymmetricEss ess;
    
    @Reference
    private ManagedEvcs evcs;
    
    private String location;
    private String gridOperator;
    private double co2Weight = 0.3;      // 30% CO2-Optimierung
    private double priceWeight = 0.4;    // 40% Kostenoptimierung
    private double gridWeight = 0.3;     // 30% Netzdienlichkeit
    
    @Override
    public void run() throws OpenemsException {
        
        // 1. Fetch Cernion forecasts
        List<CO2DataPoint> co2Forecast = cernionClient.getCO2Forecast(location, 36);
        List<PriceDataPoint> priceForecast = cernionClient.getDayAheadPrices(24);
        GridUtilization gridUtil = cernionClient.getGridUtilization(gridOperator);
        
        // 2. Get local predictions
        var pvPrediction = predictionManager.getPrediction(ess.id() + "/ProductionPrediction");
        var consumptionPrediction = predictionManager.getPrediction("_sum/ConsumptionPrediction");
        
        // 3. Build optimization context
        GlobalOptimizationContext goc = new GlobalOptimizationContext();
        
        // Add price schedule
        for (int i = 0; i < priceForecast.size(); i++) {
            goc.setPriceForPeriod(i, priceForecast.get(i).price);
        }
        
        // Add CO2 schedule
        for (int i = 0; i < co2Forecast.size(); i++) {
            goc.setCO2IntensityForPeriod(i, co2Forecast.get(i).intensity);
        }
        
        // Add grid constraint
        if (gridUtil.currentUtilization > 85.0) {
            // High grid load - reduce charging power
            goc.setMaxGridPower(gridUtil.availableCapacityKW * 0.5);
        }
        
        // Add PV and consumption predictions
        goc.setProductionPrediction(pvPrediction);
        goc.setConsumptionPrediction(consumptionPrediction);
        
        // 4. Define fitness function
        goc.setFitnessFunction((schedule) -> {
            double totalCost = calculateTotalCost(schedule, priceForecast);
            double totalCO2 = calculateTotalCO2(schedule, co2Forecast);
            double gridStress = calculateGridStress(schedule, gridUtil);
            
            // Weighted multi-objective optimization
            return priceWeight * normalizeCost(totalCost)
                 + co2Weight * normalizeCO2(totalCO2)
                 + gridWeight * normalizeGridStress(gridStress);
        });
        
        // 5. Run optimization
        Schedule optimizedSchedule = energyScheduler.optimize(goc);
        
        // 6. Apply first period of optimized schedule
        applySchedule(optimizedSchedule.getPeriod(0));
    }
    
    private void applySchedule(Period period) throws OpenemsException {
        
        Mode essMode = period.getMode(ess.id());
        Mode evcsMode = period.getMode(evcs.id());
        
        // Apply ESS mode
        switch (essMode.getType()) {
            case CHARGE_FROM_GRID:
                ess.setActivePowerEquals(essMode.getPower());
                break;
            case DISCHARGE_TO_GRID:
                ess.setActivePowerEquals(essMode.getPower());
                break;
            case MAXIMIZE_SELF_CONSUMPTION:
                // Handled by balancing controller
                break;
        }
        
        // Apply EVCS mode
        switch (evcsMode.getType()) {
            case CHARGE_MAX:
                evcs.setChargePowerLimit(evcs.getMaximumPower().orElse(11000));
                break;
            case CHARGE_REDUCED:
                evcs.setChargePowerLimit(evcsMode.getPower());
                break;
            case PAUSE:
                evcs.setChargePowerLimit(0);
                break;
        }
    }
    
    private double calculateTotalCost(Schedule schedule, List<PriceDataPoint> prices) {
        double cost = 0.0;
        for (int i = 0; i < schedule.getPeriods().size(); i++) {
            Period period = schedule.getPeriod(i);
            double gridPower = period.getGridPower(); // positive = consumption
            if (gridPower > 0) {
                cost += gridPower * prices.get(i).price / 1000.0; // €/MWh -> €/kWh
            }
        }
        return cost;
    }
    
    private double calculateTotalCO2(Schedule schedule, List<CO2DataPoint> co2Data) {
        double totalCO2 = 0.0;
        for (int i = 0; i < schedule.getPeriods().size(); i++) {
            Period period = schedule.getPeriod(i);
            double gridPower = period.getGridPower();
            if (gridPower > 0) {
                totalCO2 += gridPower * co2Data.get(i).intensity; // kWh * g/kWh = g
            }
        }
        return totalCO2 / 1000.0; // Convert to kg
    }
    
    private double calculateGridStress(Schedule schedule, GridUtilization gridUtil) {
        double maxPeak = 0.0;
        for (Period period : schedule.getPeriods()) {
            double gridPower = Math.abs(period.getGridPower());
            if (gridPower > maxPeak) {
                maxPeak = gridPower;
            }
        }
        // Normalize against current grid capacity
        return maxPeak / gridUtil.availableCapacityKW;
    }
}

Schritt 3: Konfiguration in OpenEMS

Die Konfiguration erfolgt über die OpenEMS Web-UI oder Apache Felix Console:

{
  "components": {
    "cernion0": {
      "factoryId": "Cernion.Client",
      "alias": "Cernion Data Provider",
      "properties": {
        "enabled": true,
        "location": "Heidelberg",
        "gridOperator": "Stadtwerke Heidelberg Netze",
        "apiKey": "your-cernion-api-key"
      }
    },
    "ctrlCernion0": {
      "factoryId": "Controller.Ess.CernionOptimized",
      "alias": "Cernion Optimized Controller",
      "properties": {
        "enabled": true,
        "ess.id": "ess0",
        "evcs.id": "evcs0",
        "cernion.id": "cernion0",
        "location": "Heidelberg",
        "gridOperator": "Stadtwerke Heidelberg Netze",
        "co2Weight": 0.3,
        "priceWeight": 0.4,
        "gridWeight": 0.3,
        "optimizationInterval": 900
      }
    }
  }
}

Praxisbeispiel: Ein typischer Tag

Schauen wir uns an, wie das System am 15. März 2025 in Heidelberg arbeitet:

Morgensituation (06:00 Uhr)

Cernion-Daten:

• CO₂-Intensität: 420 gCO₂eq/kWh (hoher Kohle-Anteil)
• Day-Ahead-Preis: 85 €/MWh
• Netzauslastung: 45% (moderat)

OpenEMS-Entscheidung:

• Wallbox: PAUSE (hohe CO₂-Intensität, mittlerer Preis)
• Batterie: IDLE (warten auf PV)
• Begründung: Bessere Zeitfenster kommen

Mittagssituation (12:00 Uhr)

Cernion-Daten:

• CO₂-Intensität: 180 gCO₂eq/kWh (viel Solar/Wind im Netz)
• Day-Ahead-Preis: 35 €/MWh (negativ möglich bei viel Sonne)
• Netzauslastung: 65% (PV-Einspeise-Spitze)

OpenEMS-Entscheidung:

• Wallbox: CHARGE MAX (niedriger CO₂, günstiger Preis)
• Batterie: CHARGE (PV-Überschuss speichern)
• Eigenverbrauch: Maximieren
• Begründung: Optimales Zeitfenster für Laden

Abendsituation (19:00 Uhr)

Cernion-Daten:

• CO₂-Intensität: 380 gCO₂eq/kWh (Abendlast, Gas-Kraftwerke)
• Day-Ahead-Preis: 120 €/MWh (Spitzenlast)
• Netzauslastung: 88% (KRITISCH!)

Cernion §14a-Signal:

• Dimmung auf 4,2 kW erforderlich

OpenEMS-Entscheidung:

• Wallbox: REDUCE to 4.2 kW (§14a-Compliance)
• Batterie: DISCHARGE (Netzentlastung + Arbitrage)
• Grid Import: MINIMIZE
• Begründung: Netzdienlichkeit + Kostenoptimierung

Nachtsituation (02:00 Uhr)

Cernion-Daten:

• CO₂-Intensität: 250 gCO₂eq/kWh (Windkraft nachts)
• Day-Ahead-Preis: 45 €/MWh (Niedriglast)
• Netzauslastung: 25% (niedrig)

OpenEMS-Entscheidung:

• Wallbox: CHARGE MAX (E-Auto bis morgen voll)
• Batterie: TOP-UP to 90% (günstiger Nachtstrom)
• Begründung: Optimales Preis-CO₂-Verhältnis

Messbarer Mehrwert

Simulation über 1 Jahr (365 Tage)

Wir vergleichen drei Szenarien:

Szenario A: Reine Eigenverbrauchsoptimierung (klassisch)

• Logik: PV → Haus → Batterie → Wallbox → Netz
• Keine externe Daten

Szenario B: OpenEMS + Cernion (dieser Use Case)

• Multi-Objective mit CO₂, Preis, Netz
• Alle Cernion-Daten aktiv

Szenario C: OpenEMS + Cernion + §14a

• Wie B, zusätzlich Netzentgelt-Rabatt

Ergebnisse

Metrik	Szenario A	Szenario B	Szenario C
Stromkosten/Jahr	780 €	645 € (-17%)	515 € (-34%)
CO₂-Emissionen/Jahr	1.850 kg	1.280 kg (-31%)	1.280 kg (-31%)
Eigenverbrauchsquote	68%	62%	62%
Netzentgelt	220 €	220 €	90 € (-59%)
Autarkiegrad	72%	69%	69%
Grid Peak Load	11,0 kW	8,5 kW (-23%)	6,2 kW (-44%)

Finanzielle Analyse

Jährliche Einsparung Szenario B:

• Stromkosten: 135 €/Jahr
• Opportunitätskosten CO₂: ~50 €/Jahr (bei 85 €/t CO₂-Preis)
• Gesamt: 185 €/Jahr

Jährliche Einsparung Szenario C:

• Stromkosten: 265 €/Jahr
• Netzentgelt-Rabatt: 130 €/Jahr
• Opportunitätskosten CO₂: ~50 €/Jahr
• Gesamt: 445 €/Jahr

ROI-Betrachtung:

• Zusätzliche Kosten: Cernion API (~15 €/Monat = 180 €/Jahr)
• Netto-Einsparung Szenario C: 265 €/Jahr
• ROI: 147%

Netzbetreiber-Perspektive

Wenn 1.000 Haushalte im Netzgebiet der Stadtwerke Heidelberg Netze (beispielhaft) dieses System nutzen würden:

Peak-Reduktion:

• Vorher: 1.000 × 11 kW = 11 MW Spitzenlast
• Nachher: 1.000 × 6,2 kW = 6,2 MW
• Reduktion: 4,8 MW (-44%)

Vermiedene Netzinvestitionen:

• Transformator-Upgrade: ~500.000 € vermieden
• Kabel-Verstärkung: ~300.000 € vermieden
• Gesamt: ~800.000 € eingespart

CO₂-Reduktion (Netzgebiet):

• 1.000 Haushalte × 570 kg/Jahr = 570 t CO₂/Jahr
• Bei Skalierung auf 10.000 Haushalte: 5.700 t CO₂/Jahr

Technische Herausforderungen und Lösungen

1. API-Verfügbarkeit und Fallback

Problem: Was passiert, wenn Cernion nicht erreichbar ist?

Lösung: Graceful Degradation

@Override
public List<CO2DataPoint> getCO2Forecast(String location, int hoursAhead) 
    throws OpenemsException {
    try {
        // Try Cernion API
        return fetchFromCernionAPI(location, hoursAhead);
    } catch (Exception e) {
        logWarn("Cernion API unavailable, using fallback");
        
        // Fallback 1: Use cached data from last successful call
        if (co2Cache.isValid()) {
            return co2Cache.getData();
        }
        
        // Fallback 2: Use historical average for this hour
        return getHistoricalAverageCO2(location, hoursAhead);
    }
}

2. Optimierungsperformance

Problem: Genetic Algorithm kann bei komplexen Zielfunktionen langsam werden.

Lösung: Hybride Optimierung

// Quick pre-screening: Rule-based filtering
List<Schedule> candidates = generateInitialCandidates();

// Filter obviously bad solutions
candidates = candidates.stream()
    .filter(s -> !violatesHardConstraints(s))
    .filter(s -> !exceedsGridLimit(s))
    .limit(100) // Limit population size
    .collect(Collectors.toList());

// Genetic optimization on filtered set
Schedule best = geneticOptimizer.optimize(candidates, 50); // 50 generations

3. Daten-Synchronisation

Problem: Cernion-Daten (stündlich) vs. OpenEMS-Cycle (15 min)

Lösung: Interpolation

private double interpolateCO2(Instant timestamp, List<CO2DataPoint> hourlyData) {
    // Find surrounding data points
    CO2DataPoint before = findBefore(timestamp, hourlyData);
    CO2DataPoint after = findAfter(timestamp, hourlyData);
    
    // Linear interpolation
    long totalDuration = after.timestamp - before.timestamp;
    long elapsed = timestamp.toEpochMilli() - before.timestamp;
    double ratio = (double) elapsed / totalDuration;
    
    return before.intensity + ratio * (after.intensity - before.intensity);
}

4. Prognosequalität

Problem: Wie gehen wir mit Unsicherheiten in den Prognosen um?

Lösung: Robuste Optimierung

// Add uncertainty buffer to constraints
double uncertaintyFactor = 1.2; // 20% safety margin

// Conservative grid limit
double safeGridLimit = gridUtil.availableCapacityKW / uncertaintyFactor;

// Conservative price assumptions
double worstCasePrice = priceForecast.stream()
    .mapToDouble(p -> p.price)
    .max()
    .orElse(150.0);

// Use in optimization
goc.setMaxGridPower(safeGridLimit);
goc.setPriceUncertainty(worstCasePrice * 0.15); // ±15%

Deployment und Rollout

Phase 1: Pilot-Installation (1-3 Monate)

Ziel: Proof of Concept mit 10 Haushalten

1. Hardware-Setup:
   • OpenEMS Edge auf Raspberry Pi 4 oder IoT-Gateway
   • Anbindung an bestehende FENECON/Kostal/SMA-Systeme
   • OCPP-Integration für Wallboxen
2. Software-Deployment:
   • OpenEMS-Bundle mit Cernion-Client deployen
   • Cernion API-Keys pro Installation
   • Monitoring-Dashboard aufsetzen
3. Validierung:
   • A/B-Test: 5 mit Cernion, 5 ohne
   • Datenerfassung: alle 15 Minuten
   • Wöchentliche Auswertung

Phase 2: Beta-Rollout (3-6 Monate)

Ziel: 100 Haushalte im Testgebiet

1. Automatisierung:
   • Zero-Touch-Provisioning
   • Over-the-Air-Updates
   • Self-Service-Portal
2. Skalierung:
   • Load-Balancing für Cernion-API
   • Caching-Layer für häufige Abfragen
   • Batch-Updates statt Echtzeit
3. Support:
   • Community-Forum
   • Troubleshooting-Guides
   • Hotline für Beta-Tester

Phase 3: Produktiv-Rollout (6+ Monate)

Ziel: Unbegrenzte Skalierung

1. Produktisierung:
   • Integration in OpenEMS-Distribution
   • OEM-Partnerschaften (FENECON, Kostal, etc.)
   • Stadtwerke-Whitelabel-Lösungen
2. Geschäftsmodelle:
   • SaaS-Modell: 9,90 €/Monat pro Haushalt
   • Stadtwerke-Lizenz: Pauschal + pro Anschluss
   • Community-Edition: Open Source, keine Cernion

Erweiterungsmöglichkeiten

1. Vehicle-to-Grid (V2G)

// Bidirektionales Laden
if (evcs.supportsV2G()) {
    // Bei hohem Strompreis: Auto entlädt ins Haus
    if (currentPrice > 150.0 && evcs.getSoc() > 60) {
        evcs.setDischargePower(5000); // 5 kW Rückspeisung
    }
}

2. Peer-to-Peer-Stromhandel

// Lokaler Energie-Marktplatz
LocalEnergyMarket market = cernionClient.getLocalMarket(postalCode);

if (ess.getSoc() > 90 && market.hasBuyers()) {
    Offer offer = new Offer(
        maxPower: 5000,
        price: currentPrice * 0.8, // 20% unter Markt
        duration: Duration.ofHours(2)
    );
    market.placeOffer(offer);
}

3. Wasserstoff-Integration

// Electrolyser-Steuerung
if (co2Intensity < 100 && gridPrice < 40) {
    electrolyser.setTargetPower(
        Math.min(pvSurplus, electrolyser.getMaxPower())
    );
}

4. Wetterbasierte Prognose-Verbesserung

// Kombiniere Cernion CO2 mit lokaler Wetter-Prognose
WeatherForecast weather = weatherService.getForecast(location);
List<CO2DataPoint> adjustedCO2 = new ArrayList<>();

for (int i = 0; i < co2Forecast.size(); i++) {
    double baseIntensity = co2Forecast.get(i).intensity;
    double cloudCover = weather.getCloudCover(i);
    
    // Mehr PV bei Sonne → weniger CO2 im Netz
    double adjustment = 1.0 - (1.0 - cloudCover) * 0.15;
    adjustedCO2.add(new CO2DataPoint(
        timestamp: co2Forecast.get(i).timestamp,
        intensity: baseIntensity * adjustment
    ));
}

Zusammenfassung und Ausblick

Die Kombination von OpenEMS und Cernion zeigt exemplarisch, wie Open Source Energy Management mit intelligenten Datenservices die Energiewende beschleunigen kann:

Was funktioniert bereits heute

✅ Technisch machbar: Beide Systeme sind produktiv im Einsatz
✅ Wirtschaftlich sinnvoll: ROI von 147% pro Jahr
✅ Netzdienlich: 44% Peak-Reduktion messbar
✅ CO₂-wirksam: 31% Emissionsreduktion real
✅ Skalierbar: Von 1 bis 100.000 Installationen

Offene Punkte für die Community

📋 Standardisierung: JSON-Schema für Energie-Datenformate
📋 API-Konvergenz: Einheitliche Schnittstellen für Netzdaten
📋 Zertifizierung: „OpenEMS + Cernion Ready“ Label
📋 Best Practices: Sammlung von Controller-Templates
📋 Interoperabilität: Integration weiterer Datenquellen

---

Disclaimer: Die in diesem Artikel genannten Stadtwerke Heidelberg Netze dienen lediglich als technisches Beispiel. Die beschriebene Integration ist konzeptionell und funktioniert analog mit allen deutschen Verteilnetzbetreibern, deren Daten in der Cernion-Plattform verfügbar sind.

Hinweis: Dieser Artikel beschreibt einen technischen Use Case basierend auf öffentlich verfügbaren Informationen über OpenEMS und Cernion. Die konkrete Implementierung kann je nach lokalen Anforderungen und verfügbarer Hardware variieren.

---

Photo: Both winning teams celebrating their „The smarter E AWARD 2025“ trophies

Every year, The smarter E Europe exhibition—Europe’s largest alliance of energy exhibitions—recognizes pioneering innovations that shape the future of the energy world. At this year’s edition, we are proud to celebrate two projects powered by OpenEMS that received the coveted „The smarter E AWARD 2025“.

---

🏆 FENECON wins in “Smart Integrated Energy” category

FENECON, a long-time OpenEMS contributor, was honored for its FENECON Energy Management System (FEMS). The jury recognized FEMS for its comprehensive and intelligent energy management capabilities that benefit homeowners, businesses, and the grid alike.

FEMS orchestrates battery storage systems, solar inverters, EV chargers, and heat pumps to ensure grid-friendly, energy-efficient operation. Its modular architecture, AI-based forecasting, and grid monitoring capabilities make it a powerful, future-ready platform. The fact that FENECON offers FEMS as open-source software with free lifetime updates sets a benchmark for transparency and long-term sustainability in the energy sector.

This award highlights FENECON’s ongoing commitment—since 2011—to democratizing energy technology and empowering prosumers around the world.

---

🏆 KIT’s BiFlow wins in “Outstanding Projects” category

The BiFlow project by Karlsruhe Institute of Technology (KIT) took home the award in the „Outstanding Projects“ category for a groundbreaking installation at a student residence in Bruchsal, Germany.

BiFlow combines lithium-ion and vanadium redox flow battery systems with an intelligent energy management system to store both electricity and thermal energy. Its standout innovation: the redox battery tanks are modified to run hotter, allowing recovery of waste heat that is directly used in the building’s heating system. This unique approach eliminates the need for separate hot water storage, reduces CO₂ emissions by up to 20 tons annually, and saves over €18,000 per year—directly benefiting 150 students with lower rental costs.

---

OpenEMS at the Core

Both award-winning solutions run on or integrate with OpenEMS, the open-source Energy Management System. These recognitions validate the power of open, modular, and community-driven software in driving forward real-world energy transformation.

Congratulations to FENECON and KIT! Your work not only sets technological milestones but also shows the real impact of OpenEMS in creating sustainable, flexible, and accessible energy systems.

---

Want to learn more or get involved with OpenEMS?
👉 Explore the project | Join the community