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 ...