76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[peterboeckmann]

Hallo Heiko,

wäre dann folgendes auch denkbar, damit der Skimmer bis max. 19 Uhr läuft?

Code Auswählen Erweitern

attr SolarForecast consumer16 HM_56E0D2_Sw_02
type=other
power=40
on=on
off=off
auto=Automatik
icon=debian
mode=can
mintime=570
interruptable=1
notbefore=09:30
locktime=300:300
viele Grüße,
Peter

[DS_Starter]

Das erfüllt deine Bedingung nicht unbedingt.
notbefore=09:30 bedeutet auch eine mögliche Einplanung erst ab 11:00 je nach Lage.

Wenn 19:00 ein fester Anschlag ist, dann stelle ihn ein wie vorhin gezeigt und setze noch den Schüssel swoffcond. Ist die Bedingung erfüllt, stoppt der Consumer vorfristig.
Ich kann dir noch einen Vorschlag machen wie er definiert werden könnte, aber erst heute Abend.

LG

[DS_Starter]

@Peter, ich hatte doch schon etwas Zeit. Hier wäre ein Ansatz.

Wir brauchen zuerst ein Steuerreading für den Abbruch des Consumers.
Diesen kleinen Code fügst du in Attr ctrlUserExitFn ein:

Code Auswählen Erweitern

{
  my $dt   = timestringsFromOffset ($name, time, 0);
  my $hour = int $dt->{hour};
  my $val  = 0;
 
  if ($hour >= 19) { $val = 1;}
 
  storeReading ('userFn_Stop19', $val);
}

In deinem SF-Device wird damit ein Reading userFn_Stop19 angelegt mit dem Inhalt "0" vor 19:00 und mit "1" ab 19:00 bis 24:00.
timestringsFromOffset ist eine Funktion in SF, die hier die aktuelle Stunde (nicht Stunde des Tages) zurückgibt, also 16 wenn es gerade 16:25 ist.

Jetzt setzt du in dem Consumer zusätzlich diesen Schlüssel:

 

Code Auswählen Erweitern

swoffcond=SF-Device:userFn_Stop19:1
 
SF-Device ist der Name deines SF-Devices.
Sobald das geprüfte Reading userFn_Stop19 den Wert "1" enthält, stoppt der Zyklus des Consumers unabhängig wie lange er ohne diese Stopp-Condition noch hätte laufen sollen.
Das kann man auch noch mit Minuten verfeinern, nur erstmal das Prinzip.
Damit hast du immer ein festes Ende.

[peterboeckmann]

Hallo Heiko,

dankeschön dafür!

Noch eine Rückfrage: notafter kann dann raus, notbefore bleibt aber drin?

Code Auswählen Erweitern

HM_56E0D2_Sw_02
type=other
power=40
on=on
off=off
auto=Automatik
icon=debian
mode=can
mintime=SunPath:60:-60
interruptable=1
notbefore=09:30
locktime=300:300
swoffcond=SolarForecast:userFn_Stop19:1
Oder soll notafter wie vorher auf 19:00 stehen?

Viele Grüße,
Peter

[DS_Starter]

Noch eine Rückfrage: notafter kann dann raus, notbefore bleibt aber drin?

Das kommt darauf an, ob du akzeptieren möchtest, dass dein Consumer z.B. auch erst ab 14:00 eingeplant und somit gestartet werden kann.
Hier geht es immer um die Einplanung, notbefore sagt "plane den Consumer nicht vor X ein" und notafter sagt "plane den Consumer aber nicht nach Y ein".
Mit anderen Worten ... ich will nicht dass der Consumer vor X startet, aber ich will auch nicht dass der Zyklus des Consumers (und damit der erste Start) nach Y losgeht.

Wenn du möchtest das der Start des Consumers täglich zwischen 09:30 und 11:00 eingeplant wird, dann setze beide Parameter, z.B. notbefore=09:30 und notafter=11. 

[peterboeckmann]

Wenn du möchtest das der Start des Consumers täglich zwischen 09:30 und 11:00 eingeplant wird, dann setze beide Parameter, z.B. notbefore=09:30 und notafter=11. 

