discussion of logic regarding feed-in (export) tariff pre-charging and further development

[christian1980nrw]

Lets discuss the charging conditions in case of feeding in / exporting to the grid. @ckvsoft @alex90alex If the prices and the total charging costs at night are lower than the export payout in the afternoon, we should pre-charge the battery (maybe up to 100%).

Also if we are charging we should not forget the lost profit caused of the charging. It should be part of our calculations or am i wrong?

So that we don't talk past each other, we should carry out the example calculations in a shared spreadsheet first. https://docs.google.com/spreadsheets/d/1Xkx3vjyCw-b7HOuuWABOCdY-kFDthEFuIPjaHk99Tdo/edit?usp=sharing

Regards Christian

[christian1980nrw]

@ckvsoft Meinst Du das reicht pauschal so wie im Excel oben aus oder sollten wir einen komplizierteren Ansatz wählen?

[ckvsoft]

@christian1980nrw Ja ob das alles so Einfach ist kann ich auf die schnelle gar nicht sagen. Der Economy Check wird in diese Richtung schon passen.Evtl. müsste man einige Dinge ändern und anpassen. Man müsste mal alles auf einen Nenner bringen wie cent/kw, alle Preise Netto oder Brutto, Einspeisevergütung ist ja nicht immer gleich denke ich mal, zumindest bei aWATTar nicht. Gibt es sonst noch variable kosten die berücksichtigt werden sollen usw.

Die Frage ist reicht es in der Praxis so wie es ist oder Zahlt es sich aus sich mehr anzunähern.

Wieviel die Sonne Heute liefert muss angepasst werden. Auch hier passt es oft zum Abfrage Zeitpunkt nicht mehr. Zb. bei einer Abfrage um 21 Uhr wird uns mitgeteilt des es Heute noch genug Sonne gibt und Morgen auch und ladet nicht. Sind die Wolken schon in die MJ eingerechnet oder nicht. Das alles ist offen. Wie viel MJ brauche ich überhaupt um den Akku auf den gewünschten Stand zu bringen, Der SOC müsste mit eingerechnet werden sowie MJ vom Akku.

Das sind alles noch Dinge die mir nicht klar sind. Das andere ist ob die Bash mit den vielen Rechenaufgaben nicht überfordert wird. Ich hab ja gesehen wie viel unterschied ein AWK machen kann. Dann noch die BASH auch hier gibt es Unterschiede. Am MacOS werden aus Lizenzgründen ältere Versionen der Bash installiert. Hier haben wir ja auch ein aktuelles problem das es beim macos kein declare -A gibt. Die standard shell beim mac ist seit macOS Catalina (Version 10.15) die zsh

Die Frage ist natürlich wie weit interessiert uns das. Stellen wir sicher das dieses Skript nur am VenusOS läuft? Doch da gibt es ja auch Unterschiede ob raspberry oder Victron-Geräte oder gar ein normaler PC.

lg Chris

[christian1980nrw]

