76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

ahlermi

Zitat von: 300P am 02 April 2026, 14:23:44OT:
######
Womit hast du deinen Roborock in FHEM integriert
######

Bislang hab ich ihn "nur" auf einer QNAP / Container in einer HA-Session "drin"


über eine IO-Brocker Instanz, da gibt es eine genial einfache Möglichkeit das direkt als MQTT weiterzuleiten
Dell Optiplex FHEM, PI3 FHEM, 6 x Echo mit talk2fhem, Siri, YeeLight, Homematic, MAX!, 433Mhz, LaCross, Xiaomi Vacuum V1, ESPEasy, Gardena, Telegram, FLOORPLAN, HEOS, Xiaomi Aqara, Sonoff, SolvisMax, SolvisClient, HUE, ESPEasy für Bayernlüfter, Harmony, Tasmota, JKBMS, EASUN, Roborock S8, Tesla

diebels

Guten Abend,

Mit Update auf Version 2.5.0 ist der Fehler weg! Vielen Dank!

LG


Zitat von: diebels am 31 März 2026, 08:48:43
Zitat von: 300P am 30 März 2026, 09:23:10Hier meine:
attr Forecast setupBatteryDev01 SBS37 pin=-pout:kW pout=total_pac:kW pinmax=3600 poutmax=3600 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh cap=16000 charge=chargestatus show=3:top icon=@dyn:@dyn:@dyn:@dyn asynchron=0 label=beside
attr Forecast setupBatteryDev02 SBS25_2 pin=-pout:kW pout=total_pac:kW pinmax=2500 poutmax=2500 intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh cap=bat_residual_cap:Wh charge=chargestatus show=3:top icon=@dyn:@dyn:@dyn:@dyn asynchron=0 label=below



Hallo,

hier ist meine Config (nicht so spannend  ;D ):

attr Forecast setupBatteryDev01 BatteryDummy pin=-pout:W pout=total_pac:W intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=9000
attr Forecast setupBatteryDev02 BatteryDummy2 pin=-pout:W pout=total_pac:W intotal=bat_loadtotal:kWh outtotal=bat_unloadtotal:kWh charge=chargestatus cap=7800

Heute Nacht wieder der gleiche Fehler. Wie gesagt, war nur als Hinweis gedacht :). Ich teste jetzt die 2.5.0 aus dem Trunk. Danke!

VG

DS_Starter

In meinem contrib liegt ein Update der 2.5.0.

@300P,
ich konnte die Warnung bei mir nichtbeobachten, habe aber den Anzeigecode etwas abgeändert. Damit sollte die Warnung nicht mehr kommen bzw. einen Hinweis ausdrucken falls etwas undefiniert ist.

@all,
in dem Code sind bereits viele Elemente zur Integration von BEV-Consumer eingebaut. Da es aber noch nicht fertig ist, gibt es noch keine Doku dazu. Wird aber in Kürze freigegeben.

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

Wzut

@Heiko , ich habe gestern ein Strommast Icon gesucht (Grid) und war ganz erstaunt das bei den vielen svgs keines dabei ist (oder übersehe ich es ? ) .
Ich habe mir jetzt den Mast aus deinem Modul kopiert und in ein Icon gesetzt.
Ist es ok wenn ich das im Icon Thread poste ?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

DS_Starter

Hallo Wzut,

schön dich wieder hier im Thread mal zu lesen.  :)
Klar kannst du machen. Es gibt in dem openAutomation Projekt schon ein scene_power_grid was ich hier angehängt habe. Unlängst hatte ich auch schon Wind-Icons aus dieser Sammlung einchecken lassen. openAutomation ist ein sehr schöner Fundus für Icons. Kannst ja mal schauen was dir besser gefällt.

Schöne Ostern und VG,
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

Wzut

sieht auch gut aus, ich habe beide im Wuppi Icon Fred gepostet
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

HeikoE

Hallo Heiko,
ich habe ein Verständnisproblem mit plantControl - reductionState. In der Hilfe steht:
reductionState     Liefert einen Status an SolarForecast wenn die PV-Anlage abgeregelt wird bzw. abgeregelt ist (optional).
    Device - Device welches den Abregelungsstatus liefert
    Reading - Reading welches den Abregelungsstatus liefert
    Die Prüfung des gelieferten Wertes kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
    Regex - regulärer Ausdruck der für einen Abregelungsstatus (wahr) erfüllt sein muß
    {Perl-Code} - der in {..} eingeschlossene Perl-Code muß 'wahr' für einen Abregelungsstatus liefern. Er darf keine Leerzeichen enthalten.
