76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

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

Vorheriges Thema - Nächstes Thema

cs-online

Zitat von: Shadow3561 am 02 Februar 2025, 08:27:59
Zitatdir fehlt im Attr setupBatteryDevXX sicherlich der Schlüssel cap.
Das habe ich bei mir bereits drin.
Aber nach genauem durchsehen ist mir aufgefallen, dass es jetzt ohne Angabe der Einheit sein muss
Vorher
cap=8000:Wh
Jetzt
cap=8000Dann wird der SOC wieder angezeigt.
@DS_Starter
Danke für den Wink mit dem Zaunpfahl


Hallo ihr beiden lieben,

genau das war es, ich hatte CAP drin, aber mit Einheit, nach dem Löschen der Einheit ist es wieder da :-)

Danke euch

Grüße

Christian
FHEM auf RPI 4 4GB, HM-WLAN-Gateway, einige HM-Aktoren,2x EBUSD an Heizung+Solar, ESP8266/32 am Strom-,Gas-,Wasserzähler, in WLAN-Steckdosen und Relaisleisten, Sonoff S20+S26,Shelly1/2/2.5, Lacrosse-Gateway und Sensoren,Sduino,Alexa-Fhem,Huawei PV+Speicher, alles auf einem RPI und da geht noch mehr

Skusi

Hallo,
will sich denn keiner zu meinem Post #1847 äußern?
Oder ist meine Frage so doof das man sie ignorieren muss? ::)
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

300P

Zitat von: Skusi am 03 Februar 2025, 16:47:43Hallo,
will sich denn keiner zu meinem Post #1847 äußern?
Oder ist meine Frage so doof das man sie ignorieren muss? ::)

Bei Dir :
cap=1600:Wh    :o

Das verwirrt immer wieder mal O:-) jemanden
@DS_Starter: =>> eventuell ein Zusatz hinzu damit eindeutiger wird ?
cap    installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)

NUR dann wenn ein Reading genutzt wird =>>> dann mit Einheit
Ansonsten immer ohne Einheit !

Trag mal nur dies ein (ohne Wh):
cap=1600 ;)
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

DS_Starter

@Skusi,
ich hatte doch schon in #1854 geantwortet. :o

@300P,
Zitat@DS_Starter: =>> eventuell ein Zusatz hinzu damit eindeutiger wird ?
Kann ich machen.
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

Skusi

Moin,
@300P
Zitat von: 300P am 03 Februar 2025, 19:57:23Trag mal nur dies ein (ohne Wh):
cap=1600 ;)

Danke für den Tipp, das hatte ich auch anders interpretiert. War das schon immer so, oder wurde das geändert ?

@DS_Starter
Zitat von: DS_Starter am 03 Februar 2025, 20:27:04ich hatte doch schon in #1854 geantwortet. :o

Ohh, entschuldige. Ich habe nur den Anfang des Posts überflogen und nichts zu meinem Problem entdeckt. :o

Zitat von: Skusi am 30 Januar 2025, 11:46:40Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.

Zitat von: DS_Starter am 30 Januar 2025, 19:11:38Das ist ein nicht so glückliches Setup. Abgesehen davon dass ich nicht verstehe wieso per DTU auch in der Nacht eine PV Leistung übermittelt wird, ist es problematisch wenn die erzeugte WR Leistung nicht in den setupInverterDevXX - Readings ankommt. Nur dort wird die PV-Leistung auch als solche gewertet.
Im BatteryDev01 gemeldete Leistungen können im Fall des BatIn auch eine Beladung aus dem Netz sein.
Hier müsstest du schauen, ob du mittels userReadings ein genaueres Input dem Modul bereitstellen kannst.

Die Leistung in der Nacht kommt dann aus dem WR der an dem Solix Akku hängt. Wenn der Akku entladen wird geht das ja über den WR ins Haus. Die DTU bewertet das dann als Solar Leistung.
Im Sommer wird der Akku über die beiden "Akku" Zellen beladen. Der WR meldet dann 0 Wh. Wenn der Akku voll ist, geht die Leistung der Zellen für den Rest des Tages über den WR ins Haus. Da der Zeitpunkt wann der Akku in den Bypass schaltet von der Einstrahlung abhängt, kann das Modul natürlich schwer damit rechnen.
Für meinen Fall müsste man im setupInverterDev hinterlegen können das die ersten 1600 Wh des Tages ignoriert werden. Das ist aber noch nicht alles... Da muss man noch weiter denken. Ich glaube das ist zufiel der Wünsche für mein spezielles Setup. Ich habe im Moment auch keine Idee wie ich das per userReading oder Dummy vorbereitend für das Modul umsetzen kann.

