Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

DS_Starter

Kurzer Hinweis zu der ForecastSolar-API.

Die Abrufe und das Kontingent pro Stunde beziehen sich auf die abrufende IP-Adresse.
Wenn man also mehrere Devices mit dieser API betreibt, stehlen die sich quasi gegenseitig das Kontingent.
Ich habe ein solches Szenario bei mir noch nicht getestet wie sich die Devices dann verhalten.
Vllt. habt ihr mal während meiner Abwesenheit Lust es mal auszuprobieren.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

kask

Ich habe beobachtet das schon mehrmals das Kontigent erschöpft war. Obwohl ich da, meines Wissens nach, nichts woanders abfrage.
Eine Auswirkung konnte ich aber nicht feststellen. Ich beobachte mal.

kask

#2642
Zitat von: DS_Starter am 03 Juni 2023, 07:54:45Guten Morgen,

im Setter moduleDirection kann man nun auch den Azimut Wert anstatt die Azimut Kennung angeben.

    Kennung    Azimut    
    N          -180    Nordausrichtung
    NE         -135    Nord-Ost Ausrichtung
    E          -90    Ostausrichtung
    SE         -45    Süd-Ost Ausrichtung
    S           0    Südausrichtung
    SW          45    Süd-West Ausrichtung
    W           90    Westausrichtung
    NW          135    Nord-West Ausrichtung


Azimut Werte sind Ganzzahlen im Bereich von -180 bis 180. Azimut Zwischenwerte, die nicht exakt auf eine Kennung passen, werden auf die nächstgelegene Kennung abstrahiert wenn die gewählte API nur mit Kennungen arbeitet. Das Modul verwendet den genaueren Azimut Wert sofern die API die Verwendung unterstützt, z.B. die ForecastSolar-API.

    Beispiel:
    set <name> moduleDirection Ostdach=-90 Südgarage=S S3=NW

Liegt im contrib zum Download.

"kann"? Nach dem Update gerade kommt jetzt folgendes?

2023.06.03 09:56:43 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - Request for string "Schuppen":
https://api.forecast.solar/estimate/watthours/period/xx.x3987/x.x6711/10/<unknown>/1.5
2023.06.03 09:56:54 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - ForecastSolar API server ERROR response: Invalid plane (10/<unknown>/1.5) Azimuth "<unknown>" format invalid, not in range -180 .. 180 (602)
2023.06.03 09:56:54 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - limit period: 3600
2023.06.03 09:56:54 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - limit: 12

Edit:
Mit den Zahlenwertes funktioniert es!
2023.06.03 10:03:38 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - Request for string "Schuppen":
https://api.forecast.solar/estimate/watthours/period/xx.x3987/x.x6711/10/0/1.5
2023.06.03 10:03:39 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - server response for PV string "Schuppen"
2023.06.03 10:03:39 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - request time: 2023-06-03 10:03:39 (1685779419)
2023.06.03 10:03:39 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - requests remaining: 2
2023.06.03 10:03:39 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - status: success (0)
2023.06.03 10:03:39 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - Request for string "Ost":
https://api.forecast.solar/estimate/watthours/period/xx.x3987/x.x6711/35/-90/5.85
2023.06.03 10:04:02 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - server response for PV string "Ost"
2023.06.03 10:04:02 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - request time: 2023-06-03 10:03:43 (1685779423)
2023.06.03 10:04:02 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - requests remaining: 1
2023.06.03 10:04:02 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - status: success (0)
2023.06.03 10:04:02 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - Request for string "West":
https://api.forecast.solar/estimate/watthours/period/xx.x3987/x.x6711/35/90/5.46
2023.06.03 10:04:07 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - server response for PV string "West"
2023.06.03 10:04:07 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - request time: 2023-06-03 10:04:07 (1685779447)
2023.06.03 10:04:07 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - requests remaining: 0
2023.06.03 10:04:07 1: ForecastSolarAPI DEBUG> ForecastSolar API Call - status: success (0)

Mein Haus ist auch ziemlich genau Ost/West.

DS_Starter

