76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

grappa24

moin,
Meine Prognose war die ganze Zeit recht gut, jetzt liegt sie heftig zu tief -130% am 10.03. und -107% am 11.03. mit jeweils der aktuellen contrib Version
Gruß Dieter
Gebäudesicherheit/-komfort, PV-Prognose/Verbrauchssteuerung, Heizungssteuerung, Multimedia, ...
KNX, FS20, HM, HUE, Tradfri, Shellies, KLF200, Netatmo, Nuki, SolarForecast, HEOS, Alexa-FHEM, ...
FHEM 6.4, 2 x RasPi 3B+, Debian Bullseye

DS_Starter

Moin,

ja ich beobachte das auch. Ich habe die Drift-Korrektur bereits abgeschwächt, bin mit dem Ergebnis noch nicht zufrieden.
Bleibe da dran.

LG,
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

300P

Zitat von: DS_Starter am 10 März 2026, 21:54:22Die eingebaute Drift-Korrektur reagiert zu straff wie ich heute bei mir festgestellt habe.
Ja - ist so (gewesen.
Ich hatte begonnen schon an den Einstellparameter zu drehen und 5 Berechnung gestern angeworfen... (-50 % Abweichung gab es am Ende Gestern bei mir dann :o )
Berichte dann was heute rauskommt (ohne weitere Änderung)
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.

Parallix

#5343
Kurze Frage (an Heiko):

Ist es möglich, dass Du in SF ein Attribut einbaust, mit dem eine Grundlast definiert werden kann, die dann als immer zu berücksichtigender Verbrauch von SF bei der Ladeplanung berücksichtigt wird. Für (m)einen Anwendungsfall wäre es noch besser, wenn ein Grundlast-Profil als Array mit 24 Elementen (ein Element pro Stunde) definiert werden kann oder ggf. sogar aus einem Reading bezogen werden kann.

Hintergrund: Abseits vorgenannter Grundlast ergibt sich der Verbrauch bei mir praktisch ausschließlich auf Basis von Verbrauchern, die nur bei zu erwartendem PV-Überschuss eingeschaltet werden. Letzteren ermittelt SF perfekt auf Basis des PV-Forecastings. Auf den Einsatz von KI-Einsatz möchte ich nicht nur aus Ressourcengründen verzichten, sondern auch deshalb, weil sich nahezu alle Vorgänge bei mir sehr gut mit klassischen Methoden modellieren lassen und das Regelverhalten daher konstant deterministisch ist, also nicht von Lernprozessen und deren Dauer abhängig ist.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.62) und 7591 (8.21) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

marboj

Zitat von: tomcat.x am 10 März 2026, 12:56:20Battery hat nur "pout". Oder meinst Du nicht, was sie gerade abgibt?

Hallo tomcat.x,

Heiko hatte mir die folgenden Infos gegeben:
ZitatDas ist praktisch das Solar-Ladegerät mit der Batterie. Hier muß sein:

- pvOut: die aktuelle Leistung aus PV-Erzeugung. Hier darf NUR die Solarzellenleistung drinstecken und
         keine anderen Bestandteile wie Batterieleistungsabgabe
- pin:  die aktuelle Batterieladeleistung, d.h. der Anteil der Solarleistung der in die Batterie geladen wird
        (kann alles sein) und/oder der Ladeanteil vom Wechselstromhausnetz falls dies zutreffen kann.
        Ist der Readingname "/power" so richtig?
- pout: die aktuelle Batterieentladeleistung, d.h. was die Batterie an das Hausnetz abgibt. Hier darf
        wiederum kein Solarzellenanteil drinstecken.

Wenn du diese Bedingungen einhältst, sollte die Flußdarstellung i.O. sein.

Den Parameter pvOut kann ich nicht setzen. Deswegen habe ich gefragt...

Gruß
Marco
meine FHEM-Konfiguration: Raspberry Pi4, BT-Dongle, CUL868, CeeBee II