Nachdem ich zwei Kapitel des geplanten Tutorials inklusive Screenshots fertiggestellt hatte, habe ich festgestellt, dass der bisher verwendete Endpunkt /gesamtlast_simple, auf dem das zweite Kapitel aufgesetzt hat, als "Deprecated" markiert ist. Nun gut, dann ändere ich das mal eben, ... dachte ich.
Leider scheint sich aber das Verhalten ebenfalls geändert zu haben und passt jetzt nicht mehr so einfach zum /optimize Endpunkt. Der Endpunkt /gesamtlast_simple lieferte für einen Jahresverbrauch in Wh für den Zeitraum "0:00 Uhr heute" bis "23:00 Uhr morgen" 48 Werte als Array, was ganz praktisch war, da der /optimize Endpunkt genau dieses im Knoten gesamtlast erwartet hatte.
Der neue Endpunkt liefert nun auch 48 Werte in Form eines Arrays, allerdings ab dem Zeitpunkt des Aufrufs und setzt eine Konfiguration in Form von kWh voraus. Möchte man das alte Verhalten nachbilden, muss man nun zunächst einen String im Format DateTime für den Startzeitpunkt "0:00 Uhr heute" und einen String im Format DateTime für den Endzeitpunkt "23:00 Uhr morgen" erzeugen und diese dann an /v1/prediction/list?key=load_mean übergeben, was das Ganze (zumindest in Node-RED) ein Stück aufwändiger macht. Lässt man den Endzeitpunkt weg, bekommt man sogar 48+x Werte, wobei x die Anzahl der Stunden des heutigen Tages bei Aufruf des Endpunktes ist, dessen Zweck zumindest ich irgendwie noch nicht einordnen kann, wenn doch die prediction_hours standardmäßig auf 48 Stunden stehen.
Dazu meine Fragen:
Stimmt meine Vermutung, dass das auch für die anderen Prognosen gilt?
Bevor ich das jetzt versuche umzusetzen: ist geplant, auch die Logik des /optimize Endpunkts anzupassen oder kann man sich in nächster Zeit auf die derzeitige Logik verlassen?
Und gerade fällt mir noch ein weiterer Punkt auf: in der Konfiguration kann man die Optimierung in einem definierten Intervall laufen lassen (ems_interval). Wohin (data_folder_path/data_output_subpath?) und mit welchem Namen (?) und in welchem Format (JSON?) wird das Optimierungsergebnis geschrieben?
Die "/v1"-Schnittstelle ist gerade in der Entwicklung
Die Schnittstellen ohne v1 (z.B. /optimize) sind eingefroren und sollen auf absehbare Zeit auch weiter so wie jetzt funktionieren. "Deprecated" steht da, weil keine Weiterentwicklung mehr erfolgen wird. Wir versuchen die Schnittstelle stabil zu halten, weil Andreas und Jörg nur diese Schnittstelle nutzen und sie auch in den Videos beschreiben.
Bei der "/v1"-Schnittstelle ist der Default-Startzeitpunkt der Abfrage (start datetime) das aktuelle Datum und die aktuelle Uhrzeit, evtl. gerundet auf das gewünschte Datenintervall (default eine Stunde). Falls der Endezeitpunkt nicht definiert ist, werden soviele Werte wie gerade vorhanden sind geliefert. Ansonsten kann man Start, Ende, Interval bei der Abfrage definieren.
Das aktuelle EOS im main branch kann bereits zyklisch einen "energy management run" ausführen. Der beinhaltet aber momentan nur das Update der Vorhersagen. Eine Optimierung wird nicht gestartet. Sieht man so auch im logging. Die Weiterentwicklung im PR#595 startet auch die Optimierung. Das Ergebnis der Optimierung kann dann mit den neuen Endpunkten zum Energiemanagement "/v1/energy-management/xxx" abgefragt werden. Es ist geplant sowohl das bestehende Format (wie bei "/optimize") als auch ein neues kommandoorientiertes Format ala. Datum+Uhrzeit+Kommando (z.B. Stelle Batterie auf Laden) zur Verfügung zu stellen.
Die automatische Optimierung erfordert, dass Alles was bis jetzt im Aufruf an "/optimize" übergeben wurde, durch die Konfiguration, Messwerte und Vorhersagen definiert ist. Es sind also Änderungen hier zu erwarten. Im PR#596 hat sich die Konfiguration weiterentwickelt und es gibt eine Vorhersage für fixe Einspeisetarife und eine Möglichkeit dynamische Einspeisetarife zu importieren. Die Messwertschnittstelle ist zu unflexible für das Ziel der automatischen Optimierung. Hier wird es im PR#596 noch Änderungen geben.
Danke Dir für die zeitnahe Erläuterung . Das Entwicklungsvorgehen weicht etwas von dem ab, wie ich es normalerweise kenne, erklärt dann aber einige aktuelle Gegebenheiten.
Das hatte ich auch im letzten Video von Jörg gehört und bei ihm nachgefragt, wie er mit der neuen API umgeht, aber leider bisher keine Antwort erhalten. Wenn die Beiden aber auch aktuell weiteren Content darauf aufbauen, entwickle ich das Tutorial ebenfalls auf dieser Basis und mache wie ursprünglich geplant weiter und ich erstelle später eine neue Version für die /v1-API, wenn sie reifer ist.
Ich hätte wie gesagt erwartet, dass die Anzahl der gelieferten Werte der Konfiguration von prediction_hours entspricht, zumindest im Maximum. Und es würde der Abwärtskompatibilität sehr zuträglich sein.
Damit ist dann wahrscheinlich der Hinweis "crippled version" im Log-Eintrag gemeint.
Top! Auf das kommandoorientierte Format bin ich sehr gespannt. Das wäre eine echte Hilfe, da die aktuelle Struktur unübersichtlich und schwer zu interpretieren ist (hatte ich glaube ich mal kommentiert und Vorschläge gemacht).
Je nach Entwicklung des Themas Netzentgelte wäre der dynamische Einspeisetarif natürlich interessant.
Es gab auch mal die Frage, ob ihr EOS auch an die neuen Strompreisintervalle von 15 Minuten anpasst, die ja nun kurzfristig verschoben wurden, aber zum 30.09. kommen werden. Macht ihr da was im Zuge der aktuellen Weiterentwicklung? Sonst würde EOS ab dem 01.10. nur noch suboptimale Ergebnisse liefern, wenn sich die Preise innerhalb der Stunde stärker ändern.
. Das Entwicklungsvorgehen weicht etwas von dem ab, wie ich es normalerweise kenne, erklärt dann aber einige aktuelle Gegebenheiten.