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, spielt der SoC zumindest in Hinblick auf die zu erwartende Zelllebensdauer keine Rolle.