76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

dein Vorschlag ist gut und ich habe acuh schon über eine Zusamenfassung der String-Attribute nachgedacht. Allerdings ist es nicht so einfach, vor allem unter dem Aspekt unbekannte Anzahl Strings, deren Bezeichnungen und der Fehleranfälligkeit der Eingaben.

Deswegen gibt es auch grafisch im Flow nur die zusammengesetzte "Solarzelle". Es besteht die Herausforderung eine tendenziell unbekannte Anzahl zugeordneter Strings grafisch optimal über den bis zu X Invertern zu positionieren.
Deshalb vorerst nur so, auch wenn ich um die Schwäche dieser Ansicht weiß.

Aber über ein neue Struktur der Stringsattribute mache ich mir als erstes Gedanken. Das ist eine Grundlage für weitere Ausbauten.

Das würde/wird dann z.B. bei mir ganz schön anstrengend werden die vernünftig darzustellen:
3 WR / 2 x 2 Strings / 1 x 3 String 

Gott sei Dank ist die Brennstoffzelle inzwischen bei mir schon mal weggefallen 

Gruß
300P

[DS_Starter]

Genau deswegen 

[peterboeckmann]

Das würde/wird dann z.B. bei mir ganz schön anstrengend werden die vernünftig darzustellen:
3 WR / 2 x 2 Strings / 1 x 3 String 

Das sehe ich ein. Zumal dann, wenn man die einzelnen Leistungen nicht abbilden kann oder möchte.

@Heiko:
Vielleicht ist die Konfiguration der Strings weniger fehleranfällig, wenn sie amalog zu den Verbrauchern erfolgt?

Code Auswählen Erweitern

attr setupString01...
attr setupString02...
etc.


[DS_Starter]

Vielleicht ist die Konfiguration der Strings weniger fehleranfällig, wenn sie amalog zu den Verbrauchern erfolgt?

Ja, allerdings habe ich die max. Anzahl Consumer vorgegeben und ich weiß was mich max. erwartet. Bei den Strings ist der User frei.
Eine Unbekannte für mich. Ich könnte sie beschneiden, möchte ich aber nicht. (Aber vllt. nicht zu umgehen, mal sehen)
Dann steht die Frage im Raum wieviel man max. braucht, 10 Strings vllt.? Keine Ahnung was es so allgemein gibt.

[tobi01001]

Das sollte jetzt nicht mehr so sein, außer in dem Fall wenn die Batterie aus dem Hausnetz direkt geladen wird und man keinen reinen Batteriewechselrichter, der diese Funktion übernimmt, per Attribut implementiert hat.

Ja, genau. Mein "Problem":

• die untere Flusslinie zwischen Batterie und Haus wird nicht mehr verwndet aber dennoch angezeigt.
• ohne showGenerators sehe ich nur eine Sonne als WR und da nur die Summe der Leistung aus Batterie und Solar. Was der WR halt gerade an Leistung ausgibt. Aber die reine solarpower wird nur mit showGenerators angezeigt.

Das fand ich vorher übersichtlicher und schöner (beides etwas subjektiv). Da war ich mir nicht sicher ob das so gewollt ist... Aber Falls ja, baue ich mir meinen Weg drumrum...

[EDIT]: Man müsste/könnte die Batterie(n) dann auch oben wie die Strings als Eingangsgröße für den WR hinsetzen. Sind ja aus Sicht WR dann auch Erzeuger (und "Verbraucher" in die andere Richtung).

[peterboeckmann]

Hallo Heiko,

Dann steht die Frage im Raum wieviel man max. braucht, 10 Strings vllt.? Keine Ahnung was es so allgemein gibt.

aus Symmetriegründen wurde ich 16 vorschlagen, wie bei den Verbrauchern.
Also, falls du dich für die Begrenzung entscheidest.

Viele Grüße,
Peter

[DS_Starter]

@Tobias,

schau mal im Anhang. So sähe es "normalerweise" aus wenn ich nicht künstlich den Knoten sparen würde. Mit und ohne Batterie-Wechselrichter.
Das wäre m.M. nach besser und für mich auch einfacher in Zukunft. Braucht halt etwas mehr Platz. Die Stringebene kann man ausblende, dadurch ändert sich nichts am grundlegenden Aufbau.

[Burny4600]

Ich habe noch ein Paar Fragen zur Visualisierung.

