76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

schalte mal die Grafik auf "mit Nachtanzeige" ein.
Dann sieht / verstehst du evtl. den Verlauf evtl. besser.

Code Auswählen Erweitern

graphicShowNight
Anzeigen oder Verbergen der Nachtstunden in der Balkengrafik.

0    keine Anzeige der Nachtstunden sofern kein Wert anzuzeigen ist (default)
Sofern die ausgewählten Inhalte einen Wert enthalten, werden diese Balken dennoch dargestellt.
01    Wie '0', es findet jedoch eine Zeitsynchronisation zwischen der Ebene 1
und der nachfolgenden Balkengrafikebene statt.
1    Nachtstunden werden immer angezeigt
Eventuell auch noch das "ctrDebug=batteryManagement" einschalten - dann sieht du was passiert bzw. dort berechnet wird....



EDIT:
Ups ->> Heiko war schneller mit dem schreiben.... 🥳

[DS_Starter]

@Parallix,

consForecastBase habe ich immer als elektrische Grundlast (basic load) verstanden, also als minimale Last, die für jedes Stunden-Bin (wenigstens) zu berücksichtigen ist. Wahrscheinlich wäre es einfachsten, wenn man lediglich die Beschreibung anpasst, also auf folgendes reduziert

Ja so hatte ich es auch verstanden und so ist es bereits geraume Zeit implementiert.
Die Beschreibung der aktuellen Implementierung zu präzisieren ist tatsächlich am sinnvollsten. Sie wäre präzise so zu formulieren:

consForecastBase – Untergrenze für Verbrauchsprognosen

Dieser Wert legt eine feste Mindestschwelle für die Verbrauchsprognose fest.

* berechnete Prognosen unterhalb von consForecastBase werden auf diesen Wert angehoben.
* berechnete Prognosen oberhalb von consForecastBase werden nicht verändert.

[HomeAuto_User]

Hallo,
danke für eure schnellen Antworten.

...
schalte mal die Grafik auf "mit Nachtanzeige" ein.
Dann sieht / verstehst du evtl. den Verlauf evtl. besser.
...

Diese Option ist mir klar und auch bewußt wenn ich diese setze. --> verstanden

Mit den Optionen "ctrlBatSocManagementXX" habe ich nun herumgespielt.
Sobald ich ein "upSoC" eintrage, so wird dieser in der Prognose als "Höchstwert" angenommen obwohl die Prognose Sonne anzeigt.
In meinem Falle habe ich einen MinWertBatterie von 20% und dieer sollte ja bei Überschuss steigen. Wo ist mein Bedienfehler bzw. Denkfehler?

Grüße

[Parallix]

@Parallix,

consForecastBase habe ich immer als elektrische Grundlast (basic load) verstanden, also als minimale Last, die für jedes Stunden-Bin (wenigstens) zu berücksichtigen ist. Wahrscheinlich wäre es einfachsten, wenn man lediglich die Beschreibung anpasst, also auf folgendes reduziert

Ja so hatte ich es auch verstanden und so ist es bereits geraume Zeit implementiert.
Die Beschreibung der aktuellen Implementierung zu präzisieren ist tatsächlich am sinnvollsten. Sie wäre präzise so zu formulieren:

consForecastBase – Untergrenze für Verbrauchsprognosen

Dieser Wert legt eine feste Mindestschwelle für die Verbrauchsprognose fest.

* berechnete Prognosen unterhalb von consForecastBase werden auf diesen Wert angehoben.
* berechnete Prognosen oberhalb von consForecastBase werden nicht verändert.

Die Idee seinerzeit war aber, dass man eine Grundlast definieren kann, die nicht sinnvoll Verbrauchern zuzuordnen ist. Dies mit dem Zweck diese Grundlast bei der Verbrauchsprognose auch adäquat berücksichtigen zu können. Werden dann dedizierte Verbraucher eingeschaltet, so ergibt sich natürlich ein zusätzlicher Verbrauch. Das ganze ist mit dem jetzigen Schema leider (noch) nicht abbildbar.

