76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...
Ist das irgendwie möglich, beide Speicher zu sehen.
...

Dass auch mehr als ein Speicher im Diagramm mit den Energieflüssen dargestellt werden kann, hatte ich schon einmal an früher Stelle angeregt.

Für eine derartigen Erweiterung kann ich mir folgende Darstellungsform vorstellen: Bisheriger (Summen-)Speicherknoten, von dem Pfade zu >1 (Teil-)Speichernoten ausgehen.

[Parallix]

Bei dem aktuell sehr wechselhaften Wetter beobachte ich in SF, dass bei einer nicht KI-basierte Prognose die rein durch Überschuss motivierten höheren Verbrauchsdaten sonniger Vortage zu sehr in die aktuelle Prognose einfließen. In der Konsequenz führt dies dazu, dass zu Beginn eines Tages die empfohlene Ladeleistung so hoch sein kann, dass ein SOC von 100% bereits gegen Mittag prognostiziert wird, selbst wenn safetyMargin auf 0:0 gesetzt ist.

Auch ohne klassische KI lässt sich der stets unerwünschte Effekt eines frühen Vollladens von Speichern beseitigen, da die 1h-Verbräuche eines Tages mit der solaren 1h-Erzeugung korreliert werden können. Da es neben dem statischen Zusammenhang zwischen Überschuss und Verbrauch aber auch Verbräuche gibt, die unabhängig von der solaren Erzeugung sind, dürfen die gewonnenen Korrelationskoeffizienten natürlich nur zu einem Anteil in der 1h-Verbrauchsprognose berücksichtigt werden.

[DS_Starter]

@TheTrumpeter,

Ich habe eine Wärmepumpe, die im Winter heizt, im Sommer kühlt und ganzjährig die Warmwassererzeugung übernimmt. Derzeit habe ich für jede der 3 Teilfunktionen (Heizung, Kühlung, Warmwasser) einen eigenen Verbraucher angelegt, damit die Verbräuche erfasst werden.
Die Steuerung der Verbraucher wird aber nur für's Warmwasser von SolarForecast übernommen.

Das führt nun dazu, dass nach der Heizsaison die Verbrauchsvorhersage falsch ist, weil der gelernte Heizungsverbrauch vom Winter erst mal "verlernt" werden muss. Zu Sommerbeginn ist's dann wieder falsch, weil die Kühlung erst "eingelernt" werden muss usw. usf.

Ich fürchte mit den herkömmlich implementierten Logiken ist dieses Problem nicht zu lösen. Ich würde dich vertrösten wollen bis ich ein neuronales Netz für die Verbrauchsvorhersage integriert habe. Damit könnte eine LÖsung gelingen.

LG,
Heiko

[DS_Starter]

@Parallix,

In der Konsequenz führt dies dazu, dass zu Beginn eines Tages die empfohlene Ladeleistung so hoch sein kann, dass ein SOC von 100% bereits gegen Mittag prognostiziert wird, selbst wenn safetyMargin auf 0:0 gesetzt ist.

Wo liest du die Prognose-Zeit für den SOC von 100% ab?

[TheTrumpeter]

Ich betreibe seit ca. 2 Wochen ein kleine lokale Energiegemeinschaft und überlege eine Visualisierung der Erzeugungsprognose für die Teilnehmer zu erstellen, damit sie ihre variablen Verbraucher danach richten können.

Mangels Zugriff auf die tatsächliche Produktion und Überschuss der übrigen Produzenten würde ich erstmal auf eine reine Darstellung der prognostizierten Erzeugung beschränken wollen.
Dazu habe ich überlegt eine zusätzliche SolarForecast-Instanz anzulegen, in der ich die Erzeugungsanlagen konfiguriere & die Daten dann mittels OpenMeteoWorldAPI abrufe, also genau so wie ich es heute schon für meine eigene Erzeugungsanlage mache, nur eben für alle in der EG vorhandenen.

Nun habe ich gesehen, dass es mittels "get SF html forecast_noHead_noCons" bereits möglich ist nur die Vorhersage-Diagramme abzurufen. Da ist allerdings auch die Verbrauchsprognose enthalten, die ich nicht haben möchte. Wäre es möglich eine zusätzliche Ausgabe "get SF html forecast_onlyProd" (oder so ähnlich) einzubauen, die nur die Erzeugungsprognose liefert?
Das wäre zwar etwas over-engineered, da ich dafür sonst keinerlei Features von SolarForecast benötige, ist aber die einzig mir bekannte Möglichkeit das "out-of-the-box" zu bewerkstelligen.


Wie ich die Grafik dann zugänglich mache, ist mir noch unklar... ich habe überlegt eine zusätzliche WEB-Instanz zu konfigurieren, in der ich alle Funktionen sperre und nur die Grafik anzeige. Trotzdem würde das - abhängig von der Anzahl der Zugriffe - vmtl. unnötige Zusatzlast für FHEM erzeugen.
Alternativ könnte ich die Grafik als Bild speichern und nur dieses zugänglich mache.
Nur, meine letzte Homepage habe ich vor 25 Jahren betrieben, ich habe keine Ahnung wie ich das bewerkstelligen soll.

Sorry wenn das Thema etwas Off-Topic ist, aber hat jemand andere/bessere/einfachere Ideen?

[DS_Starter]

Guten Morgen,

Nun habe ich gesehen, dass es mittels "get SF html forecast_noHead_noCons" bereits möglich ist nur die Vorhersage-Diagramme abzurufen. Da ist allerdings auch die Verbrauchsprognose enthalten, die ich nicht haben möchte. Wäre es möglich eine zusätzliche Ausgabe "get SF html forecast_onlyProd" (oder so ähnlich) einzubauen, die nur die Erzeugungsprognose liefert?

Das geht leider nicht, weil die Optionen für den Get-Befehle bestimmte Bereiche der Gesamtgrafik ausklammern, aber nicht bestimmte Anteile in den Bereichen. Man kann also z.B. nur die Balkendiagramme abrufen, aber nicht nur ein bestimmtes Balkendiagramm aus dem Balkendiagramm-Vorrat.

Ich würde es mit einer zusätzlichen Instanz machen, so wie du dir das bereits überlegt hast.

ich habe überlegt eine zusätzliche WEB-Instanz zu konfigurieren, in der ich alle Funktionen sperre und nur die Grafik anzeige. Trotzdem würde das - abhängig von der Anzahl der Zugriffe - vmtl. unnötige Zusatzlast für FHEM erzeugen.

Für mich klingt das nach einem gut und relativ einfach zu machenden Weg. Welche zusätzliche Last das erzeugt, hängt sicherlich auch von deiner Hardware ab. Ich persönlich würde es erstmal so testen und erst von Ergebnis abhängig nach Alternativen suchen.

LG,
Heiko

[Parallix]

@Parallix,
...
Wo liest du die Prognose-Zeit für den SOC von 100% ab?

Die Info zur ,,SOC Prognose" (so der Beschreibungstext) entnehme ich im Bereich der Balkengrafik der Einblendung am Batteriesymbol zu einer (Mittags-)Stunde (vgl. Anlage).

[DS_Starter]

Das habe ich vermutet. Die Anzeige in der Balkengrafik bezieht sich auf den bisherigen Standard Steuerung nach Ladefreigabe. Nun ist es so, dass ich (das Modul) nicht "weiß" welchen Steurungsmodus der Nutzer für seine Batterie einsetzen wird und somit die Anzeige von der zukünftigen Realität abweichen kann.
In dem Mouse-Over könnte ich noch einen Punkt "Strategie" aufnehmen damit man sieht worauf sich die Prognose bezieht.

[Parallix]

Das habe ich vermutet. Die Anzeige in der Balkengrafik bezieht sich auf den bisherigen Standard Steuerung nach Ladefreigabe. Nun ist es so, dass ich (das Modul) nicht "weiß" welchen Steurungsmodus der Nutzer für seine Batterie einsetzen wird und somit die Anzeige von der zukünftigen Realität abweichen kann.
In dem Mouse-Over könnte ich noch einen Punkt "Strategie" aufnehmen damit man sieht worauf sich die Prognose bezieht.

Wenn ein Teil der Grafik (hier die Bat-Symbole oberhalb noch kommender Uhrzeiten) und eine zugehörige Angabe in der Legende (hier die SOC-Prognose) in diesem Fall keine Aussagekraft besitzt, dann wäre es vielleicht besser, wenn beides vielleicht gar nicht dargestellt wird. Noch besser wäre es natürlich, wenn SF der Steuerungsmodus "Möglichst gleichmäßige Ladung nach Empfehlung" bekannt gemacht werden könnte und darauf basierend eine aussagekräftige SOC-Prognose erstellen kann. Das jedenfalls wäre mein Vorschlag.

[DS_Starter]

Wenn ein Teil der Grafik (hier die Bat-Symbole oberhalb noch kommender Uhrzeiten) und eine zugehörige Angabe in der Legende (hier die SOC-Prognose) in diesem Fall keine Aussagekraft besitzt, dann wäre es vielleicht besser, wenn beides vielleicht gar nicht dargestellt wird.

Eine Aussagekraft ist schon da, nur ist sie eben mit mehr Unsicherheit vorhanden.

Noch besser wäre es natürlich, wenn SF der Steuerungsmodus "Möglichst gleichmäßige Ladung nach Empfehlung" bekannt gemacht werden könnte und darauf basierend eine aussagekräftige SOC-Prognose erstellen kann. Das jedenfalls wäre mein Vorschlag.

Dazu müsste der User dem Modul mitteilen (per Attr) welche Ladungsstrategie er verfolgt und diese Strategie in seinem Skript auch adäquat umsetzen. Im Prinzip kein Problem, aber sicherlich ein advanced Feature für fortgeschrittene Anwender.

[Parallix]

Noch ein Nachtrag zu meinem vorherigen Posting: Wie aus angefügter Grafik ersichtlich, funktioniert die Strategie "gleichmäßiges Laden" bei mir noch nicht wirklich: In knapp 2,5h wird von 70% auf 90% geladen und das bereits jetzt um 11:00 MESZ .

[DS_Starter]

Dafür sehe ich zwei vermutliche Gründe:

- 1. lt. deinem ersten Screenshoot in #4101 verbrauchst du ab 15:00 bereits wieder Energie aus
     der Batterie weswegen versucht wird vorher die Bat maximal aufzuladen
- 2. war ich vllt. mit meiner Überhöhung gemäß Durchschnitt zu forsch

Den Punkt 2 habe ich abgeändert und in mein contrib upgedatet.

Ansonsten funktioniert bei mir die Logik ausgezeichnet. Die Realität am Ende des Tages folgt bis jetzt sehr zufriedenstellend der Prognose lt. Debuglog:

Code Auswählen Erweitern

2025.09.23 11:28:52.502 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.09.23 11:28:52.502 1: SolCast DEBUG> ChargeOTP - NOTE: The hours listed below are the estimated number of hours remaining on the current day with at least the respective PV surplus.
2025.09.23 11:28:52.502 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 12, Start SoC: 24438 Wh, Surplus: 4702 Wh (2 hrs), OTP: 2864 W, safety: 20 %
2025.09.23 11:28:52.503 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 13, Start SoC: 26825 Wh, Surplus: 5303 Wh (1 hrs), OTP: 1909 W, safety: 20 %
2025.09.23 11:28:52.503 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 14, Start SoC: 24438 Wh, Surplus: 3905 Wh (3 hrs), OTP: 1591 W, safety: 20 %
2025.09.23 11:28:52.503 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 26029 Wh, Surplus: 4873 Wh (1 hrs), OTP: 2864 W, safety: 20 %
2025.09.23 11:28:52.504 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 28416 Wh, Surplus: 2696 Wh (4 hrs), OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.504 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 28416 Wh, Surplus: 1381 Wh (6 hrs), OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.504 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 28416 Wh, Surplus: 1641 Wh (5 hrs), OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.505 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.505 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.505 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.505 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.506 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.23 11:28:52.506 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %

Ab 15:00 (hod 16)  will die Bat voll sein. Mit 0% safety geringfügig später.

[Parallix]

Dafür sehe ich zwei vermutliche Gründe:

- 1. lt. deinem ersten Screenshoot in #4101 verbrauchst du ab 15:00 bereits wieder Energie aus
     der Batterie weswegen versucht wird vorher die Bat maximal aufzuladen
- 2. war ich vllt. mit meiner Überhöhung gemäß Durchschnitt zu forsch

Den Punkt 2 habe ich abgeändert und in mein contrib upgedatet.
...

Der heute gegen 11:00 MESZ prognostizierte Verbrauch um 15:00 MESZ taucht auf, da am Vortag aufgrund eines sonnigen Tages ein Verbraucher (manuell) eingeschaltet wurden, um die andernfalls ins Netz eingespeiste Leistung sinnvoll im Haus zu nutzen. Nun frage ich mich, ob und wie es derzeit schon möglich ist, derartige manuell veranlasste Verbräuche aus der Verbrauchsprognose automatisiert herauszunehmen, wenn diese separat erfasst werden.

Beispiele für o.g. manuell veranlasste Verbräuche sind z.B. eine vorgezogene elektrolytische Backofenreinigung und ähnliche Maßnahmen, die unter Nutzung natürliche Intelligenz bei Sonnenschein veranlasst werden.

PS: Lässt sich die von Dir verwendete "Überhöhung gemäß Durchschnitt" extern reduzieren? Und wie eigentlich lässt sich einstellen, welcher maximale SOC durch eine gleichmäßige Ladung erreicht werden soll.

[DS_Starter]

PS: Lässt sich die von Dir verwendete "Überhöhung gemäß Durchschnitt" extern reduzieren?

Diese Überhöhung habe ich wie schon geschrieben entfernt. Es verbleibt nur die Erhöhung gegeben durch safety. Und die ist ja einstellbar.

Und wie eigentlich lässt sich einstellen, welcher maximale SOC durch eine gleichmäßige Ladung erreicht werden soll.

Zur Zeit gelten 100% als Ziel. Andere Wünsche müssen erst implementiert werden.

[grappa24]

mal wieder performance:
Nicht dass mein fhem auf RasPi jetzt langsam wäre, aber aufgefallen ist mir die Auslastung schon:

Ich kann nur vor dem Schlüssel "asynchron=1" warnen, ich hatte den bei meinen beiden Inverter-Devices gesetzt  .
Ich hab die heute wieder auf "0" gesetzt und schon klappts auch wieder mit der performance