76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

Begonnen von DS_Starter, 11 Februar 2024, 14:11:00

Vorheriges Thema - Nächstes Thema

300P

Das ist zwar keine PV-Beratung hier ;D ... aber ...

Nimm maximal deinen durchschnittlichen Tagesverbrauch, aber mindestens das was du im Sommer nach Sonnenuntergang bis Sonnenaufgang verbrauchst. (Kannst du den Statistikwerten des Modules entnehmen) ;)

Deine PV-Anlage sollte ebenfalls dann dazu passende technische Leistungen haben

Am Ende bestimmt dann aber auch noch das verfügbare Geld für den Speicher die Größe und die ,,Technik" der Batterie. (1 oder 3 Phasen, Erweiterungsmöglichkeiten und ob Notstrom / Ersatzstrom etc. usw. ...)

Viel Spass bei der Auswahl - aber dieses Modul kann dir deine  Entscheidung dafür leider nicht abnehmen.

Hol dir evtl. dafür vielleicht einen Ratschlag im https://www.photovoltaikforum.com/ - da gibt es sicherlich einen Bereich für Empfehlungen und Hilfe bei der Auswahlt der notwendigen Gerätschaften.


Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

kask

Und da kommen schon die 3 Meinungen in 2 Antworten.

Ich denke das Modul kann dir schon helfen bei der Auswahl. Alle benötigten Parameter sind enthalten um das auszzuloten.

Kalkuliere 110% von dem Verbrauch im Frühling/Herbst Verbrauch von Sonnenuntergang-Sonnenaufgang. 110% weil du nur 90% des Speichers nutzen kannst/hast.
Im Winter...vergess den winter! Und im Sommer hast du PV überfluß.

Dazu haust du noch eine Alterungspauschale 20%. Somit bekommst du in 20Jahren noch deine jetzt benötigte Energie raus.
Ob du in 20 Jahren die jetzige Ernergie noch brauchst oder der Speicher das überhaupt schaft, weiß jetzt keiner.
Und die Staffelung der größen ist ja auch nicht so genau bestimmbar.

Der Speicher maximal so groß das du den überhaupt mindestens 150x im Jahr voll bekommst.

Und mit einem Speicher wird es schwer das der sich amortisiert. Kann klappen, meist aber nicht.

Kann man sich aber unglaublich schön rechnen ;)
Jede kWh aus dem Speicher ist meist teurer wie gekaufter Strom.

Um 1kWh zu entnehmen muss man 1,1 - 1,25kWh rein pumpen. Das Kostet je nach Anlagengröße schon einmal 1.1-1.25 x 8,2 cent.
Weil die bekommst du nicht mehr vom Netzbetreiber.
Also deine Batterie-kWh klaut dir ca. 9-10.25 cent.
Die gekauft kWh kostet dich viel mehr, ist schon klar. Aber rechne mal wie lange es dauert das so ein Speicher sich abbezahlt hat.

Ein Speicher ist Hobby! Ein Hobby was nix kostet, ist kein Hobby!
Man kann sich alles zurecht legen, das es einem paßt.






Bison

Hallo Kask,

danke für die Anregungen ich werde die in meine Berechnung/Simulation einfließen lassen. Am besten finde ich das mit dem Hobby, Fhem ist mein Hobby und wenn ich denke wieviel Zeit ich hier schon verbraten habe...

Im Moment simuliere ich eine 10  kWh Batterie mit BatDummy. Nach den ersten Tagen sieht man schon Frühling mit schlechten Tagen zieht den schon leer.

Gruß Bison
Raspberry, Homematic, CUL, 50 Device, 260 Entities

DS_Starter

#228
Nabend zusammen,

in meinem contrib liegt die V 1.17.0 zum Test bereit.
Ich habe die OpenMeteoDWD-API integriert:

ZitatOpenMeteoDWD-API
Open-Meteo ist eine Open-Source-Wetter-API und bietet kostenlosen Zugang für nicht-kommerzielle Zwecke. Es ist kein API-Schlüssel erforderlich. Open-Meteo nutzt eine leistungsstarke Kombination aus globalen (11 km) und mesoskaligen (1 km) Wettermodellen von angesehenen nationalen Wetterdiensten. Diese API bietet Zugang zu den renommierten ICON-Wettermodellen des Deutschen Wetterdienstes (DWD), die 15-minütige Daten für kurzfristige Vorhersagen in Mitteleuropa und globale Vorhersagen mit einer Auflösung von 11 km liefern. Das ICON-Modell ist eine bevorzugte Wahl für allgemeine Wettervorhersage-APIs, wenn keine anderen hochauflösenden Wettermodelle verfügbar sind. Auf der Webseite des Dienstes ist die umfangreiche und übersichtliche API Dokumentation verfügbar.

FHEM nicht vergessen nach dem Download zu restarten.
Die API ist wie gewohnt auszuwählen. Ihr kennt das Setup ja schon ...

Die API bietet m.M.nach noch einiges an Potential. Zur Zeit habe ich die Strahlungsprognose implementiert.
Über die API beziehe ich auch schon die relevanten Wetterdaten (get ... solApiData zeigt es), sie sind aber noch nicht operational. Im nächsten Schritt könnte diese API auch das DWD Device bezüglich dieser Daten ersetzen. Weiterhin kann man auch noch Schneedaten hinzufügen. Das dürfte unsere Freunde aus Österreich und der Schweiz freuen (Open-Meteo ist ein Schweizer Dienst).
Und die KI-Integration wird vermutlich auch noch folgen können.
Auf der kurzfristigen Zeitachse können auch Strahlungswerte in 15-Minuten Taktung bezogen werden. Mit einem Abruflimit von 10000 Calls pro Tag! ist die Nutzung im Prinzip unbeschränkt.
Ich rufe die Daten alle 10 Minuten ab, das sollte reichen und die Server beim Anbieter schonen.

Ich bin gespannt auf die Ergebisse mit dieser API...

Grüße,
Heiko


Proxmox+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 muss sagen, das man durch den Installationsprozess geleitet wird ist echt mega Hilfreich!

oelidoc

Hallo,
Zitat von: DS_Starter am 20 März 2024, 17:34:39Wenn es ein bisschen in die Schule gegangen ist, kann es dann so aussehen....  ;)
Es ist aber etwas Geduld gefragt! Die Korrekturwerte sind für jede einzelne Stunde abhängig von der prognostizierten Bewölkung, Strahlung und den realen Werten.
An der LED "Qualität" kann man das bisher erreichte Verhältnis zwischen Prognose und realem Ertrag der aktuellen Stunde nach einem Ampelsystem abschätzen.
bei mir steht immer "Abweichung heute: - "
Wie bekommt man denn die Anzeige "Abweichung fortlaufend: 8,4%" wie in dem Screenshot von Heiko oder die Werte für "Abweichung heute: -"?
Vielen Dank
oelidoc

DS_Starter

Proxmox+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

oelidoc


Ingo298

Hallo Leute,
so einige Probleme konnte ich mittlerweile lösen. Heute habe ich einen neue Shelly (1PM mini) in Betrieb genommen.
Dieser liefert allerdings die Leistung bei der Erzeugung als Minuswert kann man das irgendwie invertieren sodass es
im SolarForcast Modul wieder genutzt werden kann?
RPi4 8GB: Bookworm FHEM 6.4, FTUI-3, AMAD,10.1" Tablet; MiLight;IT;HM;Dect200;VZLogger;MQTT;PiVCCU3

moskito

Mit einem Userreading und der "abs"-Funktion kannst du einen positiven Wert erzeugen.
Hier ein Beispiel aus einem meiner Shellys:
power2:apower.* {abs(sprintf('%.2f',ReadingsNum($name,"apower",0)))}
Gruß
Danny

