76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Ich habe die V 2.9.5 ins contrib geladen.

Da kamen ein par neue Logeinträge bei mir - ohne BEV / Wallbox zu besitzen:

Code Auswählen Erweitern

026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 19 -> prediction=1094, hist_ref=1437.43, blend_alpha=0.13, forward_val=1138
2026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 20 -> prediction=1054, hist_ref=1376.57, blend_alpha=0.14, forward_val=1099
2026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 21 -> prediction=639, hist_ref=1609.86, blend_alpha=0.15, forward_val=789
2026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 22 -> prediction=749, hist_ref=1301.14, blend_alpha=0.17, forward_val=842
2026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 23 -> prediction=521, hist_ref=926.00, blend_alpha=0.18, forward_val=595
2026.08.08 09:28:43 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 24 -> prediction=501, hist_ref=587.86, blend_alpha=0.20, forward_val=518

setze gleich noch die neueste V nach und berichte....



EDIT:
kommt gleichartig:

Code Auswählen Erweitern

2026.08.08 10:17:35 1: MB_CFG_SBS25: loading config from cfg file
2026.08.08 10:17:39 1: Zisterne: loading config from cfg file
2026.08.08 10:17:59 1: Including ./log/fhem.save
2026.08.08 10:18:02 0: Featurelevel: 6.4
2026.08.08 10:18:02 0: Server started with 459 defined entities (fhem.pl:31310/2026-05-28 perl:5.036000 os:linux user:fhem pid:1198768)
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 19 -> prediction=1209, hist_ref=1437.43, blend_alpha=0.11, forward_val=1235
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 20 -> prediction=1006, hist_ref=1376.57, blend_alpha=0.13, forward_val=1053
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 21 -> prediction=598, hist_ref=1609.86, blend_alpha=0.14, forward_val=741
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 22 -> prediction=736, hist_ref=1301.14, blend_alpha=0.15, forward_val=824
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 23 -> prediction=560, hist_ref=926.00, blend_alpha=0.17, forward_val=622
2026.08.08 10:18:07 1: Forecast DEBUG> AI FANN 'con' forecast blend - hod: 24 -> prediction=523, hist_ref=587.86, blend_alpha=0.18, forward_val=535
2026.08.08 10:18:14 2: AttrTemplates: got 272 entries

kommt von hier:
28786         if ($debug =~ /aiProcess/xs && $hod >= 19 && $hod <= 24) {
28787             $hist_ref    = round2 ($hist_ref);
28788             $blend_alpha = round2 ($blend_alpha);
28789             Log3 ($name, 1, "$name DEBUG> AI FANN '$fanntyp' forecast blend - hod: $hod -> prediction=$prediction, ".
28790                              "hist_ref=$hist_ref, blend_alpha=$blend_alpha, forward_val=$forward_val")
28791                 if(askLogtime ($name, "conBlendLog_$hod", 3600));
28792         }
2

[DS_Starter]

@300P,

ja, die gibt es im Debug. Sie sind zur Diagnose der Fortschreibung in den Abendstunden. Erstmal nichts besonderes.


@Wolle02,

Diesbezüglich gibt es bei mir im Wallboxdevice noch ein Reading "plug_state" das man mitgeben könnte. So könnte die KI unterscheiden, ob das Auto an der eigenen Wallbox aufgeladen wird oder unterwegs.

Das gibt es schon über den Schlüssel evid, womit erkannt wird ob BEV angesteckt/aktiviert. Das hat dann Auswirkung auf die Datenaufzeichnung csme / csmt. "Nomalerweise" sollte die KI daran diesen Status erkennen. Wir werden sehen. Und die Aufzeichnung passt auch wie bei dir zu sehen.

@Peter,

grundsätzlich denke ich, dass der SoC keine Eigenschaft der Wallbox ist, sondern eine des BEV. Daher gehörte es logischerweise eigentlich in das jeweils andere device.
Das ganze muss aber auch mit mehreren BEVs an einer Wallbox funktionieren.
Wäre das mit einer Device:Reading-Konfiguration überhaupt darstellbar? Dann müsste man ja je nach dem welches BEV gerade angeschlossen ist auch eine andere Device:Reading-Konfiguration verwenden können.

SF ist diesbezüglich folgendermaßen aufgebaut:
Hat man eine Wallbox an der mehrere BEV geladen werden, legt man in SF mehrere BEV-Consumer an. Über die evid wird erkannt welcher BEV gerade an der WB steckt und aktiviert damit das richtige Consumer-Device. Dadurch sind auch die spezifisch hinterlegen Readings eindeutig zuordenbar. Die Deviceangabe (die WB) ist in den Consumern immer gleich.

