76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ich habe das Reading Battery_TargetAchievable_XX implementiert und das Contrib upgedated.

[Hadl]

Ich habe das Reading Battery_TargetAchievable_XX implementiert und das Contrib upgedated.

Super, vielen Dank!
Habs gleich aktualisiert!

[klaus.schauer]

Perspektivisch werde ich dann wahrscheinlich, wie von Parallix vorgeschlagen, die True/False-Readings Battery_ChargeAbort_XX, Battery_ChargeRequest_XX, Battery_ChargeUnrestricted_XX und dem noch hinzukommenden Battery_TargetAchievable_XX ein zusammengefasstes Reading Battery_Status_XX erstellen.

Aber das muß ich erst in Ruhe entwickeln wenn ich mal viel Zeit und Lust zu einer solchen Änderung habe. Es muß ja auch gut erkennbar und auswertbar sein -> Zukunftsmusik.
Anwendungsseitig problematisch bei zusammengetzten Readings ist vor allem, dass es keinen Bezug mehr gibt wenn man NUR für einen bestimmten Sachverhalt, z.B. Battery_ChargeAbort_XX, einen Event haben möchte. 

Ich halte eine (bitcodierte) Zusammenführung der Readings in ein kombiniertes für kontraproduktiv. Der geneigte Anwender darf dieses dann wieder durch Bitoperationen nach Studium einer Anleitung filetieren, welch ein Fortschritt! In einer Datenbank würde man auch nicht ohne Not Vor- und Nachname zusammenführen und später rätseln, was denn nun der Vor- oder Nachname von Thomas Anton ist.
Die vorhandenen Readings kann man doch vollkommen problemlos programmtechnisch abfragen. Gib es nicht sinnvollere Aufgaben als eine solche Änderung für den Entwickler und die Anwender?

[DS_Starter]

Gib es nicht sinnvollere Aufgaben als eine solche Änderung für den Entwickler und die Anwender?

Vollkommen richtig und du kannst sicher sein, dass ich mir soetwas mehrmals durch den Kopf gehen lassen werde. Zur Zeit habe ich ganz andere Prämissen. Und wie du vllt. auch gelesen hast gibt es schwerwiegende Gründe dies nicht zu tun. Denn ich sehe genau wie du die Probleme die damit zusammenhängen würden, nämlich die Auswertung und das Eventmanagement.
Ês gäbe Vorteile, doch die unbestrittenen Nachteile überwiegen zur Zeit. Jedoch darf es gestattet sein darüber mal nachzudenken und abzuwägen.

[DS_Starter]

Ich habe noch ein wenig an der Batterie Ladungsprognose verbessert. Es hat keinen Einfluß auf die Einstellung der Ladeleistung in der aktuellen Stunde, aber für die Ladeplanung in der Zukunft, also der Prognose die man auch in der Grafik sieht.

Liegt im Contrib.

LG

[oelidoc]

Ich weiss nicht, so lange die Vorhersage so schlecht ist, braucht man sich um die Batteriesteuerung wohl keine Gedanken zu machen....

Keine Ahnung was da los ist.

Gruß

oelidoc
Du darfst diesen Dateianhang nicht ansehen.

[DS_Starter]

Na das geht doch noch 
Bei mir gibt es derzeit natürlich auch starke Ausschläge plus/minus.
Da ich mehrere Devices zum Vergleich laufen habe, kann ich sagen dass auch die Datenlieferungen der Dienste recht unterschiedlich zutreffend sind. Ich bin ja nach wie vor ein Fan des SolCast Dienstes der gestern bei -33% landete, aber heute wieder nur -1,4% (roter Plot). Evtl. frage ich dort mal nach was ein Abo für den Privatmann kosten würde, es werden m.M. nach wirklich gute Daten geliefert.

Die OpenMeteo Daten liegen leider weiter daneben, der blaue Plot zeigt die OpenMeteo DWD ICON Abweichungen und der rosa Plot die OpenMeteo Ensemble Abweichungen.

Bei der DWD (Device) Prognose liege ich bei 16,8 / 16,2% gestern/heute. Hier ist die Einstellung "on_complex_ai", die anderen nur "on_complex".
Naja, morgen ist ein recht sonniger Tag prophezeit ... da wird es sicher wieder besser. 

LG,
Heiko

[DS_Starter]

Guten Morgen,

