76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Hugo,

Welche Consumer, werden in welcher Reihenfolge abgeschaltet?
Gibt es da ein Timing? Oder eine Priorisierung?

Ja, in gewisser Weise. Die Consumer werden bei jeden Zyklus sequentiell aufsteigend entsprechend ihrer Nummer 01, 02, 03 ... behandelt.

Etwas OT, aber so ist mir das in den Kopf gekommen:
Meine Anforderung wäre, dass die Verbraucher in einer gewissen Reihenfolge abgeschaltet werden. (unabhängig von der Leistung)

Angedachte Lösung: Meine Überlegung wäre jetzt, dass ich interruptable vom jeweils vorherigen Verbraucher abhängig mache.

Das ist quasi eine Chain die aufgebaut werden soll. Kann man machen. Dazu kann man z.B. das auto-Reading benutzen.
Ausgangszustand: - auto für alle Consumer "on"
-> sind alle Consumer eingeschaltet? -> Ausschalten "auto" für alle Consumer außer dem "Master"
-> ist der Master beendet ("finished") ? -> "auto" für den nächsten Consumer wieder "on" schalten
-> ist dieser Consumer "finished" ? ->  "auto" für den nächsten Consumer wieder "on" schalten
-> usw. ....
-> wenn der letzte Consumer "finished" ist alle wieder auto "on"

Eine solche Logik kann man im ctrlUserExitFn einbauen.

Ist es bei surpmeth=median auch möglich eine Anzahl anzugeben? Wenn ja, wie?

Nein. Macht auch keinen Sinn. Median verwendet den mittleren Wert eines nach Größe geordneten Arrays aller gespeicherten Werte. Bei z.B. 7 vorhandenen Werten ist es der Wert an der 4. Stelle (Mitte bei ungeraden Zahlen). Bei gerader Anzahl der Werte ist es der Durchschnitt der beiden mittleren Werte, also z.B. Durchschnitt Wert 5 und 6 bei 10 vorhandenen Werten.

LG,
Heiko

[Burny4600]

Code Auswählen Erweitern

SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1

Ändert sich bei dir die Farbe des Energieflusses?
Bei mir ändert sich nur die Flussrichtung, aber der Beam bleibt immer grün.

[DS_Starter]

@all,

morgen gibt es nochmal ein Update.
ctrDebug ist um collectData_long ergänzt. Ich habe collectData aufgeteilt und ein Teil in collectData_long delegiert um die Übersicht des Debug zu verbessern. In collectData sind die Energie- und Leistungswerte enthalten. collectData_long ergänzt Infos zu Wetter- und Astrodaten, welche nicht so oft im Debug benötigt werden.

(Liegt auch im contrib)

LG,
Heiko

[Prof. Dr. Peter Henning]

Ich weiß nicht wen man sonst noch fragen könnte, da ja, soweit ich das verstehe, SF und FHEMWEB involviert sind. Du betreust ja SF, und wer ist verantwortlich für FHEMWEB ? Eventuell sehen 12 Augen mehr .... ??

Falscher Thread.

pah

[grappa24]

Code Auswählen Erweitern

SymGen24 icon=inverter@#ff8c00:inverter@grey strings=none ac2dc=PowerFlow_Site_P_DC_OUT:W dc2ac=PowerFlow_Site_P_DC_IN:W capacity=7680 asynchron=1

Ändert sich bei dir die Farbe des Energieflusses?
Bei mir ändert sich nur die Flussrichtung, aber der Beam bleibt immer grün.

auch bei mir ändert sich nur die Flußrichtung, allerdings "färbe" ich den Beam ja orange

[Burny4600]

auch bei mir ändert sich nur die Flußrichtung, allerdings "färbe" ich den Beam ja orange

Ich habe nun zwar zwei zusätzliche Inverter für die Batterieeinheiten, aber eine korrekte Berechnung des Energiebedarfs lässt sich so noch weniger darstellen.
Mit dieser Konfiguration werden alle Energieerzeuger addiert. Siehe Anhang.

Das stellt sich bei meinen Hybridinvertern etwas anders dar. Die Ladung der Batterien und die Generatoren dürfen aber nicht in den Verbrauch mit einbezogen werden. Da müsste ich in die SF-Berechnungen direkt eingreifen können um das zu korrigieren.

Bei meinen verwendeten Hybridinvertern gibt es Eingänge für die PV-Module, einen Ein- bzw. Ausgang für die Batterien (Nur DC), einen Eingang für den Generator (Nur AC) und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC).
Um das visuell und rechnerisch darzustellen, müssten Anpassungen gemacht werden. Zudem müssten die beiden Batterien getrennt in der Visualisierung dargestellt werden, und auch deren Berechnungen sind zu trennen.
Dazu müsste es neue feeds geben, die sowohl bei der Batterie und auch bei dem Producer zu ergänzen sind. Klingt einfach, ist es aber nicht, weil die bisherige SF Konfiguration komplett im Modul umgekrempelt werden müsste.