Ich denke es ist dann erstmal besser für die Prognose Genauigkeit wenn ich die beiden Zellen die den Akku Laden und den Akku selbst aus dem Modul entferne. Dann habe zwar eine Prognose die die Leistung bei Akku Bypass Betrieb ignoriert, aber eine andere Lösung fällt mir gerade nicht ein.

HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

Shadow3561

#1895
hier stand Müll

300P

Zitat von: Skusi am 04 Februar 2025, 15:28:53Moin,
@300P
Zitat von: 300P am 03 Februar 2025, 19:57:23Trag mal nur dies ein (ohne Wh):
cap=1600 ;)

Danke für den Tipp, das hatte ich auch anders interpretiert. War das schon immer so, oder wurde das geändert ?

Ja - war schon lange so (als Option) =>> nur das mit dem <Reading:Einheit> kam dann später mal hinzu.

PS:
Versuche es erst einmal einen Tag mit dem "richtigen" BatterieSetup.
>- vielleicht wird es ja wenn dies "richtig passt".
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

300P

Zitat von: Skusi am 30 Januar 2025, 11:46:40Hallo zusammen, super hier mitzulesen wie dieses geniale Modul immer intelligenter wird.
Allerdings wird es auch zunehmend komplizierter zu verstehen wie man es richtig mit Infos füttert. Ich benutze das Modul schon ca 3-4 Jahre und meine Anlage hat sich in der Zeit auch etwas erweitert. Nun beobachte ich die Prognosen und bin nicht zufrieden mit der Genauigkeit. Einerseits liegt es sicher an den Wettervorhersagen des DWD die selten der der Realität entsprechen, andererseits mach ich mir Gedanken über die Richtigkeit der Einbindung meiner etwas speziellen Anlage.

Aufbau:
6x Microwechselrichter 320 Wp (1 Panel) als Feld auf Dach Süd Ausrichtung
1x Microwechselrichter 600 Wp (2 Panel) auf Schuppendach Süd Ausrichtung an Solix Akku 1600 Wh

Das 6er Feld heißt im Modul "Dach" und das auf dem Schuppen "Akku"

Der 600 Wp Wechselrichter speist am Tage ausschließlich den Solix Akku bis er voll ist und leitet danach alles am Akku vorbei ins Hausnetz. Ab 21:00 entlade ich dann den Akku mit konstant 180 Wh bis er lehr ist.

Die Daten aller Wechselrichter werden über eine DTU eingesammelt und in Fhem bereitgestellt. Der Solix Akku ist auch als Device per MQTT eingebunden und stellt die benötigten Daten bereit.

Definiert habe ich das derzeit im Modul so:(zusammen kopiert)
attr SolarForcast setupBatteryDev01 Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W intotal=statistics_1_total:kWh outtotal=statistics_2_total:kWh cap=1600:Wh charge=solarbank_info_solarbank_list_1_battery_power
attr SolarForcast setupInverterDev01 OpenDTU pv=Total_power:Wh etotal=Total_yieldtotal:kWh capacity=2400
attr SolarForcast setupInverterStrings Dach,Akku
attr SolarForcast setupStringPeak Dach=1.92 Akku=0.76

setstate SolarForcast 2024-07-01 18:40:45 setupStringAzimuth Dach=7 Akku=7
setstate SolarForcast 2024-07-01 18:40:45 setupStringDeclination Dach=20 Akku=10

Da die Wechselrichte alle in einer DTU landen, habe ich dadurch natürlich auch nachts eine erzeugte Gesamtleistung. Außerdem fehlt die Leistung am Tage die in den Akku fließt. Allerdings wir diese Leistung von dem Akku Device ja an das Modul per BatteryDev01 gemeldet.

Meine Frage nun: Ist das so in Ordnung, oder kann das Modul das so durcheinander bringen das die real Daten so von der Prognose abweichen.

Macht es Sinn den 600er Wechselerichter von dem InverterDev01 abzukoppeln und über ein Dummy ein InverterDev02 davon zu machen ?

Ich bin etwas Ratlos wie die Daten einer solchen Konstellation im Modul verarbeitet werden und ob es so zu Fehler in den Berechnungen kommt.

Wie wäre es damit:

Bau dir mal einen DummyWR (s.u.) und nutze dessen "neuen" Readings in einer SF-Testumgebung die zu 99 % gleich eingerichtet ist - ABER ->> bis auf diese "neuen" Angaben im Setup für den Wechselrichter:

attr SolarForcast setupInverterDev01 InverterDummy pv=total_pac:W etotal=etotal:kWh capacity=2400