ich habe die aktuelle Contrib-Version eingecheckt und die V 1.59.5 wird morgen früh im Update enthalten sein. Der Inhalt ist in #4254 zusammengefasst. Das Wiki habe ich auch bereits nachgezogen. Wenn etwas fehlen sollte gebt mir bitte einen Hinweis.

Ansonsten sieht es bei mir heute wie prognostiziert deutlich sonniger aus. Die Batteriesteuerung habe ich auf 'smartPower' gestellt und den im Wiki hinterlegten Code zur Anwendung in meiner Batterie im Einsatz.

Gegen 17:00 sagt die Ladungsprognose die Zielerreichung (28416 Wh) voraus:

Code Auswählen Erweitern

2025.10.18 10:13:36.992 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.10.18 10:13:36.992 1: SolCast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2025.10.18 10:13:36.993 1: SolCast DEBUG> ChargeOTP Bat 01 - weighted self-consumption: 0 %
2025.10.18 10:13:36.993 1: SolCast DEBUG> ChargeOTP Bat 01 - charging target: 28416 Wh, remaining: 19039 Wh -> target likely achievable? yes
2025.10.18 10:13:36.993 1: SolCast DEBUG> ChargeOTP Bat 01 18/10 - hod: 11 / 00, lr/lc: 1/1, SoC S/E: 9377 / 13510 Wh, Surplus: 5554 Wh, OTP: 4216 W
2025.10.18 10:13:36.994 1: SolCast DEBUG> ChargeOTP Bat 01 18/11 - hod: 12 / 01, lr/lc: 1/1, SoC S/E: 13510 / 14796 Wh, Surplus: 1354 Wh, OTP: 1625 W
2025.10.18 10:13:36.994 1: SolCast DEBUG> ChargeOTP Bat 01 18/12 - hod: 13 / 02, lr/lc: 1/1, SoC S/E: 14796 / 17810 Wh, Surplus: 5108 Wh, OTP: 3173 W
2025.10.18 10:13:36.994 1: SolCast DEBUG> ChargeOTP Bat 01 18/13 - hod: 14 / 03, lr/lc: 1/1, SoC S/E: 17810 / 20683 Wh, Surplus: 6177 Wh, OTP: 3024 W
2025.10.18 10:13:36.995 1: SolCast DEBUG> ChargeOTP Bat 01 18/14 - hod: 15 / 04, lr/lc: 1/1, SoC S/E: 20683 / 23409 Wh, Surplus: 3818 Wh, OTP: 2869 W
2025.10.18 10:13:36.995 1: SolCast DEBUG> ChargeOTP Bat 01 18/15 - hod: 16 / 05, lr/lc: 1/1, SoC S/E: 23409 / 25945 Wh, Surplus: 3368 Wh, OTP: 2669 W
2025.10.18 10:13:36.995 1: SolCast DEBUG> ChargeOTP Bat 01 18/16 - hod: 17 / 06, lr/lc: 1/1, SoC S/E: 25945 / 28123 Wh, Surplus: 2486 Wh, OTP: 2293 W
2025.10.18 10:13:36.996 1: SolCast DEBUG> ChargeOTP Bat 01 18/17 - hod: 18 / 07, lr/lc: 1/1, SoC S/E: 28123 / 28416 Wh, Surplus: 559 Wh, OTP: 720 W
2025.10.18 10:13:36.996 1: SolCast DEBUG> ChargeOTP Bat 01 18/18 - hod: 19 / 08, lr/lc: 0/1, SoC S/E: 28416 / 27825 Wh, Surplus: 0 Wh, OTP: 0 W
2025.10.18 10:13:36.996 1: SolCast DEBUG> ChargeOTP Bat 01 18/19 - hod: 20 / 09, lr/lc: 1/1, SoC S/E: 27825 / 27181 Wh, Surplus: 0 Wh, OTP: 5040 W
...

Auch die Kurve der OTP-Steuerung (graue Linie) im Screenshot sieht gut aus.
Mal sehen wie es sich über den Tag ausspielt.

LG,
Heiko

[300P]

Ja- auch bei mir endlich mal wieder nach Wochen mehr als die "trübe nebelige Suppe" vor der Sonne.
...und 100 % und mehr als erwartet / prognostiziert!!

Leider nur Heute...die nächste Woche ist wieder die gleiche Suppe und viel Regen hier im Sauerland     