Also die Einspeisevergütung ist hier im Deutschland meist gleichbleibend über den Netzbetreiber vergütet (nicht über den Stromanbieter wie Tibber oder aWATTar) und nach Baujahr der Anlage für 20 Jahre festgelegt (vgl. https://www.sfv.de/lokal/mails/sj/verguetu ). Direktvermarktungsanlagen mit dynamischen Vergütungen gibt es in der Regel nur im Großanlagenbereich. Aber diese Anlagen sehe ich für das Script nicht als Zielgruppe. Das Script sollte Betriebssystem unabhängig laufen, möglichst ohne zusätzliche Software. Vielleicht bekommen wir es gemeinsam mit @smoe hin, das z.B. auf einem Debian ohne Angabe eines Repositorys ein apt-get install Spotmarket-Switcher ausreicht.

Gruß! Christian

[smoe]

Hinsichtlich dynamischer Eispeisung möchte ich auf https://www.lumenaza.community/ verwiesen haben. Denke das kommt/ist schon da auch für kleinere Installationen. Werde dorthin wohl im Frühjahr wechseln - ist angeblich mit Tibber zu kombinieren.

Debian sehe ich erstmal nicht. Müsste dafür m.E. eher eine monolithische Anwendung sein/ein Service mit GUI/shell API, nicht so ein wiederholtes Anstarten via cron.

@ckvsoft hat offensichtlich ein paar wichtige Probleme identifiziert. Einmal angenommen wir wechseln zu Python - hinreichend ähnlich schwierig wie BASH für Neueinsteiger (die bislang nicht schlangestehen) - aber mit mehr Eleganz und Freiheiten bei der Programmierung. Aber hätte ich dafür gerade Valenzen übrig? Ne. Um festzustellen, was man eigentlich will, ist diese BASH-Lösung m.E. erstmal gar nicht so schlecht.

[christian1980nrw]

Wir sollten erstmal bei der Bash bleiben und soweit optimieren bis wir alle einigermaßen mit dem Ergebnis zufrieden sind. Ich sehe momentan keine allzu komplizierten Rechenaufgaben. Keep it simple, manchmal ist weniger mehr. Danach stünde dann die GUI auf der Agenda, und da Venus OS nativ NodeRed mitbringt, habe ich bereits eine mögliche Vorlage (die viel Entwicklungsarbeit spart) hier in Absprache mit dem Entwickler organisiert: https://github.com/christian1980nrw/Spotmarket-Switcher-GUI Wie wir das ganze dann verheiraten, müssen wir sehen, ist für mich auch Neuland.

Gruß! Christian

[ckvsoft]

Die Gui brauchen wir wozu? Für die Ausgaben? Das Script in ein Service zu wandeln sei ja nicht viel aufwand In etwa so

trap 'stopservice' SIGTERM

stopservice() {
    echo "Das Skript wird beendet und führt die Bereinigung durch..."
    # code hier
}

while true; do
    # Hauptcode hier
    echo "Skript läuft..."

    # Ermitteln der aktuellen Minute und Sekunde
    current_min=$(date +'%M')
    current_sec=$(date +'%S')

    # Berechne, wie lange das Skript bis zur vollen Stunde schlafen sollte
    sleep_sec=$(( (60 - current_min) * 60 - current_sec ))

    sleep $sleep_sec
done

[Unit]
Description=Spotmarket-Switcher Service
After=network.target

[Service]
Type=simple
ExecStart=/pfad/zu/controller.sh
Restart=on-failure
User=benutzername
Group=gruppenname

[Install]
WantedBy=multi-user.target

[christian1980nrw]

Naja, der Anwender sollte schon etwas Komfort bei der Preisübersicht, Monitoring und Konfiguration haben. Ist aber kein Muss, erstmal gibts noch andere Baustellen.

Gruß! Christian

[ckvsoft]

evtl. bei einen neuen Major release darüber nachdenken. Mir reicht einstweilen das Logfile. Die Konfig werde ich ja auch nicht täglich ändern Node-red würde für mich nicht in Betracht kommen. Verwende es auch jetzt nicht. Hab noch nicht den Vorteil entdecken können. ;-) Ist mir zu kompliziert

[smoe]

Eine Status-Information würde noch benötigt - gerne aus den Logs - aber irgendetwas, das die Sensoren anfragen könnte, wäre möglicherweise beliebt.

[smoe]

Victrons Infrastruktur wäre nur sekundär, richtig?

[christian1980nrw]

Victrons Infrastruktur wäre nur sekundär, richtig?

Ja, nachdem sie nur die Ideen des Spotmarket-Switchers übernommen und sich ansonsten für eine Eigenentwicklung in Kombi mit eigener Cloud entschieden haben, bleibt eine Unterstützung zwar, eine GUI kann aber auch unabhängig entwickelt werden. Ich würde Victron da nicht (mehr) zu sehr entgegenkommen wollen. NodeRed wäre da ein Kompromiss hatte ich gedacht, es kann aber auch was anderes werden.

[Rellikon83]

Die Idee mit Node Red find ich gut.

Das Problem an der controller.sh ist aktuell, dass man vor dem PC sitzen muss um zu checken was da gerade passiert. Über mobile devices oder remote ist da wenig machbar. Bei den Berechnungen steigt der Laie sowieso aus, bzw. will sich gar nicht damit beschäftigen. Im Grunde wollen die Endverbraucher, dass die Entscheidungen beim Script liegen. Grundsätzlich gibt es für die Leute zwei wesentliche Funktionen:

Verbrauchsoptimiert: Lade auf wenns billig ist und verbrauche wenn es teuer ist. -> Hier seid Ihr heute schon im teilweise nicht mehr leicht verständlichen Bereich bei den Prognosemodellen. Die sind aber notwendig wenn man das sinnvoll macht. NodeRed kann helfen die Komplexität abzubauen. Daher GUI ja bitte, aber erst wenn alles funktioniert.

