Einbindung PV-Prognose und Tuning (solcast "Rooftop" API)

[hominidae]

Lieber Kevin,
liebe Gemeinde,

hier (m)ein Vorschlag für ein neues Feature...

Einleitung/Hintergrund:
Als neu gebackener Erstbesitzer einer PV möchte ich natürlich wissen, wie gut diese performt, aber auch besser wissen, wann es sich lohnt den eigenen Strom zu verbrauchen (oder für andere, Batterie-Besitzer interessant, wie die Be-/Entladungs-Strategie aussieht oder optimiert werden kann).
Man könnte das natürlich ausserhalb der openWb irgendwie selbst nachbauen, ich fände aber die Integration mit den Informationen an einem Platz durchaus angemessen und für den user simpler.
Daher mein Vorschlag dies in der openWB als Feature aufzunehmen.

Das Feature im Allgemeinen:

Ich sehe drei Implementierungs-Teile, die man auch nacheinander "abarbeiten" kann.

• Teil a): Integration / Darstellung einer PV-Erzeugungsprognose in das Logging (Graphen und Werte/Summenzähler für Leistung (W) und Energie (kWh)) der openWB.
• Teil b): Die openWB sollte, auf Basis der Tageswerte aus der PV-Erzeugung auch die realen, gemessenen Werte dem Prognose-Anbieter zur Verfügung stellen, wodurch lokale Eigenschaften (Azimuth, Multi-Dach Setup, Alterung, Verschmutzung) besser in die weiteren Prognosen einfliessen können.
  Hierzu sind die Tageswerte als Zeitreihe/Segmente mit entsprechendem Intervall (zB Durchschnitt PV-Watt in 30min) in der openWB "vorzuhalten" und regelmässig an den Anbieter zu übermitteln.
• Teil c): Die Möglichkeit eine Prognose zu integrieren, sollte allgemein in der openWB in den Graphen angezeigt/gespeichert werden und über mqtt zugänglich (externe Integration über publish-Methode, auslesen über subscribe) sein.

Der konkrete Vorschlag:

Integration der Rooftop PV-Prognose- und Tuning-API von Solcast (https://solcast.com/rooftop-solar/) für die Teile (a) und (b) des Features.
Jeder openWB User mit einer "kleinen PV unter 1MW" (Australien hat mehr Sonne, mehr Platz, 1MW ist da offenbar nix ) kann sich bei solcast für einen kostenlosen Rooftop Account registrieren und dort seine PV-Parameter eingeben.
Das Ergebnis im Web sieht dann zB so aus:



Über den RoofTop-Account verfügt der User auch über einen direkten API-Zugang bei Solcast (https://solcast.com/solar-data-api/api-toolkit/).
Die API erschient mir gut dokumentiert und es gibt auch schon eine Python Implementierung für die Nutzung: https://forums.solcast.com.au/t/new-python-library/209

• Zum Teil a):
  In der openWB muss der User seinen Account mit der Rooftop-ID und dem API-Token konfigurieren.
  Der solcast Rooftop Account erlaubt einem Home-, non-commercial-User die Abfrage der API allerdings "nur" 20x am Tag.
  Hinweis: Bei Registrierung erhält man erstmal 1000 Abfragen für 3 Monate "frei", bevor das 20/Tag-Limit greift.
  Bei 30min Auflösung in den Daten sollte das reichen, zwischen Sonnen -auf und -untergang ausreichend Daten für einen PV-Prognose-Graphen mit untertägigen Updates zu bekommen; die openWB sollte hier vereinfacht, zB zwischen 06:00Uhr und 21:00Uhr max. 20 Abfragen in äquidistanten Abständen durchführen.
  
  Die openWB zeigt die PV-Daten aus der API (Live + Prognose) in den Graphen (PV Prognose W) an und berechnet eine Energie-Prognose für den Tag (kWh) und zeigt diese ebenfalls im Tages- und Monatsgraph (+Jahresgraph, wenn implementiert) an.
  
  Wie das symbolhaft aussehen könnte/würde, sieht man natürlich an einem Beispiel, hier vom einem User aus dem solcast Forum (ein beispiel für die Integration in openHAB):
  
  
• Zum Teil b):
  Hinweis: Sollte in den Einstellungen der openWB zum Thema PV-Prognose als optional ein/ausschalbar durch den User sein.
  Wenn der user es aktiviert, dann sollte folgendes passieren:
  Die openWB bildet aus den eigenen, realen Werten der PV-Erzeugung über den Tag eine Zeitreihe mit 30min Abständen, und ermittelt darin jeweils die durchschnittliche Leistung.
  Mindestens einmal am Tag werden die (bisher nicht gesendeten) Zeitreihe an den Rooftop-Account zum Zwecke des PV-Tuning bei solcast, über die APi übermittelt (https://docs.solcast.com.au/?_ga=2.1228 ... oftop-site).
• Zum Teil c):
  Die Implementierung von (a) und (b) sollten grundsätzlich in mqtt Schnittstellen der openWB integriert/verfügbar gemacht werden.
  Der Anbieter solcast ist natuerlich nicht der einzige Anbieter solcher Prognosen.
  Daher wäre die Möglichkeit einer externen Anbindung über mqtt für eine andere API / Interface / Account einer weiteren/alternativen Prognose möglich.
  Zudem steht dem User für Zwecke der Integration in sein Smart Home (evtl. auch PV/Batterie-Management) diese Schnittstelle zur Verfügung.