[Parallix]

Auch wenn ich sie noch nicht alle ausprobieren konnte, so bereichern die neuen Features SF nochmals!

Derzeit an meinem Wallbox-Ladecontroller arbeitend, möchte anregen, SF wie folgt zu erweitern:

Um Wallboxen (aber auch andere Verbrauchseinrichtungen, deren Leistungsaufnahme gesteuert werden kann) besser in SF abbilden zu können, muss der entsprechende Consumer neben consumerXX→power (gem. Doku die (Nenn-) Leistung lt. Datenblatt)  auch noch durch eine minimale Ladeleistung   consumerXX→minPower beschrieben werden können, die angibt, ab welcher minimalen Leistung ein Betrieb möglich ist. Darüber hinaus sollte auch noch Mindestüberschussleistungen angegeben werden können, ab der der Consumer eingeschaltet wird (consumerXX→minOnPower) oder ab der die Einschaltung ausgeschaltet oder unterbrochen wird (consumerXX→minOffPower).

Alle Consumer erhalten eine Priorität (consumerXX→prio). Auf Basis dieser Prioritäten kann dann bei einem prognostizierter Überschuss in SF geplant werden, welche Can-Consumer in welcher Reihenfolge in der Verbrauchsprognose als eingeschaltet zu betrachten ist, um diesen Überschuss zu konsumieren. Besitzen zwei oder mehrere Can-Consumer die gleiche Priorität so werden diese planungstechnisch alternierend, jeweils für eine Zeit consumerXX→quantum < consumerXX→mintime  eingeschaltet, berücksichtigt.

[DS_Starter]

Guten Morgen,

das sind alles sinnvolle Erweiterungen die m.M. bereits jetzt zumindest teilweise vom User umgesetzt werden können.
Deswegen möchte ich vorab ein paar Dinge mit den interessierten Usern diskutieren.

1.) eine Priorität (consumerXX→prio) ist als Key aktuell nicht enthalten, jedoch wird durch die Consumernummer
    die Prio implizit ausgeübt. Consumer 01 hat dabei die höchste Prio. Damit kann man arbeiten, wobei es
    dadurch nicht/schlecht möglich ist die Prio zwischen den Consumern dynamisch abzuändern. In den meisten
    Fällen sollte diese Möglichkeit jedoch ausreichen.

2.) die Fälle in denen man den Betrieb eines Verbrauchers unterbinden möchte oder erst unter bestimmten
    Bedingungen (ein)geschaltet werden soll, sind bereits jetzt schon gegeben.
    Hier führe ich vor allem die Keys consumerXX→swoncond, swoffcond, interruptable, auto an, über die
    Bedingungen wie in den angeführten Beispielen:

    - ...Mindestüberschussleistungen angegeben werden können, ab der der Consumer eingeschaltet wird (consumerXX→minOnPower)
    - ...der ab der die Einschaltung ausgeschaltet oder unterbrochen wird (consumerXX→minOffPower)

    umgesetzt werden können.
   
    Die Schlüssel swoncond, swoffcond sind zwar allgemeiner Natur, können jedoch die beschriebenen Bedingungen
    abbilden. Würde ich nun speziell für den Consumertyp "charger" die von Parallix beschriebenen Keys
    einführen, gäbe es Doppelungen/Überschneidungen die unter Umständen mit den Angaben in den Schlüsseln
    swoncond, swoffcond in Konkurrenz stehen und zu einem schwer zu diagnostizierbaren Fehlverhalten führen
    könnten.

Da ich selbst keinen solchen Anwendungsfall habe, interessieren mich die Meinungen und Erfahrungen von euch bevor ich an diesen Stellen aktiv werde.

LG,
Heiko
   
   

[DS_Starter]

Noch eine Frage an User mit mehreren Batterien.
Mit der V 1.59.5 bzw. der contrib-Version hatte ich ja die Ladesteuerung der Batterien abhängig vom anteiligen Ladebedarf am Gesamtladebedarf gestaltet. Vorher war die installierte Batteriekapazität das Aufteilungskriterium. Gibt es bereits Erfahrungen/Erkenntnisse mit dieser Änderung die m.M. nach das Ladeverhalten bei mehreren Batterien verbessern sollte.

[Parallix]