FeedIn: Mach voll wenns billig ist, speise ein wenns teuer ist.

Btw. Super Job den Ihr macht. Ab 01.01. kann ich es hoffentlich auch testen.

[smoe]

So richtig funktioniert das bei Victrons VRM mit der Dynamik noch nicht - jedenfalls nicht bei mir. Das kann aber auch daran liegen, dass ich aktuell für meinen grid-parallelen Betrieb noch keinen Zähler bei Victron integriert habe. Kommt :)

Hinsichtlich Prognostic etc würde ich für dieses Projekt weitestgehend entspannt sein - was zu planen ist, wird man via der Tibber app bereits planen. Dort müsste man nur den Füllstand des aktuellen Stromspeichers noch mit anzeigen können.

[christian1980nrw]

@Rellikon83 Dieses Projekt konzentriert sich aktuell ausschließlich auf kostengünstigen Bezug von Strom. Einspeisung aus dem Akku ins Netz ist aufgrund der Rahmenbedingungen in Deutschland mit EEG Anlagen nicht erlaubt. Sogar der Bezug aus dem Netz in den Akku ist ein Graubereich. Insbesondere bei Einspeisung könnte man ja sonst Strom aus unterschiedlichen Quellen z.B. Kohle miteinander vermischen so die Argumentation der Lobbypolitiker. Vielleicht ändert sich das irgendwann mal, aber so lange die Rahmenbedingungen hierzu weiter schlecht bleiben, wird diese Software auch nicht in die Richtung entwickelt.

[Rellikon83]

@christian1980nrw unstrittig. Das gilt wie du schreibst für EEG Anlagen. Vermutlich der Großteil, daher ist das auch nicht der Fokus. Der Rest geht ja auch manuell.

Ich hatte heute das neue Update gezogen. Gut finde ich die Trennung zwischen Config und Controller.

Gibt es ein Topic (hier oder Social Media) über die Funktionen die man so nutzt? Bspw. WP usw. Kommen sicherlich einige Ideen zusammen Dinge in die Nacht zu legen.

[christian1980nrw]

@ckvsoft @smoe Ich bin aktuell nicht ganz zufrieden. Unser Ansatz is ja der, das wir zu günstigen Zeiten laden und dabei mit den durchschnittlichen Preisen vergleichen und bei zu hohen Ladeverlusten abbrechen. Ich nutze dazu die Gesamtpreise aus der Tibber-API. Leider reichen die Preisschwankungen meist nicht aus und es wird abgebrochen. Das hat im Herbst noch gut geklappt bei viel Wind im Netz parallel zur Sonne, momentan aber nicht mehr und es profitiert nur noch die Wärmpepumpe ohne Ladeverluste bzw. Abbrüche von den günstigen Preisen.

Es muss also ein anderer Ansatz her. Ich baue das Script bei mir gerade so um das zwar nach wie vor bei günstigen Preisen geladen wird, allerdings soll die Entladung nur noch bei höchsten Preisen erfolgen. Außerhalb dieser Zeiten wird das ESS abgeschaltet und aus dem Netz bezogen. Ich erhoffe mir davon eine deutlich höhere Rentabilität als bei der aktuellen Berechnung.

[christian1980nrw]

@ckvsoft @smoe

Ich habe mal eine experimentelle Version mit einer neuen Preismatrix bei mir im DEV hochgeladen. Es gibt in der Controller.sh noch einiges an Optimierungsbedarf was eigentlich in Schleifen müsste, aber es geht ja erstmal um die obige Idee.

Folgendes ist außer Codeoptimierung noch to do:

• Eine zweite Preismatrix die die Next-Day Preise berücksichtigt sofern verfügbar (next day funktioniert damit also momentan nicht).
• Der Economic Check müsste so angepasst werden das für die Entscheidung ein Durchschnitt aus den aktivierten ESS-Preisen gebildet wird.
• Auf dem Mac scheint das so nicht zu laufen laut Action Script. Ich hab leider keinen.