Fazit:
Ich hoffe ich habe alles grundlegend genug recherchiert und verständlich dargestellt.
...würde mich freuen, wenn das Dein/euer Gehör findet. ich wäre bestimmt bei einem Money-Pool dabei .
Für Anregungen und offene Meinungen bin ich natürlich jederzeit zu haben.

TIA,
hominidae

[openWB]

Die Idee selbst finde ich gut. Vom Aufwand her kannst du damit aber einen Vollzeitentwickler beschäftigen.
Als Ergebnis könnte die openWB dann Prognosebasiert den Tag planen und das Auto entsprechend der gängigen Gegebenheiten am sinnvollsten laden.

[hominidae]

...danke für Deinen Input.
ja, aber eine KI muss es ja nicht gleich werden.
Teil A, die Visualisierung und Summenwerte reichen ja damit Brain.exe das von vor der Tastatur manuell einplanen kann.
Teil B, weil ein Rooftop-Account nur einen Azimut und eine Location/site haben kann...ich zB habe ein West+Ost-Dach, das man über die feedback-Schleife nachjustieren kann.

Ich denke, extern, zB mit Node-Red (kenne die Internas der openWB und Python nicht) oder Telegraf/Influx/Grafana würde ich das in einem Tag hinbekommen. Aber extern wäre nicht so schön.
Hier hat es übrigens jemand mit iobroker und Javascript für eine Speicherladung-Optimierung gebaut: https://www.photovoltaikforum.com/threa ... ost1987334

[aiole]

@hominidae
Das klingt alles schön, nur ist das trotzdem viel Arbeit.

Bedenke bitte, dass Kevin und Mitentwickler auch ganz andere Dinge im Blick haben müssen als PV-Tuning. Gerade solche Spezialfeatures können das Gesamtkonstrukt gefährden, wenn es nicht richtig getestet ist. Du siehst doch, was bereits die vielen PV-/Speicherkombinationen für einen hohen Aufwand bedeuten. Erst das führt zu einer guten Funktion. Wenn aber bereits ein externer OEM ändert, muss oWB nachziehen.

Was dagegen sicher hilfreich wäre ist, wenn Du den code selbst vorbereitet, so dass nur noch Anpassarbeiten nötig sind.
Jeder der Entwickler hat hier sein Spezialgebiet. Du bist dann "Mr. PV-Prognose". Wenn Du Dich mit Node-Red auskennst und Dir das feature sehr wichtig ist, dann baue diese Lösung dort erstmal lauffähig vor. Danach kannst Du sie mit Unterstützung der SW-Gurus hier in oWB implementieren.

VG aiole

[Thomas aus W]

Teil B, weil ein Rooftop-Account nur einen Azimut und eine Location/site haben kann...ich zB habe ein West+Ost-Dach, das man über die feedback-Schleife nachjustieren kann.

was spricht gegen mehrere Accounts, für jede Dachseite eins?

bye
TW

[hominidae]

...die Lizenzbedingungen

[hominidae]

@aiole
Ja, ich weiss dass das viel Arbeit ist, ein externe Alternative ist deswegen auch einfacher.
Das habe ich auch nicht in Abrede gestellt oder das Gegenteil behauptet.
Ebenso, bewusst die Idee als Feature...es müsste also nicht kostenlos (umsonst ist es eh nicht) sein.

Was dagegen sicher hilfreich wäre ist, wenn Du den code selbst vorbereitet, so dass nur noch Anpassarbeiten nötig sind.
Jeder der Entwickler hat hier sein Spezialgebiet. Du bist dann "Mr. PV-Prognose". Wenn Du Dich mit Node-Red auskennst und Dir das feature sehr wichtig ist, dann baue diese Lösung dort erstmal lauffähig vor. Danach kannst Du sie mit Unterstützung der SW-Gurus hier in oWB implementieren.