Das wirft nun die Frage bezüglich des SOC auf. Für mehrere EV's muß es demzufolge mehrere SOC-Readings in dem WB-Device geben. Dafür muß der User dann sorgen und über geeignete userReadings für BEV1, BEV2 usw. diese Daten bereitstellen und SF übergeben.


LG,
Heiko

[DS_Starter]

@Wolle02,

Seit ein paar Tagen stelle ich bei mir ein komisches Verhalten der realen Consumerwerte fest.

Das ist ein berechneter Wert aus den ganzen Wertequellen. Zusammensetzung im Wiki beschrieben.

Um nicht raten zu müssen, wäre es gut in der Nacht mal ein Debug collectData aufzuzeichen.
Dann sieht man die Eingangswerte und kann es nachrechnen.

Vermutlich gibt es einen Geisterwert "die Batterie lädt" und entzieht so dem Haus Energie die eigentlich Verbrauch darstellt. Es wäre eine mögliche Erklärung.

[peterboeckmann]

Hallo Heiko,

SF ist diesbezüglich folgendermaßen aufgebaut:
Hat man eine Wallbox an der mehrere BEV geladen werden, legt man in SF mehrere BEV-Consumer an. Über die evid wird erkannt welcher BEV gerade an der WB steckt und aktiviert damit das richtige Consumer-Device. Dadurch sind auch die spezifisch hinterlegen Readings eindeutig zuordenbar. Die Deviceangabe (die WB) ist in den Consumern immer gleich.

Das wirft nun die Frage bezüglich des SOC auf. Für mehrere EV's muß es demzufolge mehrere SOC-Readings in dem WB-Device geben. Dafür muß der User dann sorgen und über geeignete userReadings für BEV1, BEV2 usw. diese Daten bereitstellen und SF übergeben.

danke für die Auffrischung.
So passt das auch zu meinem in SF eingebundenen Device "WallboxLeistungssumme".
Darin habe ich natürlich das reading evid und BEV-spezifische Readings für currSoC und targetSoC.

Dann kann die Definition des currSoC für mich auch so bleiben.
Sobald ein weiteres BEV dazu kommt, sind die Readings auch an meinem Wallbox-Device eindeutig.

Viele Grüße,
Peter

[300P]

@300P,

ja, die gibt es im Debug. Sie sind zur Diagnose der Fortschreibung in den Abendstunden. Erstmal nichts besonderes.

@Heiko:
Evtl zu überlegen dort statt:

