OpenEMS
Feature/evcs limiter
Hallo OpenEMS Team,
Wie im Forum angekündigt:
Kommen nun die ersten Emob Pullrequests, bestehend aus einer generischen EVCS, der Easee Ladesäule und dem EVCS Limiter.
Diese basieren auf dem TIMER der bereits als PR erstellt wurden
Verantwortlicher hier ist: @TimStoecker
Hier die Beschreibung des Limiters: This controller will oversee the Power of configured Evcs. Unlike the existing implementation, this will not need a battery. It will limit the power based on a Power limitation and a limitation on the individual Phases. The limits can be configured static or based on connected power meters. That will also mean that it is possible to configure the Evcs Limiter to only use production energy from the system if the power limit is at 1W. It will calculate a „Resource Package“ based on the PowerLimit – Meter Value. This also means that the Evcs Limiter can be configured to take other devices on the power grid into account. So if a Power Limit of 30kW is configured and there are already other devices on the grid that consume 20kW of power, the Limiter will only allow the Evcs to consume 10kW.
In addition to that, the Limiter will also handle priority Evcs. Evcs that are configured to be priority, will not be reduced ore turned off unless there is no other possibility to stay under the limits (unbalanced loads are the only exception to this). The Evcs Limiter has a Priority Current configuration, that will determine how much current a Priority Evcs should have at a minimum, but if there is not enough power in the system to give that to all Priority Evcs, it will instead distribute the Priority current to all priority Evcs evenly. As already stated, the EvcsLimiter can also be configured to check for an unbalanced load.
The EvscLimiter is designed to only need the ChargePower, PhaseCount and status of an evcs. Everything else will be handled by the Limiter, so the implementation of the Evcs can be as slim and „logic less“ as possible. The Limiter has so far been successfully tested with: Schneider, Mennekes, Keba, Easee and Abl Evcs.
LG Felix
Hey @sebastianasen
Kurzes update und entschuldige die späte Rückmeldung,
Intern wird viel vom EVCSLimiter noch angepasst und überarbeitet, deine Kommentare wurden auch so aufgenommen. Jetzt ist @TimStoecker krankheitsbedingt ausgefallen, aber ich schau dass ich die nächsten Tage mehr Infos bekomme :)
Hey @sebastianasen
ich kam leider noch nicht dazu alles zu bearbeiten, da der EvcsLimiter momentan noch ein paar Bugs hat die behoben werden müssen. Ich habe allerdings schon viele deiner Vorschläge eingebaut und würde entsprechend noch ein paar Erklärungen geben.
Bezüglich „Default Werte in der Evcs Nature“: Ich würde es auch bevorzugen wenn die Werte einheitlich gespeichert wären, allerdings haben die meisten Ladesäulen (zumindest in meiner Erfahrung) andere Minimal- und Maximalwerte wodurch die meisten Werte dadurch nicht benutzt werden könnten
Bezüglich getMiddleLoad: Ja du liegst hier richtig, das die Werte Min, Middle und Max für die Prognostizierten Stromstärken verwendet werden und sie deshalb so häufig aufgerufen werden. Aus dem Grund werden beim Aufruf auch die Globalen Variablen überschrieben. Der Hintergrund davon ist, dass einmal die Stromstärken der einzelnen Phasen berechnet werden sollen und dann damit solange gerechnet werden kann bis einer der Stromstärken bearbeitet wurden. Die Verwendung dieser Werte hat sich aber im Laufe der Entwicklung aber stark gehäuft, darum sieht es momentan entsprechend unübersichtlich aus.
Bezüglich Config Properties: Hier ist nochmal das selbe Problem. Im Laufe der Entwicklung kamen langsam immer mehr Config Werte dazu und ich hatte es bis jetzt versäumt die ganzen Werte durch eine gespeicherte Config zu ersetzen. Das habe ich jetzt aber behoben.
Bezüglich der Wiederholung der Logik (Zeile 267-270): Wir sind mehrfach auf das Problem gestoßen das die Reihenfolge in der OpenEms Komponenten aktiviert dafür sorgt das der EvcsLimiter vor einem Meter aktiviert wurde, dadurch der EvcsLimiter Exceptions Warf und sich nicht aktivierte. Um das Problem zu umgehen, ist der EvcsLimiter in der Lage ohne Meter zu starten und seine Logik solange auszusetzen bis die Meter vorhanden sind.
Bezüglich preLimiterRoutine und Exceptions: Die preLimiterRoutine ist oftmals in der Entwicklung zum Problem geworden (vorallem reallocateFreeResources()) und dadurch ist der try-catch Block notwendig geworden, da sonst debugging unmöglich wurde. Darum ist der Block tatsächlich dafür da um unerwartete Excpetions abzufangen. Sobald alle Bugs gefunden und behoben wurden könnte der dann entfernt werden.
Bezüglich emergencyStop: Der emergencyStop ist so verwendet, dass wenn er ausgelöst wird, alle Evcs ausgeschaltet werden. Der EvcsLimiter läuft dannach weiter und sollte dann in ein von 2 mögliche Szenarien übergehen:
-
Das Problem ist behoben und die neuen Chargewerte die dannach ermittelt werden sind dann normal gültig. Im Laufe der nächsten Cycles wird er sich dann von alleine fangen
-
Das Problem ist immernoch vorhanden. Dann werden auch alle folgenden methoden zum EmergencyStop übergreifen und im nächsten Cycle wird nochmal von Vorne angefangen. Wenn das Problem dann immernoch vorhanden ist dann wird sich das solange wiederholen bis das Problem behoben wurde. Es ist dann ab hier davon auszugehen, dass es ein externes Problem ist.
Bezüglich des herunterregeln von dreiphasigen Autos mit Priorität: Ein dreiphasiges Auto mit Priorität wird nur vor den ein und zweiphasigen heruntergeregelt, wenn es keine nicht-Priorität Autos mit dreiphasen gibt. Sollte es mindestens eins geben, dann wird dieses heruntergeregelt.
Das Testen ist Momentan leider immernoch etwas schwierig und es sind uns wie gesagt noch ein Paar Probleme aufgefallen die erst behoben werden müssen. Darum ist in der reallocateFreeRessources() methode auch nun der Block ausgeklammert welcher unter anderem das verschieben der Logik um ein Paar Cycles ermöglicht.
