76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo Wolle,

Nein, er endet eben nicht bei 0, sondern bei 1

Doch, definitiv. Aber möglicherweise nicht im Reading zu sehen, da bei Erreichen von '0' (es ist ein vergleichender Timestamp) die Berechnungsroutine wieder bei careCycle neu beginnt und die Tage unter Berücksichtigung von Faktoren wie stepSoc berechnet.

Doch ich kann vorgeben, dass die Batterie mit 1000 W geladen werden soll; und das tut sie auch durchgehend bis eben bei 95% die Ladung abbricht. Siehe Bild.

Das erstaunt mich ehrlicherweise da es meinem Verständnis von BMS-gesteuerten Ladephasen bei Batterien allgemein widerspricht. Aber gut, man lernt nie aus.
Wie dem auch sei, die Leistung, die für die Schaltschwelle überwacht wird ist 'bpowerin' und mit "get ... valBattery" anzusehen:

Code Auswählen Erweitern

01 => balias => Batterie 1
      basynchron => 1
      bcharge => 87
      bchargewh => 4350
      befficiency => 95
      bicon => @dyn:@dyn:@dyn:@dyn
      binstcap => 5000
      blabel => none
      bname => BatteryDummy1
      bpinmax => 14402
      bpinreduced => 600
      bposingraph => top
      bpoutmax => 14402
      bpowerin => 0
      bpowerout => 0
      bshowingraph => 2
   

Sie entspricht der Leistung geliefert durch setupBatteryDevXX->pin. Im Debug mit "batteryManagement" kannst du Abbruchbedingung auch verfolgen:

...
2025.12.28 17:44:53.922 1: SolCast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2025.12.28 17:44:53.922 1: SolCast DEBUG> ChargeMgmt Bat 01 - general load termination condition: 0
2025.12.28 17:44:53.922 1: SolCast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2025.12.28 17:44:53.923 1: SolCast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 0 % / 0 Wh
2025.12.28 17:44:53.923 1: SolCast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: -
2025.12.28 17:44:53.923 1: SolCast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 95 %
...

Sie wird auch als Boolean in "bloadAbortCond" ebenfalls unter valBattery einsehbar wenn zutreffend.
Die Abbruchbedingung arbeitet wie ein Trigger. Wenn die Ladeleistung auch nur kurz unter den Schwellenwert fällt, wird die Ladung beendet und erst wieder bei Unterschreiten des Schwellen-SoC freigegeben.
An diesen Stellen kannst du das Thema verfolgen.

Es kommt also auch darauf an, was genau der Wert im Plot ist. Es muß die Ladeleistung setupBatteryDevXX->pin sein.

LG,
Heiko

[DS_Starter]

PS: daysUntilBatteryCare ist eigentlich daysTillScheduledTopLevelBatteryCalibration oder abgekürzt  daysTillSchedTopLvlBatCal.

... was für ein Monster 

Vorschlag: Solange täglich special_daysUntilBatteryCare_XX dekrementieren, bis es zur "Wartung" gekommen ist. Dann kann jeder auf Basis der so ausgewiesenen "Fristüberschreitung" entscheiden, ob ggf. unter Netzbezug eine "Wartung" angegangen wird.

So ist es schlecht/nicht robust genug zu realisieren. Ich brauche für die Programmatik ein paar Regeln die es einzuhalten gilt.
Gegenvorschlag ... sobald days2care negativ wird, setze ich an geigneter Stelle ein days2care-Overflow-Bit welches erst bei Erreichen von maxSoC resettet wird. Das kann man als User auswerten und entsprechend agieren.
Es könnte auch ein special_-Reading sein welches mit der Aktivierung von daysUntilBatteryCare_XX mit ausgegeben wird.

LG,
Heiko

[DS_Starter]

@Dieter,

Wollte gerade zur Vorbereitung auf die V2.0.0 die libfann Pakete installieren: Mein buster wäre dafür zu alt
Gut, auf bullseye upgedatet - und nix geht mehr / bootet mehr 

Na da bietet es sich doch gleich an gute Vorsätze für das neue Jahr zu fassen ... stay heatlthy and up-to-date. 

LG,
Heiko

[Wolle02]

Doch, definitiv. Aber möglicherweise nicht im Reading zu sehen, da bei Erreichen von '0' (es ist ein vergleichender Timestamp) die Berechnungsroutine wieder bei careCycle neu beginnt und die Tage unter Berücksichtigung von Faktoren wie stepSoc berechnet.

