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