Fragen zu Änderungen in OpenEMS: CoreCycleTime + Natures

Deutsches Forum Software-Entwicklung
1

Hallo liebe Community, wir von Consolinno arbeiten derzeit stark daran unsere Module bzw Implementierungen für verschiedene Pullrequests vorzubereiten. Wir erweitern das OpenEMS insofern, dass auch der Wärmesektor (teilweise) abgedeckt werden kann.
Darunter fallen Ventile, Wärmepumpen, Bhkws, Wasser und Wärmemengenzähler, unsere eigene Hardware etc.

Controller werden ebenfalls noch in Pullrequests verwandelt, doch die werden “hinten angestellt” (sobald die “Basic” Komponenten akzeptiert wurden)

Um bestmögliche Ergebnisse zu liefern, möchte ich noch ein paar Fragen stellen.

Die Zeiten für Scheduler sind nun seit geraumer Zeit entfallen, stattdessen kann man eine CoreCycleTime einstellen.

Ventile die beispielsweise für nur 200-500ms bestromt werden sollen (Feinjustierung) würden hierdurch profitieren, allerdings würden andere Komponenten bei einer globalen CycleTime leiden (viele Modbusanfragen/Controller die in kurzer Zeit agieren etc etc ).
Beispielsweise Temperaturwerte, die man ggf nur 1x pro Sekunde oder 1x alle 5 Sekunden benötigt, würden hierdurch viel öfter als nötig abgefragt werden. Gleiches gilt für Controller die zu unterschiedlichen Zeiten bzw. in einem unterschiedlichen Abstand agieren sollen.
Meine Frage lautet daher, ist es möglich entweder unterschiedliche CoreCylceTimes anzugeben oder Controller/Komponenten/Bridges verschiedene Zeiten zuzuweisen?
Oder muss dies in der Komponente selbst geschrieben werden? Wenn ja, gibt es dafür ein gutes bestehendes Beispiel?

Eine weitere Frage die aufkam, betrifft die Natures.

Uns ist aufgefallen, dass Natures nun konkrete Klassen bei Channeln zurückliefern (IntegerReadChannel als bsp) und nicht mehr das Interface (Channel<Integer) gibt es hierfür einen bestimmten Grund? Müssen wir unsere Natures anpassen, sodass diese ebenfalls bspw. IntegerReadChannel zurückliefern? Oder wird ein Channel weiterhin akzeptiert?

Vielen Dank für die Hilfe. Wir schauen, dass wir auch ende dieser Woche / Anfang der nächsten Woche die ersten Pullrequests starten können, sodass ihr uns hier Feedback geben könnt :slight_smile:

LG
Stoecki

1 Like
2

Hallo Stoecki,

wie du weißt bin ich sehr gespannt auf eure Entwicklungen. Danke für die Initiative!

Ja, das war in diesem Pull-Request

Ich muss sagen, dass wir die Umstellung nicht bereut haben, weil sie einige Vorteile hat:

Trotzdem sind deine Argumente gut und gerade bei Wärme kann ich mir gut vorstellen, dass da häufig langsamere Zyklen sinnvoll sind.

In Controllern machen wir das tatsächlich dann so, dass wir die Verzögerung - z. B. seltener Werte schreiben - dann in der Logik z. B. des Gerätes machen. Siehe Implementierung der KEBA Wallbox: https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evcs.keba.kecontact/src/io/openems/edge/evcs/keba/kecontact/WriteHandler.java#L128

Interessant ist aber der Punkt, Daten seltener auszulesen. Das müsste man in dieser Variante auch wieder Geräte-/Protokollspezifisch unabhängig vom Cycle machen (z. B. auch wieder bei KEBA wenn das asynchrone UDP-Paket kommt). Bei einer Bridge (z. B. ModbusBridge) könnte man die verlängerte Cycle-Time vermutlich am besten dort hinterlegen.