declare -A config_matrix24=(
    ["Price"]="Charge Discharge Switch"
    [1]="1 0 1"
    [2]="1 0 1"
    [3]="0 0 0"
    [4]="0 0 0"
    [5]="0 0 0"
    [6]="0 0 0"
    [7]="0 0 0"
    [8]="0 0 0"
    [9]="0 0 0"
    [10]="0 0 0"
    [11]="0 0 0"
    [12]="0 0 0"
    [13]="0 0 0"
    [14]="0 0 0"
    [15]="0 0 0"
    [16]="0 0 0"
    [17]="0 0 0"
    [18]="0 0 0"
    [19]="0 0 0"
    [20]="0 1 0"
    [21]="0 1 0"
    [22]="0 1 0"
    [23]="0 1 0"
    [24]="0 1 0"
)

[ckvsoft]

Ja am mac gibt es declare -A nicht. Zumindest nicht in der alten Bash Version vom Mac. Der ist ja vor einiger Zeit auf die ZSH umgestiegen.

Gibt es kein python am Cerbo GX? Ich hab ja mal nichts weitergemacht weil ich mir nicht sicher bin das ich das weiter mit der bash machen möchte.

[christian1980nrw]

@ckvsoft ...doch, der Cerbo kann Python3, aber naja, selbst wenn die Bash-Programmierung schmerzhaft ist, finde ich das es sich lohnt das darauf zu lassen. Es wird dadurch sichergestellt, das das auch auf ganz einfachen Endgeräten wie Routern läuft. Und so kompliziert ist das Projekt ja jetzt auch nicht, irgendwann sind wir mit dem Code zufrieden und dann wird da nicht mehr viel geändert.

[ckvsoft]

Es müssen ja jetzt schon Klimmzüge gemacht werden um auf zwei unterschiedlichen Systemen zu laufen. Das Debuggen ist ebenfalls schwierig. Ich sehe keine Notwendigkeit das dieses Skript auf einen Router laufen sollte. Wie man in der Vergangenheit gesehen hat funktioniert es ja nicht auf einer Standard Ubuntu installation. Da gibt es so viele Abhängigkeiten von den verwendeten Tools wie awk und co. Ich habe Stunden unnötig versucht Fehler zu beheben bis ich drauf gekommen bin das der awk von Ubuntu Schuld war. Ich kann zur Zeit aber auch nicht sagen was ich machen möchte, Wie Du schon festgestellt hast ist die derzeitige Version nicht das richtige für die jetzige Jahreszeit.

[christian1980nrw]

@ckvsoft Wenn Du Lust hast, teste doch mal die Version aus meinem DEV. Die neue Methode läuft bei mir seit heute damit problemlos. Ach, ich habe gesehen das Du in Deinem Fork noch nicht gemergte Änderungen hast, vielleicht kannst Du noch einen Pull Request machen auf mein DEV, falls die sinnvoll waren.

[ckvsoft]

Man müsste auch den SOC berücksichtigen. Das Problem ist das zur Zeit die Preise ja relativ hoch sind, mein Akku entleert wird und ich dann zu teuren Preisen Strom beziehe weil der Akku leer ist. Ein Statischer startpreis hilft hier auch nicht, Ich schau mir mal das Skript an was neu ist.

[christian1980nrw]

Ja, deshalb werden jetzt auch die Entladezeiten gesteuert. Die Entladung erfolgt gezielt bei höchsten Preisen ansonsten wird ESS deaktiviert.

[christian1980nrw]

Das ist die Ausbeute des heutigen Tages mit der neuen Methode. Preisspitzen erfolgreich vermieden. Morgen wird es wahrscheinlich nicht klappen, da die Preise den ganzen Tag fast gleich sind. Ich mache den Economy Check momentan mit dem höchstem Tagespreis.

Ladevorgang 3 & 4 Uhr, die anderen Balken sind Netzbezug.

Entladung in den 5 teuersten Stunden, am Ende war der Akku leer, ich werde wohl nächstes Mal auf 85% laden anstatt 75%.

[ckvsoft]

@ckvsoft @smoe

declare -A config_matrix24=(
    ["Price"]="Charge Discharge Switch"
    [1]="1 0 1"
    [2]="1 0 1"
    [3]="0 0 0"
    [4]="0 0 0"
    [5]="0 0 0"
    [6]="0 0 0"
    [7]="0 0 0"
    [8]="0 0 0"
    [9]="0 0 0"
    [10]="0 0 0"
    [11]="0 0 0"
    [12]="0 0 0"
    [13]="0 0 0"
    [14]="0 0 0"
    [15]="0 0 0"
    [16]="0 0 0"
    [17]="0 0 0"
    [18]="0 0 0"
    [19]="0 0 0"
    [20]="0 1 0"
    [21]="0 1 0"
    [22]="0 1 0"
    [23]="0 1 0"
    [24]="0 1 0"
)

