76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[300P]

Oh je - hab Dir da sicher einen langen Abend "beschert".

[300P]

mmmh Fehler kommt weiter:

Code Auswählen Erweitern

026.03.17 07:38:28 1: MB_CFG_SBS25: loading config from cfg file
2026.03.17 07:38:31 1: PERL WARNING: (in cleanup) object of class struct fann * expected at ./FHEM/76_SolarForecast.pm line 9860.
2026.03.17 07:38:33 1: Zisterne: loading config from cfg file
2026.03.17 07:38:50 1: Including ./log/fhem.save


[300P]

Soll ich dafür einfach eventuell einige Tage rauswerfen ?

per :   set...reset aiData delIndex='20260308.*, 20260309.*'

[DS_Starter]

Moin,

nein, nichts rausschmeißen. Die Problematik ist die Speicherung des FANN-Datenobjekts.
Die Datei muß einmal neu gespeichert werden. Vermutlich reicht wenn du auf einen Stundenwechsel wartest und dann nochmal restartest.

Bei mir kommt die Warnung nicht mehr:

Code Auswählen Erweitern

...
2026.03.17 08:05:03.844 3: SolCast - cached data "pvHistory" restored
2026.03.17 08:05:03.857 3: SolCast - cached data "pvCircular" restored
2026.03.17 08:05:03.859 3: SolCast - cached data "consumerMaster" restored
2026.03.17 08:05:03.859 3: SolCast - cached data "radiationApiData" restored
2026.03.17 08:05:03.860 3: SolCast - cached data "statusApiData" restored
2026.03.17 08:05:03.861 3: SolCast - cached data "weatherApiData" restored
2026.03.17 08:05:03.906 3: SolCast - cached data "aiRawData" restored
2026.03.17 08:05:03.914 3: SolCast - cached data "NeuralNetwork" restored
2026.03.17 08:05:03.921 3: HUEDevice6: I/O device is HUEBridge
2026.03.17 08:05:03.952 3: SolCast5 - cached data "pvHistory" restored
2026.03.17 08:05:03.974 3: SolCast5 - cached data "pvCircular" restored
2026.03.17 08:05:03.975 3: SolCast5 - cached data "consumerMaster" restored
2026.03.17 08:05:03.975 3: SolCast5 - cached data "radiationApiData" restored
2026.03.17 08:05:03.976 3: SolCast5 - cached data "statusApiData" restored
2026.03.17 08:05:04.022 3: SolCast5 - cached data "aiRawData" restored
2026.03.17 08:05:04.057 3: SolCast6 - cached data "pvHistory" restored
2026.03.17 08:05:04.071 3: SolCast6 - cached data "pvCircular" restored
2026.03.17 08:05:04.072 3: SolCast6 - cached data "consumerMaster" restored
2026.03.17 08:05:04.072 3: SolCast6 - cached data "radiationApiData" restored
2026.03.17 08:05:04.073 3: SolCast6 - cached data "statusApiData" restored
2026.03.17 08:05:04.073 3: SolCast6 - cached data "weatherApiData" restored
2026.03.17 08:05:04.402 3: SolCast6 - cached data "aiTrainedData" restored
2026.03.17 08:05:04.463 3: SolCast6 - cached data "aiRawData" restored
2026.03.17 08:05:04.469 3: HUEDevice8: I/O device is HUEBridge
2026.03.17 08:05:04.470 3: HUEDevice7: I/O device is HUEBridge
2026.03.17 08:05:04.472 3: HUEDevice9: I/O device is HUEBridge
2026.03.17 08:05:04.473 3: HUEDevice10: I/O device is HUEBridge
2026.03.17 08:05:04.475 3: HUEDevice11: I/O device is HUEBridge
2026.03.17 08:05:04.477 1: FULLY: [wozi.fully] Opening device 192.168.2.140
2026.03.17 08:05:04.478 2: FULLY: [wozi.fully] Device deactivated
2026.03.17 08:05:04.479 3: HUESensor1: I/O device is HUEBridge
2026.03.17 08:05:04.480 3: HUESensor2: I/O device is HUEBridge
2026.03.17 08:05:04.485 3: HUEDevice12: I/O device is HUEBridge
2026.03.17 08:05:04.507 3: SQL_Format: URL is none, periodic updates will be limited to explicit GetXXPoll attribues (if defined)
2026.03.17 08:05:04.507 3: SQL_Format: interval is 0, no periodic updates will done.
2026.03.17 08:05:04.508 3: SQL_Format: Defined without URL featurelevel 99.99
2026.03.17 08:05:04.569 3: FHEM2FHEM opening F2F.fhem2.LinkNodeR8 at 192.168.2.46:7072
2026.03.17 08:05:04.626 3: VRMAPI - cached data "pvHistory" restored
2026.03.17 08:05:04.639 3: VRMAPI - cached data "pvCircular" restored
2026.03.17 08:05:04.640 3: VRMAPI - cached data "consumerMaster" restored
2026.03.17 08:05:04.641 3: VRMAPI - cached data "radiationApiData" restored
2026.03.17 08:05:04.641 3: VRMAPI - cached data "statusApiData" restored
2026.03.17 08:05:04.642 3: VRMAPI - cached data "weatherApiData" restored
2026.03.17 08:05:04.685 3: VRMAPI - cached data "aiRawData" restored
2026.03.17 08:05:04.690 3: VRMAPI - cached data "NeuralNetwork" restored
2026.03.17 08:05:04.714 3: openMeteo - cached data "pvHistory" restored
2026.03.17 08:05:04.724 3: openMeteo - cached data "pvCircular" restored
2026.03.17 08:05:04.725 3: openMeteo - cached data "consumerMaster" restored
2026.03.17 08:05:04.726 3: openMeteo - cached data "radiationApiData" restored
2026.03.17 08:05:04.726 3: openMeteo - cached data "statusApiData" restored
2026.03.17 08:05:04.727 3: openMeteo - cached data "weatherApiData" restored
2026.03.17 08:05:04.837 3: openMeteo - cached data "aiTrainedData" restored
2026.03.17 08:05:04.870 3: openMeteo - cached data "aiRawData" restored
2026.03.17 08:05:04.878 3: openMeteo - cached data "NeuralNetwork" restored
2026.03.17 08:05:04.891 3: httpapi: port 8088 opened
2026.03.17 08:05:04.891 2: HTTPAPI httpapi initialized
...


