Neueste Beiträge

#31

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 20 Juni 2025, 09:56:49

@Parallix,

mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.

Klar! Gerne!

Dann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.

Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.

Prima! Danke!

#32

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 20 Juni 2025, 09:49:50

@Parallix,

mit deinem Einverständnis würde ich deine Hinweise zur Batterie in #3204 gern in das Wiki übernehmen.

Dann würde man wohl die mittlere Leistung zeitlich in der Mitte des 1h-Intervalls ansetzen.

Ich baue mal ein Reading mit den mir im Modul gegebenen Möglichkeiten und dann schauen wir mal ob das Ergebnis den erwarteten Nutzen bringt.

@Wolle

Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

Momentan ist eine Regelung dieser Geräte nicht geplant. Dabei sind mehrere Aspekte zu berücksichtigen:

- die Varianten zur Steuerung bestimmter Eigenschaften in Invertern oder Batteriesystemen sind äußerst vielfältig und erfordern ein hohes
  Maß an im Modul zu hinterlegende Informationen die verwaltet und geprüft werden müssen

- unabhängig von den technisch/organisatorischen Herausforderungen gibt es auch die Frage nach einer Verantwortlichkeit wenn durch bestimmte Steuerungen,
  z.B. über Modbus, die Geräte in einen sagen wir mal "unerwünschten Zustand" versetzt werden.
  Ich möchte ungern eine derartige Zentralisierung im Modul herbeiführen. Allerdings sind solche Steuerungsmöglichkeiten immer optional, sodaß der
  User sie verwenden kann oder aber nicht wenn er eigene Logiken einsetzen möchte. Das ist ein Grundprinzip im Modul.

LG,
Heiko

#33

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 20 Juni 2025, 09:45:28

...
Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

Die Steuerung, ggf. auch Regelung, soll außerhalb von SF erfolgen, kann - in Teilen - natürlich von SF angestoßen und/oder mit Daten versorgt werden.  So jedenfalls hatte ich Heiko immer verstanden.. Darüber hinaus wird es ja auch künftig weitere, die Steuerung/Regelung steuernde Elemente geben, wie z.B. die Steuerbox.

#34

FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version ...

Letzter Beitrag von JoWiemann - 20 Juni 2025, 09:35:01

Hallo passibe,

danke für den Patch. Schaue ich mir an und werde das mal mit meinem FritzBox Zoo testen.

Grüße Jörg

#35

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 20 Juni 2025, 09:29:02

Besser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?

Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.

Dann würde man wohl die mittlere Leistung (Berechnung wie von Dir weiter oben angeben), zeitlich lokalisiert in der Mitte des 1h-Intervalls, heranziehen. Der Rest (linearer Ansatz) bliebe gleich.

[nicht aktiv steuernd]

#36

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Wolle02 - 20 Juni 2025, 09:28:00

ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.

Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.

Ok, danke. Irgendwie führt das bei mir immer wieder zu Missverständnissen. Dann fahre ich mal zweigleisig und regele die Batterie mit dem Skript und teile SF den Wert informatorisch mit.

Ist denn für die weitere Entwicklung angedacht die einzelnen Komponenten (WR, Bat) auch regeln zu können oder soll es bei den Consumern bleiben?

LG Wolle

#37

Solaranlagen / Aw: Modul für Ecoflow-Komponen...

Letzter Beitrag von Neolux - 20 Juni 2025, 09:14:28

Jetzt weiß ich, warum meine Delta2 gestern nicht aufgeladen wurde. 
Der MQTT-Server von ecoflow hatte also von 4:19 an Probleme, lief immer mal wieder, bis er schließlich bis jetzt seit 11:44 gar nicht mehr läuft. 
Läuft Eure HTTP-Rest-Methode wieder ?

Vorerst muss ich lokal über Bluetooth steuern. 

Grüße Markus

MQTT lief bei mir seit Januar generell nicht mehr. Deswegen hab ich mich ja mit dem HTTP-REST-API beschäftigt.
Und die läuft bei mir seit gestern 17 Uhr wieder. Aufgeladen wurden meine Batterien trotzdem, lediglich die 0-Einspeisung hat etwas gelitten, da die Abgabe des Powerstreams nicht nachgeregelt werden konnte.

So ein Steuerungsmodul über Bluetooth, das Daten lesen und schreiben kann, wär natürlich echt knorke... Hmmm...

#38

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 20 Juni 2025, 09:12:08

Besser wäre es meines Erachtens, wenn man sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen ansieht und daraus den zeitlichen Punkt ableitet, an dem die geforderte Mindestleistung unterschritten wird, oder?

Leistungsprognosen habe ich nicht zur Verfügung. Es gibt nur Prognosen der Energien, d.h. Verbräuche oder Erzeugungen, Einspeisungen etc. im 1h Raster.

#39

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 20 Juni 2025, 09:07:43

Moin zusammen,

@Parallix,
Motivation ist schon da.  Die Umsetzung braucht ein bisschen Vorbereitung.

Bloß kein Stress! Aktuell mache ich es noch händisch und komme mit max. zwei bis drei Anpassungen der Ladeleistung aus.

Was die letztgenannte Minimalleistung angeht, so ist diese natürlich nicht auf eine Stunde bezogen, sondern sollte in der zu betrachtenden Stunde möglichst nicht unterschritten werden.

Mein Aussage war so zu verstehen, dass ich um einen Vergleich mit der Anzahl der PV-Überschußstunden rechnen zu können, die Minimalleistung auf eine Stunde normieren muß um ebenfalls Wh zu bekommen. Anders gesagt, wenn die Bat mit der Minimalleistung von 50W eine Stunde lange geladen wird, sind das 50Wh. 
Wenn wir z.B. an einem Tag 10 Stunden ermitteln, in denen jeweils ein Überschüß >= 50Wh prognostiziert wird, hätten wir im Sinne der Anforderung einen Wert für Battery_ChargingHoursRemain_XX=10.

Das wäre m.M. nach die umzusetzende Logik zur Erstellung des Readings.

Dann bekäme man den Wert "nur" mit einer 1h-Auflösung am  PV-Produktionsende, oder?

Besser wäre es vermutlich, sich die zu erwartenden Leistungen am täglichen PV-Produktionsende an den 1h-Intervallgrenzen anzusehen und daraus den zeitlichen Punkt abzuleiten, an dem die geforderte Mindestleistung unterschritten wird.

Am PV-Produktionsstart (morgens) ist übrigens keine Sonderberechnung erforderlich, da man dort ja noch weit von SOC=100% entfernt ist.

[nicht aktiv steuernd]

#40

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 20 Juni 2025, 09:02:02

@Wolle02 / @all,

ganz allgemeine Aussage ... SF greift außer bei der Consumern nicht aktiv steuernd in die Wechselrichter oder Batteriesysteme ein.
Dazu braucht ihr stets eigene Skripte, die zum Beispiel über ctrlUserExitFn eingebunden werden können.

Die Angaben in den setup.*-Attributen dienen dazu, SF Informationen über die möglichen Leistungs- und weitere Parameter mitzuteilen. Wenn ihr also Leistungsparameter in den Invertern / Batterien (dynamisch) ändert, hinterlegt diese Anpassung auch immer über "set ... attrKeyVal" in SF damit diese Kennzahlen identisch gehalten werden.

LG,
Heiko