Ich kann den code im Sinne des Feature nicht sinnvoll selbst vorbereiten, da ich die interna von obenWB nicht kenne und, trotz Zugriff auf Github nicht verstehe.
Das ist einfach nicht meine Welt und meine Architektur-Denke.
Daher meine Anmerkung über eine externe Alternative. Die kann ich tatsächlich herstellen, aber niemand kann dann diesen code (via node-red gebaut gibt es da gar keinen, im eigentlichen Sinne) übernehmen und in openWB integrieren, so wie Du es so einfach darstellst.
Das wäre eher keine Hilfe.

Aber ich nehme Deine Challenge gerne auf.
Wie wäre es, wenn man Teil A und Teil C kombiniert und zwar so:

Die Visualisierung (erstmal nur Tagesgraph) erfolgt durch Jemanden in openWB, mit dem richtigen KnoffHoff dort.
Was also in openWB benötigt wird, ist ein generischer WerteGraf (erstmal nur im Tagesgraf)...Name/Bezeichnung und Einheit kommen auch über mqtt.
Das ist ein generisches Feature und das kann dann jeder mit mqtt Knoff Hoff für alle möglichen Informationen / Visualisierungen in openWB nutzen.

Für das PV-Prognose-Feature mache ich dann die Bereitstellung der Daten (PV-Prognose in W und Tagesprognose in kWh) über mqtt.
Dafür bauche ich gerne als Demo was mit Node-Red, damit andere es so nutzen können.
Ich mache also die Datenbereitstellung von der solcast-API in den mqtt-Broker der openWB....mit node-red (topics in der openWB sind abzustimmen oder ich mache einen Vorschlag, zB openWB/visualization/generic/1/data|name|unit und openWB/set/visualization/generic/1/data|name|unit).
Als ersten/weiteren Test/Demo auf Seiten der openWB kann man ja den realen PV-Erzeugungswert auslesen, mit einer Zufalls-Bandbreite verändern und wieder in den generischen, mqtt basierten Graphen zurückspielen

Teil B mache ich selbst in Node-Red, wenn es niemand anders machen will...die zugrundliegenden Daten wären ja aber in openWB drin.
Der neue generische Graph wäre, in meinem einfachen Verständnis, so etwas wie ein (einfacherer, abgespeckter) clone vom PV-Ertrag, der ja schon über mqtt mit Werten beliefert werden kann (WR Modul ist mqtt), oder?

Edit: Also zumindest Graph-technisch reicht mir ein zweites PV-Modul mit MQTT als WR, oder?

[aiole]

Ich denke, dass die Priorität für PV-Prognose-features eher gering ist. Auch im PV-Forum gibt es m.E. keine oder nur wenige user, die es als "must have" einstufen. Vermutlich sind die Nutzeffekte nicht groß genug.

Meine Wenigkeit kann Dir mit Prozessoren und Mosfets dienen. Bei SW sieht es eher düster aus. Aber vielleicht findet sich hier jemand, der es mit Dir forciert. Good luck!

VG aiole

[LutzB]

Für mich stellt sich schon etwas länger die Frage, was openWB bieten will und was nicht. Wird es zu einem kompletten Energiemanagement ausgebaut? Zu einem Smart Home System? Ich denke nicht, dass das zielführend ist. Der Bereich sollte anderen Systemen wie open HAB, FHEM etc. überlassen werden. Durch die MQTT Schnittstelle kann openWB dort wunderbar eingebunden werden. Warum also ein weiteres Mal das Rad neu erfinden?

OpenWB macht das, wofür es konzipiert wurde hervorragend. Nämlich das gezielte Laden von EVs in Verbindung mit PV und Speicher, um den Eigenverbrauch zu maximieren.

Meiner Meinung nach sollten neue Features vorerst nicht implementiert, sondern die gewachsene Struktur der Software bereinigt werden. Die einzelnen Module sollten auch wirklich als solche mit entsprechenden Schnittstellen überarbeitet werden. Vielleicht lassen sich die verschiedenen Regelalgorithmen ebenfalls modularisieren. Das würde die Übersichtlichkeit erhöhen und vor allem den Wartungsaufwand erheblich reduzieren.

Entschuldigt bitte, dass ich hier so OT schreibe, aber das passt meiner Meinung ganz gut hier hin. Falls es nicht gewünscht ist, mache ich gerne einen eigenen Thread auf.

[openWB]

@LutzB

Ich bin da bei dir. Die aktuellen Umbaumaßnahmen bekommst du ja auch mit. Das zieht sich nun Stück für Stück durch