76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[vneise]

Hallo zusammen,

ich nutze SolarForecast zur Steuerung von zwei Ladegeräten (Akku-Pumpe, Powerbank) und habe daneben mehrere feste Dauerverbraucher (FritzBox, Bad-Lüfter, Kühlschrank etc.) als mode=mustNot registriert, nur zur Verbrauchserfassung.

Beobachtung: Bei der Einplanung von can/must-Consumern scheint der Planstate, also das Zeitfenster für die Aufladung, nur die PV-Erzeugungsprognose gegen die Nennleistung des jeweiligen Consumers abzugleichen – die Grundlast aus den registrierten mustNot-Consumern wird dabei offenbar nicht gegengerechnet.

Konkretes Beispiel (consumer09, Powerbank, 8 W, mode=can):

Code Auswählen Erweitern

attr Balkonkraftwerk consumer09 KU.ShellyPlugSGen3Powerbank
 type=charger on=on off=off swstate=state:on:off
 pcurr=power:W etotal=energy:Wh icon=wallbox
 mode=can power=8 mintime=120 interruptable=1

Am 06.10. wurde die Powerbank zunächst für 08:00–10:00 Uhr eingeplant:

Code Auswählen Erweitern

consumer09_planned_start: 06.10.2026 08:00:00
consumer09_planned_stop:  06.10.2026 10:00:00

Zu diesem Zeitpunkt lag die PV-Erzeugungsprognose laut NextHours_Sum01_PVforecast bei ca. 25 W – meine registrierte Grundlast (FritzBox 6 W, Bad-Lüfter 10 W, weitere Standby-Lasten) liegt aber schon allein bei ca. 28–30 W, netto also im Minus. Interessant: Es gibt mit NextHours_SumNN_ConsumptionForecast sogar ein Reading, das genau diese Information (prognostizierter Gesamtverbrauch der nächsten Stunden) liefert – es scheint bei der Fensterwahl aber nicht herangezogen zu werden.
Die Powerbank ist zum geplanten Zeitpunkt nicht gestartet, sondern wurde automatisch mehrfach in kleinen Schritten neu geplant:

Code Auswählen Erweitern

planstate => replanned: 2026-10-06 08:29:08 - 2026-10-06 10:29:08

und ist letztlich erst um 10:14:40 Uhr tatsächlich angelaufen, als real genug Überschuss vorhanden war:

Code Auswählen Erweitern

consumer09
name='Powerbank Ladestation' state='on' mode='can' planningstate='started'
consumer09_planned_start: 06.10.2026 10:14:40
consumer09_planned_stop:  06.10.2026 12:14:40
consumer09_currentPower: 7.5 W

Frage: Ist das so gewollt (die Live-Schaltung über swoncond/Current_Surplus als eigentliches Sicherheitsnetz, während die initiale Zeitfensterplanung für die Aufladung bewusst nur auf der reinen PV-Prognose basiert und Grundlast ignoriert), oder ist das ein Bug bzw. eine Optimierungslücke? Falls gewollt: Gibt es einen Schlüssel, mit dem die registrierten mustNot-Consumer (oder NextHours_SumNN_ConsumptionForecast) bei der Fensterwahl berücksichtigt werden können?

Vielen Dank schon mal und viele Grüße

[DS_Starter]

Die erste Zeile kam direkt beim runterfahren von fhem. nach der letzten Logzeil steht fhem wieder.

Hast du die Version aus meinem Contrib eingespielt? Wenn ja, funktioniert mein Abfangen des Fehlers "wrong number of elements in input array, 81 found when 90 were required" noch nicht so wie erwartet.

Wenn das funktioniert, kannst du das Training einfach neu starten bzw. nichts tun weil das Modul dann automatisch auf die Legacy Methode umschaltet.

Wichtig ist das Abfangen des Fehlers der zum Absturz führt.

[DS_Starter]

@vneise, dein Thema schaue ich mir in Ruhe an. Jetzt ist es gerade ungünstig.
(Evtl. kann 300P sich der Sache schonmal annehmen und eruieren    )

[macfly]

Die erste Zeile kam direkt beim runterfahren von fhem. nach der letzten Logzeil steht fhem wieder.

Hast du die Version aus meinem Contrib eingespielt? Wenn ja, funktioniert mein Abfangen des Fehlers "wrong number of elements in input array, 81 found when 90 were required" noch nicht so wie erwartet.

Wenn das funktioniert, kannst du das Training einfach neu starten bzw. nichts tun weil das Modul dann automatisch auf die Legacy Methode umschaltet.

