76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[tobi01001]

Jede kWh die nicht ins Netz eingespeist oder vom Netz bezogen wurde, ist PV (wenn keine anderen Erzeuger).
Überschuss ist es nicht, wenn ich die Energie meist ja so oder so brauche. Aber es ist eben auf die Photovoltaik optmiert und vermeidet in meinem Fall zumindest, dass der Strom "verschenkt wird" oder unnötigerweise vom Netz bezogen werden muss. Gespart ist allerdings nur jede gar nicht erst verbrauchte kWh.

Ich lasse mir das für gewisse Verbraucher anzeigen:
Du darfst diesen Dateianhang nicht ansehen.
Das Verhältnis hat sich allerdings mit einem Jahr Tibber etwas verschiben, da nicht mehr nur nach PV, sondern auch nach Preis optimiert mird.

@Heiko: Wäre vll ein interessantes Feature, da die Daten eh im Modul vorliegen...

[Parallix]

...
in meinem (vielleicht speziellen) Fall:

- EV ist 'Stadtauto' (täglich im Einsatz aber wenig Km [7500/a],
- nur ausreichend großer Akku
- i.d.R. ab 14:30 Uhr ladebereit zuhause

Gelang es ganz gut von Ende Februar bis Ende Oktober mehr als 80% der benötigten Ladeleistung aus der eigenen PV zu nutzen
Trotz WP/WM/GSP/Warmwasser...
In den Wintermonaten dreht sich das Verhältnis dann um, Dezember Januar tendiert der PV-Anteil gen 0%

Auf Basis bisheriger Erfahrungen, insb. auch in Bezug auf das Nutzungsverhalten in meinem Haushalt, gehe ich davon aus, dass auch in meinem Fall das Laden meines EV's in drei von vier Jahreszeiten (also Frühling bis Herbst) praktisch ausschließlich mit PV-generierter Leistung möglich ist. In der letzten Jahreszeit wird man, z.B. bei über mehrere Tage mit Schnee bedeckten Solarmodulen, um einen gewissen Zukauf von Energie aus dem Grid wahrscheinlich nicht herumkommen.

Zum bisherigen Erfolg in Bezug auf Energieautarkie trägt SF in erheblichem Maße bei! Durch die angedachten Erweiterungen, wie z.B. der eines erweiterten Prognosehorizonts, insb. aber durch die Bereitstellung der Prognosedaten und entsprechend daraus abgeleiteter Daten, wird SF aus meiner Sicht immer wichtiger, um eine optimierte Ladeplanung (teilweise außerhalb von SF) vorzunehmen und die Ladung letztlich (vollständig außerhalb von SF) durchzuführen zu können.

PS: Im vorangegangenen Winter war ich nicht nur in der Lage weit über 95% der insg. von meinem Haushalt benötigte Energie über meine PV-Anlage zu liefern, sondern auch in jedem Monat noch eine Netzeinspeisung vorzunehmen. Mit EV werde ich wahrscheinlich nicht mehr auf die 95% kommen, rechne aber mit ca. 80%.

Edit: In meiner Signatur sind alle wesentlichen Details zu meiner PV-Anlage vermerkt.

[grappa24]

Mal ein paar Zahlen von mir; ist zwar "nur" ein PHEV, aber passt ideal zu meiner PV-Anlage (mit BEV sähe das sicher anders aus).

Seit Oktober 2023: 11 kWp Anlage mit 7,7 kWh Speicher
Seit März 2024: PHEV mit 12,8 kWh, 15.000 km/Jahr, 77 % geladen mit Sonnenanteil (1,9 MWh), zusätzlich 770 L Benzin

Produktion PV:      Direktverbrauch:      PHEV:                  In Batterie:            Einspeisung:      Eigenverbr.erh. durch PHEV: 2024 9,19 MWh    2024 1,9 MWh        2024 0,83 MWh    2024 1,58 MWh    2024 4,88 MWh  2024  9% 2025 8,30 MWh    2025 1,4 MWh        2025 0,79 MWh    2025 1,09 MWh    2025 5,02 MWh  2025 10%

[Prof. Dr. Peter Henning]

Mit EV werde ich wahrscheinlich nicht mehr auf die 95% kommen, rechne aber mit ca. 80%.

Edit: Habe ich nicht ganz richtig gelesen.

2025 8,30 MWh     2025 1,4 MWh        2025 0,79 MWh    2025 1,09 MWh     2025 5,02 MWh  2025 10%

Erst einmal gut, dass hier jemand in MWh rechnet. Viele hier im Forum stehen ja auf Wh, weil die Zahlen dann so schön gruselig groß werden.
Zweitens aber: Die Angabe von "In Batterie" ist nicht sehr sinnvoll, weil die Speicherverluste immer so um die 9-10% betragen. Also müsste man eigentlich unterscheiden "Solarenergie direkt" und "Solarenergie via Speicher", ferner die Speicherverluste (als "Heizung im Technikraum") separat aufführen.

LG

pah

[Max_Meyer]

Zum bisherigen Erfolg in Bezug auf Energieautarkie trägt SF in erheblichem Maße bei!

Hallo Parallix,
Ja, da können wir nur das eine oder andere Mal zu Heiko DANKESCHÖN! sagen.

PS: Im vorangegangenen Winter war ich nicht nur in der Lage weit über 95% der insg. von meinem Haushalt benötigte Energie über meine PV-Anlage zu liefern, sondern auch in jedem Monat noch eine Netzeinspeisung vorzunehmen. Mit EV werde ich wahrscheinlich nicht mehr auf die 95% kommen, rechne aber mit ca. 80%.

Der Unterschied ist klar die Heizung! Die WP ist ein zum BEV konkurrierenden Verbraucher, welcher, die in der Übergangszeit kargen PV-Überschüsse, wegfrißt. Dieser Bedarf lässt sich auch nicht auf den kommenden Tag(e)/Stunden shiften. Das sind zwischen 3.000 und 4.000 kWh jährlich (3-4 MW). Die nur in der Heizsaison anfallen( dann wenn es nass kalt neblig ist also wenig Sonne ist) Anlagen und Anforderungen sind individuell und oftmals nicht direkt über einen Parameter vergleichbar.

Zweitens aber: Die Angabe von "In Batterie" ist nicht sehr sinnvoll, weil die Speicherverluste immer so um die 9-10% betragen. Also müsste man eigentlich unterscheiden "Solarenergie direkt" und "Solarenergie via Speicher", ferner die Speicherverluste (als "Heizung im Technikraum") separat aufführen.

Hallo Pah, Hallo Grappa24
Das ist auch meine Erfahrung, nur finde ich das die ca.10% noch sehr optimistisch sind, ich arbeite zuhause seit mehr als 10Jahren mit Hausspeichern und messe die von dem BatWR aufgenommene und die von diesem abgegebene Energie, BatOut geteilt durch BatIn ergibt bei mir den Wirkungsgrad und der so ermittelte Wandlungverlust ist etwa doppelt so groß wie die o.g. Annahme. Aber vielleicht rechne ich ja falsch?
Fakt ist bei einem EV Laden tritt ja dann nochmal ein Wandlunsverlust auf.
PS: intern rechne ich immer mit kWh - vereinfacht die Kommunikation mit dem EVU
Gruß Gerd

[grappa24]

Die Wandlungsverluste meines BYD HVS 7.7 liegen aktuell bei 7,4 %

Code Auswählen Erweitern

(User_Energy_Bat_in - User_Energy_Bat_out) / User_Energy_Bat_in

[Max_Meyer]

Die Wandlungsverluste meines BYD HVS 7.7 liegen aktuell bei 7,4 %

Code Auswählen Erweitern

(User_Energy_Bat_in - User_Energy_Bat_out) / User_Energy_Bat_in

Hallo grappa24,
Bei mir sind das ca 20%, ich messe hinter dem SMA-WR. Batterie ist einmal eine LG und zum anderen auch eine BYD-HVS 5.2
Beide Werte sind in der gleichen Größenordnung. Die noch ältere Bleigelbatterie hat andere Werte und dient hier nicht als Vergleichsbasis.
Gruß
Gruß Gerd

[Parallix]

Aus meiner Regelung heraus wird das SF-Attribut "loadAbort" zyklisch via "set ... attrKeyVal ..." neu gesetzt, eigentlich nur "MinPwr". Dieses zyklische Setzen führt zu einer erheblichen Systemlast, die auch durch Einschalten des "Silent Mode" nicht reduziert werden kann.

Irgendwo hier im Thread wurde - wenn ich mich recht erinnere - eine Lösung vorgeschlagen, wie ein Attribut ressourcenschonend umgesetzt werden kann. Diese Lösung finde ich aber leider nicht wieder. Der Weg über die Attribut-Hashes wird's ja wohl nicht gewesen sein, oder? Kann mir jemand auf die Sprünge helfen?

PS: Die BYD-eigene Messung von E_BAT_IN und E_BAT_OUT ist meines Erachtens nur sehr eingeschränkt zu gebrauchen. Insb. auch, weil die BYDs kleine Ladeströme überhaupt nicht und größere nicht besonders genau messen (können).

Edit: Soeben fällt mir auf, dass in der SF-Visualisierung der SOCs und Energieflüsse bei zwei "Battery Devices", sofern diese zusammengefasst als ein Device dargestellt werden, aufgrund der Rundung des Gesamt-SOC's eine Leistung > 0 W in einen angeblich zu 100% geladenen Speicher dargestellt wird. Das ist natürlich sehr verwirrend.

[DS_Starter]

Guten Abend zusammen,

@Parallix,

Aus meiner Regelung heraus wird das SF-Attribut "loadAbort" zyklisch via "set ... attrKeyVal ..." neu gesetzt, eigentlich nur "MinPwr". Dieses zyklische Setzen führt zu einer erheblichen Systemlast, die auch durch Einschalten des "Silent Mode" nicht reduziert werden kann.

Über welche Logik setzt du attrKeyVal? Das gesetzte Attribut wird ja auf Filesystemebene bzw. configDB gespeichert. Man sollte dafür Sorge tragen, dass nur dann ein attrKeyVal ausgeführt wird wenn wirklich eine Änderung eines Parameters erfolgen soll und z.B. nicht einfach setzen auch wenn der Param immer gleich bleibt.

Dazu kann man z.B. ein (verstecktes) Hilfsreading nutzen:

Code Auswählen Erweitern

my $name = shift;
my $hash = $defs{$name};

if (...) {
   # Atribut soll gesetzt werden auf Wert 60
   if (ReadingsNum ($name, '.hilfsreading', 0) != 60) {
       readingsSingleUpdate ($hash, '.hilfsreading', 60, 0);
       fhem ("set $name attrKeyVal ....");
   }
}

Dadurch wird der Attributwert 60 nur dann per attrKeyVal gesichert wenn 60 nicht gesetzt ist. Man kann das zusammengesetzte Attribut auch per AttrVal direkt lesen, muß die Bestandteile dann aber noch parsen.
Wie das geht kann ich dir/euch auch noch zeigen wenn gewünscht.

LG,
Heiko

[Parallix]

Guten Abend zusammen,

@Parallix,

Aus meiner Regelung heraus wird das SF-Attribut "loadAbort" zyklisch via "set ... attrKeyVal ..." neu gesetzt, eigentlich nur "MinPwr". Dieses zyklische Setzen führt zu einer erheblichen Systemlast, die auch durch Einschalten des "Silent Mode" nicht reduziert werden kann.

Über welche Logik setzt du attrKeyVal? Das gesetzte Attribut wird ja auf Filesystemebene gespeichert. Man sollte dafür Sorge tragen, dass nur dann ein attrKeyVal ausgeführt wird wenn wirklich eine Änderung eines Parameters erfolgen soll und z.B. nicht einfach setzen auch wenn der Param immer gleich bleibt.

Nutze das Attribut MinPwr wie vorgesehen im Kontext "Ladeschlussleistung".

Darüber hinaus nutze ich es auch, um auf einfache Weise meinen BAT-Controller mit der Info zu versorgen, wie lange er noch bis Tagesende mit > MinPwr laden kann. Die andere Logik (siehe wenige Seiten zuvor) ist ja noch nicht da. Bis dahin muss der Attributwert für den Attributteil "MinPwr" von meinem Bat-Controller permanent an die aktuelle Situation (aktueller SOC) angepasst werden; das natürlich nur dann, wenn es ein vom alten Wert abweichendes MinPwr gibt. Bei Readings führt eine solche Anpassung von Werten zu keinem Problem in Bezug auf die Systembelastung, wohl aber bei Attributen. Über die Attribut-Hashes könnte ich das Performance-Problem wahrscheinlich lösen, vermute aber, dass das keine saubere Lösung ist und bin daher hier auf der Suche.

[DS_Starter]

Das Setzen eines Attributwertes ist auch nur eine Hash-Aktion. Allerdings, und das ist vermutlich der Grund, wird das geänderte Attribut jedesmal im Filesystem / configDB persistiert. Deswegen der Hinweis, nicht das z.B. alle 2 Sek. ein Speichervorgang angetriggert wird. Vllt. sogar öfter mit einem notify o.ä.

[DS_Starter]

@Parallix, @all,

ich habe eine Prototyplösung zu dem ab #3840 diskutierten Thema gebaut und als V 1.58.0 in mein contrib geladen.
Die optimale (bzw. Mindest-) Ladeleistung für die aktuelle Stunde wird im Reading Battery_ChargeOptTargetPower_XX für jede Batterie getrennt vorgeschlagen. Dieser Wert ändert sich dynamisch und liefert die (optimale) Mindestladeleistung mit der bei Eintritt der zugrunde gelegten Vorhersagen am Ende des Tages der maximal mögliche SoC (wahrscheinlich) erreicht wird.

Mit ctrlDebug 'batteryManagement' sieht man die prognostizierte Entwicklung.

Code Auswählen Erweitern

2025.08.30 12:02:15.219 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 13, Start SoC: 17991 Wh, Surplus: 3572 Wh, OptTargetPower: 3572 W
2025.08.30 12:02:15.219 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 14, Start SoC: 19678 Wh, Surplus: 1874 Wh, OptTargetPower: 1748 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 15, Start SoC: 21426 Wh, Surplus: 4048 Wh, OptTargetPower: 4048 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 16, Start SoC: 25960 Wh, Surplus: 2932 Wh, OptTargetPower: 614 W
2025.08.30 12:02:15.220 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 17, Start SoC: 26574 Wh, Surplus: 3441 Wh, OptTargetPower: 614 W
2025.08.30 12:02:15.221 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 18, Start SoC: 28416 Wh, Surplus: 1441 Wh, OptTargetPower: 0 W
2025.08.30 12:02:15.221 1: SolCast DEBUG> - Bat 01 OptTargetPower - hod: 19, Start SoC: 28416 Wh, Surplus: 82 Wh, OptTargetPower: 0 W

Wenn alles funktioniert, würde ich alle zukünftigen optTarget Zielwerte in nextHours integrieren. Dadurch können sie neben dem geannten Reading für eigene Steuerungen abgerufen und verwendet werden.

LG,
Heiko