Consolinnos Wärmesektor (und später Emob) kommt zu OpenEMS Step by Step

Hallo liebe Community,

Ich wollte euch mitteilen, dass wir von Consolinno dran sind,
unsere Entwicklungsarbeiten im Wärmesektor (und auch im späteren Verlauf Emobilität)
offiziell ins OpenEMS zu bringen.
Wir haben viel im Wärmesektor erarbeitet und entwickeln stetig weiter.
Das meiste, was fertig entwickelt ist,

Den Wärmesektor in einem großen Schritt zu erschlagen ist zu viel.
Daher haben wir vor, den Wärmesektor in Phasen aufzuteilen.

Diese Phasen bauen aufeinander auf, da Komponenten diverse Abhängigkeiten besitzen.

Daher möchte ich in diesem Post einen Überblick geben zu:

  1. Allgemeiner Inhalt und was euch erwartet
  2. Ablauf und Inhalt der Phasen
  3. Erklärungen welche Komponente/Paket für was zuständig ist
  4. Ausblick auf weitere Komponenten

Allgemeiner Inhalt und was euch erwartet

Wie Anfangs bereits erwähnt, spezialisiert sich Consolinno auf den Wärmesektor.
In der Entwicklung sind einige Komponenten, andere sind fertig, darüber hinaus begann Consolinno mit Entwicklungen im
E-Mobilitätssektor.
Hierbei ist es nicht nur wichtig Anlagen zu digitalisieren, sondern auch zu steuern und zu optimieren.
Dazu haben wir mehrere Komponenten entwickelt.
Den Kern der Steuerung bildet unser Leaflet.

Leaflet

Das Leaflet ist eine physische Schnittstelle zur Peripherie.
Das Grundmodul bildet hierbei die Basis, hier läuft bspw OpenEMS-Edge, aber auch unsere BaseSoftware,
was die Kommunikation mit modularen Erweiterungen des Grundmoduls ermöglicht.
Dieser Erweiterungen umfassen:

  • Relaismodule
  • Temperaturmodule
  • PWM-Module
  • Analogue InputOutput Module
    Darüber hinaus bietet das LeafletGrundmodul Schnittstellen zur Anbindung von RS485 bzw RS 232.
    Diese Module lassen sich über die BaseSoftware des Leaflets ansteuern.

Auf dieser Basis konnten wir Basis Komponenten entwickeln

Komponenten

Thermometer

Die Thermometer wurden erweitert.
Implementiert wurden:

  • Virtuelle Thermometer
  • Threshold Thermometer,
  • Thermometer Wrapper
  • Modbus Thermometer (Generisch)

Hydraulik Komponenten (Heatsystem Components)

Die Hydraulik Komponenten umfassen analoge Pumpen und analoge Ventile mit 1 oder 2 Outputs.

Wenn ich im folgenden von Heatsystem oder Hydraulik Komponenten spreche, das ist das gleiche.

Wärmeerzeuger

Eine Schnittstelle die von konkreten Komponenten erweitert werden kann,
hilft es Controllern eine standardisierte Ansteuerungen vorzunehmen.

Wärmeerzeuger können dezentralisiert sein, analog, oder auch konkret BHKWs,
Gaskessel, Hackgutkessel, Wärmepumpen.

  • Analog
  • Dezentral
  • Hackgut
  • Gaskessel
  • BHKWs
  • Wärmepumpen
    -(WIP) Elektrolyseur

Zähler

Verschiedene Wärmemengenzähler, Wasser wie auch Gaszähler die über (W)MBus kommunizieren

LucidControl

Von LucidControl Module die Analoge Signale verarbeiten (in und output)

Utility

  • Rechner fürs Channel und statische Werte Addieren und Multiplizieren
  • Interval auf Interval Mapper
  • “ConditionApplier” (WEnn etwas true/false ist mit && bzw || Verknüpfung tu X sonst Y)
  • MinMax für n Channel Input
  • Virtuelle Channel

Exceptional State

Definition einer Schnittstelle (Nature) für das nutzen von “Ausnahmezuständen”