Was ist bei dieser matrix was? 1 = Enabled?

[christian1980nrw]

Ja genau. Abhängig von den Preisen 1-24 (niedrigster bis teuerster). Einmal für Ladevorgang, Entladevorgang (ESS) und Steckdosen.

[ckvsoft]

Ok Ich hab das etwas geändert damit es auch am MAC funktioniert. Ist in meinen dev drinnen. Kannst es ja mal anschauen

[ckvsoft]

Wobei es ja nix mit den mac zu tun hat, ältere bash versionen können das nicht

[christian1980nrw]

Ich schaue morgen mal, liege gerade mit Grippe im Bett.

[ckvsoft]

Ok Bei mir funktionert das nicht. Akku ist auf 11% und entladet obwohl die ausgabe sagt es ist disabled.

Wie sehe ich ob das ess aus ist?

dbus -y com.victronenergy.settings /Settings/CGwacs/MaxDischargePower SetValue -- 0

ändert nihts an der anzeige

[christian1980nrw]

Du siehst es an ESS Status 7.

Außerdem kannst Du im ESS Menü nachsehen, ob das Limit auf 0W gesetzt (und aktiviert) wurde.

Ich bin noch mit Firmware v3.0~32 unterwegs. Liegt es vielleicht daran?

[ckvsoft]

Ok, alles klar. Dachte ich sehe das irgendwie anders ;-) Hab Version 3.12. Mein Akku war auf 10%, da schwankte es immer zwischen laden/entladen. Wär mir sonst nicht aufgefallen.

Wir sollten aber darüber nachdenken ob die Matrix nicht irgendwie dynamisch sein soll. In Verbindung mit den SOC. Im Winter wenn auch die Wärmepumpe am start ist sind manchmal die biligsten x Preise die statisch eingestellt sind zu wenig um den Akku voll zu laden.

[christian1980nrw]

Vielleicht greift bei Dir die Erhaltungsladung zu früh. Müsste man sich im Detail ansehen was auf Deinem Multiplus programmiert ist.

Also in Verbindung mit dem SoC sehe ich das nicht vernünftig auswertbar. Wenn die Ladeverluste es zulassen, wird bei mir aktuell stur auf 85% aufgeladen mit den drei günstigsten Stunden. Man könnte aber eine monatsweise Dynamik oder eine abhängig vom Solarwetter einbauen.

[ckvsoft]

Ja mit 3 Stunden komm ich nicht weit ;-)

[christian1980nrw]

Vielleicht macht die Idee das dynamisch auf den SOC zu beziehen doch Sinn. Momentan hab ich nur 15% im Akku und die möchte ich dann natürlich nur zum teuersten Preis entladen. Ich baue das mal um in den nächsten Tagen.

[ckvsoft]

Ja so ein Algorythmus wär nicht schlecht. Anhand des SOC die Anzahl von Stunden die benötigt werden um den Akku zu laden. Pro Stunde schaffe ich n% Ladung. Um den Akku auf x% zu laden werdeny Stunden benötigt. Das kann man ja dann auch lernen lassen.

[ckvsoft]

Kann dann ja manchma sein das ich die 7 niedrigsten Preise brauch und manchmal nur 3

[christian1980nrw]

Ich würde es eher als separat konfigurierbare Spalte in der Matrix einbauen... Dann kannst Du pro Preis was einstellen. Ich schaue mal.

[christian1980nrw]

@ckvsoft Ich hab das mal umgesetzt und habe die sample.config und die controller.sh in meinem DEV aktualisiert. Eigentlich war es ganz einfach. Siehe https://github.com/christian1980nrw/Spotmarket-Switcher/commit/691d5d79387222fe9e9c475f9ff855e152274570

Wenn der SOC jetzt nicht hoch genug ist, wird das ESS gemäß Matrix deaktiviert. Ob die Vorgabewerte sinnvoll sind, muss ich erstmal ein paar Tage testen wenn wieder etwas Sonne da ist.