Ich habe notafter=19:00 wieder mit reingenommen.

Danke nochmal!

Viele Grüße,
Peter

[300P]

Hallo Heiko,

hab erneut mit der gleiche Konfiguration einmal shutdown / restart von FHEM durchgeführt.

Fehlermeldung vorhanden ☹️

Code Auswählen Erweitern


2026.05.20 14:35:01 1: MB_CFG_SBS25: loading config from cfg file
2026.05.20 14:35:05 1: Zisterne: loading config from cfg file
2026.05.20 14:35:23 1: Including ./log/fhem.save
2026.05.20 14:35:26 1: PERL WARNING: Argument "initialized" isn't numeric in numeric gt (>) at (eval 2249) line 1.
2026.05.20 14:35:26 0: Featurelevel: 6.4
2026.05.20 14:35:26 0: Server started with 443 defined entities (fhem.pl:30992/2026-03-21 perl:5.036000 os:linux user:fhem pid:2041621)
2026.05.20 14:47:37 2: AttrTemplates: got 272 entries
2026.05.20 14:47:37 1: PERL WARNING: Use of uninitialized value $cakeyval in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 21034.
2026.05.20 14:47:4


Dann einmal ohne den Eintrag für das Drift-Reading

->>> kein Hinweis zu SF $cakeyval vorhanden
->>> Nur Speedwiremeldungen

Code Auswählen Erweitern


05.20 14:59:38 0: Server started with 443 defined entities (fhem.pl:30992/2026-03-21 perl:5.036000 os:linux user:fhem pid:2044771)
2026.05.20 15:00:15 1: Forecast DEBUG> start add AI raw data for hour: 15
2026.05.20 15:00:15 1: Forecast DEBUG> AI raw add - 1 entities added to raw data pool (set verbose 4 for output more detail)
2026.05.20 15:00:15 1: Forecast DEBUG> AI raw data saved into file: ./FHEM/FhemUtils/AIraw_SolarForecast_Forecast
2026.05.20 15:00:16 1: Forecast DEBUG> DRIFT SAFETY [con]: block=none
  -- RMSE Analysis --
     rmse_rel_ratio=2.767 | dynamic_limit=4.603 | margin=1.836 ok
     Limit Composition: base=4.0 | peak_part=0.049 (peak_ratio=0.049) | sem_part=0.323 (sem_ratio=0.756) | var_part=0.231 (slope_var=0.46148)
  -- Slope Analysis --
     slope_live=0.619 | slope_drift=0.809 | slope_rel_drift=0.191 | slope_var=0.46148
     slope_var_limit=14.40208 | var_ratio=0.03 ok
  -- Bias Analysis --
     bias_live=783.0 | bias_limit=1015.2 | bias_ratio=0.77 ok
     quant30=846.0 | quant90=2215.0 | median_load=848.0
  -- Context --
     drift_score=1.390 | bias_drift_norm=1.125 | bias_var_norm=0.340
     peak_ratio=0.049 | sem_ratio=0.756
2026.05.20 15:00:16 1: Forecast DEBUG> DRIFT [con]: Flag=mild | WindowSize=96 | Block=0 | SlopeLive=0.619 | DriftSlope=0.809 | BiasLive=782.99 | DriftBias=407.76 | RMSErelLive=83.0 | RMSErelRatio=2.77 | BiasVarNorm=0.34 | DriftIndex=1.54 | DriftScore=1.39 | Zone3Hours=4 | Zone3Reset=0 | Hist=[mild,mild,mild,mild,mild,low,low,low,low,low,mild,low,low,low,low,mild,mild,mild] | Retrain=none (-)
2026.05.20 15:00:16 1: Forecast DEBUG> AI FANN drift data type 'con' successfully written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_Forecast
2026.05.20 15:00:18 1: SMAInverter SBS25_2 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2026.05.20 15:00:18 1: SMAInverter SB30 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2026.05.20 15:00:18 1: SMAInverter SB40 -> BlockingCall SMAInverter_getstatusDoParse Timeout: process terminated
2026.05.20 15:00:19 1: SMAEM SMA_Energymeter -> BlockingCall SMAEM_DoParse Timeout: process terminated
2026.05.20 15:00:19 1: PERL WARNING: Argument "Timeout: process terminated" isn't numeric in numeric gt (>) at (eval 5974) line 1.