Meinst du z. B. solche Methoden in der Nature? (https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.meter.api/src/io/openems/edge/meter/api/SymmetricMeter.java#L337:L344)

public default IntegerReadChannel getActivePowerChannel();
public default Value<Integer> getActivePower()

Das haben wir eingeführt, weil es die eigentliche Anwendungslogik etwas leichter macht. Man muss nicht mehr this.channel(SymmetricMeter.Channel.ACTIVE_POWER).setNextValue(...) schreiben, sondern einfach this._setActivePower(...).

An sowas werden eure Pull-Requests aber sicherlich nicht scheitern, bzw. ich arbeite solche Themen dann auch gerne noch selbst etwas nach.

Wie schon öfters gesagt starte ich immer gerne mit einem kleinen Pull-Request, dann bekommt man ein Gespür dafür und hat nicht gleich einen Berg mit 10.000 Zeilen zu reviewen. Ich bin gespannt, was kommt!

Gruß,
Stefan

3

Hey Stefan,

Vielen Dank für deine ausführliche Antwort.
Deine Infos bezgl der CoreCycleTime werden uns deutlich weiterhelfen, insbesondere das konkrete Beispiel.

Zu den Natures:
Vielen Dank, sehr gut, das ist gut zu wissen.

Wir schauen dass wir mit etwas kleinem beginnen und ich versuche auch so gut es geht viele kleine bis mittelgroße Pullrequests zu machen.

Meine Mqttimplementierung zu Zeiten der Bachelorarbeit hat sich auch (minimal) weiterentwickelt, ist aber natürlich etwas umfangreicher, daher werde ich meine alte Pullrequest zu Mqtt schließen und eine neue aufmachen.
Ich kann, wenn du möchtest, dazu auch nochmal meine Inhalte in dem Forum darstellen.

Abgesehen davon planen wir u.a. folgende Pullrequests:

  • Unsere eigene Hardware → Kommunikation zw OpenEMS u. Module via Modbus

  • Erzeuger (BHKWs) wie von kwenergy und wolf sowie dachs

  • Erzeuger(BHKWs/Gaskessel) von viessman

  • Erzeuger(Hackgutkessel) von Gilles

  • Heizzähler via MBus

  • Wasserzähler die via MBus und WMBus kommunizieren (Erweiterung der MBus Bridge mit WMBus)

  • Eine REST Bridge um Remote mit anderen OpenEMS Systemen zu kommunizieren (Remote: Channelabfrage und interner nutzen davon) → Wird verwendet um bspw. Zentrale Wärmeanlage mit Dezentralen Informationen zu versorgen

  • Support von Analog I/O Modulen von LucidControl , 0-10V lesend/schreibend

  • Einfache Heizsystemkomponenten (Ventile/Mischer/Pumpen)

  • weiter Pullrequests kommen noch

  • wenn die meisten Pullrequests durch sind folgen Controller (Heizsystemsteuerung)

Aber das wird noch etwas dauern. Wir bemühen uns aber, das so zügig wie möglich durchzuziehen :slight_smile:

4

Hallo Stoecki,

eine Frage am Rande: Wir definieren mit einigen Kunden gerade Referenzanlagen, welche dann möglicherweise mehrfach ausgerollt werden. Eure Hardware bietet im Endkunden-Segment einige Vorteile und wir würden diese gerne als eine Basis für unsere oEMS-Box verwenden. Kannst du schon abschätzen, bis wann ihr die Pull Requests für eure Hardware fertig haben werdet? In den nächsten paar Wochen hätten wir ein, zwei Gelegenheiten um die Hardware mit ins Spiel zu bringen…

Viele Grüße,
Christian

5

Hallo Christian,

einer von uns zieht noch die Schönheitsfehler gerade, und dann würden wir heute/spätestens morgen die Pullrequest starten.
Leider ist eines unserer Module noch nicht getestet und somit noch nicht in der pullrequest drin. Das AnalogInputOutputmodul. Das muss noch produziert werden bzw ein Teststack intern bereitgestellt werden. Die Pullrequest dazu würde separat in (naher) Zukunft erfolgen.
Ansonsten Temperatursensoren, Relais und Pwm können genutzt werden.

Viele Grüße

Stoecki/Felix
:slight_smile:

6

Hallo Felix,
das ist hervorragend! Eure Hardware liegt hier schon ein paar Tage präsent auf meinem Arbeitsplatz und schaut mich traurig an. Die werde ich in den nächsten Tagen gleich im Testrack installieren und in unsere Tests einbeziehen. Ich freue mich und bin schon sehr gespannt.
Viele Grüße und euch Allen vielen lieben Dank,
Christian

2 Likes