Generische ModbusKomponente

Eine implementierung zur Benutzung von generischen Modbuskomponenten
→ Umgesetzt wurden bspw Generische Zähler, oder auch Thermometer und Virtuelle Channel

Somit kann man on The Fly Modbuskomponenten konfigurieren

Timer

Timer die Komponenten helfen um zu überprüfen ob “Zeiten” abgelaufen sind

Kommunikationsbrücken

MQTT Bridge

Die IoT Schnittstelle die es ermöglicht Individuelle Topics und Payloads für
OpenEMS Komponenten zu hinterlegen (nach Konfiguration der Brücke, geh in TelemetryComponent und mach publish und subscribe sachen)
subscribe → schreibe Daten aus der Payload einer Topic in einen Channel
publish → schreibe Daten aus einem Channel (n verschiedene Daten und Channel) in die Payload und schicke an Topic

QoS, Zeitintervall usw kann konfiguriert werden

Da unser Fahrplan mit dem RabbitMQ server mit Mqtt version 3.1.1 arbeitet ist hier ein extra Wrapper notwendig gewesen etc.

Der Fahrplanoptimierer (Optimizer) funktioniert nur mit unserer MqttBridge

Rest Bridge

Diese Bridge dient zur Kommunikation via REST zu anderen OpenEMS-Edge devices.
Channel können damit beschrieben oder ausgelesen werden.
RestRemoteDevices → Dort kommen die Lesenden bzw Schreibenden Werte hinein.
(Strings werden nicht unterstützt, nur Zahlen)

Genibus

GenibusBridge für die Kommunikation mit Grundfos Pumpen die nicht über ModbusTCP gehen

WMBus

WMBus → Erweiterung zu MBus

Controller

Multi Heater / Cooler

Ein Controller der ‘n’ input an Wärmeerzeugern bekommt die auf ‘n’ Aktivierungs- und n Deaktivierungs-Temperaturen sowie Thermometer gemapped wird.

Dieser Controller dient dazu Heater/Cooler ein/auszuschalten wenn Temperaturen über oder unterschritten werden.

Als Ein- und Ausschalt-Temperaturen können auch Channeladdressen verwendet werden.

GLT / Kommunikationszentrale

Diese dient Primär dazu RestRemoteDevices zu erhalten und als in bzw output zu nutzen
Sie erkennt ob bei dezentralen Heizsystemen verschiedene Arten der Anforderung (z.b. Wärme und mehr Wärme)
vorliegen und kann individuell reagieren (Konfigurationssache)

Heizkurvensteuerung (WIP)

Das Controlcenter nutzt die Summe aus Aufwärmprogramm und Heizkurve sowie dem “hören” auf “überschreiben”
und kann damit eine SollTemperatur ermitteln und einem PID Controller überreichen zusätzlich wird eine Pumpe eingeschaltet

Strang Heizer/Kühler

Ein Controller der nach Zeit, “EnableSignal” oder ‘dezentral gesteuert’ angehen kann.
Er sorgt dafür in Channel/Ventil/singleChannel zu schreiben und kann damit Komponenten öffnen/schließen
bzw bei Ventilen → kann Minimum und Maximum einstellen und somit “limitieren”

Surveillance (Fallback)

Der Controller hat eine ReferenzTemperatur, wenn diese über- bzw unterschritten wird von den Ein-/ausschalt-Temperatursensoren
dann kann ein Heater / HydraulikKomponente oder beides aktiviert werden.

Damit ist eine Fallback bzw. eine einfache Spitzenlastüberwachung möglich.

Watchdog

Ein Watchdog, der 2 Temperaturen überprüft. Wenn hier das DeltaT über bzw unterschritten wird,
dann wird ein “ExceptionalState” ausgerufen (nach einer bestimmten TestZeit)
Dieser Ausnahmezustand wird für eine konfigurierte Zeit gehalten.
Wichtig: Der Watchdog wird nur aktiv wenn eine Komponente mit einem Channel einen bestimmten Wert erreicht hat
bspw ein Heater mit EnableSignal true.

