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