Ich bin mir nur gerade nicht sicher ob der SOC immer eine Integer Ganzzahl ist oder ob da auch mal 12.5 ausgegeben wird, habe ich nie drauf geachtet. Ansonsten müssen wir da nochmal ran und z.B. mit awk vergleichen. Meinst Du das müssen wir noch ändern?

[christian1980nrw]

@ckvsoft Ich habe Deine exit manage sockets Abfrage wieder entfernt. Meinen Steckdosen ist es egal wenn sie jede Stunde abschalten, aber leider machen Sie Ärger wenn sie nur einmal ein- und nie wieder ausgeschaltet werden. Siehe https://github.com/christian1980nrw/Spotmarket-Switcher/commit/99c634c9f035813082e5bf21147e0ec4b425a05a

[ckvsoft]

Und warum? Hab das nicht aktiv. Hab dann natürlich Fehler

[christian1980nrw]

Das Script schaltet erst beim nächsten Durchlauf wieder ab. Oder wenn zwei günstigste Stunden aufeinander folgen wird halt zweimal hintereinander eingeschaltet. Das ist so gewollt, da der Steckdosenstatus nirgends gespeichert ist. Ursprünglich hatte ich mal eine fast einstündige Pause im Script bis wieder abgeschaltet wurde, aber das hatte dann kurze Aussetzer zwischen zwei Laufzeiten zur Folge, also nicht so toll für Wärmepumpen. Die Alternative wäre den Status von der Steckdose auszulesen und abhängig davon eine Aktion auszuführen, das war mir aber zu kompliziert, da schalte ich lieber mehrfach ein oder mehrfach aus.

[ckvsoft]

Dann sollte die abfrage vielleicht umgebaut werden. Wenn ich keine Steckdosen hab dann sollen die auch nicht versucht werden zu schalten

[christian1980nrw]

Anso in der aktuellen Version im DEV kommt dann W: skip Fritz DECT. not activated W: skip Shelly Api. not activated

wenn man use_fritz_dect_sockets=0 und use_shelly_wlan_sockets=0 setzt.

Ggf. könnte man auf die Fehlermeldung verzichten, sie wird nervig sein für Nutzer die das nie planen zu nutzen.

[christian1980nrw]

Hoffentlich scheint bald mal etwas die Sonne oder kommt eine größere Preisschwankung, bin gespannt ob die neue ESS-Preisdynamik wie erwartet funktioniert.

[ckvsoft]

Ja egal. Zur Zeit hab ich andere Probleme mit laden und entladen. Das passt mir noch gar nicht. Ich warte auf mein Akkuupdate und weiter Multiplus II. Vielleicht wirds dann besser. Der Akku ist immer zum falschen Zeitpunkt leer bzw unter 20% Heute gabs zb. 0kw von der PV und vom Netz wurde zu wenig lange geladen.

[christian1980nrw]

Was hast Du denn für einen Akku? Ich habe damals meine Parameter aus Vorgabeempfehlungen vom Meintechblog konfiguriert. Die passen soweit. Kommt er mal unter 10%, setzt direkt die Erhaltungsladung ein, auch bei langsamer Selbstentladung wird nach der ersten BMS-Warnung direkt wieder auf 10% aufgeladen. Moment, ich suche mal den Link raus wo die Werte standen.

[ckvsoft]

Hat ja mit BMS jetzt nichts zu tun. Nur 17Kwh sind halt nicht gleich aufgeladen. Darum wollte ich ja das laden dynamisch eingestellt haben. Ich werde mir das überlegen wenn ich wieder Zeit dazu habe wie ich das lösen könnte

[christian1980nrw]

https://meintechblog.de/2022/12/13/operation-hausspeicher-lifepo4-zellen-und-die-richtigen-spannungseinstellungen/

Em Ende des Posts ist eine Tabelle.

[christian1980nrw]

Hat ja mit BMS jetzt nichts zu tun. Nur 17Kwh sind halt nicht gleich aufgeladen. Darum wollte ich ja das laden dynamisch eingestellt haben. Ich werde mir das überlegen wenn ich wieder Zeit dazu habe wie ich das lösen könnte

Ach so, naja, da kannst Du dann von den günstigen Preisen möglichst viele aktivieren. Von welchem Parameter willst Du die Dynamik denn abhängig machen bzw. ableiten? Vom Solarwetter oder vom jeweils gültigem Monat? Das könnte man genauso wie es jetzt in meinem DEV beim ESS umgesetzt ist mit der Matrix tun.