76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

fragend
Martin
[EDIT]
so geht es nicht - hab ausprobiert
[/EDIT]

Ja da wird strikt nach DD HH abgeprüft 
Nix anderes geht da (sicherheitshalber)

[MartinD]

Wenn das nicht wirkt - nehm dann mal den ganzen Tag 31

Code Auswählen Erweitern

set <name> reset pvHistory 31


So habe ich gemacht und der Tag ist pfutsch.

Danke!

[All-Ex]

Hi zusammen,

aktuell liegt Schnee auf meinen Solarzellen, daher gibt es 0 Watt Leistung. Wie wäre es, wenn die Vorhersage Schnee berücksichtigt?

Das angehängte Python Skript gibt mir aus dem Icon D2 Modell die Schneehöhe der nächsten 48 Std. für einen Standort zurück.

Da wir die Neigung der Solarzellen kennen, können wir ein paar vereinfachte Annahmen treffen, z.B.:
<15°: Schnee bleibt liegen => 0% freie Modulfläche
15-30°: Die Hälfte rutscht ab => 50% freie Modulfläche
30-45°: Das meiste rutscht ab => 75% freie Modulfläche
>45°: Alles rutscht ab => 100% freie Modulfläche
(Teilverschattung führt manchmal zu null Leistung, aber bei modernen Modulen wird das auch etwas ausgeglichen. Das könnte über einen Faktor, den man pro String angibt, modelliert werden.)

Zusätzlich könnten wir die Leistungsminderung je nach Schneehöhe abschätzen, z.B.
<=1 cm: 90% Leistung
2 cm: 70% Leistung
3 cm: 50% Leistung
4 cm: 20% Leistung
>=5 cm: 0% Leistung

Macht also z.B. bei 3 cm Schneehöhe und 35° Neigung: 50% Leistung * 75% freie Modulfläche = Es werden 37,5% der Leistung ohne Schnee erreicht.

Beides könnte per KI erlernt werden. Die KI könnte auch lernen, wie viel Lichteinstrahlung (ist bekannt) dazu führt, dass der Schnee auf der Südseite schneller schmilzt als im Norden.
Allerdings liegt an den meisten Orten sehr selten Schnee, so dass die KI wenig Daten zum Lernen hat.

Code Auswählen Erweitern

import requests
import pandas as pd

latitude = 51.20
longitude = 8.52

url = (
    "https://api.open-meteo.com/v1/forecast"
    f"?latitude={latitude}"
    f"&longitude={longitude}"
    "&hourly=snow_depth,snowfall"
    "&models=icon_d2"
    "&forecast_days=2"
    "&timezone=Europe/Berlin"
)

response = requests.get(url)

print("Status:", response.status_code)

data = response.json()

if "hourly" not in data:
    print("Fehlerantwort:")
    print(data)
    exit()

df = pd.DataFrame({
    "time": data["hourly"]["time"],
    "snow_depth_m": data["hourly"]["snow_depth"],
    "snowfall_cm": data["hourly"]["snowfall"]
})

print(df)

Ausgabe:

Code Auswählen Erweitern

                time   snow_depth_m  snowfall_cm
0   2026-02-19T00:00           0.16         0.00
1   2026-02-19T01:00           0.16         0.00
2   2026-02-19T02:00           0.16         0.00
3   2026-02-19T03:00           0.16         0.00
4   2026-02-19T04:00           0.16         0.00
5   2026-02-19T05:00           0.16         0.00
6   2026-02-19T06:00           0.16         0.49
7   2026-02-19T07:00           0.16         0.98
8   2026-02-19T08:00           0.17         0.98
9   2026-02-19T09:00           0.19         1.54
10  2026-02-19T10:00           0.21         1.12
11  2026-02-19T11:00           0.22         0.84
12  2026-02-19T12:00           0.23         0.84
13  2026-02-19T13:00           0.23         0.84
14  2026-02-19T14:00           0.23         0.42
15  2026-02-19T15:00           0.24         0.21
16  2026-02-19T16:00           0.23         0.00
17  2026-02-19T17:00           0.23         0.00
18  2026-02-19T18:00           0.23         0.00
19  2026-02-19T19:00           0.23         0.00
20  2026-02-19T20:00           0.22         0.00
21  2026-02-19T21:00           0.22         0.00
22  2026-02-19T22:00           0.22         0.00
23  2026-02-19T23:00           0.22         0.00
24  2026-02-20T00:00           0.22         0.00
25  2026-02-20T01:00           0.22         0.00
26  2026-02-20T02:00           0.22         0.00
27  2026-02-20T03:00           0.22         0.00
28  2026-02-20T04:00           0.22         0.00
29  2026-02-20T05:00           0.22         0.00
30  2026-02-20T06:00           0.22         0.00
31  2026-02-20T07:00           0.22         0.00
32  2026-02-20T08:00           0.22         0.00
33  2026-02-20T09:00           0.22         0.00
34  2026-02-20T10:00           0.21         0.00
35  2026-02-20T11:00           0.21         0.00
36  2026-02-20T12:00           0.21         0.00
37  2026-02-20T13:00           0.20         0.00
38  2026-02-20T14:00           0.20         0.00
39  2026-02-20T15:00           0.20         0.00
40  2026-02-20T16:00           0.20         0.00
41  2026-02-20T17:00           0.19         0.00
42  2026-02-20T18:00           0.19         0.00
43  2026-02-20T19:00           0.19         0.00
44  2026-02-20T20:00           0.19         0.00
45  2026-02-20T21:00           0.19         0.07
46  2026-02-20T22:00           0.19         0.28
47  2026-02-20T23:00           0.20         0.77


[300P]

Ja - Schneebelag war schon mehrfach Thema bis hin zu "Schneesensoren".
Soweit ich es kenne "möchte" Heiko irgendwann die PV-Prognose evtl. auf AI:FANN umstellen. Solange wird er sicher nicht nochmalig an das Thema "Schnee-Einfluss" gehen wollen. Da wird er sicher dann nach dem Urlaub evtl. was zu sagen.

Aktuell wird n.m.W. die EV-Fraktion und deren Wünsche erst einmal einbinden.

PS:
Bei mir gibt es auch Schnee - bei starker Sonne am ersten Tag mit 4-6 Stunden Sonne weg - bei Frost und viel Wolken bleibt er tagelang bei 48 Grad komplett liegen.....das nenne ich "Shit happens" - oder ich nehme meine langen Alu-Auszieh-Besen (7m länge) und fege den Schnee am 1 Tag sofort wieder runter       

Wirklich ==>>> ich habe den 7 Meter langen Wasser-Besen sowieso zum Reinigen im Herbst / Frühjahr als B-Ware mal bei eBay geschossen!

[300P]

Wenn das nicht wirkt - nehm dann mal den ganzen Tag 31

Code Auswählen Erweitern

set <name> reset pvHistory 31


So habe ich gemacht und der Tag ist pfutsch.

Danke!

Falls du dich noch erinnerst - war da irgendwas am 31.1. mit deinem FHEM-Rechner - Absturz / Stromausfall / Rechnerproblem etc. ??

[peterboeckmann]

Hallo 300P,

meine langen Alu-Auszieh-Besen

Dafür gibt es auch einen Schneeschiebe-Aufsatz. Damit arbeitet es sich wesentlich leichter. 🙂

Viele Grüße,
Peter

[300P]

Ja- der ist bei meiner Version dabei gewesen 😉

[MartinD]

Wenn das nicht wirkt - nehm dann mal den ganzen Tag 31

Code Auswählen Erweitern

set <name> reset pvHistory 31


So habe ich gemacht und der Tag ist pfutsch.

Danke!

Falls du dich noch erinnerst - war da irgendwas am 31.1. mit deinem FHEM-Rechner - Absturz / Stromausfall / Rechnerproblem etc. ??

Hallo 300p,
nee, nichts desgleichen oder Ähnlichen.
Das ganze ist mir erst nach FHEM-update aufgefallen.

Gruß
Martin

[Parallix]

@Parallix, @all,

ConsumerXX->mode kann nun auch den Wert 'mustNot' erhalten. Dadurch kann ähnlich wie bei type 'noSchedule' die Planung verhindert werden.

Hier (m)ein erstes Zwischenfazit:
Das neue Feature funktioniert bestimmungsgemäß und perfekt!

Damit wurde in SF eine wichtige Grundlage zur Berücksichtigung von BEVs geschaffen.

Sehr gut ist auch, dass via consForecastLastDays=0 jetzt auch eine reine Vorwärtsplanung durchgeführt werden kann, bei der historische Daten keine Rolle mehr spielen.

Zur Frage, was noch verbessert werden könnte, muss zunächst festgehalten werden, dass Heiko mit SF schon eine sehr hohes Niveau erreicht hat. Wie auch in der Wissenschaft. sollen wir aber aber weiterhin offen für nützliche Erweiterungen und Verbesserungen sein.

Aus meiner Sicht wäre es insb. in Hinblick BEVs hilfreich, wenn SF den Verbrauch ausgewiesener Consumer (hier ein an einer Wallbox hängendes BEV) nicht grundsätzlich nach vorne propagieren würde. Ausgewiesene Consumer sollten also trotz consForecastLastDays > 0 verbrauchstechnisch nur dann in der Zeitleiste in einem in der Zukunft liegenden Zeitraum auftauchen, wenn

• es sich um "can"-Consumer handelt und
• eine "kostenfreie" Ladung mittels zu erwartendem PV-Überschuss möglich ist.

oder

• es sich um "must"-Consumer handelt und
• eine ggf. "kostenpflichtige" Ladung erforderlich ist, um das BEV bis zu einer Zielzeit in den Zustand "aufgeladen" zu bringen.

Hallo EV-Nutzer,
...

Anmerkung: In vielen Fallen ist es nicht möglich, den SOC eines BEVs aus FHEM heraus abzufragen. Was aber praktisch immer festgestellt werden kann ist, ob das BEV auf einen im Fahrzeug eingestellten Ziel-SOC gebracht worden ist. In diesem Fall erfolgt nämlich ein seitens des Consumers (hier BEV) initiiertes Pausieren des Ladevorgangs, welches FHEM via Wallbox signalisiert wird.

Wenigstens ein Datum fehlt noch in Kontext Deiner BEV-Reading-Liste: Ab 2024 installierte Wallboxen müssen die §14a-Forderung "dimmbar" erfüllen. Es sollte also noch ein Reading geben, mit dem die aktuelle oder zu erwartendene Dimmaufforderung des Netzbetreibers abgefragt werden kann. Da sich ein Dimmbefehl bei Verwendung eines EMS sich nicht zwingend auf ein Verbraucher bezieht, muss und sollte das Reading nicht unmittelbar mit einem Verbraucher assoziiert sein!

[Parallix]

Vor einiger Zeit hatte ich hier im Forum berichtet, dass nicht hohe SOC-Stände an sich ein Problem darstellen. Vielmehr sind es die bei ungünstigem Ladevorgang damit häufig einhergehenden hohen Zellspannungen (> 3500 mV bei LiFePO4). Vor diesem Hintergrund habe ich längere Zeit mit der Programmierung eines auf SF aufsetzenden Ladecontroller beschäftigt, der dafür sorgt, dass auch bei hohen SOC-Ständen keine Zellspannung über einem konfigurierbaren Maximalwert (bei mir mit meinem LiFePO4-System auf 3500 mV eingestellt) liegt. Dies geht natürlich nur bei BAT-Sytemen, auf denen eine Abfrage der einzelnen Zellspannungen möglich ist, was aber gar nicht so selten der Fall ist.

Seit vielen Wochen betreibe ich nun diesen Controller, möchte kurz über meine Erfahrungen damit berichten und daraus ggf. ableitbare zukünftige SF-Features  mit Euch gemeinsam entwickeln. Hier meine Feststellungen, die sich durch den Betrieb des o.g. Controllers ergeben:

• Der SOC des Systems erreicht typischerweise nicht mehr die 100%. In aller Regel werden 99,2% nicht mehr überschritten.
• Trotz Nichterreichen der 100%-Marke findet ein Balancing statt, was aber aufgrund sehr gut angeglichener Zellspannungen aber seltener der Fall ist.
• Bei den o.g. 99,2% erreichen alle Zellen nach Beendigung der Ladung eine Ruhespannung von rund 3350 mV.
• Beim Entladen mehrerer so geladener BAT-Systeme gleicher Kapazität driftet deren SOC nur wening auseinander. Auch konnte ich bislang keinerlei SOC-Sprünge beobachten.
• Da ein SOC von 100% nicht erreicht wird, greift die z.B. bei BYD im BMS eingebaute Deaktivierung der Ladung bis zum Unterschreiten der 96%-Schwelle glücklicherweise nicht mehr. Erfolgen Energieentnahmen, so können diese unmittelbar danach auch wieder durch Ladung ausgeglichen werden.
  

Eine erste Ableitung bzgl. SF ergibt sich unmittelbar: SF sollte eine erfolgte ,,Wartung" auch bei bei SOC-Ständen unterhalb eines SOC von 100% erkennen oder aber extern signalisiert bekommen können.

Edit: Zur Illustration unten zwei Bilder vom Ladezustand meiner zwei BAT-Systeme, jeweils bei einem SOC von 99,1%

[300P]

Juhuhuhuhu

Endlich gab es am 25.02 mal wieder mehr Sonnenenergie für den Tag als meine "Hütte" zusammen mit der im letzten Jahr eingebauten WP verbraucht. Der Speicher reichte bis heute Morgen....
 
Der Sommer kann weiter so kommen....  

Edit / PS:
...Vorhersage war prima ..:
PV -14 % (übertroffen >>"mehr" produziert - Nebel schneller weg )
CO -4 % (überschritten >> "mehr" verbraucht)

[DS_Starter]

Morgen zusammen,

bin wieder zurück und lese mich langsam wieder ein.
Die wichtigste und erfreulichste Nachricht für mich ... der Schnee ist weg und die Sonne lacht. 

@All-Ex,

aktuell liegt Schnee auf meinen Solarzellen, daher gibt es 0 Watt Leistung. Wie wäre es, wenn die Vorhersage Schnee berücksichtigt?

Wie 300P bereits erwähnte, hatten wir dieses Thema bereits öfter. Eine Problematik ist, dass die OpenMeteo diese Schneewerte liefert (kenne ich), aber das DWD-Device in FHEM dies hingegen nicht ermölicht. Es liest MOSMIX S/L aus, der OpenData Server liefert Schneewerte aber über MOSMIX-SNOW aus was nicht eingebunden ist. Die API Forecast.Solar liefert diese Werte nach einem ersten Check ebenfalls nicht.
Es gibt also eine Disharmonie in den API's die berücksichtigt werden müssten. Darüber hinaus müsste die herrkömmliche Vorhersage ohne KI drastisch erweitert werden um ähnlich der Bewölkung von Sonnenstand und Schneebelag abhängige Korrekturfaktortabellen erstellt und verarbeitet werden. Ein Blick in "get ... pvCircular" lässt erahnen welcher Aufwand dahinter steckt. In diesen Korrekturen müsste auch die Zellenneigung mit der empirischen "Abrutschkorrektur" und Leistungsminderung durch Schneehöhe auf den Zellen berücksichtigt werden.
Alles in Allem ist das zuviel Aufwand.

Allerdings, 300P hat es auch bereits erwähnt, habe ich vor auch die Solarprognose auf die AI::FANN KI umbubauen. Damit ergäbe sich m.M. nach durchaus die Möglichkeit die Schnee-Daten mit einfließen zu lassen sofern man eine liefernde API ausgewählt hat. Bei den anderen API's werden diese Daten dann schlichtweg als "0" vorgegeben.


@Parallix,

Das neue Feature funktioniert bestimmungsgemäß und perfekt!

Damit wurde in SF eine wichtige Grundlage zur Berücksichtigung von BEVs geschaffen.

Sehr gut ist auch, dass via consForecastLastDays=0 jetzt auch eine reine Vorwärtsplanung durchgeführt werden kann, bei der historische Daten keine Rolle mehr spielen.

Das freut mich. Deine weiteren Anmerkungen/Vorschläge muß ich mir erst noch genauer anschauen und bewerten.

@MartinD,
diese Problematik wurde vielleicht mal mit einer contrib-Version "eingeschleppt". Ich kann es nicht sagen, denn die Schlüssel werden stringent erstellt. Dennoch wird in der kommenden Version ein einfaches Ausfrufen von "get ... pvHistory" solche ungültigen Tages- und Stundenschlüssel automatisch entfernen.

LG,
Heiko
 

 

[cs-online]

Hallo zusammen,

wie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ? Meist passt das ja so inetwa, d.h. die generelle Funktion ist schon da, aber manchmal bekomme ich solche etwas merkwürdigen Angaben. Und noch eine Frage: Was ist denn die CO-Abweichung ?

Grüße

Christian

[DS_Starter]

Hallo cs-online,

wie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ?

Das ist eine Frage der Perspektive. Es wurde weniger vorhergesagt als tatsächlich produziert, also negativ (nach unten) verschätzt. Das ist eine Ansichtssache und kann mit

Code Auswählen Erweitern

plantControl->genPVdeviation=...:reverse

umgestellt werden.

Und noch eine Frage: Was ist denn die CO-Abweichung ?

Das ist die Abweichung der Verbrauchsprognose, also der Prognose des Energieverbrauchs im Haushalt.

LG,
Heiko

[DS_Starter]

@Parallix,

Anmerkung: In vielen Fallen ist es nicht möglich, den SOC eines BEVs aus FHEM heraus abzufragen. Was aber praktisch immer festgestellt werden kann ist, ob das BEV auf einen im Fahrzeug eingestellten Ziel-SOC gebracht worden ist. In diesem Fall erfolgt nämlich ein seitens des Consumers (hier BEV) initiiertes Pausieren des Ladevorgangs, welches FHEM via Wallbox signalisiert wird.

So wie ich bisher gelesen habe, ist es in den dargestellten Fällen kein Problem den SoC des BEV auszulesen.
Für eine Betrachtung der Wahrscheinlichkeit eines (zukünftigen) Energieverbauchs durch die KI Prognose ist dieser Wert von grundlgender Bedeutung, es ist ein Kernsignal für "Ladebedarf".
Sollte dieser Wert nicht geliefert werden können muß man einfach festhalten, dass ein Consumer vom Typ "BEV" nicht sinnvoll angelegt werden kann sofern man damit die Prognose-KI füttern möchte. D.h. die Auswahl eines entsprechend Profils wäre nur möglich wenn diese Voraussetzung vorliegt. Allerdings würde ich aus Gründen der programmtechnischen Vereinfachung den SoC Wert der Bat bei einem BEV-Typ verpflichtend definieren. Sonst nimmt man einfach "other" in solchen Fällen.