#2643
Du hättest vermutlich nur einfach restarten müssen nach dem Update.
Wenn du plantconfig check ausführst müssen in der Stringübersicht sowohl dir als auch azimut auftauchen.

String Configuration    erfüllt      Schleppdach => azimut: 0, dir: S, peak: 0.825, tilt: 30
                                                    Süddach => azimut: 0, dir: S, peak: 5.13, tilt: 45

Ein Neusetzen von moduleDirection bewirkt das gleiche wie ein restart -> Neubefüllen des Stringhash.

Kannst jetzt auch nochmal zu den Kennungen wechseln und zurück oder gemischt. Geht alles.

ZitatIch habe beobachtet das schon mehrmals das Kontigent erschöpft war. Obwohl ich da, meines Wissens nach, nichts woanders abfrage.
Eine Auswirkung konnte ich aber nicht feststellen. Ich beobachte mal.
Das Kontingent bezieht sich auf eine Stunde nach dem ersten Abruf, also nicht auf volle Stunden. Da wird hoch und runtergezählt. Sieht man im Debug. Ist nicht einfach zu durchschauen, aber sobald das Kontingent erschöpt ist nutzt das Modul die von der API empfohlene Wartezeit und alles beginnt wieder.
Gibt keine negativen Auswirkungen außer das der Zyklus der Daten mal etwas länger dauert.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

MarkusN

Zitat von: DS_Starter am 02 Juni 2023, 16:41:15@Markus,

Zitat von: MarkusN am 02 Juni 2023, 08:55:27Bedeutet das dass der Verbraucher auch dann geschaltet wird, wenn der prognostizierte Überschuss nicht für die benötigte Leistung ausreicht?

Ich hole mal ein bisschen aus ...
Wir unterscheiden die Consumer Planung und dessen Schaltung.

Mit dem mode=can/must wird festgelegt ob und wenn ja wie der Consumer eingeplant wird. Bei "can" wird geschaut ob die Prognose den gewichteten Verbrauch des Verbrauchers irgendwann übersteigt. Nur dann erfolgt eine optimierte Einplanung, sonst nicht. Bei "must" wird auf jeden Fall eingeplant, auch wenn der Bedarf die Prognose übersteigt. Aber auch hier wird das Maximum gesucht. Also der Consumer braucht 1000 Wh, es werden aber max. 500 Wh um 12 Uhr erzeugt, dann erfolgt die Einplanung in der Nähe dieses Maximums.

Die tatsächliche Schaltung des Consumers erfolgt ab dem Beginn der Einplanungszeit abhängig davon ob tatsächlich mehr erzeugt wird als benötigt, aber nur dann wenn der Schlüssel power auf den nominalen Verbrauch gesetzt ist.  Bei der Angabe "0" wird immer die Einschaltung zu Beginn der Einplanungszeit ausgeführt auch wenn kein Überschuß vorhanden ist.

Wenn du also power=<Nominalleistung> angibst, wird eine Einplanung auf jeden Fall (mode=must) vorgenommen, aber es wird nur dann eingschaltet wenn tatsächlich Überschuß >= Nominalleistung vorliegt. tatsächlich heißt, dass Erzeugung minus Hausverbrauch größer 0 ist.


Vielen Dank für die Erklärung! Das bedeutet aber, dass ein Verbraucher mit "must" und power=0 letzten Endes jeden Tag, also auch im Winter bei unzureichendem Ertrag geschaltet würde, korrekt? Genau dieses Verhalten möchte ich beim Heizstab unterbinden.

Würde sich ein Off-Grid-/Nulleinspeisungsmodus für das Modul realisieren lassen? Die Differenz zwischen tatsächlichem und prognostiziertem Ertrag würde dann als Überschuss gewertet, woran sich dann die Schaltung des Verbrauchers orientiert.

Grüße,
Markus

DS_Starter

#2645
ZitatDas bedeutet aber, dass ein Verbraucher mit "must" und power=0 letzten Endes jeden Tag, also auch im Winter bei unzureichendem Ertrag geschaltet würde, korrekt?
Ja genau. Deswegen wäre dann in deinem Szenario mode=can und die Angabe power=<nominal> richtig.

