76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Wenn ich das richtig sehe, dann wird Battery_OptimumTargetSoC_XX – eine nach meinem Empfinden sehr schlechte Bezeichnung für das Reading – schrittweise angehoben, damit der erforderliche obere SOC zur Batteriepflege auch erreicht werden kann.

Ja, jedoch nicht nur das. Es wird tatsächlich optimaler SoC berechnet, der auf die PV Erzeugung der nächsten zwei Tage reagiert. Das führt dazu, dass in dieser für PV armen Zeit dennoch im Normalfall genügend Speicherplatz verfügbar ist um den Wechsel von schlechten zu sehr guten Erzeugungslagen (die gibt es tatsächlich  ) zu managen. Das ist der große Vorteil gegenüber (kommerziellen) Lösungen die einen statischen SoC einstellen. Deswegen ist die Namensgebung auch absolut richtig und passend.

Nach meinem Erfahrungen und bei meiner Anlagenkonfiguration wird dieser Zustand bei einem nicht zu kurz eingestellten careCycle, der in meinem Fall bei 14 Tagen liegt, auch ohne Anhebung des Mindest-SOC hinreichend oft erreicht.

Bei mir nicht da ich eine sehr hohe Speicherkapazität gegenüber der installierten PV-Leistung habe was mir allerdings viele Vorteile bietet.

Des weiteren schlage ich vor, dass der Zähler special_daysUntilBatteryCare_XX bis zur turnusmäßigen Batteriewartung – sofern nicht bereits realisiert (steht aber nicht im Wiki) - auch negative Werte annehmen kann und damit die bisherige Überschreitung des Wartungstermins in Tagen leicht ermittelbar wird.

Ich sehe für eine solche Änderung keine Notwendigkeit und ich möchte auch mal ein Stück vorwärts kommen mit den noch anstehenden Dingen. Das aktuelle Verfahren hat sich bewährt und geht jetzt schätzungsweise in die 3. oder 4. Wintersaison.

Wenn dann noch ein Attribut, z.B.  careCycleTolerance, existiert, mit dem die tolerierte Überschreitung des Wartungstermins angegeben werden kann, könnten weitere sinnvolle Funktionen bzw. Readings in oder außerhalb von SF realisiert werden.

Was wäre das beispielsweise?

Abschließend möchte ich außerdem noch anregen, die binäre Readings, die sich auf ein Device beziehen und wie z.B.  Battery_ChargeAbort_01, Battery_ChargeRequest_01 und Battery_ChargeRequest_01 das Vorliegen einer Sondersituation signalisieren, in ein einziges Reading zu überführen

Worin besteht der Unterschied zwei Readings auszuwerten oder nur ein Reading bezüglich seines Wertes, der verschiedene Status repräsentiert?
Was ist denn der überragende Vorteil einer solchen Änderung gegenüber dem Nachteil alle Codes, sämtliche Onlinehilfen und Wikibeschreibungen ändern/anpassen müssen?
Kannst du das bitte darlegen? Ich bin bei vielen Dingen gern bereit mitzugehen, will aber verstehen wofür ich meine Freizeit/Lebenszeit verbrennen soll.

LG,
Heiko

[Parallix]

Wenn ich das richtig sehe, dann wird Battery_OptimumTargetSoC_XX – eine nach meinem Empfinden sehr schlechte Bezeichnung für das Reading – schrittweise angehoben, damit der erforderliche obere SOC zur Batteriepflege auch erreicht werden kann.

Ja, jedoch nicht nur das. Es wird tatsächlich optimaler SoC berechnet, der auf die PV Erzeugung der nächsten zwei Tage reagiert. Das führt dazu, dass in dieser für PV armen Zeit dennoch im Normalfall genügend Speicherplatz verfügbar ist um den Wechsel von schlechten zu sehr guten Erzeugungslagen (die gibt es tatsächlich  ) zu managen. Das ist der große Vorteil gegenüber (kommerziellen) Lösungen die einen statischen SoC einstellen. Deswegen ist die Namensgebung auch absolut richtig und passend.

Ja! SF kann sehr viel und in der Tat deutlich mehr als kommerzielle Lösungen und das im übrigen auch mit sehr wenig Datentransport nach außen! Den Readingnamen finde ich deshalb schlecht, da aus ihm überhaupt nicht hervorgeht, dass es sich um einen optimalen unteren SOC handelt. Hier wäre z.B. BatOptMinSoC_XX (ggf, auch weniger abgekürzt) greifbarer - man könnte auch "optimaler" sagen

[DS_Starter]

dass es sich um einen optimalen unteren SOC handelt.
BatOptMinSoC_XX

Ja, da könnte ich auch auch mitgehen. 

[Parallix]

Nach meinem Erfahrungen und bei meiner Anlagenkonfiguration wird dieser Zustand bei einem nicht zu kurz eingestellten careCycle, der in meinem Fall bei 14 Tagen liegt, auch ohne Anhebung des Mindest-SOC hinreichend oft erreicht.