Zitat von: Ingo298 am 23 März 2024, 16:44:09Hallo Leute,
so einige Probleme konnte ich mittlerweile lösen. Heute habe ich einen neue Shelly (1PM mini) in Betrieb genommen.
Dieser liefert allerdings die Leistung bei der Erzeugung als Minuswert kann man das irgendwie invertieren sodass es
im SolarForcast Modul wieder genutzt werden kann?
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

kask

Zum Vorzeichen invertieren:
powerneg:apower.* {sprintf('%.2f',ReadingsNum($name,"apower",0)*-1.0)}

kask

Kurze Info:
Ich muß sagen das die OpenMeteo-Prognose bis jetzt einen wirklich guten Eindruck macht, was die Genauigkeit angeht.
Läuft ja erste ca. 24h, aber sieht echt vielversprechend aus.
Mal weiter beobachten.

erwin

kann mich kask nur anschließen:
läuft erst 2 h, es ist zwar hier kein "idealer Sonnentag", aber Forecast wesentlich besser vs. ForecastSolar !!!
Danke erwin !
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

DS_Starter

#238
Moin,

ZitatIch muß sagen das die OpenMeteo-Prognose bis jetzt einen wirklich guten Eindruck macht, was die Genauigkeit angeht.
Läuft ja erste ca. 24h, aber sieht echt vielversprechend aus.
Das kann ich wie erwin bestätigen. Ich gehe sogar soweit zu behaupten, dass die Witterungsverhältnisse schneller und spezifischer geliefert werden als mit MOSMIX-S!

Meine Beobachtung basiert darauf, dass ich inzwischen auch die Möglichkeit geschaffen habe das Wetterdevice (Attr ctrlWeatherDev1) auf den OpenMeteo-Dienst umstellen zu können.
Wenn so gesetzt, werden sowohl die Strahlungsdaten als auch die Wetterdaten von OpenMeteo bezogen und ausgewertet. Dann sieht man die Unterschiede zum DWD Device mit MOSMIX-X.
Vllt. bekomme ich noch heraus, ob es evtl. Sinn macht bei MOSMIX-X einen anderen Kennwert für die WeatherID zu benutzen (wenn es den gibt). Der Vorteil von OpenMeteo kann natürlich darauf basieren, dass das DWD ICON Modell statt MOSMIX benutzt wird.

Laut DWD Doku:
ZitatDas vollautomatische MOSMIX-Verfahren des DWD optimiert und interpretiert die Berechnungen der numerischen Modelle ICON des DWD und IFS des EZMW, kombiniert diese und berechnet statistisch optimierte Wettervorhersagen in Form von Punkt-Termin-Prognosen (PTP).
MOSMIX ist demnach eine Mischung aus ICON und EZMW, dem deterministischen Prognosen des IFS-Modells (Integrated Forcasting System, math. Modell und Software) des EZMW.
Aber ich bin kein Experte und versuche nur für meine Beobachtungen eine nachvollziehbare Begründung zu finden.

In meinem contrib liegt ein Update der V1.7.0 welches diese Weiterentwicklungen enthält.
Seht auch die Hilfe zum Attr ctrlWeatherDevX und Setter currentRadiationAPI.
(Wie immer Restart nicht vergessen)

Edit: gerade nochmal eine kleine Änderung ergänzt und der Hinweis, dass ich die Anlagenprüfung noch anpassen muß. Falls dort also bei der Verwendung von OpenMeteo noch ein paar Fehler gemeldet werden könnt ihr das irgnorieren.

Grüße,
Heiko
Proxmox+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

DS_Starter

#239
@erwin,
auch bei mir ist die ForecastSolar-API der Dienst mit den schlechtesten Ergebnissen.
Es hat sich durch diverse Maßnahmen im Modul schon ziemlich gebessert, ist aber dennoch deutlich hinter den anderen Möglichkeiten (bei mir) einzuordnen.

LG
Proxmox+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