Log3 ($name, 1, "$name DEBUG> AI FANN '$fanntyp' forecast blend - hod: $hod -> prediction=$prediction, ".

Log3 ($name, 4, "$name DEBUG> AI FANN '$fanntyp' forecast blend - hod: $hod -> prediction=$prediction, ".

? ? ? .........wegen

0 - Server start/stop
1 - Fehlermeldungen oder unbekannte Pakete
2 - bedeutende Ereigbisse/Alarme.
3 - ausgesendete Kommandos werden gelogged.
4 - von den einzelnen Geräten empfangene Daten.
5 - Fehlersuche.

[DS_Starter]

Das gilt für normales Logging.
Deswegen gibt es im SF die verschiedenen Degug Modes.
Nur einschalten wenn gewünscht, spnst nicht. Dann ist auch Ruhe im Log.

LG,
Heiko

[DS_Starter]

Moin,

@300P, ich die gewisse Logausgabe in den Modus 'aiData_long' verschoben, da es eine erweiterte Ausgabe bei der Datenabfrage ist, nicht im Prozess des Trainings.

Update liegt im Contrib.

LG,
Heiko

[DS_Starter]

@all,

Thema Batteriesteuerung.
Ich habe in den externen Steuerungscode des TermVoltageTaper (Zellschutz nahe Vollladung) eine Hysterefunktion eingebaut. Dadurch ergibt sich ein gleichmäßiger Abregelungsverlauf im Kniebereich. Die Erläuterungen und den Code im Wiki habe ich aufgefrischt.


LG,
Heiko

[DS_Starter]

Moin,

in meinem contrib liegt ein Update der Version 2.9.5.

Nun ist es möglich, den BEV Consumern opmode "prio" und "auto" mitzuteilen.

Konkret gibt es bei bev-Consumern nun diesen Schlüssel zusätzlich:

opmode    definiert eine <Device>:<Reading> Kombination welche den aktuellen Lademodus liefert (optionale Angabe).
   Syntax: <Device>:<Reading>
   Ausgewertet werden folgende Modi: prio auto
   prio - vorhandener PV-Überschuss wird mit Priorität vor dem Hausspeicher zum Laden des BEV verwendet
   auto - BEV Laden ist mit dem Hausspeicher und sonstigen Verbrauchern gleichberechtigt
   Alle anderen Werte werden intern dem Lademodus 'other' zugeordnet.

Historisch sind also alle Ladevorgänge dem Modus 'other' zugeordnet. Erst neuere Datensätze werden evtl. unterschieden sofern man diese Modi
in dem Device:Reading mitteilt.

ACHTUNG: Nutzer mit dem Profilflag 'bev' müssen neu trainieren, da es mit dieser Änderung eine Featureerweiterung gibt.

Im Überblick enthält diese Version nun:

- BEV Batteriedaten auch bei nicht aktivierten BEV-Consumer gespeichert
- NEU: Logausgabe des ausgeführten set reset Befehls zum Datenspeicher Management vor Ausgabe der Ergebnisse
- neuer Debug Modus aiData_long
- NEU: Verringerung der Log Frequenz bei Debug aiData und aiData_long
- List pvCircular, pvHistory um BEV accum_csmXX_<mode>_wseconds bzw. BEV csmXX_<mode>_points erweitert
- NEU: Aktivierung BEV opmodes 'auto' und 'prio' -> Retraining bei Verwendung bev-Flag nötig!
- weitere kleinere Patches

LG,
Heiko

[DS_Starter]

Nabend @all,

ein weiteres Update liegt in meinem contrib:

- BEV Batteriedaten werden auch bei nicht aktivierten BEV-Consumer gespeichert
- Logausgabe des ausgeführten set reset Befehls zum Datenspeicher Management vor Ausgabe der Ergebnisse
- neuer Debug Modus aiData_long
- Verringerung der Log Frequenz bei Debug aiData und aiData_long
- List pvCircular, pvHistory um BEV accum_csmXX_<mode>_wseconds bzw. BEV csmXX_<mode>_points erweitert
- NEU: List pvHistory, aiRawData um Anzeige bevcsmPhasesXX erweitert
- vollständige Pipeline-Integration (Training + Inferenz) für die BEV opmode-Fraktionen 'auto' und 'prio' -> Retraining bei Verwendung bev-Flag nötig!
- NEU: bev-Consumer: Aufzeichnung der zum Laden verwendete Anzahl Phasen – reine Rohdatenerfassung für später   
- FIX: Model VictronKiAPI: Fix fehlenden success-Status in Victron VRM API Forecast Response wenn vorher Response fehlerhaft war
- weitere kleinere Patches


Für bev-Consumer kann nun der Schlüssel "phases" gesetzt werden. Die Anzahl der zum Laden verwendeten Phasen (1 bis 3) werden aktuell nur aufgezeichnet um sie später entsprechend verwenden zu können.

LG,
Heiko

[peterboeckmann]

Hallo Heiko,

Für bev-Consumer kann nun der Schlüssel "phases" gesetzt werden. Die Anzahl der zum Laden verwendeten Phasen (1 bis 3) werden aktuell nur aufgezeichnet um sie später entsprechend verwenden zu können.

vielen Dank für die Implementierung meiner Vorschläge!

Eine Frage zu den Phasen: sollte in dem Reading stehen, was seitens der Wallbox-Steuerung erlaubt ist oder das, wie tatsächlich aktuell geladen wird?

Hintergrund: ich kann meine Wallbox (Heidelberg Energy Control) einphasig oder dreiphasig betreiben. Vermutlich beschränkt sich die Vorgabe bei den meisten Wallboxen auf diese beiden Optionen.
Betreibe ich die Wallbox dreiphasig, kann das Auto trotzdem noch entscheiden, wieviele Phasen verwendet werden. Mein Auto (Kia Niro SG2) entscheidet sich regelmäßig unterhalb von 6,7 A Sollstrom, nur zwei Phasen zu nutzen.

Anhand der jeweiligen Stromstärken der drei Phasen kann ich ermitteln, ob ein-, zwei- oder dreiphasig geladen wird.

Was empfiehlst du mir?

Viele Grüße,
Peter

[300P]

Das können nur die realen Daten auf den Phasen sein.

Das "erlaubt sind XYXYX W" ist für die Erfassung und Datensammlung in SF vollkommen nebensächlich bei / für das NN bei der CON-Vorhersage bzw. der Speicherung in der History.

Ich hätte im Winter gern auch die Batterien voll und würde dies erlauben, aber irgendwie liegt es an der Sonne 

[DS_Starter]

Wie 300P schon eingeschätzt hat, wäre die tatsächliche Anzahl der benutzten Phasen relevant.
Für die KI ist die Korrelation zwischen der Phasenanzahl und der Leistung pro Zeiteinheit der relevante Zusammenhang.
Für die Prognose ist dann die Projektion der verwendeten Phasen in die nächsten Stunden von gewisser Relevanz. Aber es gibt natürlich noch mehr Werte. Die Phasenanzahl wird eine Unterstützungsfunktion haben und nicht die höchste Relevanz.

[300P]

@Heiko:

Ich hab mir relativ ganz einfaches DoIf ausgedacht das meine 2 Batterien_XX auf Basis von SF netzorientiert steuern sollten:

Code Auswählen Erweitern

defmod di_SF_BatteryControl_XX DOIF ([Forecast:Battery_ChargeUnrestricted_XX:d] == 0 and [Forecast:Battery_ChargeOptTargetPower_XX:d] > 0 and [Forecast:Current_BatCharge_XX:d] < 98) (set MB_SBS25_XX Set_Leistung_W -[Forecast:Battery_ChargeOptTargetPower_XX:d], set MB_SBS25_XX Set_Aktiv 802, {Log 3, "di_SF_BatteryControl_XX- BatCtrl_XX: Drossel aktiv auf -[Forecast:Battery_ChargeOptTargetPower_XX:d] W"}) DOELSE (set MB_SBS25_XX Set_Aktiv 803, {Log 3, "di_SF_BatteryControl_XX - BatCtrl_XX: Drossel inaktiv, Automatik (803)"})
attr di_SF_BatteryControl_XX do always
attr di_SF_BatteryControl_XX group SF
attr di_SF_BatteryControl_XX repeatcmd 300
attr di_SF_BatteryControl_XX room 020_PV
Zuerst hatte ich mir was in ctrlUserExitFN geschrieben - das lag ich weit über 2 Sekunden SF-Laufzeit.
Dann testweise auch in die 99_myUtils_SolarForecastUtils.pm per Aufruf ausgelagert - bracht etwas aber nicht viel.
Grund sind n.m.M. wohl die jeweiligen Modus-Device-Befehle mit Laufzeiten......

Es sieht nach 2 Tagen testen so aus, als ob wohl meine beiden SMA-BWR darauf sauber reagieren, aber leider werden bei keine Änderungen bei den BWR ins Ereignisprotokoll geschrieben. Normal kenne ich es das dort Veränderung protokolliert werden, aber es kommt nichts dort rein - die Änderungen werden m.M.n durchgeführt.

Siehst du da noch ein Handicap das ich da etwa falsch bei SF in dem DoIf heranziehe ??

Die Modbus-Adressen sind (schon länger her) von mir an anderer Stelle genutzt worden und hatten dabei dann sonst immer Einträge hervorgerufen.
Kann ja auch sein das durch das BWR-Firmware-Update letztes Jahr diese mir bekannten Einträge im BWR-Ereignislog ja nicht mehr kommen......


PS:
Hab vergessen anzugeben das die Timeout's in den beiden BWR für die Kommunikation bei mir bei 30 Minuten stehen.........

[DS_Starter]

@300P,

ich weiß nicht ob ich dich richtig verstanden habe ... die Frage ist wohl dass deine Änderungen mit dem "set MB_SBS25_XX ..." nicht im SMA im Protokoll zu finden sind und ob du etwas "falsch" bzgl. SF auswertest.

Wenn ich die Frage richtig verstanden habe, kann ich sie dennoch nicht beantworten weil:

- ich noch nie DOIF benutzt habe und ich es auch noch nie vermisst habe
- ich meinen SMA mit SMAInverter auslese und kein Modbus benutze

Aber bezüglich SF liest du ja auch nur die Readings aus und rechnest damit in dem DOIF.
Ob die Syntax und Notationen von DOIF richtig verwendet sind kann ich leider nicht sagen. Das habe ich wie geschrieben schon immer vermieden zu benutzen.
Ich nutze immer notify oder at je nach Fall.

Aber wenn, wie du sagst, die Reaktionen des BWR nachvollziehbar richtig sind scheint ja alles richtig zu sein?