Dies Szenario könnte eigentlich so für meine Hybridinverter aussehen.
setupInverterDev01
Deye_12k_SFD icon=inverter@#0CFB0C:solar
strings=SuedOstDach,SuedWestWand
capacity=8700
pvIn=PV_Leistung__W:W
pvOut=Last__W:W
etotal=PV_Energie__kWh:kWh
limit=100
asynchron=1

setupBatteryDev01
Deye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=24000
feed=Inv1
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1

setupGeneratorDev01
AB_WG2KWD pcurr=Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
feed=Inv1
icon=Ventilator_wind@darkorange

setupUSVDev01
Out=USV__W:W
...............

####################################################################

setupInverterDev02
Deye_15k_SFD icon=inverter@#0CFB0C:solar
strings=SuedOstDach,SuedWestWand
capacity=13200
pvIn=PV_Leistung__W:W
pvOut=Last__W:W
etotal=PV_Energie__kWh:kWh
limit=100
asynchron=1

setupBatteryDev02
Deye_12k icon=@dyn:@dyn:@dyn:@dyn show=2:bottom label=beside cap=48000
feed=Inv2
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1

setupGeneratorDev02
AB_NS6KWD pcurr=Active_Power__W:W etotal=Active_Energy_Day__kWh:kWh
feed=Inv2
icon=sani_garden_pump@darkorange

setupUSVDev02
Out=USV__W:W
...............

[DS_Starter]

@all,

in meinem contrib liegt die V 1.54.4.

Mit dem Consumer Key 'aliasshort' kann man eine Kurzbeschreibung der Consumer in der Flußgrafik einblenden.
Es stehen dafür 10 Zeichen (keine Leerzeichen) zur Verfügung.
Je nach Anzahl eurer Consumer müsst ihr evtl. mit flowGraphicControl die Grafik passend einrichten.

Das Beispiel in meinem Screenshot arbeitet mit:

Code Auswählen Erweitern

size=480
animate=1
homenodedyncol=1
consumerdist=160
strokeconsumerdyncol=1
h2consumerdist=20
strokewidth=17
showGenerators=1

LG,
Heiko

[DS_Starter]

@Chris,

Ich habe nun zwar zwei zusätzliche Inverter für die Batterieeinheiten, aber eine korrekte Berechnung des Energiebedarfs lässt sich so noch weniger darstellen.
Mit dieser Konfiguration werden alle Energieerzeuger addiert. Siehe Anhang.

Dann stimmt aber noch etwas im Setup nicht. Die Flüsse der Batterieinverter werden vom Knoten subtrahiert sofern die Laufrichtung (d.h. In/Out) richtig verwendet wird.
Leider sehe ich das Setup der Batterieinverter nicht.

Meiner sieht z.B. so aus:

Code Auswählen Erweitern

MQTT2_cerboGX_c0619ab34e08_vebus 
dc2ac=DC_IN:W
ac2dc=DC_OUT:W
capacity=7200
strings=none
asynchron=0

DC_IN und DC_OUT sind userReadings die je nach Vorzeichen der Quelle .../vebus/276/Dc/0/Power in der Quelle erzeugt werden.

D.h. erzeugen deine Inverter Strom, wird der entsprechende Batterie-In-Wert vom Verbrauch abgezogen (Wiki).

Man kann die einzelnen Bestandteile mit ctrlDebug=collectData (mit der aktuellen Version) ganz gut verfolgen:

Code Auswählen Erweitern

...
2025.07.20 18:20:44.866 1: SolCast DEBUG> current Power values -> PV2Node: 1195 W, PV2Grid: 0, Other: 0 W, GridIn: 327 W, GridCon: 0 W, BatIn: 0 W, BatOut: 10 W
2025.07.20 18:20:44.867 1: SolCast DEBUG> current Consumption result -> 878 W
...


Die Ladung der Batterien und die Generatoren dürfen aber nicht in den Verbrauch mit einbezogen werden. Da müsste ich in die SF-Berechnungen direkt eingreifen können um das zu korrigieren.

Bezüglich der Generatoren bin ich anderer Meinung. Sofern sie Energie liefern, ist diese als Input in den Verbrauch mit einzubeziehen. Batterien siehe oben.
Ich sehe aktuell nichts was diesbezüglich korrigiert werden müßte.

Zudem müssten die beiden Batterien getrennt in der Visualisierung dargestellt werden, und auch deren Berechnungen sind zu trennen.

Intern werden alle Batterien getrennt gerechnet. Nur in der Flußdarstellung sind alle Bat zusammengefasst.
Die Anteile der Batterien an In/Out werden über die oben erwähnten (virtuellen) Batterieinverter zusammengefügt.

