Release 2021.18.0

  • Time-of-use-Tariff Discharge Controller

Schedules the discharging of an AC or DC energy storage system in the night based on time-of-use prices, predicted production and consumption.

  • ESS Cycle Controller

Executes charge/discharge cycles on an ESS.

  • Generic Off-Grid ESS Implementation

Similar to the existing Generic-ESS, this Off-Grid variant takes any off-gridable battery inverter (like Sinexcel), any battery and an external device that manages grid-switching and off-grid detection to seamlessly transfer between public- and micro-grid.

  • Numerous bug fixes, dependency updates and other changes

https://github.com/OpenEMS/openems/releases/tag/2021.18.0

Israel’s first grid-connected industrial energy storage facility is powered by OpenEMS

Israel’s first grid-connected all-in-one industrial energy storage facility has gone online earlier this spring. It supplies green energy to one of the leading renewable technology oriented Kibbutz in the country.

Read more → https://kaco-newenergy.com/news-and-events/notice-detail/kaco-new-energy-supplies-israels-first-grid-connected-industrial-energy-storage-facility/

This project was implemented by OpenEMS Association members KACO new energy and FENECON.

OpenEMS in der Praxis: Leaflet Step-by-Step

Consolinno Leaflet Konfiguration Step by Step

OpenEMS-Mitglied Consolinno hat uns bereits seinen Energy-Manager Leaflet inklusive How to vorgestellt. Wie genau das Leaflet konfiguriert werden muss, erfahrt ihr in fünf Schritten in diesem Step-by-Step-Guide.

1. Wie funktioniert die Konfiguration mit der Apache Felix Web Console? 

Über die Apache Felix Web Console werden alle Konfigurationen vorgenommen. Sie ist unter [ipadresseLeaflet]:8080/system/console/configMgr zu erreichen. Bei einer Neuinstallation müsst ihr als erstes runterscrollen und – wenn noch nicht vorhanden – den Scheduler All Alphabetically aktivieren.

Dafür ruft ihr den Konfigurationspunkt auf, woraufhin sich folgendes Fenster öffnet: 

Hier müsst ihr nichts mehr eingeben, sondern einfach nur unten rechts auf Save drücken.

2. Und weiter: Was ist die Modbus/TCP Bridge?

Danach wird die Bridge Modbus/TCP aktiviert, sie ist nur eine Kommunikationsschnittstelle, kein Server. Hier ist wichtig, dass ihr bei der IP-Adresse entweder die des Leaflets angebt oder einfach wie im Bild unten „localhost“. Dazu muss der Port zu „1502“ geändert werden (standardmäßig steht hier 502), was ihr wiederum mit Save unten rechts bestätigt. 

3. Wie konfiguriert man das Leaflet selbst?

Ihr ruft hierfür den Consolinno Leaflet Modbusconfigurator oder (wie auf dem folgenden Bild) in neueren Versionen den Consolinno Leaflet Core auf. Sollte es nicht automatisch passiert sein, müsst ihr an dieser Stelle nur zwei Werte vergeben. Die ModbusUnitId ist immer „1“ und die ModbusbridgeId ist der Name der Bridge, die im Schritt vorher erstellt wurde (also hier: „modbus0“).

4. Welche Rolle spielt die ModbusRegMap?

An dieser Stelle ist eine „modbusregmap.csv“ wichtig: Diese Konfig ist nicht dafür gedacht, vom Nutzer bearbeitet zu werden und auch der Pfad sollte nicht geändert werden. Der Inhalt dieser Konfig ist die Zuweisung der Modbusregister zu den Modulen und ihren Funktionen. Die CSV-Datei ist von rein interner Bedeutung, wird von der Firmware aus geliefert, aktiv bearbeitet und geupdated. Sie sieht so aus:

Sollte sich der Pfad der CSV-Datei ändern, wird das auch bei einem OpenEMS-Update übernommen.

Nochmal: Ihr braucht an der Datei nichts ändern, eine Bearbeitung kann das System unbrauchbar machen!

Der einzige Grund, warum diese Datei überhaupt in der Konfig erscheint, ist für den (unwahrscheinlichen) Fall, dass ein Nutzer mehrere OpenEMS-Versionen benutzen will, die jeweils eine andere ModbusRegMap benötigen. In jedem anderen Fall kann dieser Konfig-Punkt getrost ignoriert werden.

5. Leaflet abgehakt – was ist bei den Modulen noch zu tun?

Sobald der ModbusConfigurator bzw. Core aktiv ist, könnt ihr nun die gewünschten Leaflet Module konfigurieren. Hier als Beispiel das neu hinzugefügte AIO-Modul, Consolinno Leaflet Modbus Aio:

Das AIO-Modul (Analog Input Output) ist in der Lage, verschiedene Spannungen und Stromstärken auszugeben und Temperaturen zu lesen. Hier müsst ihr noch eine Id vergeben sowie die Modulnummer des AIO-Moduls (Module) und die Position des AIO-Steckplatzes bzw. Pins (Position), welche benutzt werden sollen. Wie bei allen anderen Modulen auch werden die Pins einzeln betrachtet (z.B. Relay 1 oder Temperatur Sensor-Eingang 2 etc.). Das heißt, ihr konfiguriert nicht ein ganzes Modul, sondern immer einen einzelnen Ein- oder Ausgang. Die ModbusUnitId ist wie bei allen Modulen „1“ und die ModbusBridgeId ist dieselbe wie die der ModbusBridge, im unserem Beispiel „modbus0“.

Für euren jeweiligen Anwendungsfall müsst ihr entsprechend den richtigen Modus auswählen. Die vorhandenen Modi (Type) seht ihr im Drop-Down:

Sehen wir uns als weiteres Beispiel das Temperatur-Modul an, Consolinno Leaflet Modbus Temperatur Sensor:

Hier gebt ihr ebenfalls die Modulnummer des Temperatur-Modules (Module) und die Position des Inputs (Position) an. Die ModbusUnitId ist wiederum „1“, die ModbusBridgeId „modbus0“.

Zum Schluss noch eine Anmerkung zum PWM-Modul: Sollten die angeschlossenen PWM-Module eine andere Frequenz ausgeben als die Standard-Frequenz, müsst ihr den Consolinno Leaflet Pwm Frequency Configurator konfigurieren:

Ihr gebt nur die PWM-Modulnummer (Pwm Module Module Number – hier wird ausnahmsweise das gesamte Modul konfiguriert) an und danach die Frequenz (Frequency).

Viel Erfolg beim Konfigurieren – euer Consolinno-OpenEMS-Team!

Release 2021.14.0

  • Similar-Day Predictor

The research in EMSIG project showed, that the ‚Similar-Day-Model‘ can achieve good results for prediction of a household consumption. This release comes with an implementation of this model as a predictor in OpenEMS.

  • Bosch BPT-S 5 Hybrid Energy Storage System

The dated Bosch BPT-S 5 Hybrid ESS is now supported by OpenEMS.

  • Numerous bug fixes, dependency updatens and other changes

https://github.com/OpenEMS/openems/releases/tag/2021.14.0

OpenEMS in der Praxis: MQTT-Implementierung von Consolinno

Consolinno MQTT