Bei mir nicht da ich eine sehr hohe Speicherkapazität gegenüber der installierten PV-Leistung habe was mir allerdings viele Vorteile bietet.

Ja! Dass das bei Dir so ist, das glaube ich Dir! Meinerseits hatte ich ja auch geschrieben: "Um SF an möglichst viele [andere] Konfigurationen und Anwendungsfälle  anpassen zu können" ...

[Parallix]

Wenn dann noch ein Attribut, z.B.  careCycleTolerance, existiert, mit dem die tolerierte Überschreitung des Wartungstermins angegeben werden kann, könnten weitere sinnvolle Funktionen bzw. Readings in oder außerhalb von SF realisiert werden.

Was wäre das beispielsweise?

Außerhalb z.B. das zwangsweise Beladen des Speichers aus dem Netz, was innerhalb von SF durch ein Reading (oder Bit innerhalb eines Readings) z.B. empfohlen werden könnte.

[DS_Starter]

Außerhalb z.B. das zwangsweise Beladen des Speichers aus dem Netz, was innerhalb von SF durch ein Reading (oder Bit innerhalb eines Readings) z.B. empfohlen werden könnte.

Fragezeichen im Kopf ... das ist doch schon gegeben -> Das Reading Battery_ChargeRequest_XX signalisiert doch bereits das Ladeverlangen. Vllt. stehe ich einfach nur auf dem Schlauch...

[Parallix]

Abschließend möchte ich außerdem noch anregen, die binäre Readings, die sich auf ein Device beziehen und wie z.B.  Battery_ChargeAbort_01, Battery_ChargeRequest_01 und Battery_ChargeRequest_01 das Vorliegen einer Sondersituation signalisieren, in ein einziges Reading zu überführen

Worin besteht der Unterschied zwei Readings auszuwerten oder nur ein Reading bezüglich seines Wertes, der verschiedene Status repräsentiert?
Was ist denn der überragende Vorteil einer solchen Änderung gegenüber dem Nachteil alle Codes, sämtliche Onlinehilfen und Wikibeschreibungen ändern/anpassen müssen?
Kannst du das bitte darlegen? Ich bin bei vielen Dingen gern bereit mitzugehen, will aber verstehen wofür ich meine Freizeit/Lebenszeit verbrennen soll.

• Eine zu behandelnde Sondersituation lässt sich durch Abfrage eines Readings feststellen (Readingwert > 0), was auch bei einer künftige Erweiterung von Sondersituationen weiter so wäre. Die Anzahl an Readings würde reduziert. (Datensparsamkeit)
• Bei einer Konfiguration ggf, nicht relevante oder genutzte Readings würden nicht mehr angezeigt (Übersichtlichkeit)
• Spezifischere Angaben lassen sich ohne zusätzliche Readings machen, z.B. dringende Ladeempfehlung wg. SOC < lowSOC, Anregung zur Ladung aus dem Netz, um den Speicher in den "Wartungszustand" zu bringen. (Detailliertheit)

[DS_Starter]

Ja, diese allgemeinen Vorteile sind mir bewusst. Was ich eher meinte ist ein unmittelbarer Vorteil der den AUFWAND einer solchen Umstellung lohnt. Man muß sich bewusst sein, dass diese grundlegende Änderung von Readingsinhalten bzw. ihrer Datenpendants in den internen Strukturen (currentVal, Nexthours, Circular, History, ...), die Erstellung von Routinen zum Parsen von Readinginhalten sowie das Überprüfen/Nachziehen von Doku etc. inklusive der dazugehörigen Tests und Fehlerbereinigungen viele Stunden Freizeit bis zu einigen Tagen dieser wertvollen Zeit verschlingen können.

Deswegen hinterfrage ich den Nutzen von solchen Vorschlägen sehr genau. Das ist kein böser Wille, aber es geht um meine Zeit...

Wenn es mal weitere Funktionen geben sollte, die eine gewisse "Notwendigkeit" (ähnlich den zusammengesetzten Attributen) einer solchen Zusammenfassung erfordern, kann man darüber nachdenken.

Unmittelbar ließen sich thematisch gleiche Anforderungen in einem vorhandenen Reading darstellen, zum Beispiel eine Ladeanforderung im Reading Battery_ChargeRequest_XX -> 0 - keine, 1 - normale Anforderung (SoC < upSoC), 2 - dringende Anforderung/Notladung (SoC < lowSoC). Auch hier wären einige Codeänderungen nötig, weil eine einfache Prüfung true/false nicht mehr reicht, aber der Umfang wäre überschaubar. Aber wie gesagt "nice to have" ist einfach zu wenig.
Wenn jemand sagt es würde mir wirklich sehr helfen weil "..." wenn ich diese oder jene Funktionalität hätte, bin ich der letzte der sich querstellt.

[Parallix]

...
Aber wie gesagt "nice to have" ist einfach zu wenig.
Wenn jemand sagt es würde mir wirklich sehr helfen weil "..." wenn ich diese oder jene Funktionalität hätte, bin ich der letzte der sich querstellt.

Es sind alles nur Vorschläge und ich werde wahrscheinlich auch überleben, wenn keiner der Vorschläge realisiert werden würde  .