Noch eine Frage an User mit mehreren Batterien.
Mit der V 1.59.5 bzw. der contrib-Version hatte ich ja die Ladesteuerung der Batterien abhängig vom anteiligen Ladebedarf am Gesamtladebedarf gestaltet. Vorher war die installierte Batteriekapazität das Aufteilungskriterium. Gibt es bereits Erfahrungen/Erkenntnisse mit dieser Änderung die m.M. nach das Ladeverhalten bei mehreren Batterien verbessern sollte.

Hier teste ich aktuell noch. Da erst kürzlich eine "Wartung" erfolgte, haben meine Speicher nahezu den gleichen Ladestand. Das wird sich sicher die nächsten Tage ändern. Bislang verhält sich alles erwartungsgemäß, SF arbeitet also phantastisch!

Edit:

...
1.) eine Priorität (consumerXX→prio) ist als Key aktuell nicht enthalten, jedoch wird durch die Consumernummer
    die Prio implizit ausgeübt. Consumer 01 hat dabei die höchste Prio. Damit kann man arbeiten, wobei es
    dadurch nicht/schlecht möglich ist die Prio zwischen den Consumern dynamisch abzuändern.
...

Derzeit lassen sich auch gleiche Prioräten nicht abbilden. Das ist aktuell absolut nicht dringend, aber etwas, was man vielleicht irgendwann einmal haben möchte, insb. auch in Bezug auf die Verbrauchsprognose.

...
2.) die Fälle in denen man den Betrieb eines Verbrauchers unterbinden möchte oder erst unter bestimmten
    Bedingungen (ein)geschaltet werden soll, sind bereits jetzt schon gegeben.
...

Hier hast Du mich (teilweise) falsch verstanden. Es geht mir primär um die Berücksichtigung der o.g. Dinge bei der Verbrauchsprognose und nicht erst dann, wenn der Zeitpunkt des Einschaltens gekommen ist!

[DS_Starter]

Derzeit lassen sich auch gleiche Prioräten nicht abbilden.
...

Genau gleiche Prios kann ich nicht abbilden. Die Consumer bzw. technisch die Elemente des Arrays der Consumer werden immer sequentiell nacheinander behandelt, sowohl bei der Einplanung als auch der Schaltung.
Lediglich die Reihenfolge der Elemente des Arrays kann ich nach bestimmten Kriterien, z.B. einem Prio-Key, verändern. Zur Zeit ist diese Reihenfolge durch die Consumernummer gegeben.

Wenn man also den Consumern einen identischen Prio-Key setzen würde, käme eine weitere Nebenbedingung für die Reihenfolge im Array zum Tragen, nämlich die Consumernummer. Hätte Consumer01 und Consumer02 eine identische Prio=1, würde sich die Reihenfolge durch die ID 01 -> Id 02 usw. ergeben.
Natürlich könnte ich noch eine Zusatzbedingung implementieren, z.B. wenn Co01: Prio=1 und C02: Prio=1 dann nimm den Consumer der die höchste nominale Power angeben hat.

Das ist alles machbar. Status quo ist wie oben beschrieben.

Hier hast Du mich (teilweise) falsch verstanden. Es geht mir primär um die Berücksichtigung der o.g. Dinge bei der Verbrauchsprognose und nicht erst dann, wenn der Zeitpunkt des Einschaltens gekommen ist!

Ok. das hatte ich tatsäschlich falsch interpretiert. Ich komme nochmal darauf zurück. Zur Zeit bin ich an anderer Stelle beschäftigt.


Bezüglich der Priorität wäre eine Erweiterung in dem oben beschriebenen Zusammenhang möglich und auch relativ gut mit überschaubaren Aufwand zu implementieren wenn es der Wunsch sein sollte. Eine genau gleiche Prio ist wie beschrieben aber nicht möglich.

[Parallix]

...
Bezüglich der Priorität wäre eine Erweiterung in dem oben beschriebenen Zusammenhang möglich und auch relativ gut mit überschaubaren Aufwand zu implementieren wenn es der Wunsch sein sollte. Eine genau gleiche Prio ist wie beschrieben aber nicht möglich.

Letztere sind aber z.B. dann sinnvoll, wenn in zwei oder mehr mit Elektroheizkörpern ausgestatteten Räumen die Heizkörper abwechselnd eingeschaltet werden müssen, um beide Räume mit PV-Überschuss zu beheizen. Typisch wäre z.B. eine Umschaltung alle 30 Minuten.