ZitatWürde sich ein Off-Grid-/Nulleinspeisungsmodus für das Modul realisieren lassen? Die Differenz zwischen tatsächlichem und prognostiziertem Ertrag würde dann als Überschuss gewertet, woran sich dann die Schaltung des Verbrauchers orientiert.
Ja. In deinem Fall musst du mit etwas Geschick dafür sorgen, dass dem Modul eine PV Erzeugung mitgeteilt wird obwohl es keine gibt.
Mit einem Dummy der dann mit den Readings als currentInverterDev angegeben wird, lässt sich so etwas erreichen.

Nur als Anregung ... nimm die aktuelle Erzeugung von deinem WR und addiere eine virtuelle Leistung hinzu die du aus der aktuellen Ladung deiner Batterie (Wh) geteilt durch deine Vorgabe wie lange die Batterie leisten soll (h) ableitest. Das Modul erkennt dann einen Überschuß auch wenn keine PV erzeugt wird und schaltet.
Den Parameter etotal aus dem WR musst du in den Dummy "spiegeln" weil man nur ein Device als Quelle angeben kann.
Der Phantasie sind wenig Grenzen gesetzt.  ;)

LG
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

MarkusN

Gute Idee, das werde ich mir mal anschauen. Ich habe noch eine Frage die in die Richtung dummy und readings spiegeln geht.
Bei mir ist mein Consumer device (das welches den Aktor schaltet) ein anderes als das welches den Stromverbrauch misst.
Was ist der beste Weg die Readings vom Stromverbrauch in das Aktor Device zu bekommen? Ich habe schon mit userreadings getestet, das scheint device-übergreifend jedoch nicht zu funktionieren. Irgendwelche Ideen?

DS_Starter

#2647
userReadings kannst du verwenden.
Im Zieldevice wo du das gespiegelte Reading anlegen möchtest als Beispiel:

attr userReadings etotal:<triggerreading>.* {ReadingsVal("<Quellendevice>","<Quellenreading>",0)},

Der Wert für das userReading etotal wird aus dem <Quellendevice>, <Quellenreading> geholt.
Gibt sicherlich noch mehr Möglichkeiten mit einem notify u.ä.

Edit: Klammer hat gefehlt.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

gvzdus

Hi, ich habe die Überlegungen zum Modul 2021 am Rande verfolgt, gestern mal mit Freunden über das Thema gesprochen (unabhängig von FHEM), und dann heute mal geguckt.

Ganz vorab: "Wow!". Ich will ja nicht das FHEM-Netz beschmutzen, aber es gibt echt wenige Module in FHEM, bei denen die Einbindung so flexibel und anwenderfreundlich wie bei Dir ist. Konkret habe ich einen Victron MP 2, 7 kWh Pylontech, 10 kWp mit SolarEdge-WR, und alles ging wirklich straight forward. Ursprünglich hatte ich den Thread bis Seite 40 gelesen, um alle Gedanken mitzubekommen - aber dann habe ich einfach aufgegeben und gemacht.

Jetzt erst mal meine Anmerkungen:
Ja, auch meine Überlegungen gingen in die Richtung, den Victron erst "später" und langsam zu laden. Führt zu Punkt 1.

1) Das Dokument von Victron (die URL im Wiki lässt sich übrigens nicht aufrufen, aktuell liegt es hier: https://www.victronenergy.com/upload/documents/Output-rating-operating-temperature-and-efficiency.pdf ) spricht vom Effizienzverlust beim Invertermodus bei hohen Leistungen, vom Charging lese ich (flüchtig!) da nichts. Klar ist trotzdem: Niedrige C-Rate ist gut für den Akku. Meine Überlegungen gehen eher in die Richtung, sich marktfreundlich zu verhalten. Entweder aus Idealismus, oder aber, falls doch mal variable Einspeisevergütung breit kommt. Außerdem ist die Zeit bei 100% SoC ja ein Faktor: Aktuell lade ich eh' nur auf 80%, wenn aber die Zeit wieder dunkler wird, dann möchte ich den Akku möglichst wenige Stunden auf 100% SoC haben.

2) Der Wiki und die "Benutzerführung" beim Device erlauben wirklich eine schnelle Ersteinrichtung. Was mir fehlt: Ich weiß schmerzlich, dass im Westen wegen Wald bei mir nichts zu holen ist. Mir fehlt ein Abschnitt "Anpassung an Deine Hütte" im Wiki. Hilfsweise wäre ich echt glücklich, wenn ich einen Link "Lies mal ab Seite 88 in diesem Thread" bekommen könnte. Mit diesen "lokalen" Gegebenheiten hatte ich mich schon ein bisschen beschäftigt. Will's jetzt nicht lange erklären, aber unter http://www.garnix.de/balkonhorizont.html sieht man, wie meine lokale Situation beim Balkonkraftwerk aussieht.