defmod InverterDummy dummy
attr InverterDummy event-on-change-reading .*
attr InverterDummy group Energy Meter
attr InverterDummy icon measure_photovoltaic_inst@green
attr InverterDummy room 020_PV,Energie
attr InverterDummy stateFormat {sprintf("current %9.3f W    Today_PVforecast  %9.3f kWh      Today_PV %9.3f kWh      Total_PV %9.3f kWh",\
(ReadingsVal($name,"total_pac",0)/1),\
(ReadingsNum("Forecast","Today_PVforecast",0)/1000),\
(ReadingsVal($name,"etoday",0)/1),\
(ReadingsVal($name,"etotal",0)/1),)}
attr InverterDummy userReadings etoday { ReadingsVal("OpenDTU","etoday_Wert_soweit_vefuegbar",0)/1;; }, \
etotal { ReadingsVal("OpenDTU","Total_yieldtotal",0)/1;; }, \
total_pac { ((ReadingsVal("OpenDTU","Total_power",0)/1) + (ReadingsVal("Solarbank","solarbank_info_total_charging_power",0)/1) - (ReadingsVal("Solarbank","solarbank_info_total_output_power",0)/1));; }
attr InverterDummy verbose 2


Erläuterung : PV-WR-Leistung = Summe aus WR +(Batteriebeladewert Akku) - (Batterieentladewert Akku)   (#->> Werteangabe aber alle positiv !!!)


Damit sollte tagsüber der "richtige" Wert der PV-Erzeugung in der Grafik gezeigt werden.
Nachts wird/müsste dann "0" PV-Erzeugung gezeigt, denn entstehende Minuswerte durch den Akku werden in SF (soweit ich es kenne) abgefangen und "genullt".
Dein Akku würde dir aber die Werte vom Laden und Entladen ebenfalls anzeigen sollen.

ABER - keine Garantie dafür  O:-)

Gruß
300P
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

300P

Nachsatz / Kopierfehler:
In der vorherigenDefinition war ein Kopierfehler - sorry ist korrigiert worden.

Du musst aber auch noch in einem 2.ten Schritt dann den InverterDummy noch weiter anpassen =>> damit die PV-Leistung und deren Berechnung auch passt

Dazu musst du zusätzlich den fortlaufenden Summenzähler vom Akku (Beladung Akku) noch im Dummy zum fortlaufenden Erzeugungszähler des DTU addieren um deine "gesamte erzeugte PV-Energiemenge" zu erhalten. (Einheiten bitte beachten bei der Berechnung)

