76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

PS: ChatGPT & Co. "verstehen" die Beschreibung bis dato auch nicht, was möglicherweise aus dem - aus meiner Sicht - sehr ungünstig benannten Reading Battery_OptimumTargetSoC_XX rührt.

Findest du? Also Copilot kann den Text aus dem Wiki, den ich ihm(es) vorgeworfen habe ganz gut interpretieren.
Ansonsten sagt der Name m.M. genau das aus was der Wert ist. Andere Vorschläge sehe ich mir aber auch gern an. Sie müssen aber einen echten Mehrwert enthalten denn Änderungen an Readings, die zur Steuerung verwedet werden, sind für Anwender des Moduls immer mit (erheblichen) Aufwand verbunden. Das sollte man nur tun wenn es tatsächlich triftige Gründe dafür gibt.

Ich glaube nicht, dass die meisten User ganze Texte interpretieren lassen. Gesucht wird eher etwas wie "SolarForecast Battery_OptimumTargetSoC_XX". Und da war das Ergebnis bis dato eher erschreckend:

Das Reading Battery_OptimumTargetSoC_XX (wobei XX für die Kennungsnummer des jeweiligen Batteriespeichers steht) ist ein zentraler Steuerungswert im FHEM-Modul 76_SolarForecast.

Es definiert den optimalen Ziel-State-of-Charge (SoC) in Prozent, den der Batteriespeicher zu einem bestimmten Zeitpunkt erreichen bzw. nicht unterschreiten sollte.

Edit: Aus meiner Sicht ist Battery_OptimumTargetSoC_XX eben kein Target, sondern eine untere Schranke. Was eigentlich soll der "bestimmte Zeitpunkt" sein? Die Grenze darf bzw. sollte doch ganztägig niemals unterschritten werden, oder? Vielleicht habe ich dieses Reading aber immer noch nicht (ganź) verstanden.
 

[DS_Starter]

Naja, man muß eine KI vernünftig prompten sonst wird das nichts. Also da sollte man schon versuchen einen Text auch selbst zu lesen und zu verstehen (nur meine Meinung). Und, ganz ehrlich, wir (Menschen) sollten vermeiden uns zu sehr auf KI zu verlassen und uns davon abhängig zu machen. KI ist ohne Zweifel in vielen Fällen äußerst hilfreich, jedoch ersetzt sie (noch) nicht die NI, natürlich Intelligenz  .
Hoffen wir, dass es so beibt....

Edit: Aus meiner Sicht ist Battery_OptimumTargetSoC_XX eben kein Target, sondern eine untere Schranke.

Stimmt nur zum Teil. Es ist auch ein Ladeziel (zum Beispiel eine Nachladung aus dem Netz), wenn nach Anhebung des O-SoC der aktuelle SoC zu niedrig ist.

Was eigentlich soll der "bestimmte Zeitpunkt" sein?

Keine Ahnung. Wohl KI generiert.

[Wolle02]

Was eigentlich soll der "bestimmte Zeitpunkt" sein?

Keine Ahnung. Wohl KI generiert.

Also wenn ich das noch richtig im Hinterkopf habe wurde mal gesagt, dass der Zielzeitpunkt das Ende des Sonnentages sei. Das kann man ja auch im Attribut ctrlBatSocManagement im Schlüssel loadTarget einstellen: "Optionaler Ziel-SoC (%), Zielzeit zur Berechnung der Ladefreigabe und optimalen Ladeleistung.
Der angegebene Ziel-SoC muß größer als der Wert von 'lowSoC' sein. Ein höherer Wert im Reading
Battery_OptimumTargetSoC_XX gegenüber der Parametervorgabe hat Vorrang.
Eine angegebene Zielzeit ist die volle Stunde (1..20) oder als negativer Wert (-20..-1) die
letzte volle Stunde vor dem Sonnenuntergang abzüglich diesem Wert.
Syntax: <Ziel-SoC>[:<Zielzeit>]"

Bei mir funktioniert das mit der Zielzeit aber irgendwie nicht. Die Berechnung scheint immera uf 16:00 Uhr ausgerichtet zu sein. Ich habe auch schon versucht mit den Werten zu spielen, aber das hatte keine Auswirkung.
Ich wollte das auch schon mal schreiben, hab es aber vergessen. Sorry.

[DS_Starter]

Die Einstellung ctrlBatSocManagementXX->loadTarget sind Parameter für die Ladesteuerung, nicht der SoC-Steuerung (anderer Kontext). Hat aber natürlich damit zu tun bzw. Schnittmengen, weil zum Beispiel der berechnete Battery_OptimumTargetSoC_XX ein evtl. niedrigeres <Ziel-SoC> überschreibt. Möglicherweise auch der Punkt an dem deine Betrachtung scheitert, kann natürlich auch ein Bug sein.
Wenn es nicht funktioniert, gucken wir uns das ctrlDebug=batteryManagement Log mal an. Da wird man vermutlich sehen was nicht passt oder passen könnte.

[Parallix]

Naja, man muß eine KI vernünftig prompten sonst wird das nichts.

Da bin ich ja ganz bei Dir. Nun verwenden viele Leute Google & Co. auch dazu, mal schnell etwas zu recherchieren und hinterfragen angezeigte Ergebnisse viel zu häufig leider nicht.

Persönlich würde ich daher anstreben, Darstellungen so vorzunehmen, dass die KI hier auch ohne gutes Prompting das Ergebnis liefer, was ich mir selber wünsche. Vorliegend wird ganz offensichtlich das Wort "Target" aufgrund seine ursprüngliche Bedeutung von der KI im Kontext Battery_OptimumTargetSoC_XX, und leider nicht wie von Dir intendiert, interpretiert. Für mich und die anderen aktiven Mitstreiter hier ist das kein Problem, da Du geduldig Dinge auch mehrfach erläuterst oder Falschinterpretationen gerade rückst.

