76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

aiNeuralNetConState empfiehlt aiConBitFailLimit=0.4

Bist du sicher dass 0.4 und nicht 0.40 empfohlen wurden?
Wenn doch, dann war es ein Artefakt. In der aktuellen Version ist die Empfehlung immer zweistellig nach dem Komma (0.XX).
Ich werde es aber nochmal im Code sicherstellen.

Zu 99% sicher... das neue Training läuft immer noch (seit bald 7h... so lange hat es mit Abstand noch nie gebraucht), drum kann ich nicht nachschauen.

In der aktuellen Version ist die Empfehlung immer zweistellig nach dem Komma (0.XX)

Gelernt wurde noch mit der alten Version, ausgelesen habe ich aber jedenfalls mit der neuen Version.
Unabhängig davon, auch wenn die Empfehlung künftig immer Hundertstel angibt, erschließt sich mir als Mathematiker nicht, warum der Syntax-Check nicht auch Zehntel akzeptiert. Ich hab' grad mal "0.4x" probiert um auszuschließen, dass es nur um die Anzahl an Zeichen ginge, was aber auch nicht akzeptiert wird. Entsprechend läuft da ja ohnehin schon irgendeine Plausibilisierung. Lt. Commandref ist zulässig: "0.05 .. 0.50". Warum also nicht einfach den Schlüssel auslesen und prüfen, ob mathematisch korrekt "0.05 <= Schlüssel <=0.5" erfüllt ist?

[dieter114]

Hallo Heiko,
nur kurze Rückmeldung:
Nachdem ich den Fehler in der Config beseitigt hatte ist die Abweichung soll/ist schon nach einem Tag <8%.
Das sind unglaublich gute Werte.

Und noch ein Hinweis:
Im Grafik Kopfbereich steht rechts "PV Abweichung heute....." und "CO Abweichung fortlaufend...."
Mach doch bitte aus dem CO mal ein CON für Consum...
Das ist nicht so verwirrend wenn jemand das erste Mal draufschaut.

LG WDS

[300P]

@TheTrumpeter

Das wird schon so im Programmcode gemacht:

Code Auswählen Erweitern


aiConBitFailLimit  => { comp => '0\.(0[5-9]|[1-4]\d|50)',                                    act => 0 },



[tomcat.x]

ich hätte mal eine Frage zur Darstellung der Verbrauchswerte; und zwar nicht zur Verbrauchsvorhersage, sondern zur Darstellung des realen Verbrauchs.

Nur weil das so ähnlich ist, wie bei mir bis vor kurzem (bei PV Erzeugung stimmt der Verbrauch nicht mehr): Hast Du mal mit get ... pvHistory für die entsprechende Stunde )oder generell) geprüft, ob alle pvrl01, pvrl02 und pvrl03 plausible Werte haben? Falls wirklich was nicht passt, würde ich bei der Verteilung der PV-Leistung auf pvrl03 tippen.

Ansonsten noch der Verweis zum Wiki, den Heiko mir gegeben hatte:  Verbrauchsermittlung

Viele Grüße
Thomas

[DS_Starter]

Hallo Wolle02,

Das passt mit 397 Wh eigentlich ganz gut.
Warum wird bei den blauen Balken für den realen Verbrauch bei Stunde 12 dann 918 Wh angezeigt?

Jetzt ist die Frage was tatsächlich real war und wann das etotal der beteiligten Geräte upgedated wird.
Das kann man so nicht beantworten. Für ein Debug wäre "collectData" recht sinnvoll.
Man darf auch nicht vergessen, dass die Verlustleistung der Inverter mit eingeht, die bei hohen PV Umsätzen auch erkennbar steigt. Aber das sieht man dann.

Edit: Überschneidung ...jetzt erst den Beitrag von tomcat.x gelesen ...
 

[DS_Starter]

Mach doch bitte aus dem CO mal ein CON für Consum...

Gerne, kein Problem.

[DS_Starter]

Gerade noch gelesen ...

Ich hab' grad mal "0.4x" probiert um auszuschließen, dass es nur um die Anzahl an Zeichen ginge, was aber auch nicht akzeptiert wird.

Also zum Beispiel:

Code Auswählen Erweitern