Wichtig ist das Abfangen des Fehlers der zum Absturz führt.

Ja, das war die neue Version.

Ich habe mal aus /opt/fhem/FHEM/FhemUtils alle *SolarForecast* weggeschoben, jetzt startet das Modul.

Wenn du weitere Tests bzgl. Fehlerbehandlung benötigst, kann ich die Dateien dahin zurückschieben und neu testen.

[DS_Starter]

@macfly,

das neue Modul scheint bei dir nicht geladen zu sein, denn die Fehlerzeile in weiterhin 40312 die aber im neuen Modul eine Leerzeile ist.
Checke bitte nochmal dass du wirklich die Datei Rev. 31734 vom 05.10. 17:33 aus meinem contrib geladen hast.

Die relevante Funktion befindet sich nun in Zeile 40407 - 40428.

[macfly]

@macfly,

das neue Modul scheint bei dir nicht geladen zu sein, denn die Fehlerzeile in weiterhin 40312 die aber im neuen Modul eine Leerzeile ist.
Checke bitte nochmal dass du wirklich die Datei Rev. 31734 vom 05.10. 17:33 aus meinem contrib geladen hast.

Die relevante Funktion befindet sich nun in Zeile 40407 - 40428.

hm, über die update-funktion in fhem kam keine Änderung an, ich habe die Datei jetzt direkt aus dem fhem-svn geladen und ausgetauscht.

jetzt steht im Log nach einem neustart (und mit dem alten Daten in /opt/fhem/FHEM/FhemUtils):

Code Auswählen Erweitern

2026.10.06 14:14:54 3: SolarForecast - cached data "Initialize" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "pvHistory" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "pvCircular" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "consumerMaster" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "radiationApiData" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "statusApiData" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "aiTrainedData" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "aiRawData" restored
2026.10.06 14:14:54 3: SolarForecast - cached data "NeuralNetwork" restored for FANN type 'con'
2026.10.06 14:14:54 3: SolarForecast - cached data "Messages" restored
2026.10.06 14:14:57 1: SolarForecast - WARNING - FANN Model 'con' did not return a valid result (input size mismatch: got 81, model requires 90). New training is required.
2026.10.06 14:14:57 3: SolarForecast - new Simple correction factor for hour 14 calculated: 0.88 (old: 0.85)
2026.10.06 14:14:57 3: SolarForecast - new Complex correction factor for hour 14 calculated: 1.40 (old: 1)

scheint also zu gehen.

nur das mit dem update aus fhem wurmt mich etwas.


Danke für deine Hilfe,
Friedhelm

ps: Version jetzt:

Code Auswählen Erweitern

$Id: 76_SolarForecast.pm 31734 2026-10-05 15:33:01Z DS_Starter $

pps: im Check steht jetzt:

Code Auswählen Erweitern

Your local 76_SolarForecast module is modified (2667739 Bytes). The SVN version of FHEM/76_SolarForecast.pm has creation time: 2026-09-28_07:45:04 (2663121 Bytes).
Wie ist denn die korrekte Version, die letzte Version aus git im fhem zu bekommen?

[DS_Starter]

Wie ist denn die korrekte Version, die letzte Version aus git im fhem zu bekommen?

Die letzte offizielle Version von SF bekommst du immer über das ganz normale FHEM-Update jeden Morgen.
Üblicherweise kündige ich es über das SF Hinweissystem (Postkasten im Kopf) an.

Schnelle Fixes, Weiterentwicklungen und Testversionen stelle ich über mein Contrib (Fußtext) zur Verfügung, wie jetzt auch.
Wenn diese Versionen eine gewisse Menge an Changes und Reifegrad erreicht haben, checke ich die Version ein + Hinweis im Hinweissystem von SF.

So ist der übliche Weg.

Edit: Du behältst also zunächst die gefixte Version. Das kommende Update enthält dann diesen Fix und du kannst DANN SF auch wieder updaten. Die enthaltenen Fixes kommuniziere ich überlicherweise auch. So weiß jeder ob seine Problemlösung mit enthalten ist.

LG,
Heiko

[macfly]

Wie ist denn die korrekte Version, die letzte Version aus git im fhem zu bekommen?

Die letzte offizielle Version von SF bekommst du immer über das ganz normale FHEM-Update jeden Morgen.
Üblicherweise kündige ich es über das SF Hinweissystem (Postkasten im Kopf) an.