Also nochmals das Userreading anpassen:
attr InverterDummy userReadings etoday { ReadingsVal("OpenDTU","etoday_Wert_soweit_vefuegbar",0)/1;; }, \
etotal { ((ReadingsVal("OpenDTU","Total_yieldtotal",0)/1) +((ReadingsVal("Solarbank","statistics_1_total",0)/1);; }, \
total_pac { ((ReadingsVal("OpenDTU","Total_power",0)/1) + (ReadingsVal("Solarbank","solarbank_info_total_charging_power",0)/1) - (ReadingsVal("Solarbank","solarbank_info_total_output_power",0)/1));; }


FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

kask

Ich würde die "total"-Werte auch oder nur als monotonic ausführen um beim wechseln der Geräte den Wert nicht nocheinmal manipulieren/angleichen zu müssen.

etotaltot:etotal:.* monotonic { ReadingsNum($name,"etotal",0.0) }
total_pactot:total_pac:.* monotonic { ReadingsNum($name,"total_pac",0.0) }

DS_Starter

Ich habe die letzten Tage einige Bereinigungen und kleinere Bugfixes vorgenommen.
Die V 1.45.2 ist morgen früh im Update und auch jetzt bereits in meinem contrib verfügbar.

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

Skusi

@ 300P
Vielen Dank für dein Gehirnschmalz.

Ich hab den Dumm mal angelegt und beobachte die Readings.

Parallel habe ich mir die verfügbaren Readings meiner beteiligten Devices und die Definition von SolarForcast nochmal genauer angesehen und die Attribute folgendermaßen angepasst:
setupInverterDev01
OpenDTU pv=Sued_1-6_power:Wh etotal=Sued_1-6_yieldtotal:kWh capacity=1800 strings=Dach
Ich habe im OpenDTU neue userReadings nur für die Zellen die direkt ins Haus gehen, also ohne Akku Anbindung angelegt (Sued_1-6)
setupInverterDev02
Solarbank pv=solarbank_info_total_photovoltaic_power:Wh etotal=statistics_1_total:kWh capacity=600 strings=Akku feed=bat

Der 2. Inverter bekommt nun readings aus dem Akku Device. pv= reine Leistung der Zellen, egal ob die in den Akku fließt oder später wenn Akku voll ins Haus. etotal= aufsteigender Zähler der abgegebenen Leistung des Akkus. Nachts beim Endladen und tags wenn Bypass aktiv. Ich hoffe durch die Angabe strings=Akku feed=bat das das Modul die Daten richtig verarbeitet.
setupBatteryDev01
Solarbank pin=solarbank_info_total_charging_power:W pout=solarbank_info_total_output_power:W outtotal=statistics_1_total:kWh cap=1600 charge=solarbank_info_solarbank_list_1_battery_power
Unverändert nur cap ohne Einheit

Ich beobachte die vom Modul angezeigten Momentan Werte. Diese sind Tagsüber plausibel. Mal sehen was heute Abend bei Entladung des Akkus passiert.

Eine Frage noch zu
setupStringPeak Dach=1.92 Akku=0.76

Welche Leistung ist hier gefordert. Tatsächlich die max Leistung der Panels bei 100% Einstrahlung, oder die Maximal Leistung die die Microwechselrichter abgeben können
HP ThinClient 630, SIGNALduino, NanoCul868 (a-culfw), JeeLink Clone (LaCrosse), Firmata  für FB Heizung,Wasser+Gas+Klingel+Lux, Somfy Rolladen, Pollin Steckd.,TX29DTH,Tasmota+IR Lesekopf an Stromz., MAX Fensterkontakte, IButton, Fingerprint, SonOff Tasmota, ESP LED Controler, WLed,zigbee2mqtt...

300P

#1902
Zitat von: DS_Starter am 05 Februar 2025, 21:33:38Ich habe die letzten Tage einige Bereinigungen und kleinere Bugfixes vorgenommen.
Die V 1.45.2 ist morgen früh im Update und auch jetzt bereits in meinem contrib verfügbar.

Grüße,
Heiko

Könnte es sein das die Logik für den Interval mit dieser Version nicht zu 100 % funktioniert ??
Die Anzeigegrafik verändert sich bei mir nicht mehr bzw. kein Update der Webseite mehr ?

Gruß
300P


Nahsatz:
Hab grad leider erst bemerkt:
Es hakt bei der Aktualisierung nur dann wenn man direkt auf dem SF-Modul als "zum Anzeigen" steht.
Wenn es "normal" irgendwo in FHEM eingebunden ist funktioniert es auch normal.
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

300P

Zitat von: Skusi am 06 Februar 2025, 10:52:17....Ich beobachte die vom Modul angezeigten Momentan Werte. Diese sind Tagsüber plausibel. Mal sehen was heute Abend bei Entladung des Akkus passiert.

Eine Frage noch zu
setupStringPeak Dach=1.92 Akku=0.76

Welche Leistung ist hier gefordert. Tatsächlich die max Leistung der Panels bei 100% Einstrahlung, oder die Maximal Leistung die die Microwechselrichter abgeben können

Siehe auch in den Erläuterungen zum Attribut:

setupStringPeak <Stringname1>=<Peak> [<Stringname2>=<Peak> <Stringname3>=<Peak> ...]

Die DC Peakleistung des Strings "StringnameX" in kWp. Der Stringname ist ein Schlüsselwert des Attributs setupInverterStrings.
Bei Verwendung einer KI basierenden API (z.B. Model VictronKiAPI) sind die Peakleistungen aller vorhandenen Strings als Summe dem Stringnamen KI-based zuzuordnen.

Beispiele:
attr <name> setupStringPeak Ostdach=5.1 Südgarage=2.0 S3=7.2
attr <name> setupStringPeak KI-based=14.3 (bei KI basierender API)

Gruß
300P
FHEM 6.3|RaspberryPi|VControl300|VITOVALOR300P|SMAEM|SMAInverter|DbLog|DbRep|MariaDB|QNAP|HTTPMOD|Modbus ser+TCP|SolarForecast|ESP32Gasmeter|ESP32Watermeter|ESP32CAMOV2640

DS_Starter

ZitatEs hakt bei der Aktualisierung nur dann wenn man direkt auf dem SF-Modul als "zum Anzeigen" steht.
Wenn es "normal" irgendwo in FHEM eingebunden ist funktioniert es auch normal.
Ich weiß nicht, ob das jetzt eine Frage ist.
In der Detailansicht ("zum Anzeigen") erfolgt keine automatische Aktualisierung. In der Raumansicht (also "normal") arbeitet die automat. Aktualisierung.
So ist es.
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