aiConBitFailLimit=0.44  oder
aiConBitFailLimit=0.40  etc.
wird problemlos akzeptiert.
Geprüft wird mit Regex wie 300P schon geschrieben hat.

[Elektron]

Hallo zusammen,

Zunächst vielen, vielen Dank DS_Starter für das Tolle Modul!!!

Ich habe seit einigen Monaten das Problem, dass mein FHEM immer wieder (unregelmäßig, aber meistens Nachts) blockiert.
Ich stoppe dann den FHEM-Service über die Console und starte ihn neu, danach ist wieder alles gut.

Rudolf gab mit dem Tip zu sehen welches Modul nach dem ,,Abschießen" im Log steht.
Habe ich jetzt mal gemacht und die letzten Minuten stehen nur Einträge aus dem SolarForecast im Log.
Kann es sein, dass das Modul blockiert? Ich verwende SolarForecast schon sehr lange, bisher immer ohne Auffälligkeiten.


Hier der Auszug aus dem Log:
2026.03.22 19:36:31 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:36:33 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:37:04 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:37:35 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:38:06 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:38:08 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:38:39 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:39:10 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:39:39 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:39:41 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:40:12 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:40:42 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:41:11 3: Wechselrichter_getdata return value: There are still path commands in the action queue
2026.03.22 19:41:13 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:41:44 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings
2026.03.22 19:42:15 3: SolarPrognose_getdata return value: Data cycle triggered, watch readings

Vielen Dank und Grüße Michael

[DS_Starter]

Hallo zusammen,

ich habe mir mit dem Wissen vorangegangener Diskussionen weitere Gedanken zur BEV-Integration gemacht (ist nicht in Vergessenheit geraten) und mit Hilfe einer leistungsfähigen KI ein Pflichtenheft zur BEV Einbindung im Kontext der vorhandenen Consumer- und AI::FANN Verbrauchvorhersage erstellt.

Es ist hier angehängt und interessierte User bitte ich einen Blick darauf zu werfen und ggf. Ideen/Ergänzungen zu geben.

LG,
Heiko

[DS_Starter]

Hallo Michael,

man soll zwar niemals nie sagen, doch ich glaube nicht daran dass SF der unmittelbare Verursacher ist.
Alle API-Abfragen sind non-Blocking ausgeführt und die Geräteabfragen / Datensammlungen werden durch Auslesen von Readings realisiert und nicht durch die direkte Geräteabfrage. Das ist Aufgabe der Gerätemodule.

Problematisch können Schaltvorgänge von Verbrauchern sein, was aber hier nicht der Fall zu sein scheint.

Die Meldung:

Code Auswählen Erweitern

SolarPrognose_getdata return value: Data cycle triggered, watch readings

Ist die Rückmeldung der SF-Zentralschleife, d.h. zu diesem Zeitpunkt ist alles schon durch und erledigt.

Die Meldung:

Code Auswählen Erweitern

Wechselrichter_getdata return value: There are still path commands in the action queue
Ist mir unbekannt und wird nicht von SF generiert. Das muß eine Rückmeldung deines WR Gerätemoduls sein.

Ich schlage dir vor dass du das Special Reading special_runTimeCentralTask aktivierst:

Code Auswählen Erweitern

attr ... ctrlSpecialReadings runTimeCentralTask

Dieses Reading liefert die die Zeit eines gesamten Schleifenzyklus von SF mit allen darin enthaltenen Zeiten für Abfragen etc (im Bereich 0.2-0.3 s bei mir). Die Zeiten kannst du loggen (File oder DB) und später auswerten (SVG, DbRep). Dann siehst du ob und wann evtl. Probleme aufgetreten sind.

Falls du jetzt schon weist dass du irgendwelche Verbraucher aktiv schaltest, wäre das eine heiße Spur wenn die relevanten Gerätemodule beim Schalten des Consumers durch Warten auf das Schaltergebnis blockieren.

Edit: Ich vergaß zu erwähnen, dass SF in regelmäßigen Abständen die modulinternen Datenstrukturen in das Filesystem schreibt. Sollte dein Filesystem Probleme haben, wäre das eine mögliche Blockierungsquelle. 

LG,
Heiko

[DS_Starter]

Zur Vorgehensweise bei Blockierungsanalysen habe ich jetzt einen Abschnitt im Wiki hinterlegt.

LG,
Heiko