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:
- Allgemeiner Inhalt und was euch erwartet
- Ablauf und Inhalt der Phasen
- Erklärungen welche Komponente/Paket für was zuständig ist
- 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
- Die erste Phase beinhaltet
- MqttBridge
- Leaflet
- LucidControl
- Timer
- Die Zweite Phase beinhaltet
- Heater API
- Heater Analogue
- Genibus
- HeatsystemComponents
- ExceptionalState
- Thermometer
- REST Bridge
- Utility
- Die Dritte Phase
- HydraulikController
- Multiheater
. Watchdog
- Die vierte Phase
- Dezentrale Heizer
- CommunicationMaster (GLT)
- TemperatureSurveillance Controller
- HeizkurvenController
- 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!