[300P]

neu gestartet nach dem Stundenwechsel:

Fehler ist "weg"

Code Auswählen Erweitern

026.03.17 08:14:52 1: MB_CFG_SBS25: loading config from cfg file
2026.03.17 08:14:57 1: Zisterne: loading config from cfg file
2026.03.17 08:15:15 1: Including ./log/fhem.save

Dankeschön !!!

[Parallix]

Bezüglich Battery_OptimumTargetSoC_XX habe ich im Wiki noch den erläuternden Satz hinterlegt der die Funktion dieses Readings gut zusammenfasst:


🎯 Kurzfazit: Was beschreibt Battery_OptimumTargetSoC_XX?

Battery_OptimumTargetSoC_XX definiert den optimalen Ziel‑SoC, den die Batterie erreichen bzw. nicht unterschreiten sollte, um prognostizierte PV‑Überschüsse aufzunehmen, ausreichende Reserven zu halten und die erforderlichen Pflegezyklen zu erfüllen.

In der Beschreibung würde ich "optimalen Ziel-SoC" in "gewünschten Ziel-SoC" ändern, da es eigentlich keinen optimale SoC gibt. Selbst die oft zu lesende Behauptung, ein geringer SoC wäre für die Zellen besser, kann man so nicht stehen lassen, insb. nicht bei LiFePO4-Zellen.

Entscheidend sind die Zellspannungen. Solange keine Zelle oben und unten an die - je nach Zell-Technologie (z.B. LiFePO4) unterschiedliche - untere und obere Grenze kommt und erst recht nicht zu lange an der Grenze verbleibt, spielt der SoC zumindest in Hinblick auf die zu erwartende Zelllebensdauer keine Rolle.

[DS_Starter]

Moin Parallix,

der Begriff "optimalen Ziel-SoC" hat in diesem Kontext keinen Bezug zu der Batterie Physik (falls dies so verstanden wird), sondern ist abgestellt auf die Ziele der Steuerung durch das Modul.
Insofern passt das auch, ich kann das Fazit aber noch dahingehend schärfen um Mißverständnisse zu vermeiden. 

[Parallix]

Moin Parallix,

der Begriff "optimalen Ziel-SoC" hat in diesem Kontext keinen Bezug zu der Batterie Physik (falls dies so verstanden wird), sondern ist abgestellt auf die Ziele der Steuerung durch das Modul.
Insofern passt das auch, ich kann das Fazit aber noch dahingehend schärfen um Mißverständnisse zu vermeiden. 

Kann mir vorstellen, dass eine entsprechende Schärfung künftige Fragen reduzieren könnte.