Ich habe also ein Userreading angelegt und es mit "0" gefüttert.
Damit wird allerdings die Anzeige im Header gelb.
Du darfst diesen Dateianhang nicht ansehen.
Mit "1" ist die Anzeige grün.
Du darfst diesen Dateianhang nicht ansehen.
Ich verstehe die Erklärung so, dass der Zunstand "Abgeregelt" über ein (wahr) - also 1 - erkannt werden müsste.
Ist das so gewollt?

Frohe Ostern,
Heiko

DS_Starter

Hallo Heiko,

ja, die Abregung wird über das Vergleichsergebnis  <Regex>="true" erkannt.
Jetzt kommt es darauf an welchen Regex du als Test angegeben hast. Mit diesem Beispiel erreichst du das Verhalten 0->keine Abregelung, 1->abgeregelt:

reductionState=<Device>:<Reading>:1

Mit Version  2.5.0 (im contrib) habe ich die Hilfe augebessert:

reductionState    
SolarForecast nutzt diesen Parameter, um den aktuellen Abregelungsstatus der PV-Anlage auszulesen (optional).
   Die Syntax ist eine <Device>:<Reading>:<Funktion>-Kombination. Möglich als <Funktion> sind:
   <Regex> - Der Regex wird auf den Wert von <Device>:<Reading> angewendet. Boolesches Ergebnis: true'->abgeregelt, 'false'->nicht abgeregelt
   <{Perl-Code}> - Das Ergebnis des Perl-Codes wird ausgewertet. Boolesches Ergebnis: 'true'->abgeregelt, 'false'->nicht abgeregelt
            Der Perl-Code darf keine Leerzeichen enthalten. Der Wert von <Device>:<Reading> wird dem Code
            mit der Variable $VALUE übergeben.

Ich hoffe damit ist es klarer geworden.

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 02 April 2026, 23:26:23@300P,
ich konnte die Warnung bei mir nichtbeobachten, habe aber den Anzeigecode etwas abgeändert. Damit sollte die Warnung nicht mehr kommen bzw. einen Hinweis ausdrucken falls etwas undefiniert ist.