Schnelle Fixes, Weiterentwicklungen und Testversionen stelle ich über mein Contrib (Fußtext) zur Verfügung, wie jetzt auch.

   Ja, Danke, deinen Fußtext hätte ich auch mal lesen können.

Vielen Dank!

[300P]

@vneise, dein Thema schaue ich mir in Ruhe an. Jetzt ist es gerade ungünstig.
(Evtl. kann 300P sich der Sache schonmal annehmen und eruieren    )

Bin leider diese und nächste Woche sehr weit weg von Zuhause 🫣 und nur mit dem Handy ab und an in einem freien WLan......- ansonsten gerne ...

[DS_Starter]

@vneise,

Frage: Ist das so gewollt (die Live-Schaltung über swoncond/Current_Surplus als eigentliches Sicherheitsnetz, während die initiale Zeitfensterplanung für die Aufladung bewusst nur auf der reinen PV-Prognose basiert und Grundlast ignoriert), oder ist das ein Bug bzw. eine Optimierungslücke? Falls gewollt: Gibt es einen Schlüssel, mit dem die registrierten mustNot-Consumer (oder NextHours_SumNN_ConsumptionForecast) bei der Fensterwahl berücksichtigt werden können?

Die Einplanung erfolgt im default auf der Grundlage der PV-Prognose.
Es gibt den Schlüssel plantControl->consForecastInPlanning der gesetzt werden kann um auch die Verbrauchsprognose bei der Planung mit einzubeziehen.
Bei der Einplanung werden bestimmte Rahmenparameter wie der aufgezeichnete tatsächliche Verbrauch des Verbrauchers in den Laufstunden, der Modus (can/must), der Consumer-Schlüssel exconfc etc. berücksichtigt. Sollte bei Erreichen des Einplanungsfensters der Start des Consumers nicht erfolgen weil die Voraussetzung dafür doch nicht erfüllt sind, erfolgt eine dynamische Neueinplanung wie du bereits festgestellt hast. Dieser Vorgang ist ein komplexer und hoch dynamischer Prozess.
Mit ctrlDebug=consumerPlanning,epiecesCalc,consumerSwitchingXX stehen Werkzeuge zur Info und Analyse zur Verfügung.

LG,
Heiko

[vneise]

Hallo Heiko,

vielen Dank für die schnelle und hilfreiche Antwort!

Ich habe plantControl->consForecastInPlanning=1 gesetzt. Die Planung verhält sich seitdem anders: Statt wie vorher auf 08:00 Uhr mit anschließender mehrfacher Neueinplanung liegt das Fenster jetzt direkt in einer sinnvollen Zeit. Heute ist es stark bewölkt bis regnerisch, und die Powerbank (mode=can) wurde bereits am Vormittag auf den Folgetag eingeplant:

Code Auswählen Erweitern

consumer09 name='Powerbank Ladestation' state='off' mode='can' planningstate='planned'
consumer09_planned_start: 09.10.2026 12:00:00
consumer09_planned_stop:  09.10.2026 16:00:00

Das passt für mich zur Logik, da die Netto-Bilanz (PV-Prognose minus Verbrauchsprognose) heute offenbar nirgends ausreicht. Ich werde in den nächsten Tagen beobachten, wie sich das an sonnigen Tagen verhält.

Noch eine Vermutung: Mir ist aufgefallen, dass NextHours_SumNN_ConsumptionForecast die Verbrauchsspitzen (Waschmaschine, Geschirrspüler) mit enthält (z. B. 662 Wh für 4 Stunden, also im Schnitt ca. 165 W), während meine echte Grundlast nur bei ca. 30 W liegt. Vermutlich ist die Planung mit consForecastInPlanning=1 bewusst eher konservativ und verbessert sich durch das Lernen über die Tage. Ist meine Vermutung richtig?

Danke dir und viele Grüße

[DS_Starter]

@all,

die v2.10.6 ist eingecheckt und ist morgen fürh im Update enthalten.

Hier das Changelog:

- **Neu:**
  * _calcDataEveryFullHour: Einbau einmalige Größenausgabe der internen Datenstrukturen (auskommentiert)
  * Reading Battery_OptimumBaseSoC_XX parallel zum bestehenden Reading Battery_ChargeOptTargetPower_XX welches abgelöst werden soll (Forum: https://forum.fhem.de/index.php?msg=1369429)
  * sub mallocTrim -> Rückgabe aller freigegebenen Arenen
  * Einbindung mallocTrim in centralTask Nachtverarbeitung Task 4

- **Change:**
  * __delObsoleteAPIData: Speicheroptimierung der Funktion
  * Nachtverarbeitung: aiDelRawData aus Task 6 nach Task 4 verschoben
  * Wrapper AIF_modelRun gehärtet und Fehlerausgabe in _aiFannPredict verbessert (Forum: https://forum.fhem.de/index.php?msg=1369865)
  * Änderungen von MCache_get, MCache_set für Robustheit und echtes FIFO, Anpassung der Aufrufe von MCache_get
  * Parametrisierung des Aufrufs HttpUtils_NonblockingGet sowie return Funktion geändert ($caller)
  * Änderung der Anzeigereihenfolge im Mitteilungssystem: neueste Mitteilungen stehen ganz oben


LG,
Heiko

[DS_Starter]

Code Auswählen Erweitern

Mir ist aufgefallen, dass NextHours_SumNN_ConsumptionForecast die Verbrauchsspitzen (Waschmaschine, Geschirrspüler) mit enthält (z. B. 662 Wh für 4 Stunden, also im Schnitt ca. 165 W), während meine echte Grundlast nur bei ca. 30 W liegt. Vermutlich ist die Planung mit consForecastInPlanning=1 bewusst eher konservativ und verbessert sich durch das Lernen über die Tage. Ist meine Vermutung richtig?In der SumNN Verbrauchsvorhersage steckt alles drin was das Modul anhand der "Erfahrungen" und evtl. steuernden Parameter (durch User gesetzt) in der Lage ist vorherzusehen. Auch die KI-Prognose oder eine eingestellte Mischprognose (KI + Legacy) ist verankert.

Die Verbrauchsprognose ist ebenfalls ein sehr komplexes Thema. Die erreichte Abweichung der CON-Prognose liegt aktuell typisch  bei < +-10%, oft auch im Bereich +-0.x%. Das Ergebnis hängt stark vom Verbrauchslastgang und der Dynamik des Haushalts ab und natürlich von der Menge der gesammelten Daten über die Zeit um bessere Schätzungen zu ermöglichen.

[Pete]

Hallo zusammen,

mir ist bei SolarForecast Folgendes aufgefallen: Wenn FHEM (bzw. der Container) mitten in einer Stunde neu startet, hat das Modul danach keinen Stunden-Startwert mehr für Zähler wie GridConsumption und BatIn/BatOut. In den Readings steht dann der komplette Lifetime-Zählerstand als Stundenwert.

Beispiele aus meinem System:

Today_Hour16_GridConsumption = 16065764 Wh (Neustart um 16:xx)
Today_Hour10_BatIn_01 = 68524 Wh und BatOut = 60546 Wh (Neustart um 09:50)

Im Log kommen dann Meldungen wie "higher than limit of 7500 Wh" bzw. "negative ... not saved". Die Plausibilitätsprüfung verwirft den Wert also zu Recht für die Verbrauchs-KI, aber der Unsinnswert bleibt bis Mitternacht im Reading stehen. Damit rechnen alle Konsumenten dieser Readings weiter, zum Beispiel Dashboards, die Stundenwerte summieren. Bei mir ergab das "Netzbezug heute 6200 €".

Meine Fragen und Vorschläge:

Ist das bekannt oder gewollt? Gibt es einen Weg, die Stunden-Startwerte über den Neustart hinweg zu erhalten, etwa durch Persistenz im Cache?
Falls nicht: Könnte das Modul die Stundenwerte nach einem Neustart als ungültig markieren, also leeres Reading oder -, statt den Lifetime-Zähler einzutragen? Oder die Plausibilitätsprüfung auch auf das Reading selbst anwenden und nicht nur auf die Weitergabe an die KI?

Als Workaround habe ich im Dashboard eine Obergrenze (20 kWh pro Stunde) eingebaut, die Werte darüber ignoriert. Das ist aber nur ein Pflaster.

SolarForecast-Version und get SolarForecast ...-Ausgaben liefere ich gern nach.

Danke und Gruß
Jens

[TheTrumpeter]

Today_Hour16_GridConsumption = 16065764 Wh (Neustart um 16:xx)
Today_Hour10_BatIn_01 = 68524 Wh und BatOut = 60546 Wh (Neustart um 09:50)

Also ich habe heute um 09:52 nach dem Update neu gestartet (mittels shutdown restart), bei mir sieht es so aus:

Code Auswählen Erweitern

Today_Hour10_GridConsumption 0 Wh
Today_Hour10_GridFeedIn 4522 Wh
Today_Hour10_PVforecast 7410 Wh
Today_Hour10_PVreal 6540 Wh