[DS_Starter]

upSoC regelt, dass in Perioden mit geringem PV-Überschuß der SoC sich tendenziell zwischen 'upSoC' und 'maxSoC' bewegt. Aus Sicht SF wird die Batterie dann nicht tiefer als upSoC entladen wenn dem Reading Battery_OptimumTargetSoC_XX gefolgt wird. Das ist typischerweise in den sonnenarmen Monaten der Fall.

In deinem Fall ist deine Batterie aktuell tiefer als upSoC entladen, was aus Sicht des Moduls eine Situation ist, die nicht gewünscht ist und eigentlich nicht 'sein kann' da sie den Vorgaben widerspricht.
Möglicherweise wird Battery_ChargeRequest_XX=1 gesetzt um mit Ladung aus dem Netz den SoC auf upSoC zu bringen.
Demzufolge ist dann die Prognose auch dort.

In deiner Grafik sieht man, dass morgen sehr wenig PV und vermutlich 0 Überschuß über den Tag vorliegen wird. Demzufolge auch keine Ladung, aber auch keine Entladung wenn upSoC bei 50 eingestellt ist.

Für mehr Sicht -> ctrDebug=batteryManagement einschalten.

[DS_Starter]

Die Idee seinerzeit war aber, dass man eine Grundlast definieren kann, die nicht sinnvoll Verbrauchern zuzuordnen ist. Dies mit dem Zweck diese Grundlast bei der Verbrauchsprognose auch adäquat berücksichtigen zu können. Werden dann dedizierte Verbraucher eingeschaltet, so ergibt sich natürlich ein zusätzlicher Verbrauch.

Das ist eine etwas andere Logik. In dem Fall wäre es ein AddOn auf die Prognose.
Es ist ja nicht so, dass die Prognose nur von dedizierten Verbrauchern abhängig ist. Sie wird ja im Legacy Modus aus verschiedenen Durchschnitten der eingestellten Tage unter Berücksichtigung von geplanten Verbrauchern realisiert und nicht nur von dem Verbraucher allein.

Ich kann durchaus auch einen Parameter (wie auch immer) einführen um von aktuell "Basement" auf "AddOn" umschalten zu können. Das war auch die Idee aus der Diskussion.

[Parallix]

...
Ich kann durchaus auch einen Parameter (wie auch immer) einführen um von aktuell "Basement" auf "AddOn" umschalten zu können.
...

Ja, bitte!

[tpm88]

Hallo Heiko,

ich hätte einen kleinen Feature Request... Hoffe, ich habe in der Doku nichts übersehen.

Nach meinem Verständnis wird der Standort der PV-Anlage aus den globalen FHEM Attributen latitude und longitude ermittelt und der im Attribut setupWeatherDev<n> Wetter-API wie z.B. OpenMeteoDWD-API durchgereicht.

Ich würde nun gerne in der gleichen FHEM Installation ein weiteres SolarForecast Device für eine kleine Anlage an einem anderen Standort ( Haus der Eltern ) definieren.

Könntest Du je SolarForecast Device optionale "lokale" Attribute für latitude und longitude einführen? Und wenn diese beim Setup nicht angegeben werden, werden wie bisher die globalen verwendet.

Danke wieder einmal für das tolle Modul.

Tobi

[DS_Starter]

Hallo Tobi,

Könntest Du je SolarForecast Device optionale "lokale" Attribute für latitude und longitude einführen? Und wenn diese beim Setup nicht angegeben werden, werden wie bisher die globalen verwendet.

Ja, kein Problem. Kommt in plantConfig mit hinein.... und Danke 

LG,
Heiko

[justcallmeal]

Hallo Heiko,

bei meiner Anlage stellt die Energieflussgrafik von SolarForecast die Netzladung eines AC-gekoppelten Speichers missverständlich dar. Ich möchte Dir das anhand eines konkreten Beispiels erläutern und einen Änderungsvorschlag zur Prüfung und möglichen Aufnahme in eine kommende Revision übermitteln. Ich hoffe in Deiner Doku nichts übersehen zu haben.

Ich verwende SolarForecast 2.10.2 mit folgendem Modulheader:

76_SolarForecast.pm 31608 2026-08-29 22:38:59Z DS_Starter

Der Speicher ist ein Zendure SolarFlow 4000 MIX AC+, ausschließlich AC-gekoppelt. Am Speicher sind weder PV-Module direkt angeschlossen noch Verbraucher an der netzunabhängigen Steckdose. Die PV-Leistung kommt über OpenDTU, die Netzleistung vom Shelly Pro 3EM.

Der Speicher ist über setupBatteryDev01 eingebunden, mit pin=gridInputPower:W, pout=outputHomePower:W und charge=SOC. Eine zusätzliche Batterie-/Hybridwechselrichter-Konfiguration besteht nicht. Die vollständigen relevanten Attribute stehen in der beigefügten technischen Erläuterung.

Das konkrete Fehlerbild

Der beigefügte Screenshot zeigt:

PV-Erzeugung: 68 W

Netzbezug: 2235 W

Akkuladung: 1999 W

Hausverbrauch: 304 W

Akkustand: 17 %

Die Leistungsbilanz stimmt: 68 + 2235 = 1999 + 304 W.

Die Grafik zeigt allerdings 1999 W auf der oberen Verbindung vom PV-/Wechselrichterknoten zum Akku. Gleichzeitig steht auf der Verbindung dieses Knotens zum Haus −1931 W. Rechnerisch lässt sich der Rückfluss damit erklären; für den Betrachter entsteht aber der Eindruck, die knapp 2000 W Akkuladung kämen aus der PV-Anlage.

Gewünscht wäre für diesen Fall: 68 W von PV zum Haus, 2235 W vom Netz zum Hausnetz und 1999 W vom Hausnetz zum Akku. Die obere Verbindung PV → Akku wäre inaktiv.

Beim PV-Überschussladen soll dagegen weiterhin PV → Akku angezeigt werden. Bei gemischter Ladung sollten beide Verbindungen mit ihren jeweiligen Anteilen erscheinen. Entladung bleibt Akku → Haus.

Vorgeschlagene Umsetzung

Der beiliegende Patch ergänzt eine optionale Einstellung batteryFlow=source innerhalb von flowGraphicControl. Ohne diese Einstellung beziehungsweise mit batteryFlow=legacy bleibt die bisherige Darstellung erhalten.

Die Zuordnung erfolgt unter der Annahme ,,PV versorgt rechnerisch zuerst den Hausverbrauch":

Hausnetz → Akku = Minimum aus positiver Netto-Ladeleistung und positivem Netzbezug.

PV → Akku = verbleibender Ladeanteil.

Der bisherige Grafikwert PV → Haus wird um den über Hausnetz → Akku dargestellten Anteil erhöht.

Dabei handelt es sich ausdrücklich um eine bilanzielle Zuordnung, nicht um eine unabhängig gemessene Energieherkunft oder die Darstellung der tatsächlichen Verkabelung.

Die Änderungen betreffen _attrflowGraphicControl, die lokalen Anzeigewerte und SVG-Pfade in _flowGraphic sowie die Attributdokumentation. __calcVectorConsumption, Messwerte, Energiezähler und Steuerung bleiben unverändert.

Die Erweiterung ist für ausschließlich AC-gekoppelte Speicher mit AC-Messwerten für pin/pout vorgesehen. Bei erkannten expliziten Batterie-/Hybridwechselrichter- oder direkten PV-Batterie-Konfigurationen bleibt die bisherige Darstellung erhalten.

Prüfung und Einschränkungen

Der Vorschlag wurde mit den extrahierten Modulfunktionen außerhalb von FHEM geprüft: 69 erfolgreiche Einzelprüfungen, darunter Netzladung, PV-Überschussladung, gemischte Ladung, Entladung und Leerlauf. In den geprüften Fällen blieb die SVG-Ausgabe ohne aktivierte Erweiterung identisch zur Ausgangsfassung.

Ein Test im laufenden FHEM oder im Browser steht aus. Zeitlich versetzte Messwerte werden durch diese Anzeigeänderung nicht korrigiert.

Der Diff basiert auf meiner vorhandenen lokalen Moduldatei, die bereits andere lokale Anpassungen enthält. Er ist daher als Implementierungsvorschlag zu verstehen und vor einer Übernahme gegen Deinen aktuellen offiziellen Stand zu prüfen. Die vorgeschlagene Grafikänderung habe ich nicht produktiv installiert.

Könntest Du die Problematik und den Vorschlag prüfen und eine passende Lösung in eine kommende Revision aufnehmen? Falls die gewünschte Darstellung bereits mit einer vorgesehenen Konfiguration erreichbar ist, freue ich mich auch über einen entsprechenden Hinweis. Ich möchte eine dauerhafte lokale Moduländerung vermeiden.

Im Anhang findest Du den Patch, den Original-Screenshot, die Konfiguration und technische Erläuterung sowie den Offline-Prüfbericht.

Vielen Dank und viele Grüße
al

[DS_Starter]

Moin al,

Ich schaue mir die Berichte noch genauer an und prüfe was die KI sich da ausgedacht hat.
Aber nach meinen bisherigen Erfahrungen und den schon sehr häufigen Patches der Flowgrafik ist es sehr wahrscheinlich, dass es sich hier um ein Konfigurationsproblem handelt.
Denn der Flow von/zur Batterie wird durch korrekt eingestellte Schlüssel sowie die Einhaltung deren Inhalt durch die Hardware dahinter bestimmt.
Ein weiterer Parameter würde die Ursache vermutlich nur verdecken. Das soll nicht heißen, dass es dennoch einen Spezialfall geben kann und ich unrecht habe. 

Was wichtig wäre zu Analyse:
- der Inhalt der Attribute setupBatteryDevXX und setupInverterDevXX
  EDIT: habe ich in den Erläuterungen gefunden:
  attr SolarForecast flowGraphicControl showconsumerremaintime=0
  attr SolarForecast setupBatteryDev01 Zendure_4000 pin=gridInputPower:W pout=outputHomePower:W intotal=BatInTotal_Wh:Wh outtotal=BatOutTotal_Wh:Wh pinmax=4000 poutmax=4000 charge=SOC cap=8000 show=1 asynchron=1
  attr SolarForecast setupInverterDev01 OpenDTU pvOut=Power:W etotal=YieldTotal:kWh capacity=2000

- eine Erläuterung was die in den Schlüsseln angegebenen Readings der Quelledevices genau bedeuten, also was dort geliefert wird (fehlt noch)
- ein Auszug des Debuglogs mit ctrlDebug=collectData

Das Debuglog ist für den dargestellten Fall interessant denn ich nehme an, du siehst dieses Bild nur ab und zu in bestimmten Situationen.

EDIT: Ist meine Vermutung richtig, dass es nur darum geht, eine Akkuladung aus dem Netz nicht über der Inverknoten, sondern über den Hausknoten zur Batterie laufen zu lassen?

EDIT2: Es geht tatsächlich nur um eine Änderung der Flußlogik für den Fall der Netzladung des Akkus. Ich brauche keine weiteren Infos zur Zeit. Ich denke das kann ich ohne zusätzliche Schlüssel und Einstellung seitens des Users lösen. Testversion wird kommen.

LG,
Heiko

[DS_Starter]

@al (& all),

in meinem contrib liegt ein Update bzgl. der Korrektur Flowcontrol:
 
 * Korrektur der Darstellung bei Netzladung der Batterie über den Hausknoten.
   Ein negativer Energiefluss zwischen Inverterknoten und Hausknoten wird nun korrekt als direkter Fluss Hausknoten → Batterie dargestellt.
   Der angezeigte Hausverbrauch bleibt davon unberührt.

Man braucht keine zusätzlichen Einstellungen/Schlüssel etc.
Einfach Einspielen, restarten und testen ob bei Netzladung die Flußrichtung stimmt (und natürlich alles andere wie bisher).

LG,
Heiko