Leistungsprognose für Wechselrichter

[DS_Starter]

Update zum Batterie Management. Die gestern formulierte Erwartung hat sich heute bei mir erfüllt. Die Bat wurde auf 99% SoC geladen, der Rest wurde direkt verbraucht. Waschmaschine und Trockner haben heute ihren Teil geleistet. Von erzeugten 24.1 kWh wurden lediglich 0.5 kWh eingespeist. Passt für mich.

Die Batterien wurden auch harmonisiert. Im Plot sieht man das Zusammenlaufen ab ca. 90%.

[grappa24]

Wo lebt ihr denn
Bei uns in Frankfurt/M schien heute Null die Sonne 

[DS_Starter]

Bei Leipzig. Morgen sieht es hier lt. Prognose auch sehr mau aus.
Heute war seit längerem der erste ergiebige Tag, ein Ausnahmetag zur Zeit. 

Edit: Ist aber eine gute Zeit das Batterie Mangement zu testen. Im Sommer hat das eher keinen Sinn.

[TheTrumpeter]

Ich habe das Modul schon seit einigen Monaten auf meiner ToDo-Liste & am Freitag endlich die Installation durchgeführt.
Seitdem habe ich mich durch die 137 Seiten dieses Themas gewälzt, da das Wiki als auch die CommandRef doch einige Fragen/Konzepte nicht beantworten konnte. Zugegeben, die detaillierten Diskussionen anfangs sowie die Diskussionen um die Grafik habe ich nur überflogen, aber doch ein paar Antworten auf meine offenen Punkte finden können.

Ein paar Themen sind doch noch offen geblieben, ich hoffe die Punkte kann mir jemand beantworten.

Mögliche APIs:

• Begonnen habe ich mit der ForecastSolar-API, weil die ohne Registrierung funktioniert und ich die Konfiguration am Logischsten gefunden habe. Allerdings waren die Prognosedaten für die ersten 2 Tage so falsch/komisch, dass ich kurzerhand auf die SolCastAPI umgestellt habe. Das Problem mit den ggü. dem Standardwert geringer verfügbaren Abfragen konnte ich mittlerweile lösen. Ursprünglich habe ich gedacht, dass die ForecastSolar-API ev. mit einer ungenauen Himmelsrichtung abgefragt wird, aber irgendwo in den letzten Seiten wurde dann klargestellt, dass die genaue Angabe verwendet wird. Braucht die API länger um zu "lernen"? Die SolCastAPI ist heute (2. wolkenloser Tag in Folge) noch ohne Korrektur schon sehr genau, nachdem ich den Effizienzfaktor gestern Abend korrigiert habe.
• Eigentlich wollte ich auch die Victron-API ausprobieren, weil die in der CommandRef recht interessant klingt. Nachdem ich mich dort angemeldet habe, musste ich feststellen, dass Voraussetzung für die Nutzung wohl auch ein dazupassender Wechselrichter von denen ist? Stimmt das oder übersehe ich einen "Bypass"?
• Für die Vorhersagen mittels DWD braucht man wohl eine Wetterstation, die "Rad1h"-Werte liefert, die ich nicht habe. Unklar ist mir, ob man die "Rad1h"-Werte trotzdem braucht, wenn man eine andere API verwendet? (Im Konfigurations-Check wird's nicht angemeckert, in den 137 Seiten Thema hier kommt aber immer wieder die Frage nach den "Rad1h"-Werten. Dabei war mir nie ganz klar, ob sich das dann immer auf die Nutzung als "API" bezog oder es eine generelle Anforderung an die Wettervorhersage ist, siehe z.B.:
  

  Im PlantConfiguration Check, wenn rad1h fehlt, steht das nicht so schön aufgeführt wie bei den weatherproperties meine ich.

Hauptziel des Moduls ist es für mich die Ladung des Warmwasser-Speichers (über Wärmepumpe) etwas flexibler zu gestalten.
Vereinfacht gesagt prüfe ich aktuell einfach den Überschuss (gleitender Mittelwert der letzten 5min) und starte bei ausreichend Überschuss die Aufheizung. Zusätzlich würde ein Schaltprogramm der Wärmepumpe zum Zeitpunkt des Sonnenhöchstandes das Aufheizen starten, wenn die Speichertemperatur zu niedrig ist. Das führt aber dazu, dass bei Wetterbesserung am Nachmittag tendenziell unnötig Strom aus dem Netz kommt. Die Verbrauchersteuerung von SolarForecast scheint mittlerweile alle nötigen Voraussetzungen zu bieten, damit ich das umstellen kann. Das Schaltprogramm würde dann am späten Nachmittag nur noch als "Hosenträger" dienen und sollte dann im Normalfall die Wärmepumpe nicht mehr starten.

Um mich vorab mal mit der Verbrauchersteuerung vertraut zu machen, habe ich ein paar Verbraucher definiert und beobachte deren Verhalten. Auf Basis dessen habe ich noch nicht ganz verstanden wann das Modul einen "gestarteten Verbraucher" erkennt bzw. ihn starten würde.
So habe ich beispielsweise einen Geschirrspüler definiert, dessen Leistungsaufnahme über eine Steckdose mit Leistungsmessung erfasst wird. Wenn ich die Daten aus "valConsumerMaster" richtig verstehe, erkennt das Modul den durchschnittlichen Leistungsbedarf gemittelt auf 1 Stunde ("epiecHist_x"). Zusätzlich gibt's aber "Default-Werte", die sich aus der Definition als "dishwasher" ergeben ("epieces" oder "ehodpieces"). Was davon verwendet das Modul nun, um den Verbraucher einzuplanen? Die gelernten historischen Werte (bzw. ein Mittel daraus) oder die "Default-Werte"?
Falls immer die "Default"-Werte verwendet werden, verstehe ich den Sinn der "Lernfunktion" nicht und würde mir wünschen die Werte selbst vorgeben zu können.

Weiters habe ich noch nicht ganz verstanden, wann der Verbraucher "gestartet" wird. Ich hätte erwartet, dass das Modul einen manuellen Start auch entsprechend anzeigt, da die Historienspeicher ja richtig gefüllt werden. Bei mir ist es immer "planned", hier ein Screenshot sowie die "valConsumerMaster"-Daten von gestern als ich den Verbraucher händisch eingeschaltet habe.
Du darfst diesen Dateianhang nicht ansehen.

Code Auswählen Erweitern

tuya_local_bf7f17146809bc4929lnna type=dishwasher power=2000 mode=must on=on off=off asynchron=1 pcurr=cur_power:W:1 etotal=energy:kWh icon=scene_dishwasher mintime=165 swstate=cur_power:[1-9]\d*[.]\d:[0][.]\d auto=solarforecast_auto

Code Auswählen Erweitern

01 => alias => Geschirrspueler
      asynchron => 1
      auto => 0
      autoreading => solarforecast_auto
      avgenergy => 509.89
      avgruntime => 109.20
      currpowerpercent => 0.785
      cycleStarttime => 1702904268
      cycleTime => 107.616666666667
      dspignorecond =>
      dswitch => tuya_local_bf7f17146809bc4929lnna
      dswoffcond =>
      dswoncond =>
      ehodpieces => 16=327.07 17=72.68 18=327.07
      energythreshold =>
      epiecAVG => 1=553.75
      epiecAVG_hours => 1
      epiecHist => 5
      epiecHist_1 => 1=0.44
      epiecHist_10 =>
      epiecHist_1_hours => 1
      epiecHist_2 => 1=741.00 2=54.00 3=6.00
      epiecHist_2_hours => 3
      epiecHist_3 => 1=741.00 2=53.00 3=6.00
      epiecHist_3_hours => 3
      epiecHist_4 => 1=733.00 2=53.00 3=6.00
      epiecHist_4_hours => 3
      epiecHist_5 => 1=697.00 2=47.00
      epiecHist_5_hours => 2
      epiecHist_6 =>
      epiecHist_7 =>
      epiecHist_8 =>
      epiecHist_9 =>
      epiecHour => 2
      epiecStartEtotal => 39388
      epiecStartTime => 1702904268
      epieces => 1=229.45 2=50.99 3=229.45
      hysteresis => 0
      icon => scene_dishwasher
      interruptable => 0
      isConsumptionRecommended => 0
      isIntimeframe => 1
      lastMinutesOn => 0
      lastOnTime => 1702910725
      locktime => 0:0
      mintime => 165
      minutesOn => 45.4166666666667
      mode => must
      name => tuya_local_bf7f17146809bc4929lnna
      noshow => 0
      notafter =>
      notbefore =>
      numberDayStarts => 1
      offcom => off
      offreg => [0][.]\d
      oncom => on
      onoff => on
      onreg => [1-9]\d*[.]\d
      plandelete => regular
      planstate => planned: 2023-12-18 15:11:09 - 2023-12-18 17:56:09
      planswitchoff => 1702918569
      planswitchon => 1702908669
      power => 2000
      powerthreshold => 1
      remainTime => 0
      retotal => energy
      rigncond =>
      rpcurr => cur_power
      rswoffcond =>
      rswoncond =>
      rswstate => cur_power
      spignorecondregex =>
      startTime => 1702908000
      state => on
      swoffcondregex =>
      swoncondregex =>
      type => dishwasher
      uetotal => kWh
      upcurr => W
Weiters: Macht es Sinn dem Modul Verbraucher bekanntzumachen, die halbwegs regelmäßige Verbräuche liefern, wenn ich sie nicht vom Modul steuern lassen will? (Beispielsweise habe ich das Heizprogramm so eingestellt, dass die Wärmepumpe erst startet, wenn an sonnigen Tagen ausreichend PV-Leistung vorhanden sein müsste & sie würde auch rechtzeitig vor Sonnenuntergang fertig sein, wenn es nicht extrem kalt ist oder der WW-Speicher ganz leer war.) Im Winter wird die Anlage da ohnehin die ganzen Sonnenstunden über laufen & in der Übergangszeit sollte um 9 Uhr trotzdem schon halbwegs Energie vom Dach kommen, sodass kaum Strom aus dem Netz gezogen würde. Soll ich sie trotzdem als Verbraucher registrieren oder ist es für die Planung der übrigen Verbraucher egal?


Und eine Frage noch, dann war's das für's erste mal:
Wie gesagt würde ich mich vorwiegend auf das Einplanen des WW-Speichers beschränken, weil ich es für Geschirrspüler und Waschmaschine vmtl. nicht schaffen werde eine Lösung mit ausreichend WAF zu implementieren. Die Voraussetzungen der beiden Geräte sind bei mir wie von @fhainz hier beschrieben:

Im Normalfall hat der Geschirrspüler Spannung und ist ausgeschalten. Nachdem der Geschirrspühler gestartet wurde und er eine Leistung > 10W aufnimmt, schaltet ich die Steckdose mit dem Relais spannungslos und warte auf die Freigabe durch das SolarForecast Modul. Sobald die Freigabe durch das Modul kommt schalte ich das Geschirrspüler Relais wieder ein und das Gerät fängt an zu waschen. Läuft auch prima bisher so.
Mein Problem besteht darin wenn das Gerät ein zweites mal am Tag laufen soll. Hier bekomme ich dann keine Freigabe mehr durch das SolarForecast Modul, obwohl die swoncond zutrifft.
Der entsprechdene consumer ist derzeit so definiert:
Code Auswählen Erweitern

Code Auswählen Erweitern

PV01_FRG_GSP_dummy type=dishwasher power=1900 mode=must mintime=240 icon=scene_dishwasher on=on off=off swstate=state:on:off swoncond=R11_SD02_PV_ANF:value:on notbefore=8 notafter=20 auto=1 pcurr=power:W:3 etotal=cons:kWh

Einzige Möglichkeit eventuell einen ausreichend hohen WAF zu erreichen wäre, dass ich genauso vorgehe.
@fhainz: Kannst Du Dein notify dazu hier teilen? Dann erspare ich mir es neu zu erfinden... ich müsste es dann vmtl. noch mit Uhr-/Tageszeiten ergänzen, den Rest könnte die Definition des Verbrauchers im SolarForecast übernehmen.



EDIT: Noch ein Verbesserungswunsch:
Wenn ich es richtig sehe, werden Sonnenauf- und Untergangszeiten vom DWD übernommen. Wäre es möglich dafür eine andere Quelle zu nutzen (ggf. auch über die Lat/Lon-Angabe im global-Device)? Je nachdem wo die Wetterstation ist, stimmen die Zeiten nicht ganz.

[DS_Starter]

Hallo TheTrumpeter,

du hast viele Themen angeschnitten. Ich will versuchen wenigstens ein paar zu behandeln.
Allgemein schicke ich voraus, dass ich versuche das Wiki Stück für Stück aufzubauen. Das Modul ist sehr umfangreich und es bedarf manchmal einiger Erläuterung.

Seitdem habe ich mich durch die 137 Seiten dieses Themas gewälzt ...

Das wird keinesfalls erwartet weil es hier eher ein Arbeitsthread während der Entwicklungsphase ist.
Es hat sich auch etwas verselbständigt weil Themen dazu kamen die für eine integrative Lösung sprachen.

Begonnen habe ich mit der ForecastSolar-API, weil die ohne Registrierung funktioniert und ich die Konfiguration am Logischsten gefunden habe. Allerdings waren die Prognosedaten für die ersten 2 Tage so falsch/komisch ....

Ja, die API hat auch meine gesteckten Erwartungen bisher nicht erfüllt, wobei sie bei mir inzwischen durch die Autokorrektur einigermaßen brauchbare Werte liefert. Läuft aber als Vergleichsdevice mit, produktiv setze ich die SolCastAPI ein.

Das Problem mit den ggü. dem Standardwert geringer verfügbaren Abfragen konnte ich mittlerweile lösen.

Vielleicht für andere User interessant wie du es gelöst hast?

Eigentlich wollte ich auch die Victron-API ausprobieren, weil die in der CommandRef recht interessant klingt. Nachdem ich mich dort angemeldet habe, musste ich feststellen, dass Voraussetzung für die Nutzung wohl auch ein dazupassender Wechselrichter von denen ist? Stimmt das oder übersehe ich einen "Bypass"?

Die Victron-API ist Nutzern vorbehalten die eine Victron-Anlage haben. Die Anlage (das Victron Cerbo Steuergerät) überträgt Ist-Daten an das VRM-Portal. Ich will nicht ausschließen evtl. mit "Trickserei" auch andere Produkte überreden zu können mit dem VRM zu arbeiten. Das ist aber außerhalb meines Fokus und überlasse es anderen Usern evtl. einen Weg zu finden.

Für die Vorhersagen mittels DWD braucht man wohl eine Wetterstation, die "Rad1h"-Werte liefert, die ich nicht habe. Unklar ist mir, ob man die "Rad1h"-Werte trotzdem braucht, wenn man eine andere API verwendet?

Nein, nur bei Verwendung der DWD "API" braucht man die Rad1h Werte. Die anderen API's liefern eine direkte Ertragsvorhersage aufgrund der übermittelten/eingestellen Angaben. Das DWD Device liefert nur die Rad1h Strahlungswerte, aus denen im Modul die Ertragsvorhersagewerte errechnet werden.

Aus diesem Grund kann man auch getrennte DWD Devices für Starhlung und Wetter angeben. Dadurch ist man frei für die Wettervorhersage eine lokal näher liegende Station auszuwählen, auch wenn sie keine Rad1h Werte liefert.

Was davon verwendet das Modul nun, um den Verbraucher einzuplanen? Die gelernten historischen Werte (bzw. ein Mittel daraus) oder die "Default-Werte"?

Vereinfacht gesagt ... alle verfügbaren bzw. relevante Informationen. Es gibt zum Beipiel auch Verbraucher die liefern keine Verbrauchsmessung. Manches ist eine Näherungsschätzung weil zum Bsp. eine WaMa nach dem Einschalten deutlich mehr verbrauchen wird als in der Zeit danach wenn die Temp nur noch zu halten ist.
Für die Vorplanung ist die Angabe der nominalen Leistung "power" von starker Bedeutung.

Weiters habe ich noch nicht ganz verstanden, wann der Verbraucher "gestartet" wird. Ich hätte erwartet, dass das Modul einen manuellen Start auch entsprechend anzeigt, da die Historienspeicher ja richtig gefüllt werden. Bei mir ist es immer "planned", hier ein Screenshot sowie die "valConsumerMaster"-Daten von gestern als ich den Verbraucher händisch eingeschaltet habe.

Dieses Thema hatten wir in der Vergangenheit schon öfter. Ich möchte nicht nochmal alles aufdröseln. Aber das Modul kennt nicht nur die logischen Zustände gestartet/finished, sondern auch interrupted/continued sowie planned, suspended, noSchedule und weitere. Alle diese Zustände sind zwar für sich genommen "ein/aus", signalisieren aber logisch einen anderen Sachverhalt. Wenn man manuell schalten will, dann die Möglichkeiten des Moduls benutzen, also die Schalter in der Grafik oder die Setter consumerImmediatePlanning und consumerNewPlanning.
Deswegen muß/sollte man sich entscheiden, entweder die Steuerung dem Modul zu überlassen, oder lieber selbst eine Logik aufzubauen und nur die Anzeige zu nutzen. Beides geht. Aber vermischen ist keine gute Vorgehensweise.

Weiters: Macht es Sinn dem Modul Verbraucher bekanntzumachen, die halbwegs regelmäßige Verbräuche liefern, wenn ich sie nicht vom Modul steuern lassen will?
...
Soll ich sie trotzdem als Verbraucher registrieren oder ist es für die Planung der übrigen Verbraucher egal?

Zur Zeit wird die Verbrauchsprognose Stundengenau aus den aufgezeichneten Meterwerten der Vergangenheit abgeleitet. Diese Werte fließen in die Planung mit ein.
Dennoch würde eine Registrierung empfehlen wenn es möglich ist und nicht zu viele Consumerattribute verbraucht. Die Entwicklung des Moduls findet fortwährend statt und vllt. gewinnen diese Daten an Bedeutung.

Die Problematik von fhainz...
Mein Problem besteht darin wenn das Gerät ein zweites mal am Tag laufen soll. Hier bekomme ich dann keine Freigabe mehr durch das SolarForecast Modul, obwohl die swoncond zutrifft.

Inzwischen gibt es den Setter "set ... consumerNewPlanning <Verbrauchernummer>". Damit kann man sich eine abhängige Mehrfachplanung pro Tag aufbauen.

EDIT: Noch ein Verbesserungswunsch:
Wenn ich es richtig sehe, werden Sonnenauf- und Untergangszeiten vom DWD übernommen. Wäre es möglich dafür eine andere Quelle zu nutzen (ggf. auch über die Lat/Lon-Angabe im global-Device)?

Ich hätte keine Idee wie ich daraus auf einfachem Wege den Sonnenauf- bzw untergang bestimmen könnte, bin für Vorschläge aber offen.
Ich schau mir evtl. aus SUNRISE_EL etwas hilfreiches ab.

Grüße,
Heiko

[kask]

Code Auswählen Erweitern

Wenn sich das bewahrheitet, könnte man in einer Schleife gefangen sein wenn der Korr-Faktor aus welchen Gründen auch immer auf 0 gefallen ist. Das kann eigentlich nicht passieren weil pvfc: 0 bzw. pvrl: 0 nicht berücksichtigt werden.
So wird es aber sein.
Leider ist heute Nacht mein Server ins stocken gekommen. Was ich aber gelöst habe, ungeachtet des Problems hier.
Somit ging fhem auch den ganzen Tag nicht und nix ist passiert an logs.

Heute Nachmittag habe ich neu gestartet da war immer noch 0 in der 14ten Stunde. Die Abfrage hatte aber Werte geliefert.
Danach habe ich die fhem.save angepasst mit den "pvCorrectionFactor_15" & "pvCorrectionFactor_15_autocalc" von Stunde 13.
Da diese Werte auch nicht vorhanden waren. Und den percentile auf 1.0 gesetzt.

Danach lieferte die 14te Stunde wieder Werte. Auch in der Grafik.

Es scheint so das wenn fälschlicherweise eine "0.00" in der percentile steht dann ist man gefangen und kommt wohl wirklich nicht mehr automatisch aus dem status.
Das sollte man dann doch lieber verhindern und eine 0.00 nicht zulassen.

[DS_Starter]

Das sollte man dann doch lieber verhindern und eine 0.00 nicht zulassen.

Das ist in der aktuellen V im contrib auch so gemacht.

Wenn du ein "get ... forecastQualities" ausführst, darfst du keine "factor" mit 0 oder 0.00 finden.

[TheTrumpeter]

Das Problem mit den ggü. dem Standardwert geringer verfügbaren Abfragen konnte ich mittlerweile lösen.

Vielleicht für andere User interessant wie du es gelöst hast?

Attribut ctrlSolCastAPImaxReq auf 10 gesetzt und auch ctrlSolCastAPIoptimizeReq wie empfohlen auf 1.

Die Problematik von fhainz...
Mein Problem besteht darin wenn das Gerät ein zweites mal am Tag laufen soll. Hier bekomme ich dann keine Freigabe mehr durch das SolarForecast Modul, obwohl die swoncond zutrifft.

Inzwischen gibt es den Setter "set ... consumerNewPlanning <Verbrauchernummer>". Damit kann man sich eine abhängige Mehrfachplanung pro Tag aufbauen.

Das habe ich verstanden, aber mir ging's um den Schritt davor... die Steckdose muss bei mir immer "ein" sein, damit die Waschmaschine/Geschirrspüler programmiert werden können. Wenn das Programm beginnt, brauchen sie mehr Strom (bzw. bei der Waschmaschine verursacht bereits die Türverriegelung einen ordentlichen Peak, der zum Triggern geeignet wäre).
Das muss ein "notify" erkennen, die Steckdose dann abschalten, das "automatic"-Flag für SolarForecast setzen und ein "consumerNewPlanning" aufrufen, um die weitere Steuerung SolarForecast zu überlassen. (Zusätzlich muss ich dann noch die Einplanungszeit abhängig vom Wochentag setzen, weil meine Frau erwartet, dass ein morgens gestarteter Geschirrspüler auch fertig ist, wenn sie am frühen Nachmittag nach Hause kommt. Und wer weiß was mir noch einfällt).
Daher habe ich mich Anfrage explizit an @fhainz gestellt, weil ich aus seinem Beitrag verstanden hätte, dass er genau so ein "notify" bereits hat.

EDIT: Noch ein Verbesserungswunsch:
Wenn ich es richtig sehe, werden Sonnenauf- und Untergangszeiten vom DWD übernommen. Wäre es möglich dafür eine andere Quelle zu nutzen (ggf. auch über die Lat/Lon-Angabe im global-Device)?

Ich hätte keine Idee wie ich daraus auf einfachem Wege den Sonnenauf- bzw untergang bestimmen könnte, bin für Vorschläge aber offen.
Ich schau mir evtl. aus SUNRISE_EL etwas hilfreiches ab.

Genau das habe ich gemeint, siehe auch https://wiki.fhem.de/wiki/SUNRISE_EL bzw. https://fhem.de/commandref_DE.html#SUNRISE_EL.
Man muss nur die beiden Attribute "latitude" und "longitude" im "global"-Device setzen, dann kann man mittels Perl-Funktionen "sunrise" bzw. "sunset" die Uhrzeit von Sonnenaufgang bzw. -untergang ermitteln. Das verwende ich beispielsweise zum Schalten der Weihnachtsbeleuchtung mittels "at" oder der Bewässerung.

An der Stelle fällt mir noch was ein... mit welchen Koordinaten wird die ForecastSolar-API abgefragt? Vom DWD-Gerät oder aus den Koordinaten vom "global"-Gerät? Falls das DWD-Gerät verwendet würde, wäre das eine mögliche Fehlerquelle für die durchwachsenen Prognosen.


Nochmal eine Verständnisfrage dazu:

Für die Vorplanung ist die Angabe der nominalen Leistung "power" von starker Bedeutung

Versucht das Modul dann diese Leistungüber die ganze Laufzeit einzuplanen? Dann würde beispielsweise für einen Geschirrspüler mit 2100 W nominaler Leistung und 2,5h Laufzeit versucht werden, in 3 aufeinander folgenden Stunden 4,2/4,2/2,1kWh ungenutzte Solarenergie zu finden? Tatsächlich braucht mein Geschirrspüler im Eco-Modus nur in der ersten halben Stunde 1500 W, dann kommt ein kurzer Peak auf die 2100 W. Alles in den 2 übrigen Stunden ist komplett vernachlässigbar, was das Modul in den "epiecHist_x" ja auch richtig gelernt hat.

Ich will das Modul nicht schlecht machen, im Gegenteil, ich finde es schon alleine was die Prognose betrifft sehr gelungen und hilfreich. Damit ich die Consumer vernünftig (d.h. so, dass sie möglichst viel Strom vom Dach verbrauchen) definieren/anlegen kann, möchte ich etwas genauer verstehen wie die Einplanung funktioniert.

[DS_Starter]

Moin,

An der Stelle fällt mir noch was ein... mit welchen Koordinaten wird die ForecastSolar-API abgefragt?

Hier gehen Latitude und Longitude sowie weitere Daten ein. Hat mit DWD nichts zu tun, d.h. der Anbieter verwendet seinerseits DWD und andere Quellen.
Die Abrufe sieht man wenn im ctrlDebug "apiCall" ausgewählt wird.

Man muss nur die beiden Attribute "latitude" und "longitude" im "global"-Device setzen, dann kann man mittels Perl-Funktionen "sunrise" bzw. "sunset" die Uhrzeit von Sonnenaufgang bzw. -untergang ermitteln. Das verwende ich beispielsweise zum Schalten der Weihnachtsbeleuchtung mittels "at" oder der Bewässerung.

Verwende ich seit Jahren ebenso.

Versucht das Modul dann diese Leistung über die ganze Laufzeit einzuplanen?

Nein. Wie ich schon schrieb gehen alle verfügbaren Daten ein. Es werden Energiescheiben auf Stundenbasis gebildet. Wenn vorhanden auf Basis von Messungen, sonst auf Defaults bzw. Näherungswerten.


Die Entwicklung des Moduls ist nicht abgeschlossen. Auch die Consumersteuerung wird weitere Verbesserungen und Features erfahren. Nächste Schritt wird z.B. die Dynamisierung der Planung sein.
Damit ist gemeint, dass die initiale Planung, die i.A. kurz vor Sonnenaufgang vorgenommen wird, auf sich verschiebende Prognosen reagieren wird sofern der Start noch nicht erfolgt ist.
Oder eine konfigurierbare automatische Wiedereinplanungsfunktion ist geplant.
Alle diese Dinge werde ich versuchen nach und nach im Wiki inklusive der Hintergründe und Verfahren zu beschreiben/erläutern. Hier im Forum kann es nur angerissen werden weil es sonst einfach zu viel Zeitressourcen verbraucht immer wieder auf ähnliche Fragen zu antworten die ich für Weiterentwicklungen und Bugfixing benötige. Deswegen bitte etwas Nachsicht an dieser Stelle. 

LG,
Heiko

[DS_Starter]

@all,

im contrib ist die V 1.6.0 upgedated.
Neue Erkenntnisse sind in das Batteriemanagement eingeflossen und der Sonnenauf- bzw. untergang wird entsprechend der latitude/longitude ermittelt sofern im global device gesetzt.
Ansonsten werden diese Daten wie bisher aus dem DWD-Device gezogen.
Die Attribute latitude/longitude werden im Anlagencheck jetzt allgemein gecheckt.

[stefanru]

Hi Heiko,

ich habe gerade mal die Version "76_SolarForecast.pm:v1.5.1-s28265/2023-12-07" vom FHEM Server gezogen und die Funktionalität für FTUI Files getstet.
Habe meine gelöscht und dann "get SolCast ftuiFrameFiles" ausgeführt.
Die js Files wurden kopiert und ein css "ftui_smaportalspg.css"
Das "ftui_forecast.css" aber nicht.

Ich denke das Problem wurde hier schon besprochen.
Ist das schon gefixed aber noch nicht im CVS?

Danke und Gruß,
Stefan

[DS_Starter]

Hallo Stefan,

die Version 1.6.0 ist noch im contrib. Das ist einiges reingeflossen.
Wenn du magst, holst du die aus meinem contrib und probierst es. Sollte alles klappen.
Wird aber auch nicht mehr lange dauern bis ich die V einchecke.

[DS_Starter]

@all,
in der V 1.6.0 (update im contrib) gibt es nun auch ein Reading Battery_ChargeRequest bei aktivierten SoC Management.
Wenn der SoC unter den Optimum SoC gefallen sein sollte, signalisiert dieses Reading mit '1' dass eine Zwangsladung, ggf. mit Netzstrom, vorgenommen wird/werden sollte.
Victron z.B. wird die Batterie mit Netzstrom beladen, wenn der Soll-SoC 5% höher als der aktuelle SoC der Batterie ist. Die Batterie lädt dann mit maximalen Ladestrom aus dem Netz.

Das Reading kann zum Beispiel dazu verwendet werden, den max. Ladestrom der Batterie auf einen "genehmen" Wert zu begrenzen solange der Wert '1' ist, anderenfalls setzt man den möglichen Ladestrom wieder auf Maximum.
Die Berechnung des optimimalen SoC habe ich noch dahingehend angepasst, dass eine evtl. nötige Erhöhung des SoC immer erst nach Sonnenuntergang aktiviert wird damit eine leichte Zuladung der Batterie über den Tag (auch bei schlechtem Wetter) zunächst realisiert werden kann.
Das verhindert, dass die Batterie durch eine Erhöhung des Soll-SoC zu Beginn des Tages im worst case mit Netzstrom auf den Sollwert gebracht wird, wobei die +5% über den Tag solar in die Batterie hätten geladen werden können.

[DS_Starter]

Hallo zusammen,

die V 1.6.0 ist soeben eingecheckt und befindet sich morgen früh im Update.
Sofern keine Fixes nötig werden sollten, wovon ich ausgehe, werde ich mich dem weiteren Aufbau des Wikis zuwenden wenn wieder etwas Zeit dafür übrig ist.
Insbesondere die Consumersteuerung ist da sicherlich von Interresse.

Doch zunächst wünsche ich allen Solar Begeisterten ein paar schöne und vor allem sonnige Feiertage, Gesundheit und persönliches Glück.

Heiko

[jophb]

Hi zusammen, ich habe meine FHEM-Installation auf einen anderen Rechner umgezogen. Seitdem läuft das SolarForecast-Modul nicht mehr.
Aus meiner config wird die ganze Device-Definition rausgeworfen.
Wenn ich in der Kommandozeile

Code Auswählen Erweitern

define Forecast SolarForecast eingebe, kommt die Fehlermeldung

Cannot load module SolarForecast

.
Habe mir das Modul nochmals über wget geholt, die Rechte passen auch. In meiner Erinnerung waren im WIKI noch als Vorbereitung Perl-Module zu installieren. Fehlt der Abschnitt oder lässt mich da mein Gedächtnis im Stich? Oder gibt es sonst noch etwas zu beachten was ich nicht auf dem Schirm habe?