Im Anhang habe ich eine Übersicht zusammengestellt, wie die Energieflüsse bei mir sind. Ich weis es ist betreffend Hybridinverter noch nichts fertig, aber vieleicht habe ich einen Denkfehler bei der Visualisierung der Stromflüsse. ÜberscihtIst.png ist die aktuelle Ansicht der Konfiguartion.

Bei den Verbrauchern habe ich jedenfalls einen Konfigurationsfehler, und komme nicht darauf woran es liegt.
Es wird kein Stromfluss, kein Status und kein Verbrauch angezeigt.

ZB: Wärmepumpe der mittels Dummy eingebunden wird.
list HZG_WPD

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/myprogram/energiemanagement_rasp02.pm
   FUUID      6822145f-f33f-f4d2-a327-12d2bcbaa47ad659
   NAME       HZG_WPD
   NR         1922
   STATE     
<b>
<br>
    <span style='color:#00FFFF'>Verbrauch aktueller<span style='color:transparent'>..............<span style='color:#00FFFF'>26.2 W
<br>
    <span style='color:#C90076'>Verbrauch Energie heute<span style='color:transparent'>......<span style='color:#C90076'>-2940.611 kWh
<br>
</b></span>

   TYPE       dummy
   eventCount 1083
   READINGS:
     2025-05-13 12:01:03   Active_Energy_Day__kWh -2940.611
     2025-05-13 12:01:03   Active_Power__W 26.2
     2025-05-13 12:01:03   state           EIN
Attributes:
   alias      AP Garage Ost - Heizung - Wärmepumpe
   cmdIcon    EIN:remotecontrol/black_btn_GREEN AUS:remotecontrol/black_btn_RED
   devStateIcon EIN:sani_heating_heatpump@0CFB0C AUS:sani_heating_heatpump@gray
   devStateStyle style="text-align:left;;font-weight:bold;;"
   icon       sani_heating_heatpump
   room       Energiemanagement,Heizung
   stateFormat {
my $ap=ReadingsNum($name,'Active_Power__W',0);


my $aed=ReadingsNum($name,'Active_Energy_Day__kWh',0);

"
<b>
<br>
    <span style='color:#00FFFF'>Verbrauch aktueller<span style='color:transparent'>..............<span style='color:#00FFFF'>$ap W
<br>
    <span style='color:#C90076'>Verbrauch Energie heute<span style='color:transparent'>......<span style='color:#C90076'>$aed kWh
<br>
</b></span>
"
}
   webCmd     ::EIN:AUS
Forecast Definition Wärmepumpe consumer01

Code Auswählen Erweitern

HZG_WPD:Wärmepumpe type=noSchedule icon=sani_heating_heatpump
power=0 pcurr:Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
on=EIN off=AUS swstate=state:EIN:AUS auto=0
asynchron=1
Forecast Reading consumer02

Code Auswählen Erweitern

.........
consumer01 name='Wärmepumpe' state='on' mode='can' planningstate='noSchedule' 2025-05-13 12:02:11
consumer01_currentPower 0 W  2025-05-13 12:02:11
......
Aus irgendeinen Grund ändert sich der aktuelle Zustand nicht. Auch die Werte der Readings Active_Power__W und Active_Energy_Day__kWh aus dem Dummy werden nicht übernommen. etotal=Active_Energy_Day__kWh:kWh fehlt zur Gänze.

[DS_Starter]

@Chris,

die Inverterdefinition ist nicht richtig. Du hast sicherlich feed=bat gesetzt, was einen Batteriewechselrichter kennzeichnet. Außerdem müsstest du die jeweils 2 Strings den 2 WR zuweisen (nicht 4 PV-WR). Zukünftig wird es ein feed=hybrid geben um Hybridwechselrichter zu implementieren.
Für eine Übergangszeit könntest du zusätzliche reine Batteriewechselrichter versuchen einzubauen um die Flüsse von/zu den Batterien nachzubilden. Die Batterien werden generell als Batteriepack dargestellt, nicht einzeln an den WR.

Bzgl. Consumer liegt das Problem wahrscheinlich in zwei Fehlern:

- Active_Energy_Day__kWh -2940.611 hat einen negativen Verbrauchswert -> soll positiv sein (negativer Verbrauch wäre für mich "Erzeugung")
- Syntaxfehler pcurr:Active_Power__W:W -> pcurr=Active_Power__W:W

Grüße,
Heiko

[Burny4600]

Dummer Sysntax-Fehler.
Das mit dem feed=bat stimmt. Ich wollte nur sehen ob sich da schon etwas geändert hat.