3) Gut fände ich auch eine Diskussion der Datenquellen. Ich habe jetzt DWD_OpenData eingerichtet, die Alternative SolCast liefert bei mir nur einen 401er (vielleicht schalten die erst manuell frei?).

Soweit mal mein Feedback, und ich spiele die Tage weiter!

DS_Starter

#2649
Hallo gvzdus,

vielen Dank für deine Einschätzung zum Modul. :D

Den Link zum Victron Dokument habe ich im Wiki gleich angepasst. Habe selbst auch eine Anlage mit MP II + Pylontech und bin immer noch beim Erweitern des ESS (Dreiphasen Anlage).
Bezüglich des Effizienzverlust und des Dokumentes hast du recht. Ich habe viel in Netz recherchiert und bin für mich zu der Überzeugung gekommen ein optimiertes Laden schonender und effizienter ist.
Aber das kann man natürlich diskutieren, ist bestimmt ein weitreichendes Feld.

Das Wiki allgemein ist noch im Aufbau. Leider finde ich zu wenig Zeit es so schnell aufzubauen wie ich es mir wünsche. Die Weiterentwicklung steht gerade im Vordergrund. Und dann noch das schöne Wetter  ;)

Mittlerweile gibt es eine weiter Alternative, ForecastSolar-API -> https://forecast.solar/
Die geht ohne Registrierung.

Inzwischen gibt es bereits weitere Entwicklungen, die ich aber erst nach meinem Urlaub veröffentlichen möchte da ich die nächste Zeit keinen oder nur beschränkt Support leisten kann.
Einstweilen wünsche ich dir und der Community viel Spaß mit dem Modul und dem Entdecken der Möglichkeiten ...

LG,
Heiko

Edit: anbei drei Vergleichsgrafiken der heutigen Ergebnisse von SolCast-API, ForecastSolar-API und DWD. Das DWD habe ich wegen Weiterntwicklungen erst vor kurzem eingerichtet.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Dracolein

Ja, ich lese nebenher hier weiterhin regelmäßig mit.
Kurz mal zwischengerufen:

Die prozentuale Abweichung Soll-Ist mit der SolCast-API ist bei mir derzeit gigantisch klein un dliegt etwa zwischen 2 - 10%(in Worten: zwei bis zehn Prozent!)
Unter Berücksichtigung meiner drei unterschiedlichen PV-Generatoren in alle möglichen Himmelsrichtungen usw. finde ich das spitze. Die Vorhersagen passen auch deutlich besser, als es die SMA-App prognostiziert.
Gekostet hat es mich lediglich viele Justagevorgänge (Trial & Error) innerhalb der SolCast-Oberfläche über die letzten Monate hinweg, bis ich alle 3 PV Generatoren ungefähr meinen realen Bedingungen angepasst hatte (Verschattung kann man dort ja nicht so wirklich konfigurieren, also immer mal wieder einloggen, am Offset spielen, abwarten usw.). Geil.

Der Urlaub sei Dir gegönnt.  8)
Obwohl... eigentich wollen wir mehr Features asap  ;D  ;D
Raspberry Pi 4 mit FHEM; FTUI Dashboard auf Asus 15,6" VT168H Touchscreen; ZigBee mit ConBee2 USB-Stick; div. Shelly 2.5; integr. Gaszähler mit ESP8266 & ESPEasy;

ch.eick