Bei meinen verwendeten Hybridinvertern gibt es Eingänge für die PV-Module, einen Ein- bzw. Ausgang für die Batterien (Nur DC), einen Eingang für den Generator (Nur AC) und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC).

einen Ein- bzw. Ausgang für die Batterien (Nur DC) -> den wirst du sicherlich für die virtuellen Batterieinverter nutzen -> wenn ja, daraus userReadings erstellen die wie oben beschrieben In/Out jeweils als positiven Werte bereitstellen.

einen Eingang für den Generator (Nur AC) -> den verwendest du für deinen (virtuellen) OtherProducer

und einen Ein- bzw. Ausgang für die Last (nur AC inklusive Grid) und einen Ausgang für die USV Verbraucher (nur AC) -> die wirst du auch zusammenfassen müssen, beide gehen als Lieferung an den Inverterknoten ein.

LG,
Heiko


 

[hugomckinley]

Zitat
    Ist es bei surpmeth=median auch möglich eine Anzahl anzugeben? Wenn ja, wie?

Nein. Macht auch keinen Sinn. Median verwendet den mittleren Wert eines nach Größe geordneten Arrays aller gespeicherten Werte. Bei z.B. 7 vorhandenen Werten ist es der Wert an der 4. Stelle (Mitte bei ungeraden Zahlen). Bei gerader Anzahl der Werte ist es der Durchschnitt der beiden mittleren Werte, also z.B. Durchschnitt Wert 5 und 6 bei 10 vorhandenen Werten.

Das würde schon Sinn machen meiner Meinung nach. In der Commandref steht, dass bis zu 20 Werte für den Median genutzt werden. Das würde bei einer Zykluszeit von 60sec bedeuten, dass bis zu 20 Minuten für die Bildung des Medians genutzt werden.
Wenn es beispielsweise folgende Werte sind: 1500, 1200, 1500, 1200, 1500, 1800, 2700, 3100, 3200, 3400, 4700, 4800, 5000
Bilde ich den Median über alle 13 Werte (13 Minuten) ist das 2700
Bilde ich aber den Median über die letzten 5 Werte (nur die letzten 5 Minuten) ist das schon 4700
Somit kann ich den Schwankungen des Ertrags wesentlich schneller folgen, aber trotzdem Ausreißer halbwegs ausbügeln.
Wenn der Median aber über 20 Minuten gebildet wird ist er sehr träge und noch dazu steht bis zu 20, was es noch dazu recht undefinierbar macht.

Habe ich da einen Denkfehler, oder wäre es schon sinnvoll, wenn man die Anzahl der Werte einschränken (festlegen) kann?

[DS_Starter]

und noch dazu steht bis zu 20, was es noch dazu recht undefinierbar macht.

Das "bis zu" bedeutet, dass z.B. bei einem Restart das Array erst aufgebaut werden muß da es ja nicht vorhanden ist. Wenn es voll aufgebaut ist, sind es 20 Werte.

Bilde ich aber den Median über die letzten 5 Werte (nur die letzten 5 Minuten) ist das schon 4700
Somit kann ich den Schwankungen des Ertrags wesentlich schneller folgen, aber trotzdem Ausreißer halbwegs ausbügeln.

So gesehen hast du Recht. Mir war der Glättungsgedanke wichtiger.

Ich mache mir ein paar Gedanken wie ich 'median' ergänzen könnte.

 

[hugomckinley]

Ich mache mir ein paar Gedanken wie ich 'median' ergänzen könnte.

Es wäre toll, wenn man auf diesen Wert dann auch zugreifen könnte. Pro Consumer wäre perfekt, das würde (fast) genau meinen Anwendungsfall abbilden.
Ich bügle Ausreißer in beide Richtungen (recht erfolgreich) mit den Waittimern von DOIF weg. z.B.: War der Überschuss in den letzten x Minuten immer über 1800W, dann schalte die Poolheizung ein.
Wenn der Zeitraum etwas länger ist, sollte das ein kurzer Zeitbereich beim Median aber genauso abbilden. Das ist dann glaube ich nur mehr herumprobieren mit den Werten, bis sich das ähnlich verhält.

[DS_Starter]

Es wäre toll, wenn man auf diesen Wert dann auch zugreifen könnte. Pro Consumer wäre perfekt, das würde (fast) genau meinen Anwendungsfall abbilden.

Wie meinst du das? Weil über den Schlüssel surpmeth kannst du es doch spezifisch für jeden Consumer einstellen.

Den Wertevorrat kann man sich jetzt schon anschauen bzw. programmtechnisch auslesen. Es ist der Schlüssel surplusslidereg im "get ... valCurrent".
Per Programm kommt man mit "CurrentVal ('<Name>', 'surplusslidereg', <default>)" an die Werte (Wiki). In diesem Fall wird eine Array-Referenz geliefert welche dann zu dereferenzieren ist.