Hydraulik Komponenten Controller (HeatSystemComponentController)

Hier gibt es 2 Controller.

Einer der statische Positionen fährt wenn dieser aktiv ist, und einen PID Controller
der den PID Filter verwendet.
Hier wird eine HeatsystemComponent genutzt. Genauso auch ein Temperatursensor.
Statische Positionen (konfigurierbar) werden nach Temperatur gefahren.
Der PID Controller fährt die HeatsystemComponent nach der SollTemperatur und der IST Temperatur.

Optimierer

Der Optimizer erhält von unserer KI einen standardisierten Fahrplan und schreibt daraufhin in eine konfigurierte Komponente bzw in den konfigurierten Channel.

Emobilität

EVCS Limiter (WIP)

Der EVCS Limiter kann PV Überschussladen und priorisiertes Laden und somit Ladesäulen steuern.
(Support für die Ladesäulen die von Consolinno implementiert wurden)

EVCS (WIP)

Diverse Ladesäulen die implementiert wurden und in der Testphase sind.

Ablauf und Inhalt der Phasen

  1. Die erste Phase beinhaltet
- MqttBridge
- Leaflet
- LucidControl
- Timer
  1. Die Zweite Phase beinhaltet
- Heater API
- Heater Analogue
- Genibus
- HeatsystemComponents
- ExceptionalState
- Thermometer
- REST Bridge
- Utility
  1. Die Dritte Phase
- HydraulikController
- Multiheater
. Watchdog
  1. Die vierte Phase
- Dezentrale Heizer
- CommunicationMaster (GLT)
- TemperatureSurveillance Controller
- HeizkurvenController
  1. Fünfte Phase und unabhängige Komponenten
- Nach dem Merge von der Heater Nature können unabhängig von folgenden Phasen
  genaue Implementierungen von WP, BHKWs und Co anzufragen
- WMBus, MBus Zähler bzw WMBus Bridge
- Wenn getestet HeaterCluster
- Wenn getestet Emobilität

Erklärungen welche Komponente/Paket für was zuständig ist

Bei Bedarf, würde ich aus unserem internen Wiki bestimmte Komponenten im Detail erklären, da das hier allerdings den Rahmen aktuell sprengen würde, würde ich diesen Punkt vorerst weglassen.

In unserer GithubRepo
befinden sich alle Module. Jedoch sind diese noch auf der Version Java-8.
Nichts destotrotz, könntet ihr euch die Pakete zu nutze machen, wenn ihr möchtet.
Den feature branch werde ich auch regelmäßig updaten.

Ausblick auf weitere Komponenten

Es gibt in unserer Pipeline Komponenten die noch ein WIP sind bzw. implementiert werden müssen,
diese würden wir nachziehen und auch Ankündigen.

Bei Fragen stehen wir euch gerne zur Verfügung!

3 Likes

Hier das Leaflet mit den Modulen und Preisen.
Andere Hardware, die bereits in OpenEMS implementiert war, kann natürlich alternativ genutzt werden.

Leaflet Grundmodul 915€ (Mit H-Busschiene zum Verbinden unter den Modulen) - 890 € ohne H-Bus
Ausgeliefert vorkonfiguriert mit Software
Leaflet Temperature 248€
Leaflet Relay 164€
Leaflet PWM 167€
Leaflet AIO 356€

Datenblätter lade ich später noch hoch.

Etwas verzögert, aber hier die Datenblätter und Gebrauchsanleitungen

Leaflet Grundmodul Gebrauchsanleitung
Leaflet Grundmodul Datenblatt
Leaflet PWM Gebrauchsanleitung
Leaflet PWM Datenblatt
Leaflet Temperature Gebrauchsanleitung
Leaflet Temperature Datenblatt
Leaflet Relay Gebrauchsanleitung
Leaflet Relay Datenblatt
Leaflet Analaog Input/Output Gebrauchsanleitung
Leaflet Analaog Input/Output Datenblatt

1 Like