Wenn es um Herzensangelegenheiten geht, so würde ich mich über einen frei konfigurierbaren TargetSOC und eine Änderungs-/Abschaltmöglichkeit des schrittweisen Anhebens des unteren SOCs schon sehr freuen. Aktuell bin ich dabei, SF auch bei der Ladung (m)eines EV's stärker heranzuziehen. Hier habe ich aber arge Probleme, da die jetzige Bat-Steuerung noch in einem recht engen Korsett steckt.

[DS_Starter]

Wenn es um Herzensangelegenheiten geht, so würde ich mich über einen frei konfigurierbaren TargetSOC und eine Änderungs-/Abschaltmöglichkeit des schrittweisen Anhebens des unteren SOCs schon sehr freuen. Aktuell bin ich dabei, SF auch bei der Ladung (m)eines EV's stärker heranzuziehen. Hier habe ich aber arge Probleme, da die jetzige Bat-Steuerung noch in einem recht engen Korsett steckt.

Da lässt sich bestimmt etwas machen.  
Mit "schrittweisen Anhebens des unteren SOCs" meinst du sicherlich die 5% des Taget-SoCs, also des Readings Battery_OptimumTargetSoC_XX? Das muß ich mir anschauen wie es in die generelle Ablauflogik passen würde wenn es einen konfigurierbaren Schlüssel gäbe.
Bei "frei konfigurierbaren TargetSOC" bin ich mir unschlüssig was du meinst. Soll damit Battery_OptimumTargetSoC_XX manuell setzbar und nicht mehr logikgeführt sein?

[Parallix]

...
Da lässt sich bestimmt etwas machen.  
Mit "schrittweisen Anhebens des unteren SOCs" meinst du sicherlich die 5% des Taget-SoCs, also des Readings Battery_OptimumTargetSoC_XX? Das muß ich mir anschauen wie es in die generelle Ablauflogik passen würde wenn es einen konfigurierbaren Schlüssel gäbe.

Wenn die Anhebung von einem fixen Startwert aus erfolgt - so jedenfalls hatte ich Dich immer verstanden - und die Anhebung DeltaPerStep um die bislang festen 5 Prozentpunkte (woher kommen die eigentlich ?) konfigurierbar sein, dann könnte man, z.B. mit DeltaPerStep=0, den unteren Ziel-SOC festsetzen.

Bei "frei konfigurierbaren TargetSOC" bin ich mir unschlüssig was du meinst. Soll damit Battery_OptimumTargetSoC_XX manuell setzbar und nicht mehr logikgeführt sein?

Du hattest mir an früherer Stelle mal geschrieben, dass die Ladungsplanung für loadStrategy == optPower immer von 100 als (oberer) TargetSOC ausgeht. Insb. im Sommer würde ich diesen Wert aber absenken wollen. Darum geht es mir. Da bei mir (auf der Nordhalbkugel) der Sommer erst einmal vorbei ist, ist diese Feature eher eine niedrig zu priorisierende Angelegenheit.

Übrigens wird bei mir aktuell (bei SOC = 75) Battery_ChargeOptTargetPower_XX mit 250 W =  pinreduced angegeben; das ist eigentlich viel zu wenig. Wahrscheinlich ist es sinnvoll, künftig von zwei Steuerungsmöglichkeiten auszugehen: a) Fixes Setzen der Ladung mit  Battery_ChargeOptTargetPower_XX b) Fixes Setzen der maximalen Ladung mit Battery_ChargeOptTargetPower_XX. Also einmal eher in Richtung Regelung und einmal in Richtung Steuerung zu denken.

Edit: Bin gleich zum Sport und daher dann offline. Also bitte nicht wurden, wenn ich nicht direkt antworte.

[DS_Starter]

Wenn die Anhebung von einem fixen Startwert aus erfolgt - so jedenfalls hatte ich Dich immer verstanden - und die Anhebung DeltaPerStep um die bislang festen 5 Prozentpunkte (woher kommen die eigentlich ?) konfigurierbar sein, dann könnte man, z.B. mit DeltaPerStep=0, den unteren Ziel-SOC festsetzen.

Ja, die Anhebung basiert auf dem aktuellen Battery_OptimumTargetSoC_XX (initial aus dem Sommer kommend == lowSoC) und erfolgt in 5er Schritten 40,45,50, etc. Das 5er Raster ist eine empirische Festlegung von mir und berücksichtigt die verbleibenden Tage von careCycle.

Du hattest mir an früherer Stelle mal geschrieben, dass die Ladungsplanung für loadStrategy == optPower immer von 100 als (oberer) TargetSOC ausgeht. Insb. im Sommer würde ich diesen Wert aber absenken wollen. Darum geht es mir.

Ok, verstanden.

Übrigens wird bei mir aktuell (bei SOC = 75) Battery_ChargeOptTargetPower_XX mit 250 W =  pinreduced angegeben;

Es müsste mindestens pinreduced * safetyMargin sein. Also würde ich pinreduced und/oder safetyMargin anheben.