Meine Vermutung ist das zu dem Zeitpunkt (vor dem Ende des ersten SF-Zyklus/Durchlauf) der Wert dann noch nicht definiert ist und daher der Pearl-Hinweis kommt 🤔

[dieter114]

Warum hast du alles gelöscht?
Ich meine das ist ja nicht schlimm, man muß jetzt nur etwas warten. 

weil alle Daten total fehlerbehaftet und damit unsinnig waren aber
äh . soll ich jetzt 84 Tage warten eh ein neuer Durchlauf starten kann?
Nicht dein Ernst - oder....
Das würde ja bedeuten das Jeder der das Modul erstmalig neu in sein System integriert 84 Tage auf einen Teil der Funktion warten muss.

Grüße WDS

[DS_Starter]

weil alle Daten total fehlerbehaftet und damit unsinnig waren aber
äh . soll ich jetzt 84 Tage warten eh ein neuer Durchlauf starten kann?
Nicht dein Ernst - oder....
Das würde ja bedeuten das Jeder der das Modul erstmalig neu in sein System integriert 84 Tage auf einen Teil der Funktion warten muss.

Das ist kein böser Wille von mir Wolfdieter. Aber ein neuronales Netz braucht für ein Training nunmal Trainingsdaten.
Woher würdest du die denn nehmen wenn du noch keine hast oder sie löscht? Kannst du mir das sagen?
Wenn du eine Lösung hast nehme ich sie gerne entgegen.

[DS_Starter]

Du hast allerdings eine Lösungsmöglichkeit. Du kannst dir deine Daten aus einer Sicherung wiederherstellen und einlesen.
Wenn das gemacht ist, löscht du die Daten aber nicht komplett, sondern lässt die letzten 3 Monate stehen.
Wie das geht steht im Wiki beschrieben.
Du brauchst aber nur die Datei AIraw_SolarForecast_<name> wieder aus einem Backup holen.

[dieter114]

Ok - macht eh keinen Sinn.
Daten die total fehlerhaft sind nützen nicht für ein Restore
nur um schneller zum Ergebnis zu kommen - welches dann wieder falsch ist 
Alles klar - wir warten ab......
LG WDS

[300P]

Er hatte leider leider .... die ganze Zeit falsche fortlaufende Zählerstände bei Einspeisung und bei Bezug beim EM. Dadurch der seltsame Forecast bei CON und bei PV. 😮
Da gab es leider nichts bzw. maximal die letzten 8-10 Tage zu retten nachdem das eindeutig gemerkt und dann korrigiert war.

[300P]

weil alle Daten total fehlerbehaftet und damit unsinnig waren aber
äh . soll ich jetzt 84 Tage warten eh ein neuer Durchlauf starten kann?
Nicht dein Ernst - oder....
Das würde ja bedeuten das Jeder der das Modul erstmalig neu in sein System integriert 84 Tage auf einen Teil der Funktion warten muss.

Grüße WDS

Schalte solange auf den legacy Forecast um - das ist doch auch schon recht zuverlässig !!

[DS_Starter]

In dem KI Popup gibt es jetzt eine Bewertung des Lernverhaltens mit Hinweisen für verbesserte Einstellungen. Im Anhang sieht man zwei Beispiele, ein gutes Lernverhalten und eins mit entsprechenden Hinweisen nach einem schlechten Lernverhalten.

@300P, deine Warnungen kommen vermutlich daher dass eins der anzuzeigenden Readings noch keinen Wert hat und demzufolge undef ist. Ich habe eine Maßnahme eingebaut die in diesem Fall eine Warnung verhindert.

Liegt im Contrib.