Leider kann ich momentan nicht so "richtig" im Netz bei mir arbeiten...meine Fritzbox ist heute Nacht abgeraucht und hat einen Totalschaden.
Gut das die Fritte bei mir nicht alles alleine steuert und "nur" als Router fürs Internet und die Telefonie zuständig ist.
(ist kein DHCP-Server bzw. hab auch viele feste IP's und ist auch nicht Firewall etc. usw.)

Deshalb habe ich aktuell extra nur ein "reload" nach dem Download der neuen Version von gestern Abend machen wollen / können - keine Logmeldung erfolgt.
Sobald ich die Tage wieder eine andere Fritzbox im Haus habe....... melde ich ob es beim Shutdown/Restart bzw. einem kompletten Reboot auch wieder ohne den Perl-Hinweis ist.

Gruß
300P

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

HeikoE

Zitat von: DS_Starter am 03 April 2026, 20:28:44Hallo Heiko,

ja, die Abregung wird über das Vergleichsergebnis  <Regex>="true" erkannt.
Jetzt kommt es darauf an welchen Regex du als Test angegeben hast. Mit diesem Beispiel erreichst du das Verhalten 0->keine Abregelung, 1->abgeregelt:

reductionState=<Device>:<Reading>:1

Mit Version  2.5.0 (im contrib) habe ich die Hilfe augebessert:

reductionState   
SolarForecast nutzt diesen Parameter, um den aktuellen Abregelungsstatus der PV-Anlage auszulesen (optional).
    Die Syntax ist eine <Device>:<Reading>:<Funktion>-Kombination. Möglich als <Funktion> sind:
    <Regex> - Der Regex wird auf den Wert von <Device>:<Reading> angewendet. Boolesches Ergebnis: true'->abgeregelt, 'false'->nicht abgeregelt
    <{Perl-Code}> - Das Ergebnis des Perl-Codes wird ausgewertet. Boolesches Ergebnis: 'true'->abgeregelt, 'false'->nicht abgeregelt
            Der Perl-Code darf keine Leerzeichen enthalten. Der Wert von <Device>:<Reading> wird dem Code
            mit der Variable $VALUE übergeben.

Ich hoffe damit ist es klarer geworden.

LG,
Heiko
Danke für die Erklärung.
Dass der dritte Wert die Prüfung ist, hatte ich wirklich nicht verstanden.
Ich habe
reductionState=DR.PV_Vorhersage:redState:0da stehen...
Vielleicht solltest Du noch hinzufügen, dass $value dann in diese Prüfungsfunktion einfliesst.


klaus.schauer

In PV-Vorhersage algorithmisch - abgeleitet aus Globalstrahlung wird die Berechnung der PV-Einstrahlung auf Basis von Globalstrahlungsprognosen beschrieben. Einfach aus Interesse: Wie wird das in SolarForecast derzeit realisiert?

300P

Das kommt grundsätzlich schon mal darauf an welche externe "Daten-Quelle" als Wettervorhersage der Benutzer ausgewählt hat.
Dann natürlich jeweils welcher sub aufgrund der Vorgabe dieser Quelle durchlaufen werden.

Einige Beispiele sind im Code etwas textlich erläutert ehe die Berechnung dann real erfolgt (u.a. bei z.B. DWD-Nutzung):
##################################################################################################
4513    # Abruf DWD Strahlungsdaten und Rohdaten ohne Korrektur
4514    #
4515    # Berechnung nach Formel 1 aus http://www.ing-büro-junge.de/html/photovoltaik.html
4516    # als Jahreserträge:
4517    #
4518    #    * Faktor für Umwandlung kJ in kWh:   0.00027778
4519    #    * Eigene Modulfläche in qm z.B.:     31,04
4520    #    * Wirkungsgrad der Module in % z.B.: 16,52
4521    #    * Wirkungsgrad WR in % z.B.:         98,3
4522    #    * Korrekturwerte wegen Ausrichtung/Verschattung etc.
4523    #
4524    #    Die Formel wäre dann:
4525    #    Ertrag in Wh = Rad1h * 0.00027778 * 31,04 qm * 16,52% * 98,3% * 100% * 1000
4526    #
4527    # Berechnung nach Formel 2 aus http://www.ing-büro-junge.de/html/photovoltaik.html:
4528    #
4529    #    * Globalstrahlung:                G = kWh/m2   (DWD Rad1h = kJ/m2)
4530    #    * Korrektur mit Flächenfaktor f:  Gk = G * f
4531    #    * Globalstrahlung (STC):          1 kW/m2
4532    #    * Peak Leistung String (kWp):     Pnenn = x kW
4533    #    * Performance Ratio:              PR (typisch 0,85 bis 0,9)
4534    #    * weitere Korrekturwerte für Regen, Wolken etc.: Korr
4535    #
4536    #    pv (kWh) = G * f * 0.00027778 (kWh/m2) / 1 kW/m2 * Pnenn (kW) * PR * Korr
4537    #    pv (Wh)  = G * f * 0.00027778 (kWh/m2) / 1 kW/m2 * Pnenn (kW) * PR * Korr * 1000
4538    #
4539    # Die Abhängigkeit der Strahlungsleistung der Sonnenenergie nach Wetterlage und Jahreszeit ist
4540    # hier beschrieben:
4541    # https://www.energie-experten.org/erneuerbare-energien/photovoltaik/planung/sonnenstunden
4542    #
4543    # PV Berechnungsgrundlagen
4544    # https://www.energie-experten.org/erneuerbare-energien/photovoltaik/planung/ertrag
4545    # http://www.ing-büro-junge.de/html/photovoltaik.html
4546    #
4547    ##################################################################################################
oder auch hier
##################################################################################################
4669    #  Flächenfaktor Photovoltaik
4670    #  Prof. Dr. Peter A. Henning, September 2024
4671    #  ersetzt die Tabelle auf Basis http://www.ing-büro-junge.de/html/photovoltaik.html
4672    #  (für den Jahresertrag!)
4673    #  siehe Wiki: https://wiki.fhem.de/wiki/Ertragsprognose_PV
4674    ##################################################################################################
4675    sub ___areaFactorFix {
........
........
##########################################################################################################
4697 #  Flächenfaktor Photovoltaik und Direktstrahlungsanteilsfaktor in Abhängigkeit des Sonnenstandes
4698 #
4699 #  Die Globalstrahlung  (Summe aus diffuser und direkter Sonnenstrahlung)
4700 #  ----------------------------------------------------------------------
4701 #  Die Globalstrahlung ist die am Boden von einer horizontalen Ebene empfangene Sonnenstrahlung
4702 #  und setzt sich aus der direkten Strahlung (der Schatten werfenden Strahlung) und der
4703 #  gestreuten Sonnenstrahlung (diffuse Himmelsstrahlung) aus der Himmelshalbkugel zusammen.
4704 #  Bei Sonnenhöhen von mehr als 50° und wolkenlosem Himmel besteht die Globalstrahlung zu ca. 3/4
4705 #  aus direkter Sonnenstrahlung, bei tiefen Sonnenständen (bis etwa 10°) nur noch zu ca. 1/3.
4706 #
4707 #  Direktstrahlung = Globalstrahlung * 0.75   (bei >  50° sunalt)
4708 #  Direktstrahlung = Globalstrahlung * 0.33   (bei <= 10° sunalt)
4709 #
4710 #  Quelle: https://www.dwd.de/DE/leistungen/solarenergie/globalstrahlung.html?nn=16102&lsbId=416798
4711 #
4712 #  Return:
4713 #  $daf - direct Area Faktor für den Anteil Direktstrahlung der Globalstrahlung
4714 #  $sdr - Share of direct radiation = Faktor Anteil Direktstrahlung an Globalstrahlung (0.33 .. 0.75)
4715 #
4716 ##########################################################################################################


Schau einfach mal in den Programmcode per Anzeige im Contrib bei den hier extra mit angezeigten Zeilenummern und lese dich evtl. tiefer ein  O:-)
Gruß
300P

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

lorisurfen

Guten Abend,

mir fällt schon seit längerem auf, dass meine 10 consumer von SF oft alle gleichzeitig eingeschaltet werden, obwohl der Überschuss nicht für alle consumer in Summe ausreicht. Weil der Überschuss nicht für alle eingeschalteten consumer ausreicht erfolgt Netzbezug und alle consumer werden wieder ausgeschaltet.

Vereinfachtes Beispiel: 5 consumer mit je 1000W, Current_Surplus=2500.
Für mich sieht es so aus, als ob alle 5 consumer für sich betrachtet die Einschaltbedingung erfüllen und alle 5 eingeschaltet werden, anschließend erfolgt 2500W Netzbezug und es werden alle 5 wieder ausgeschaltet und so toggelt es dann.

Nachfolgend beispielhaft ein consumer:
Shelly_UG_1 type=heater power=800 icon=IR@red pcurr=power:W etotal=energy:Wh mode=can mintime=SunPath on=on off=off interruptable=0 swoncond=calcEnergieManager:calc_surplus:{$VALUE>700?1:0;} swoffcond=calcEnergieManager:calc_surplus:{$VALUE<-500?1:0;} auto=automatic
Frohe Ostern
Markus

DS_Starter

Hallo Markus,

ZitatFür mich sieht es so aus, als ob alle 5 consumer für sich betrachtet die Einschaltbedingung erfüllen und alle 5 eingeschaltet werden, anschließend erfolgt 2500W Netzbezug und es werden alle 5 wieder ausgeschaltet und so toggelt es dann.
Ja, das ist ein Problem was momentan auftreten kann und du hast es richtig erkannt. Allerdings überprüft SF vor dem Einschalten des nächsten Consumers die aktuellen Leistungsverhältnisse im Netz. Das funktioniert allerdings nicht in Echtzeit denn unsere Meßeinrichtungen liefern ja nur in gewissen Abständen Daten abhängig vom Device.

Helfen würde in diesem Fall eine Cycle-Chain, d.h. wenn ein Consumer eingeschaltet wurde, darf im selben Zyklus kein weiterer Consumer eingeschaltet werden. Erst im nächsten Zyklus wäre dies möglich sofern die Netzverhältnisse es erlauben. Eine solche Logik muß ich aber erst implementieren.

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

DS_Starter

Im contrib liegt das Udpate der V2.5.0.
Integriert ist nun der Consumertyp "bev".

"bev" wird wie andere Verbraucher auch eingerichtet mit ein paar Besonderheiten die in der Hilfe beschrieben sind. Wichtig und neu in der Architektur ist der Schlüssel "evid", der einen Consumer aktiviert. So ist es möglich eine N -> 1 -> N Beziehung zu erstellen. D.h. N E-Autos teilen sich 1 Wallbox und werden in SF in N Consumern abgebildet.

Es werden zur Zeit NUR die Werte gesammelt und gespeichert. Wenn alles funktioniert und es sind ausreichend Daten vorhanden, kann später ein Profil für die FANN KI erstellt werden. In der Legacy Verbrauchsprognose haben die gesammelten Werte natürlich schon Einfluß und können entsprechend hohe Prognose verursachen. Das liegt in der NAtur der Sache wenn EV's im Haushalt vorhanden sind.

Wir werden also zunächst schauen ob die Aktivierung per "evid" wie gewünscht funktioniert und dass alle benötigten Daten in pvHistory und aiRawData gespeichert werden.
In der pvHistory werden diese Daten gespeichert:

csmt19: 60000, csme19: 60000.00, minutescsm19: 34, bevcsmSoC19: 72, bevcsmTargSoC19: 84
In der aiRawData sind es:

bevcsm: 19,20, ..... csme19: 0, bevcsmSoC19: 72, bevcsmTargSoC19: 84, bevcsmSoC20: 70, bevcsmTargSoC20: 87
Es wird sicherlich noch Nachbesserungsbedarf geben, aber die ersten Schritte sind getan.

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