Wenn hier in der Community niemand das Reading Battery_OptimumTargetSoC_XX in eigenen Codes verwendet (und davon gehe ich aus), könnte man es wohl problemlos umbenennen und dadurch für mehr Klarheit sorgen. Das jedenfalls wäre mein Vorschlag.

[DS_Starter]

Wenn hier in der Community niemand das Reading Battery_OptimumTargetSoC_XX in eigenen Codes verwendet (und davon gehe ich aus), könnte man es wohl problemlos umbenennen und dadurch für mehr Klarheit sorgen. Das jedenfalls wäre mein Vorschlag.

Ich z.B. verwende ihn und übertrage den Wert in die Batterieanlage. Weiterhin müssen dann alle Beschreibungen und Wiki Beiträge geändert werden.
Erkärt sich jemand bereit, das zu übernehmen? Die Online Hilfe im Modul müßte ich natürlich umsetzen.
Eine Umbenennung muß den Aufwand den sie verursacht auch rechtfertigen. Bis jetzt kenne ich keinen solchen Vorschlag eines besseren Namens der dieses Prädikat auch verdient. Oder habe ich etwas überlesen?
Wenn es also Vorschläge gibt und eine hinreiche Anzahl Anwender sich für eine Umbenennung des Readings unter den dargelegten Prämissen ausspricht, will ich dem auch nicht im Wege stehen ... nur damit kein falscher Eindruck entsteht.

[Parallix]

...

Dass Du die Variable in einem SF-externen Code nutzt, habe ich mir schon gedacht, da das Reading sonst sicher ein SpecialReading geworden wäre. 

(M)ein Vorschlag wäre folgende Umbenennung:

Code Auswählen Erweitern

Battery_OptimumTargetSoC_XX -> Battery_DynLowerSoCBound_XXWarum

• Dyn(amic): Weil SF die untere Grenze flexibel den sich änderten Bedingungen anpasst. Ändert sich im Tagesverlauf z.B. die Erzeugugnsprognose für den Folgetag, so passt SF die Grenze an.
• Lower: Weil es die untere Grenze ist und daher auch als solche ausgewiesen werden sollte.
• SoC: Weil es um den SoC geht.
• Bound: Weil es sich um eine Grenze handelt, die vom tatsächlichen SoC nicht unterschritten werden sollte.

Was das Search & Replace (OptimumTargetSoC -> DynLowerSoCBound) im Code und Wiki angeht, so kann ich das gerne übernehmen. 

[DS_Starter]

Deine Herleitung ist sicherlich soweit schlüssig.
DynLowerSoCBound finde ich allerdings nicht gut bzw. nicht besser, weil:

- der Name mit Battery beginnen muß wegen der optischen Sortierung der Readings, d.h. müßte dann Battery_DynLowerSoCBound_XX heißen.
- der Anspruch eines berechneten Optimums fehlt
- sich mir nicht erschließt welchen Sachverhalt der Anwender aus diesem Namen besser ableiten soll als von Battery_OptimumTargetSoC_XX

Er muß sich genauso wie aktuell die Doku dazu durchlesen um den Inhalt zu verstehen, d.h. was wird damit besser?
Aber vllt. habe ich auch einen Tunnelblick und würde gerne weitere Meinungen dazu lesen.

[Hadl]

Ich hab nun careCycle=20 gesetzt, das hat jedoch den Zähler zurückgesetzt und ich bekomme nun wieder 20 Tage:

Code Auswählen Erweitern

2026.09.21 17:26:13 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 0, care SoC: 5 %, remain days until care SoC: 19, Target: 100 %Damit funktioniert alles und die OTP Steuerung klappt wieder wie gewünscht. Mal sehen was passiert wenn die 20 Tage rum sind.

Aber je besser ich die SOC Steuerung verstehe desto mehr glaube ich das die für meinen Anwendungsfall eher deaktiviert werden sollte.
Da mein Akku relativ klein im Vergleich zur PV Leistung ist begrenze ich eher das zu häufige Vollladen. Anfangs mit einem maximalen SOC, jetzt mit einer Maximalen Zellspannung. Damit komm ich quasi nie auf 100% geschätzten SOC, erreiche aber trotzdem den oberen Balancing trigger. Das er 20 Tage am Stück nicht voll wird ist eher unwarscheinlich bei mir, aber wenn mal lange Schnee liegt sicher auch möglich.

Aber ja, die Beschreibung was denn die SOC Steuerung tut hab ich auch lange nicht verstanden. Vor allem die Beziehung mit loadTarget hat mich am Anfang glauben lassen das OptimumTargetSoC das Ziel ist bis zu dem geladen werden soll, aber das war falsch es ist das Ziel bis zu dem Entladen werden soll. Nachdem es aber immer auf 5% Stand hab ich es nie verwendet.
Das könnte man sicherlich im Wiki nochmal besser abgrenzen und vor allem drauf hinweisen das man dies nicht verwenden sollte wenn man die Maximale Ladung auch begrenzt.
Was ich nicht verstehe ist das OTP zum Ende der Stunde ans Maximum geht wenn er einen CareCycle machen will. Sollte da nicht einfach auch nur der "loadTarget" auf minimum OptimumTargetSoC gesetzt werden? Dann würde man trotzdem gleichmäßig volladen.

[DS_Starter]

Damit funktioniert alles und die OTP Steuerung klappt wieder wie gewünscht. Mal sehen was passiert wenn die 20 Tage rum sind.

Na das sieht doch schonmal gut aus.
Schauen wir mal ...