Edit: Andererseits stellt sich mir aber die Frage, warum SF - wenn's nur um die SF-Steuerung angeht -  nicht selber Battery_OptimumTargetSoC_XX vorgibt. Wahrscheinlich habe ich einfach ein Problem mit dem Wort "optimal". Seht es mir nach

[DS_Starter]

Edit: Andererseits stellt sich mir aber die Frage, warum SF - wenn's nur um die SF-Steuerung angeht -  nicht selber Battery_OptimumTargetSoC_XX vorgibt.

SF gibt ja Battery_OptimumTargetSoC_XX vor. Das Reading enthält das Ergebnis diverser Kalkulationen im Modul.
Es geht nur um das Verständis im Wiki was Battery_OptimumTargetSoC_XX ist und bedeutet.

[Parallix]

Edit: Andererseits stellt sich mir aber die Frage, warum SF - wenn's nur um die SF-Steuerung angeht -  nicht selber Battery_OptimumTargetSoC_XX vorgibt.

SF gibt ja Battery_OptimumTargetSoC_XX vor. Das Reading enthält das Ergebnis diverser Kalkulationen im Modul.
Es geht nur um das Verständis im Wiki was Battery_OptimumTargetSoC_XX ist und bedeutet.

Du hast Recht! Hatte mich schlicht sehr ungünstig ausgedrückt und meinte folgendes:

Andererseits stellt sich mir aber die Frage in Hinblick auf eine Nachschärfung im Wiki, warum SF - da es um die SF-interne Steuerung geht - dynamisch sich verändernde Battery_OptimumTargetSoC_XX vorgibt. Wenn klarer würde, warum der jeweilig via Reading ermittelbare Battery_OptimumTargetSoC_XX optimal ist, würde wahrscheinlich einiges klarer.

[DS_Starter]

Naja, wenn man sich den ganzen Wiki-Abschnitt und ggf. nachfolgende durchgelesen hat, sollte der Zusammenhang eigentlich schon klar geworden sein.

[DS_Starter]

Die Bias- und Drift-Rekalibrierung scheint mittlerweile ganz ordentlich zu funktionieren.
Ich habe in der Statusübersicht noch einen Eintrag mit dem Zeitpunkt der letzten Rekalibrierung hinzugefügt.

Unter diesen Gesichtspunkten kann man z.B. ein Retraining mit aiConTrainStart=21:3 stellen um nur alle 21 Tage neu zu trainieren.
Das muß man ausprobieren welches ein günstiges Intervall dafür ist.

Update liegt im contrib.

[seayak]

Ich habe das userreading eingerichtet, es triggert aber leider nicht.

Code Auswählen Erweitern

attr zendure_bridge_b0b21c980b18 userReadings Solar_Summe_Wh:solar_input_power.* integral { ReadingsVal ($name, "solar_input_power", 0) / 3600 }
event_on_change_reading steht auf .*

Hi Denis,

Deine Thematik läßt mir einfach keine Ruhe. Deine Definition sollte stimmen, kannst Du auch mit den Wiki Einträgen zu "userReadings" und der möglichen Summenfunktion gern im Wiki nachlesen.

Ich sehe aber nicht die Quelle Deines "fütternden" userReadings mit der PV Leistungsangabe und kenne auch Deine Anlage nicht im Detail. Bei mir und einer anderen, von mir betreuten Anlage werden die Daten der PV Wechselrichter hinsichtlich PV Leistung mit dem Modbus TCP Modul vom FHEM im Intervall von 5 Sekunden von den Geräten geliefert und daraus dann das summierende Userreading in FHEM gebaut. Die Anzahl der Readings, die ich auf diese Art vom Wechselrichter hole, sind extrem minimalsistisch und auf die Notwendigkeit zugeschnitten, um FHEM nicht in Lastzsenarien zu bringen, obwohl ich keine RPi`s nutze, sondern nur Headlsess Thin Clients aus der Refurbished Kiste... Auch das Attribut "event_on_change_reading" steht auf .* bei diesen Wechselrichtern.

Bitte betrachte Dein Szenario hinsichtlich des Readings mit der aufzusummierenden PV Leistung noch einmal im Detail. Es müssen hier Daten angeliefert werden, damit etwas aufsummiert werden kann. Und wie Heiko dann auch schon sagte, das SF Modul liest dann nur noch das Reading im definierten Interval aus und verarbeitet es dann.

Ich wünsche Dir weiterhin viel Erfolg!

Peter