Die Syntax für zwei Strings pro Wechselrichter habe ich noch nicht verstanden wie diese aussehen sollte.

Code Auswählen Erweitern

Deye_12k strings=SüdOstDach,SüdWestWand icon=inverter@red:solar capacity=1960
pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh
asynchron=1
limit=100
Beim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.


Bei Active_Energy_Day__kWh -2940.611 hatte ich den falschen Wert herangezogen, aber es kann sein das die Eastronzähler 0.0 oder -0.0 anzeigen wenn zB. die Waschmaschine nicht läuft.
Da muss ich mir beim Dummy noch etwas einfallen lassen.

[DS_Starter]

Beim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.

Die Strings werden einzeln gerechnet bzw. über die API abgefragt um die Lage/Ausrichtung/Stringleistung spezifisch für den String zu berücksichtigen. Die ermittelten Leistungsprognosen wird dann ggf. mit gelernten Korrekturfaktoren und/oder KI-Prognosen bewertet. Daraus ergibt sich eine Summe die <= dem capacity Wert sein muß sonst wird sie gekappt. capacity hat in diesem Kontext lediglich die Funktion einer worst case Begrenzung nach oben, alles andere obliegt den beschriebenen Mechanismen.
 

[300P]

Die Syntax für zwei Strings pro Wechselrichter habe ich noch nicht verstanden wie diese aussehen sollte.

Code Auswählen Erweitern

Deye_12k strings=SüdOstDach,SüdWestWand icon=inverter@red:solar capacity=1960
pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh
asynchron=1
limit=100
Beim Parameter string ist es klar strings=SüdOstDach,SüdWestWand aber wie gehe ich mit den Leistungswerten der einzelnen Strings um.
Der Parameter capacity ist auch klar das ich hier beide Strings summmieren muss. Das ergibt aber ein Problem wenn die Strings unterschiedliche Leistungen bzw. Ausrichtung haben.
Oder es sind Verschattungen gegeben, wie es bei mir bei SüdWestDach1 und SüdWestDach2 mit untergehender Sonne geschieht.

Hier zur Erklärung mein SB40 (mit 3 Strings - aufgeteilt wegen der verschiedenen sich ergebenden Verschattung.
Vielleicht wird es dadurch klarer:

max. Leistung WR = 4000 W
String HausSE1 = 2.100 kWp
String HausSE2 = 2.100 kWp
String HausSW  = 2.230 kWp
==========================
Summe aller Strings = 6.430 kWp

==> unter dem erlaubten Summenwert aller angeschlossenen Strings des WR soweit ich es kenne

Code Auswählen Erweitern

attr Forecast setupInverterDev03 SB40 pv=total_pac:kW etotal=etotal:kWh capacity=4000 strings=HausSE1,HausSE2,HausSW limit=100 asynchron=0

attr Forecast setupStringAzimuth GarageSE=-55 GarageNW=135 HausNW=135 HausSW=35 HausSE1=-55 HausSE2=-55
attr Forecast setupStringDeclination GarageSE=38 GarageNW=38 HausNW=48 HausSW=48 HausSE1=48 HausSE2=48
attr Forecast setupStringPeak GarageSE=2.75 GarageNW=3.200 HausNW=2.230 HausSW=2.230 HausSE1=2.100 HausSE2=2.100
aGruß
300P

[300P]

Das ergibt dann am Wechselrichter diese meßbaren 2 wirklichen Strings:
(siehe Screenshot1)

Aber beim SB40 auf der Phase 3 dann (max 4 kw):
(siehe Screenshot2)

[Burny4600]

Und die fasst in einem Unterprogram die 3 Strings zusammen woraus sich dann ein total_pac und etotal für die 3 Strings ergibt.

[DS_Starter]

In SF werden die Einzelanteile der angeschlossenen und berechneten Strings in eine resultierende Gesamtsumme für die Prognose zusammengefasst.
total_pac und etotal ist ja der gemessene/gelieferte Output des WR und aus Sicht des Moduls unabhängig davon welche Strings angeschlossen sind.

EDIT: @Chris, gerade gesehen:   "pv=PV1_Leistung__W,PV2_Leistung__W:W etotal=PV1_Energie_Heute__kWh,PV2_Energie_Heute__kWh:kWh" ist falsch.  Nur  "pv=total_pac:W etotal=etotal:kWh". d.h. die aktuelle Leistung des WR -> Hausnetz und seine gesamte kumulierte erzeugte Energie.