Der Tag hat morgens mit dem Wert 2 begonnen. Nach Beendigung des Sonnentages am Nachmittag wurde er auf 1 dekrementiert. Dann wurde sofort das Reading Battery_ChargeRequest_01 auf 1 gesetzt und somit die Zwangsladung gestartet. Wäre das erst bei 0 geschehen hätte der Wert ja zweimal am Tag dekrementiert werden müssen.

Im Debug mit "batteryManagement" kannst du Abbruchbedingung auch verfolgen:

Ehrlich gesagt kann ich mit dem Debug so nicht arbeiten. Wenn ich das aktiviere schreibt er mir die Debuginformationen bei jedem Zyklus jeweils neu ins Logfile. Auf die Weise ist das Logfile innerhalb kurzer Zeit im Megabytebereich. Deshalb will ich das auch nicht einschalten, um herauszufinden warum jede Nacht um 00.00 Uhr die Batterie wieder auf upSoC entladen wird (und zwar unabhängig davon wieviel Sonne am nächsten Tag prognostiziert wird).
Kannst man das nicht so realisieren, dass nicht das Fhemlog für das Debug verwendet wird, sondern ein separates Logfile? Das kann man danach auch wieder löschen.

LG
Wolle

[Parallix]

...

Vorschlag: Solange täglich special_daysUntilBatteryCare_XX dekrementieren, bis es zur "Wartung" gekommen ist. Dann kann jeder auf Basis der so ausgewiesenen "Fristüberschreitung" entscheiden, ob ggf. unter Netzbezug eine "Wartung" angegangen wird.

So ist es schlecht/nicht robust genug zu realisieren. Ich brauche für die Programmatik ein paar Regeln die es einzuhalten gilt.
Gegenvorschlag ... sobald days2care negativ wird, setze ich an geigneter Stelle ein days2care-Overflow-Bit welches erst bei Erreichen von maxSoC resettet wird. Das kann man als User auswerten und entsprechend agieren.
Es könnte auch ein special_-Reading sein welches mit der Aktivierung von daysUntilBatteryCare_XX mit ausgegeben wird.
...

Dann könnte man aber auch gleich in einem "special reading" die Fristüberschreitung in Tagen (bis zur "Wartung" auf 0 gesetzt = keine Fristüberschreitung) angeben, oder?

[DS_Starter]

Ehrlich gesagt kann ich mit dem Debug so nicht arbeiten. Wenn ich das aktiviere schreibt er mir die Debuginformationen bei jedem Zyklus jeweils neu ins Logfile.

Ja, das ist klar.
Für sowas erstellt du dir am Besten ein einfaches at oder notify je nach Bedarf.
Das at kann z.B. 23:55 das Attr ctrlDebug auf "batteryManagement" setzen und um 00:10 wieder auf "none". Damit hast du nur das relevante Zeitfenster und die Übersicht bleibt erhalten. Ein notify kann man benutzen um Debugging abhängig von einem Reading/Event ein/auszuschalten.
Das ist auch für mich einfacher zu analysieren wenn ihr die Daten mal zur Verfügung stellt.

Dann wurde sofort das Reading Battery_ChargeRequest_01 auf 1 gesetzt und somit die Zwangsladung gestartet. Wäre das erst bei 0 geschehen hätte der Wert ja zweimal am Tag dekrementiert werden müssen.

Ah, jetzt verstehe ich was du meinst. Du stellst eine gedankliche Abhängigkeit zwischen daysUntilBatteryCare_XX = 0 und Battery_ChargeRequest_XX her.
Das ist aber nicht bzw. nur indirekt (docare: 1 im Log) der Fall. Es wird daysUntilBatteryCare_XX=1 gesetzt wenn der aktuelle SoC unter dem geforderten (neuen) optimalen Ziel-SoC liegt. Der neue opt. SoC wird etwa in der Mitte des rechnerischen Sonnentages aktiviert. Dann kann noch Restsonne zur Ladung verwendet werden falls vorhanden.

LG,
Heiko

[DS_Starter]

Dann könnte man aber auch gleich in einem "special reading" die Fristüberschreitung in Tagen (bis zur "Wartung" auf 0 gesetzt = keine Fristüberschreitung) angeben, oder?

Das sollte machbar sein.