Moin,
abgesehen von PV-Tagen mit Strahlungsschwankungen und Wolken liegt meine KI Prognose auch in dem Bereich von 2-10% pro Stunde daneben und das ohne jegliche Justage :-) Gestern und heute sind einige Wolken durch gezogen, da lag die KI auch mal rund 20% daneben, wenn man jedoch mal berücksichtigt, was man damit steuert ist das alles noch nebensächlich.

Bei der Summe der Erträge pro Stunde liegt das ganze rund 5% daneben, wobei ich die 5% mehr an Ertrag habe, es somit konservativ ist.

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

gvzdus

Moin, im Moment ist Prognose ja (zumindest bei mir) Kinderkrams: Morgens Licht an, Nachts aus, dazwischen 60 kWh Ertrag :-). Spannend wird es, wenn es enger wird. Die DWD-Abweichung ist ja scheinbar vor allem in den Randzeiten.

Jetzt möchte ich aber noch einmal auf meinen PV-Horizont zurückkommen. Ich habe die Daten über Langzeit "auf Platte". Damit habe ich den höchsten, gemessenen PV-Ertrag (sei es auch nur 10 Sekunden) für jeden Stand der Sonne zurückgerechnet und kann damit ein Bild des "Horizonts" aus Sicht meiner PV-Anlage bauen. Das ist für mein Balkonkraftwerk hier:
http://www.garnix.de/balkonhorizont.html
und für die "Großanlage" hier:
http://www.garnix.de/pvhorizontmax.html

Man sieht deutlich:
- den Berg am Vormittag (das Dunkelblaue)
- die Bäume am Nachmittag mit zunehmender Höhe, sowie, dass ab 83° (schon vor Westen) nüscht mehr hinter den Bäumen durchkommt.
Diese Werte würde ich nun gerne einfließen lassen, z.B. "bei -10° Azimut bis 15° Elevation kein Direkt-Licht". Any chance?

Ich kann diesen Horizont übrigens gerne auch für andere mal rechnen, die mir Daten schicken.

ch.eick

Zitat von: gvzdus am 05 Juni 2023, 14:51:32Moin, im Moment ist Prognose ja (zumindest bei mir) Kinderkrams: Morgens Licht an, Nachts aus, dazwischen 60 kWh Ertrag :-). Spannend wird es, wenn es enger wird. Die DWD-Abweichung ist ja scheinbar vor allem in den Randzeiten.
Das hat bei mir im letzten Winter mit der KI auch besser gepasst als mit der selber gerechneten Solar-Forecast Funktion, weshalb ich ja umgestiegen bin.

Zitat< snip >
Man sieht deutlich:
- den Berg am Vormittag (das Dunkelblaue)
- die Bäume am Nachmittag mit zunehmender Höhe, sowie, dass ab 83° (schon vor Westen) nüscht mehr hinter den Bäumen durchkommt.
Diese Werte würde ich nun gerne einfließen lassen, z.B. "bei -10° Azimut bis 15° Elevation kein Direkt-Licht". Any chance?

Ich kann diesen Horizont übrigens gerne auch für andere mal rechnen, die mir Daten schicken.
Das wäre bei der KI alles hinfällig, da dort nur der tatsächliche Ertrag der Anlage oder auch eines Schwarms in Bezug auf die Wetterdaten einfließt. Somit sind technische Besonderheiten oder auch Schatten nicht mehr von belang. Die KI entscheidet aufgrund änlicher Bedingungen und lernt dazu, je mehr vergleiche in der Datenbank sind.

Das soll übrigens nur als Zusatzinformation dienen, dass man all diese Cloud Prognosen nicht unbedingt braucht. Der DWD bleibt natürlich als Quelle für die Wetterdaten.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

plin

Als ich mit der KI-Lösung angefangen habe hatte ich zunächst auf "linear regression" gesetzt. Dann kam der Hang hinter meinem Haus zum Einsatz und hat mir kurz vor Sonnenuntergang den schönen linearen Ansatz verhagelt. Mit dem jetzigen "random forrest" Ansatz kann ich gut leben. Insbesondere wenn keine Wolken spontan aufkreuzen sind die Forecasts ziemlich gut (siehe Anhang).
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB