76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

@all,

morgen früh ist die V 1.58.2 im Update enthalten.
Es ist enthalten:

- die Weiterentwicklung und Fixes bzgl. der Batterie Leistungssteuerung
- Attr flowGraphicControl->shiftx: Entfernung der Wertebeschränkung

LG,
Heiko

[Max_Meyer]

Ich dokumentiere gerne morgen meinen Hybridwechselrichter mit zwei Inverterdevices

Hallo Grappa,
wenn du willst kannst du gern das beigefügte Bild mit verwenden - es zeigt eine auf SMA-Inverter basierende Anbindung eines Hybridwechselrichters
Gruß Gerd

[Max_Meyer]

Die (Haus-)Speicher sollen schonend geladen werden.

Hallo Parallix,
ich würde gern folgende Punkte zur Diskussion beitragen.

den o.g. Satz wie folgt abändern: Die (Haus-)Speicher sollen schonend ge- und entladen werden
Motivation: am Ende entscheidet der System Performance Index (SPI) des kompletten Systems.
Entladen mit sehr geringer Leitung ist i.d.R. ineffizient. Insbesondere bei mehreren Batterien ist es also wichtig wann die andere Batterie(n) beispringen um das System effektiv zu halten - kurz gesagt Laden und entladen sollte mit betrachtet werden - aus meiner Sicht.

Auch bei EV-Batterien führt eine schonende Ladung zu den beim Haus-Speicher beschriebenen positiven Auswirkungen. Anders, als beim Hausspeicher ist die Leistung, mit der EV-Batterien geladen werden können, nicht nur nach oben, sondern (leider) auch nach unten hin begrenzt. Die untere Grenze ist zumeist durch einen minimal erforderlichen Ladestrom von 6 A vorgeben. Bei einer typischerweise vorliegenden Ladespannung von 230 V ergibt sich an einer 11 kW-Wallbox bei einphasiger (1P) Laden ein Ladeleistungsbereich von [1380, 3680] W und bei dreiphasigem (3P) Laden ein Ladeleistungsbereich von [4140, 11040] W.

zum Thema EV einige Anmerkungen
- nach ISO15118 sind Ladeleistungen an 650W erlaubt - inwieweit das sinnvoll ist?
- die meisten (neuen) Ladestationen schalten selbständig zwischen 1PH und 3PH um.
- Ist ein BEV eine Batterie?  oder eher ein Verbraucher? - wie z.B. eine Waschmaschine - die Zustände (Schnellladen, kontinuierliches Laden etc.) sind die Programme des Verbrauchers - analog zu WA, GSP ergibt sich dann je gewählten Programm, ein unterschiedlicher Energiebedarf über die Zeit. Ich glaub das ist sehr individuell.
- Möglichkeiten des BEV in Bezug auf schonende Ladung müssten beachtet werden - in (einigen) BEV lassen sich 'Ladeprofile' vorgeben die die Reaktion der WB beeinflussen z.B. bei mir können Ladestufen vorgewählt werden - d.h. Ein Wallboxsollwert '16A' bewirkt bei eingestellter Ladestufe2 eine Ladeleistung von 4300 W bei Ladestufe5 11000W. 
- ist es möglich/sinnvoll solche Möglichkeiten in ein allgemeines Modul wie SF zu berücksichtigen?

Bei Fragen Ergänzungen bitte melden
Gruß Gerd

[Parallix]

Die (Haus-)Speicher sollen schonend geladen werden.

Hallo Parallix,
ich würde gern folgende Punkte zur Diskussion beitragen.

den o.g. Satz wie folgt abändern: Die (Haus-)Speicher sollen schonend ge- und entladen werden.
...

Hallo Gerd,

über Dein Feedback zu meiner Liste habe ich mich sehr gefreut. Bitte bedenke, dass meine Sammlung in Hinblick auf SF erstellt wurde und von daher seitens SF auch nur Planungen bzw. Empfehlungen, nicht aber Maßnahmen erfolgen. Um hier nicht begrifflich rumzueiern, nenne ich das, was ich mit SF derzeit verbinde, eine ,,Begleitung durch SF als Expertensystem".

Da – anders als das Wetter – Verbräuche häufig wesentlich schlechter vorhergesagt werden können, als solare Erzeugungsleistungen, habe ich aktuell nur eine sehr vage Vorstellung, wie derartiges überhaupt durch SF begleitet werden könnte. Sicherlich denkbar ist, dass bei mehren Speichern in der Nacht, wenn absehbar nur noch eine geringe Grundlast zu bedienen ist, SF vorschlagen könnte, einen der Speicher den Standby zu versetzen. Wenn die nächtliche Last sehr hoch ist, kann es ggf. auch sinnvoll sein, den Ratschlag zu geben, auch den WR in den Standby zu versetzen.
Vor diesem Hintergrund ergänze ich gerne meine Liste den Punkt "Das Standby-Management von Speichern soll unterstützt werden" und "Das Standby-Management von Wechselrichtern soll unterstützt werden" mit entsprechender Motivation.

[grappa24]

Hier nun meine Doku zum Thema Hybridwechselrichter

[hugomckinley]

Was man auch andenken könnte, wäre eine Integration von dynamischen Stromtarifen.

Angenommener Hintergrund:
Wenn ein großer Akku vorhanden ist, dann wäre es mit einem dynamischen Stromtarif möglich, den Energiebedarf der nächsten 1-2 Tage zu den günstigsten Stunden aus dem Netz zu laden und dann über den Tag verteilt zu verbrauchen. (Schlechtwetter, Winter [günstiger Windstrom in der Nacht])
In einer Extremvariante könnte man auch die mindestens benötigten kWh für ein BEV aus dem Akku laden, wenn das Auto voraussichtlich nicht zu Hause ist, wenn der Strom günstig "genug" ist.
Da SF ja den Verbrauch der nächsten zwei Tage schätzen kann, könnte man in dieser Zeit auch die Differenz aus Verbauch und PV Ertrag aus dem Netz laden.
Was günstig ist, muss komplett parametrierbar sein, da die Strommärkte sehr unterschiedlich sind. So sind die Netzgebühren in AT ein viel kleiners "Problem" als in DE.
Auch muss man genau überlegen, ab wann es wirklich günstiger ist. In einem ersten Anlauf käme ich auf einen kWh-Preis aus dem Akku von ca. Arbeitspreis + xx% Speicherverluste + Verschleiß Speicher/kWh
Beispiel: 3ct/kWh + 3ct/kWh * 0,2 + 4ct/kWh = 7,6ct/kWh
d.h. die Energie ist aus dem Akku erst günstiger, wenn die kWh über 7,6ct/kWh kostet. Das müsste man dann Stundenweise mitrechnen, denn ein Mittelwert hilft hier nicht.

Zu diesem Zweck habe ich mir als ersten Schritt dieser Anleitung
https://wiki.fhem.de/wiki/AWATTar_-_Virtueller_Stromkunde
folgend, ein System für den österreichischen Anbieter SmartEnergy zurecht gelegt.
Somit weiß bis zum Tagesende die Energiepreise und ab 17:00 sogar schon für den kompletten nächsten Tag.
Dazu gibt es dann Funktionen, die verschiedene Auswertungen erlauben.
Ein Beispiel ist z.B die Indizes der Stunden, um bei gegebener (Lade-)Leistung eine gewisse Energiemenge zu laden.
Anwendung: Batteriespeicher kann(soll) mit 10kW aus dem Netz laden und ich brauche 30kWh. Welche Stunden muss ich den Speicher laden, um in spätestens 8h dieses Ziel zu erreichen?

Code Auswählen Erweitern

{getRequestedEnergyHoursIndex(10,30,8)}
Ergebnis:

Code Auswählen Erweitern

14 15 16
Mir ist auch bewusst, dass man das mit Readings aus SF vermutlich auch extern lösen kann, aber ich weiß nicht, ob es nicht doch Vorteile geben könnte, wenn auch das in SF integriert wäre.

Meine Überlegungen sind mangels noch fehlendem Speicher, WP und BEV noch rein theoretisch und am Anfang, aber ich bin vermutlich nicht der einzige dem sowas im Kopf herumspukt.

Grüße,
Hugo

[MartinD]

Hallo,

vielen Dank für Deine Zeit!

Dem Rat folgend habe ich:

Code Auswählen Erweitern

define Speicher_dc2ac dummy
define Speicher_ac2dc dummy

und

Code Auswählen Erweitern

define di_Speicher_Leistung doif ([SolarEdge:B_Instantaneous_Power] >= 0) (set Speicher_dc2ac {([SolarEdge:B_Instantaneous_Power] * 0)}, set Speicher_ac2dc {([SolarEdge:B_Instantaneous_Power] * 1)} ) DOELSE  (set Speicher_dc2ac {([SolarEdge:B_Instantaneous_Power] * -1)}, set Speicher_ac2dc {([SolarEdge:B_Instantaneous_Power] * 0)} )
Ich wusste keinen anderen Weg.

Vielleicht findest Du noch Zeit, die Ausgabe von ctrlDebug zu überprüfen:

Code Auswählen Erweitern


2025.09.14 15:45:04 1: SolCast DEBUG> collect Inverter 01 data - device: MD_SolarEdge, source: pv, delivery: default =>
2025.09.14 15:45:04 1: SolCast DEBUG> pvOut: 190 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 6435200 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> collect Inverter 02 data - device: SolarEdge, source: bat, delivery: default =>
2025.09.14 15:45:04 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> summary data of all Inverters - pv: 190 W, this hour Generation: 0 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> State of Plant derating: 0, info: reductionState not set
2025.09.14 15:45:04 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2025.09.14 15:45:04 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 16: 100 % -> pvrlvd: 1
2025.09.14 15:45:04 1: SolCast DEBUG> collect Meter data - device: SolarEdge =>
2025.09.14 15:45:04 1: SolCast DEBUG> gcon: 30.8 W, gfeedin: 0 W, contotal: 257343 Wh, feedtotal: 257343 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> write to pvHistory - day: 14, hod: 16, GridConsumption (gcons): 206 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> collect Battery Readings data: device=MD_SolarEdge =>
2025.09.14 15:45:04 1: SolCast DEBUG> pin: 0 W, pout: 0 W, totalin: 206799 Wh, totalout: 193965 Wh, soc: 100
2025.09.14 15:45:04 1: SolCast DEBUG> Battery Power data after resolving the special case 'pou eq -pin' =>
2025.09.14 15:45:04 1: SolCast DEBUG> pin: 0 W, pout: 0 W
2025.09.14 15:45:04 1: SolCast DEBUG> EnergyConsumption input -> PV: 0 Wh, PP: 0 Wh, GridIn: 201 Wh, GridCon: 201 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> EnergyConsumption result -> 0 Wh
2025.09.14 15:45:04 1: SolCast DEBUG> current Power values -> PV2Node: 190 W, PV2Bat: 0, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 30 W
2025.09.14 15:45:04 1: SolCast DEBUG> current Power Battery -> BatIn: 0 W (Node2Inv2DC: 0 W), BatOut: 0 W (DC2Inv2Node: 0 W)
2025.09.14 15:45:04 1: SolCast DEBUG> current Consumption result -> 220 W
2025.09.14 15:46:14 1: SolCast DEBUG> collect Inverter 01 data - device: MD_SolarEdge, source: pv, delivery: default =>
2025.09.14 15:46:14 1: SolCast DEBUG> pvOut: 190 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 6435200 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> collect Inverter 02 data - device: SolarEdge, source: bat, delivery: default =>
2025.09.14 15:46:14 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> summary data of all Inverters - pv: 190 W, this hour Generation: 0 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> State of Plant derating: 0, info: reductionState not set
2025.09.14 15:46:14 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2025.09.14 15:46:14 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 16: 100 % -> pvrlvd: 1
2025.09.14 15:46:14 1: SolCast DEBUG> collect Meter data - device: SolarEdge =>
2025.09.14 15:46:14 1: SolCast DEBUG> gcon: 30.8 W, gfeedin: 0 W, contotal: 257347 Wh, feedtotal: 257347 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> write to pvHistory - day: 14, hod: 16, GridConsumption (gcons): 209 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> collect Battery Readings data: device=MD_SolarEdge =>
2025.09.14 15:46:14 1: SolCast DEBUG> pin: 0 W, pout: 0 W, totalin: 206799 Wh, totalout: 193965 Wh, soc: 100
2025.09.14 15:46:14 1: SolCast DEBUG> Battery Power data after resolving the special case 'pou eq -pin' =>
2025.09.14 15:46:14 1: SolCast DEBUG> pin: 0 W, pout: 0 W
2025.09.14 15:46:14 1: SolCast DEBUG> EnergyConsumption input -> PV: 0 Wh, PP: 0 Wh, GridIn: 206 Wh, GridCon: 206 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> EnergyConsumption result -> 0 Wh
2025.09.14 15:46:14 1: SolCast DEBUG> current Power values -> PV2Node: 190 W, PV2Bat: 0, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 30 W
2025.09.14 15:46:14 1: SolCast DEBUG> current Power Battery -> BatIn: 0 W (Node2Inv2DC: 0 W), BatOut: 0 W (DC2Inv2Node: 0 W)
2025.09.14 15:46:14 1: SolCast DEBUG> current Consumption result -> 220 W
2025.09.14 15:47:24 1: SolCast DEBUG> collect Inverter 01 data - device: MD_SolarEdge, source: pv, delivery: default =>
2025.09.14 15:47:24 1: SolCast DEBUG> pvOut: 190 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 6435200 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> collect Inverter 02 data - device: SolarEdge, source: bat, delivery: default =>
2025.09.14 15:47:24 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 0 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> summary data of all Inverters - pv: 190 W, this hour Generation: 0 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> State of Plant derating: 0, info: reductionState not set
2025.09.14 15:47:24 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2025.09.14 15:47:24 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 16: 100 % -> pvrlvd: 1
2025.09.14 15:47:24 1: SolCast DEBUG> collect Meter data - device: SolarEdge =>
2025.09.14 15:47:24 1: SolCast DEBUG> gcon: 64.6 W, gfeedin: 0 W, contotal: 257385 Wh, feedtotal: 257385 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> write to pvHistory - day: 14, hod: 16, GridConsumption (gcons): 248 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> collect Battery Readings data: device=MD_SolarEdge =>
2025.09.14 15:47:24 1: SolCast DEBUG> pin: 0 W, pout: 0 W, totalin: 206799 Wh, totalout: 193965 Wh, soc: 100
2025.09.14 15:47:24 1: SolCast DEBUG> Battery Power data after resolving the special case 'pou eq -pin' =>
2025.09.14 15:47:24 1: SolCast DEBUG> pin: 0 W, pout: 0 W
2025.09.14 15:47:24 1: SolCast DEBUG> EnergyConsumption input -> PV: 0 Wh, PP: 0 Wh, GridIn: 209 Wh, GridCon: 209 Wh, BatIn: 0 Wh, BatOut: 0 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> EnergyConsumption result -> 0 Wh
2025.09.14 15:47:24 1: SolCast DEBUG> current Power values -> PV2Node: 190 W, PV2Bat: 0, PV2Grid: 0 W, Other: 0 W, GridIn: 0 W, GridCon: 64 W
2025.09.14 15:47:24 1: SolCast DEBUG> current Power Battery -> BatIn: 0 W (N


[MartinD]

@ Grappa
Vielen Dank!

bei ModbusAttr sind analoge Readings:
I_AC_Power, I_DC_Power, M_AC_POWER und B_Instantaneous_Power (alles in kW)
Der Register für Leistung der Panele habe ich nicht gefunden --> muss man vermutlich errechnen.
Und hier beginnt das Drama erst richtig:
Denkbar wäre

Code Auswählen Erweitern

I_DC_Power - B_Instantaneous_Power - M_AC_POWER = Leistung vom Dach
Funktioniert aber nicht, weil die Readings über ZWEI Register (Wert und Skalierungsfaktor) gelesen werden.
Dies betrifft insbesondere M_AC_POWER - kommen falsche Werte rein.
Deswegen mein Umweg über SolarEdgeAPI (Reading "status-pv_power" alle 3 Min),
mit dem unschönen Effekt dass die Readings nicht Synchron sind.

Ich habe schon hier im Forum danach gefragt, aber habe ich offensichtlich meine Frage nicht richtig gestellt.

Mit besten Grüßen

Martin