Neues von unserem OpenEMS-Mitglied Consolinno: Diesmal gibt’s einen Experten-Artikel zum Thema MQTT! Da der Artikel mit Fachwörtern gespickt ist, findet ihr bei Bedarf am Ende einige Begriffserklärungen (#).

Was heißt MQTT? 

Consolinno: Das „Message Queuing Telemetry Transport Protokoll“ (kurz MQTT) ist ein stark präsentes Protokoll im IoT-Bereich, das die Datenkommunikation zwischen verschiedenen Teilnehmern, z. B. den verbundenen Geräten, über einen #Broker ermöglicht. Daher war es uns wichtig, dieses Protokoll in OpenEMS umzusetzen.

Gibt es Unterschiede zum MQTT-Protokoll von Fenecon, das bereits in OpenEMS implementiert ist? 

Consolinno: Wie man in einem Update von Stefan Feilmeier nachlesen kann, unterstützt OpenEMS das MQTT-Protokoll 5. Es hat feste #Topics und eine fest implementierte Art und Weise, wann und wie es seine Daten pushed. Er erwähnte ebenfalls:  

„Be aware that this implementation only marks the start of MQTT support in OpenEMS. Therefor implementation details might change with future versions.“ 

Das bedeutet, MQTT mit der Version 5 kann genutzt werden. Dies stellt einen Vorteil gegenüber der Consolinno-Implementierung dar, welche lediglich die Version 3.1.1 (OASIS-Dokumentation) bzw. mit leichten Änderungen auch Version 3.1 des MQTT unterstützt. Die Nutzer*innen können aber mit Hilfe unserer Implementierung aussuchen, welche Daten an welche #Topics geschickt werden sollen. Das geschieht für jede Komponente individuell – also für die konfigurierbaren Module in OpenEMS (z.B. eine PV-Anlage oder auch virtuelle Komponenten). Pro Komponente können theoretisch mehrere #Payloads und #Topics konfiguriert werden.

Was ist mit eurer Implementierung noch möglich? 

Consolinno: Zusätzlich können Daten #subscribed werden. So könnten virtuelle Komponenten wie Temperatursensoren Daten erhalten, mit denen ein reales Energiesystem arbeitet. Außerdem können Commands #subscribed werden (das sind einfache Befehle, auf die eine Komponente reagieren kann). Die konkreten Befehle und die Reaktion darauf müssen jeweils implementiert werden. Weiter können Fahrpläne, die von einer KI erstellt werden und nach einem bestimmten Schema aufgebaut sind, abonniert werden. Fahrplancontroller können diese richtig zusammensetzen und auf die OpenEMS-Komponenten verteilen. Dadurch schaffen wir eine intelligente KI-Steuerung von Energiesystemen, was zukünftig im Klimaquartier Esslingen oder bei MAGGIE in Regensburg eingesetzt wird.  

Mit unserer Implementierung können Komponenten nicht nur über die ApacheFelix Web-Oberfläche für MQTT konfiguriert werden, sondern auch über ein JSON file oder sogar über REST. Diese Konfiguration kann im Nachhinein abgeändert werden. Der Nutzer wird dabei unterstützt, indem ihm angezeigt wird, welche Daten er von einer Komponente #publishen kann. Er kann auch angeben, in welchem Intervall eine Nachricht #gepublished und #subscribed werden soll.

Könnt ihr das wichtigste nochmal zusammenfassen? 

Consolinno: Unsere Implementierung unterstützt eine andere MQTT-Version (3.1.1 und mit leichter Abänderung 3.1). Alle Komponenten sind individuell konfigurierbar und in unterschiedlichen Zeitabständen können mehrere #Payloads an mehrere/ unterschiedliche Topics bei unterschiedlicher #Quality of Services verschickt werden.

Die Komponenten können auf bestimmte Kommandos individuell reagieren. Es werden also Nachrichten abonniert und Fahrpläne entgegen genommen, welche eine KI-optimierte Steuerung, etwa von Energieerzeugern, ermöglicht.  

Als Verbesserungen stehen das Speichern einer geupdateten Konfiguration und die Unterstützung von MQTT v.5 an. Die Implementierung von Fenecon ermöglicht es, über MQTT v.5 alle Daten des OpenEMS an festgeschriebene #Topics zu erhalten, was den Konfigurationsaufwand minimiert. Doch wie bereits Stefan Feilmeier sagte, ist die Implementierung von Fenecon noch am Anfang.

Begriffserklärungen: 

#Broker:  
Die Cloud/der Server, der die ankommenden Daten von #Publishern entgegennimmt und verwaltet bzw. dafür zuständig ist, Abonnenten/ #Subscribern die Topics, die sie abonniert haben, zukommen zu lassen. Der Broker ist also die Brücke der Kommunikation zwischen #Publishern und #Subscribern: Er ist das „Gebäude“, in dem sich „Sprecher“ und „Zuhörer“ bewegen; die Sprecher (#Publisher) sagen ihren Inhalt (#Payload) in einem Raum (#Topic), die Zuhörer (#Subscriber) bewegen sich in dem Gebäude und suchen sich Räume (#Topics) aus, in denen sie zuhören möchten.

#Payload:  
Nachrichteninhalt. 

#Publish/#Subscribe:  
Nachrichten veröffentlichen (publish)/abonnieren (subscribe) bzw. erhalten. 

#QoS/#Quality of Service:  
Art und Weise, mit welcher Garantie eine Nachricht beim Broker ankommt. 

#Topic:  
Eine Art URI oder URL (quasi etwas wie https://openems.io/), die innerhalb von MQTT eine eindeutige Adresse darstellt. 

Europäische Förderung für CarBatteryReFactory, powered by OpenEMS

Deggendorf, 29. Juli 2021 – FENECON, ein führender Hersteller für Heim-, Gewerbe- und Industrie-Stromspeicherlösungen, erhält als eines von nur zwei deutschen Unternehmen eine Förderung aus dem EU Innovation Fund, der besonders klimafreundliche Projekte unterstützt. Die Gelder in Höhe von 4,5 Millionen Euro investiert das mittelständische Unternehmen in den Bau eines neuen Produktionsstandortes nach Automobilstandard im niederbayerischen Iggensbach bei Deggendorf, die „CarBatteryReFactory“. Ab 2023 werden dort aus Zero- und Second-Life-Elektroautobatterien – also Ersatzteilbatterien und solchen, die bereits in Fahrzeugen im Einsatz waren – Containerspeichersysteme gefertigt. Energieversorger, Ladeparkbetreiber und Industrieunternehmen nutzen solche Anlagen, um Strom zwischenzuspeichern und die Netzstabilität zu erhöhen. […]

Das dafür eingesetzte Energiemanagementsystem FEMS basiert auf OpenEMS, einer Open-Source-Plattform, die von Fenecon initiiert wurde und mittlerweile weltweit verwendet wird. Auf Basis des Industrial-Speichers entstehen im geplanten Werk günstige Großspeichersysteme sowie sogenannte lebende Ersatzteillager für Fahrzeugbatterien, die Stromnetze aktiv stabilisieren. Zudem können die Containerspeicher für einen zeitlich begrenzten Einsatz bei Veranstaltungen, Umweltkatastrophen, für Ladeparks oder in der Industrie gemietet werden. […]

Quelle:

Backlinks dazu:

  • Solarserver
  • Electromobiliste